There are a few options.

1.      Most likely it will leak information (STUN, NAT-PMP, etc.).
2.      You could look obvious signs of NATted traffic. (e.g. re-use of the same
        source port number to different destinations from the box, etc.)
3.      You can look at the TTL or Hop-Count on packets coming out of the box.
        Most NAT routers (I believe DD-WRT included, IIRC) do still decrement
        the TTL/Hop-Count (v4/v6) when passing the packet.
4.      NMAP the device… DD-WRT will usually look strikingly different from most
        desktop hosts.

I’m sure there are other ways, but those are the first 4 that spring to mind. 
Each
could be defeated by a particularly careful/clever implementer, but in an 
enterprise,
usually it makes little sense to go to that much trouble to violate policy. 
Universities
are an exception as that’s a whole different set of equations on risk/benefit.

Owen


> On Jun 8, 2018, at 10:32 , David Hubbard <dhubb...@dino.hostasaurus.com> 
> wrote:
> 
> This thread has piqued my curiosity on whether there'd be a way to detect a 
> rogue access point, or proxy server with an inside and outside interface?  
> Let's just say 802.1x is in place too to make it more interesting.  For 
> example, could employee X, who doesn't want their department to be back 
> billed for more switch ports, go and get some reasonable wifi router, throw 
> DD-WRT on it, and set up 802.1x client auth to the physical network using 
> their credentials?  They then let their staff wifi into it and the traffic is 
> NAT'd.  I'm sure anyone in a university setting has encountered this.  
> Obviously policy can forbid, but any way to detect it other than seeing 
> traffic patterns on a port not match historical once the other users have 
> been combined onto it, or those other users' ports go down?
> 
> David
> 
> 
> On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" 
> <nanog-boun...@nanog.org on behalf of m...@beckman.org> wrote:
> 
>    When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which 
> has a Layer-2 collection feature that identifies the number and MACs of 
> devices on any given switch port. We export this list and cull out all the 
> known managed switch links. Anything remaining that has more than one MAC per 
> port is a potential violation that we can readily inspect. It’s not perfect, 
> because an unmanaged switch might only have one device connected, in which 
> case it wont be detected. You can also get false positives from hosts running 
> virtualization, if the v-kernel generates synthetic MAC addresses. But it’s 
> amazing how many times we find unmanaged switches squirreled away under desks 
> or in ceilings.
> 
>     -mel 
> 
>> On Jun 7, 2018, at 4:54 AM, Jason Hellenthal <jhellent...@dataix.net> wrote:
>> 
>> As someone already stated the obvious answers, the slightly more difficult 
>> route to be getting a count of allowed devices and MAC addresses, then 
>> moving forward with something like ansible to poll the count of MAC’s on any 
>> given port ... of number higher than what’s allowed, suspend the port and 
>> send a notification to the appropriate parties.
>> 
>> 
>> All in all though sounds like a really brash thing to do to your network 
>> team and will generally know and have a very good reason for doing so... but 
>> not all situations are created equally so good luck.
>> 
>> 
>> -- 
>> 
>> The fact that there's a highway to Hell but only a stairway to Heaven says a 
>> lot about anticipated traffic volume.
>> 
>>> On Jun 7, 2018, at 03:57, segs <michaelolusegunru...@gmail.com> wrote:
>>> 
>>> Hello All,
>>> 
>>> Please I have a very interesting scenario that I am on the lookout for a
>>> solution for, We have instances where the network team of my company bypass
>>> controls and processes when adding new switches to the network.
>>> 
>>> The right parameters that are required to be configured on the switches
>>> inorder for the NAC solution deployed to have full visibility into end
>>> points that connects to such switches are not usually configured.
>>> 
>>> This poses a problem for the security team as they dont have visibility
>>> into such devices that connect to such switches on the NAC solution, the
>>> network guys usually connect the new switches to the trunk port and they
>>> have access to all VLANs.
>>> 
>>> Is there a solution that can detect new or unmanaged switches on the
>>> network, and block such devices or if there is a solution that block users
>>> that connect to unmanaged switches on the network even if those users have
>>> domain PCs.
>>> 
>>> Anticipating your speedy response.
>>> 
>>> Thank You!
> 
> 

Reply via email to