Application or Software to detect or Block unmanaged swicthes
mel at beckman.org
Fri Jun 8 18:24:06 UTC 2018
Enterprise WiFi systems, such as those by HPE (Aruba) and Cisco, have built-in rogue detection including integrated spectrum analysis. Every AP becomes a spectrum analyzer, so the WiFi controller can detect rogue APs, identify whether or not they’re physically connected to your network, and then even tell you the switch and port they’re plugged into. You can disable that port to kill the rogue’s network access, then follow that cable to the interloper.
We use a 2’ pipe wrench for enforcement :)
> On Jun 8, 2018, at 11:14 AM, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:
> This is one of the reasons why large organizations, such as the ones you
> describe, have both portable spectrum analyzers (covering the 2400 range
> and 5150-5850 MHz 802.11(whatever) bands), and also ability to hunt for MAC
> addresses of wifi devices that don't match known centrally managed APs.
> Even if somebody sets up to not broadcast the SSID, the MAC will still be
> there and can be recognized as an unknown device, then physically
> triangulated upon for its OSI layer 1 location, with RSSI/RSL level and a
> portable spectrum analyzer with directional yagi antenna.
> On Fri, Jun 8, 2018 at 10:32 AM, David Hubbard <
> dhubbard at 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?
>> On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" <
>> nanog-bounces at nanog.org on behalf of mel at 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.
>>> On Jun 7, 2018, at 4:54 AM, Jason Hellenthal <jhellenthal at dataix.net>
>>> 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 <michaelolusegunrufai at gmail.com>
>>>> 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
>>>> inorder for the NAC solution deployed to have full visibility into
>>>> points that connects to such switches are not usually configured.
>>>> This poses a problem for the security team as they dont have
>>>> 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
>>>> 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!
More information about the NANOG