Application or Software to detect or Block unmanaged swicthes

Kasper Adel karim.adel at gmail.com
Fri Jun 8 19:20:57 UTC 2018


How about some scripts around fail2ban, if the same account logs in
multiple times, its banning time.

Kasper

On Friday, June 8, 2018, 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?
>
> David
>
>
> 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.
>
>      -mel
>
>     > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal <jhellenthal at 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 <michaelolusegunrufai at 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!
>
>
>



More information about the NANOG mailing list