I’m a huge fan of deploying “dot1x”. With very little configuration (a Windows NPS server, a little group policy and some access switch commands) you can authenticate every device that connects to your network. Unlike MAC based security, dot1x ensures that your devices must be successfully authenticated by a centralised RADIUS server before they are allowed to communicate on their ports (although usually some traffic is permitted such as LLDP/ CDP). What I’ve found however is that dot1x can lead to a false sense of security!
Not everything supports IEEE802.1x! Anyone who has ever deployed dot1x to any scale will already appreciate this one. This unfortunate truth means that any malicious individual can quickly slip past your protections just by spotting those connections which can’t have dot1x enabled (think printers, wireless access point uplinks and wall boards).
Rogue access points. So you have configured your corporate devices to authenticate with wireless networks based on the AD user account via NPS? Sounds like a fairly routine implementation, no extra credentials for users to worry about and you can assign their VLAN on the fly. What most people don’t configure is the server verification options under the Protected EAP Properties. Without this configuration, anyone can stand up a RADIUS server behind a wireless AP with the same SSID as your corporate LAN and start stealing password hashes! Not only can these hashes (if cracked as they are NETNTLM) give the attacker access to the network but they will probably be able to use them logon to workstations and move laterally through the network.
More info on setting up that attack here.
Mitigation? Ensure you push out Group Policy to inform the PCs to verify the RADIUS server by its certificate and, where possible, authenticate with a certificate or computer password (as these are *dare I say it* uncrackable).
VOIP phones. Most of you who have worked in enterprise will be all to familiar with the setup of a PoE phone sitting on a desk and then a computer piggy backing its connection via effectively an embedded unmanaged switch. If you configure dot1x on the access port upstream of the phone then both devices can be separately authenticated and all is secure, right? Wrong, dot1x works by managing the authentication to the RADIUS server and then authorising the device. Unfortunately, post authentication there is no change made by the client to their traffic, so the switch can only keep a log that it has authenticated the device and presume that if the traffic it receives has the same MAC (and comes in the same port) then it must be the same device. The problem with VOIP phones is we can unplug the PC from the back of the VOIP phone without the uplink access switch port going down. This means if you unplug the PC from the VOIP phone and then plug in another device with a spoofed MAC address, the switch never notices the change.
The mitigation for this attack is to massively reduce the re-authentication period on the access switches. This can be achieved on Cisco devices by issuing the following commands:
Router(config)# dot1x re-authentication Router(config)# dot1x timeout re-authperiod 180
But be warned, if you have a lot of devices authenticating then this could have a huge impact of the switch CPU usage. More troublesome, if your RADIUS server is down for whatever reason (think vmware snapshot or migration) then you will have clients losing connectivity at around 2% of all dot1x devices per second!