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 <[email protected]>
> 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"
> <[email protected] on behalf of [email protected]> 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 <[email protected]> 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 <[email protected]> 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!
>
>
