Procurve 8212 block device mac-address

[bickyz]

Dear all,

We have a core switch (Procurve 8212) and 10+
Is there anyway to block mac-address on the Procurve 8212 ? We have few students with their personal laptop who has been connecting to the network wall port. I cannot use port-security as they are going around the different part of the building and plugin their device to the different ports/switches.

Any help would be much appreciated, thank you.

[parnassus]

Why not disabling that network wall port on its corresponding Switch completely OR enabling its operation only for a single (or multiple) specific MAC Address(es)?

Isn't more simple to allow a known/admitted MAC Address(es) instead of locking down - each time - new (so unknown) rouge ones?

What will happen if - once you discover it - you lock down just single/multiple (rouge Laptop's) MAC Address/Addresses and, on the same network wall port, users instead of a Laptop alternatively place a Wireless AP (impersonating a Laptop) doing NAT?

[Ian Vaughan]

Hello,

I'd second what @parnassus says - it would be easier longer term to concentrate on allowing the "good" hosts rather than trying to deny the "bad" ones. 

It is much easier to centralise your "allowlist" in an Authentication server than try and manage it across a distributed network. 

My approach would be as follows. It is not a "quick win" but it is relatively inexpensive and would be a good investment of your time: 

It is not too difficult to add a "Network Policy server" role to a Windows Server - you may already have one setup for VPN access - and use this as your Network Access enforcement layer. 

The hard work will be in collecting the MAC addresses and adding the devices as AD Users with  MAC:MAC as the UserID:Password combo into AD. Fortunately this can be scripted if you take this route. 

However, I would prefer to convert the domain clients to use dot1x to sign onto the network - this can be done either using the machine Certificate or the user credentials - one or the other is permissable.

If you use the machine Cert you won't have "foreign" non-domain devices on your network. Using Domain credentials would still allow foreign devices but users would need to use their ID/password to access the network so 

Using the MAC address is susceptible to MAC cloning which is really easy on any platform, especially linux, these days. I tend to only use this technique for devices such as phones, printers etc that don't offer a dot1x client or supplicant and don't need internet access. 

Once you have the NPS side of things configured you can look at the clients who may need a Group Policy update to get them to use the dot1x supplicant capability of their network adapter.

 It is then just* a question of bringing the switches into NPS as a "Network Access server" or NAS and configuring the switch to use RADIUS messages to authenticate network access against AD. 

(*) - once you get the first switch configured and accepting secured users onto the network you can add each switch as a NAS in NPS and pretty much duplicate the config on the switch.  

Whether you use MAC or dot1x, either is better than nothing. The biggest benefit is that the intelligence about network access is held centrally and you don't need to manage all those MAC access rules on a per switch basis. The time that you invest will pay you back many times and you will have a super secure network that only the trusted clients should be able to access. 

There are many resources (videos, config guides, walk-throughs) on the web at your fingertips to get you from where you are to where you need to be with the configuration. 

If this kind of network access solution is of interest let us know and we can dig out some further reading for you. 

Not quite what you asked for but sometimes these things don't always look like what you imagined. 

many thanks

Ian 

[Vince-Whirlwind]

While I agree with what's been written above, it can also be entertaining to mess with these students.

Find out what the MAC address is, and then reserve an IP address against that MAC address in DHCP.

Then, setup some special firewall rules for that IP address.

Of course, if you use dot1x, this is all automated for you, but switching on dot1x isn't something that happens overnight, depending on what support you get within the organisation for doinbg the work required to enable it.

I once worked in a big hospital where there was virtually no security over what got connected and whether people even logged into the domain.
I used to have fun on the firewall with people who spent their day surfing - I'd get in in the morning and filter down to their IP address and watch what they were doing online. Every now and then, I'd grab the IP address of whatever website they were visiting and add it to the blocked list on the firewall. I'd repeat this over and over again LOLing to myself at how annoyed they were probably getting.

[parnassus]

Yep, that's an interesting experience...but it's something you can do (and it's funny a lot!) on the Firewall when you have traffic that is traversing it going outside (or to other subnets...if the Firewall manages routes to other Subnets)...when users (students) can just connect to the LAN in dangerous ways (or using unauthorized devices) and they can do that staying local...without necessarily going outside the LAN traversing the Firewall...the "bastion role" is, from the point of view of the Access Layer, a duty of the Switch they're connected to.