Depending on what type of traffic is going over the network, it's often not feasible that an employee brings a wireless router and sets it up into your network. This is because often, they are not or poorly secured and present a backdoor into the network. What can you do to prevent rogue wireless access points being introduced into your network?
asked May 8, 2013 at 12:48
Add a comment
|
11 Answers
Lucas's answer above is a bit of a starting point. There are however two or three other things that must be considered. These end up being somewhat outside the scope of network engineering, but certainly have impacts for network engineering and security so here they go.
You probably want some way of preventing wireless cards in company laptops from being switched into ad hoc mode. Assuming the laptops are running Windows, you probably want to use a GPO to set to infrastructure mode only. For Linux, it is harder to fully restrict, but there are ways to do this too.
Enforcing IPSec is also a good idea, particularly with good key management and trusted enforcement. For example if you can go to X509 certs for key management this can keep unauthorized devices from communicating with the rest of your network directly. Consider key management as a core part of the infrastructure here. If you use a proxy server you may even be able to block unauthorized devices from accessing the internet.
Note the limitations of your efforts. None of these prevents a person from setting up an unsecured wireless access point connected to a USB NIC, for sole purposes of communicating with their computer, especially if the SSID is hidden (i.e. not broadcast).
Not sure how to further contain problems or if further paranoia is well past the point of insufficient returns.....
-
3+1 for disabling Ad-hoc mode, it's easy to miss that your own managed devices can be turned into rogue APs. May 8, 2013 at 14:58
-
2
-
-
I don't think one can run an AP on Windows also. One can on Linux if the wireless card and driver support it though. So that's one more thing on the Linux checklist..... May 20, 2013 at 1:22
-
1@ChrisTravers: Yes you can, works well too. See virtualrouter.codeplex.com, among others– erictSep 5, 2013 at 19:40
First of all you need to build a policy prohibiting introducing network equipment into the network which is not owned by or approved by the company IT department. Next enforce port security so that unknown mac addresses cannot connect to your network.
Third set up a separate wireless network under your control (if you give them what they want they are less likely to introduce rogue AP) (if possible and feasible) for accessing the internet with their (mobile) devices. These access points should be secured with PEAP or similar and preferably run on a separate network.
Last you can also do regular security scans using tools like netstumbler to detect and track rogue access points in your network.
There is also the option to perform IPsec over your network so that in case someone does set up a rogue AP, the exposed "waves" will not be plain readable in case of someone sniffing the wireless network.
answered May 8, 2013 at 12:48
-
2In addition to this, vendors such as Meraki have build in rogue AP detection AND suppression and will actively send disconnects forcing users associated with rogue points to lose connection and re-associate. May 8, 2013 at 12:56
-
@SimonJGreen: This method won't work with 802.11w-capable stations and AP.– BatchyXMay 19, 2013 at 9:15
-
@SimonJGreen bear in mind that the FCC has handed out a big fine to someone who did that. Deliberately messing with other people's wireless comms is not ok. Mar 26, 2016 at 20:10
-
"Third set up a separate wireless network under your control (if you give them what they want they are less likely to introduce rogue AP) (if possible and feasible)" Exactly this. nobody is going into effort and expense of setting up their own AP because they're content with what's already available to them. Fulfill their need correctly, and you won't have to worry about them trying to do it incorrectly. May 28, 2019 at 4:36
All of my experience so far has been with Cisco products so that is all I can really speak to.
The WCS controlled APs (lightweight and normal) have the ability to detect and report when non-trusted SSIDs pop up and how many clients are connected to it. If you have heatmaps set up and a decent number of access points you stand a pretty good chance of being able to figure out where the access point is in proximity to your APs. The only down side to this is that if you are in close proximity to any bars/coffee shops/college dorms/neighborhoods expect to see pages worth of "rogue" SSIDs that change as frequently as people move.
The WCS also has the ability to do some switchport tracing and alert you if rogues are plugged into your network. I have yet to have much luck getting this to work. I honestly haven't had a whole lot of time to play with it. By default, at least on my network, there seem to be quite a few false-positives with the way the trace works. Without looking for sure, I believe it only looks at OUI of the MAC and if it matches then you get an alert about a rogue on the network.
Lastly, the WCS also has the ability to contain rouge APs/SSIDs. It does with by using deauth and disassociate messages to any clients that are connected to that AP.
-
2+1 for WCS rogue detection. I've done some work with Ruckus, Aerohive and Meraki, and each vendor has rogue detection in place. It's especially important to note that many of these will also recognize a rogue device that is also on the wire, which are the ones you want to address first. May 9, 2013 at 14:59
-
2Keep in mind the legal hot water you can find yourself in if you enable that AP containment on WCS/WLC unless you own a large enough campus and can legally show no other APs from neighboring companies could be there and you're only containing APs brought into your environment that would have no other way of reaching there. Jun 1, 2013 at 18:18
-
AP containment mode in the WLC does work quite well. I've done it on a few access points for fun in the workplace and I was literally sitting right next to the rogue ap with my laptop (like 10cm) away and I was unable to join the network. A consumer rogue ap I tried it with couldn't even display it's ssid. If I recall it rebooted too after a few minutes– knotsehJun 5, 2013 at 4:33
From a monitoring standpoint, you could run a tool like NetDisco to find switchports with more MAC addresses connected than you would expect. It wouldn't automatically prevent a rogue WAP from being introduced to the network, but it would let you find one after the fact.
If the equipment connected to your switchports can be expected to remain static, MAC address limiting (with violations configured to administratively down the switchport) could prevent any rogue device (not just WAPs) from being connected.
-
1
Only if the AP is in bridging mode, can you catch it with port security.
Limiting the number of MAC addresses will not help, in the event the rogue AP is also configured as a "Wireless Router".
DHCP snooping is helpful, in that it will catch the Wireless AP, connected in backward, i.e., if the LAN port of the rogue devices that has DHCP enabled is connected to your network, DHCP snooping will drop the traffic.
With minimal budget, DHCP snooping is my only option, I just wait until a user is dumb enough to plug their AP in backwards ... then I go hunting :)
Personally, if the network is for the most part an all Cisco shop, meaning at least your access layer is setup with Cisco switches; I would look at port security and DHCP Snooping as a way to guard against this type of issue. Setting a max of 1 MAC address on all Access ports would be extreme but would ensure that only 1 device could show up on a switchport at a time. I would also set the port to shutdown if more than 1 MAC shows up. If you decide to allow more than 1 MAC, DHCP snooping would help as most consumer grade Wireless Routers introduce DHCP in the local subnet when the end user plugs the device into the switchport. At that point port security would shut the switchport down once DHCP snooping detects that the Access Point is offering DHCP.
-
a) dhcp snooping will only catch them if they plug the lan side of the router running dhcp into the network. and b) dhcp snooping won't shut down the port; it simply drops dhcp server traffic on untrusted ports. (I've never had a port shut down by dhcp snooping)– RickyJun 4, 2013 at 19:13
-
You're right, DHCP Snooping will only catch them if they plug the lan side of the router into the network. I have seen end users do this. Now what I did not say was DHCP Snooping would shut the port down, I did say that Port Security would shut it down. Jun 4, 2013 at 19:18
-
You said "point port security would shut the switchport down once DHCP snooping detects ..." DHCP snooping will simply stop the answers from entering the network, and possibly disrupting normal operations (read: rogue dhcp server) It's port security's MAC limit that'll kill the port once more than one device is seen on the port. It's most likely a DHCP DISCOVER broadcast that'll trigger it, but that's a client op that snooping will not block. The device will get an address from the AP, and try to go on the net...– RickyJun 4, 2013 at 19:34
-
Ok I stand corrected. Need to think before writing in the future. Unfortunately I have seen where an end user bridged our network with his Wireless AP on the LAN Side of his device and you're right Port Security, not DHCP Snooping shut the port down. Jun 4, 2013 at 19:42
-
Dumb question: "Port security" is port-as-in-port-on-a-switch, not port-as-in-port-80[-or what have you], right?– ruffinOct 6, 2014 at 17:55
Don't forget that you can also run 802.1x on wired ports. 802.1x can prevent unauthorized devices and port-security helps prevent someone from hooking up a switch and tailgating the port. Remember that even with the best network controls in place, you must take measures at the PC level or users will simply be able to run NAT on their PC and bypass your network security measures.
As noted, first and foremost, policies matter. This may seem like an odd starting point, but, from a corporate and legal standpoint, unless you define and distribute the policy, if someone breaks it, there's little you can do. No point in securing the door if, when someone breaks in, you can't do anything to stop them.
What about 802.11X. You don't really care about what the access point is, legal or not, so long as no one gets access to the resources below it. If you can get the access point or the user beyond it, to support 802.11X, without approval, they get access, but they can't do anything.
We actually find this useful as we assign different VLANs based on it. If you are approved, you get access to the corporate VLAN, otherwise, it's the in-build ad network. Want to watch our promo videos all day, we're OK with that.
-
Do you mean 802.1X? There was never an IEEE 802.11X Working Group created. Jun 1, 2013 at 18:11
Nessus has a plugin for detecting rogue APs - you could script a scan to look periodically.
http://www.tenable.com/blog/using-nessus-to-discover-rogue-access-points
Prevention is hard.
You could replace wired Ethernet ports by using WiFi for all devices - eliminating need for people to setup their own APs. 802.1X to authenticate and IPsec to secure connection.
Detection may be only reliable way:
Wireless links have high packet loss and probably significant delay variation. By monitoring packet loss and delay you can detect connections over rouge access points.
Have you give any thought to overlay wireless intrusion prevention systems (WIPS)?
Rogue APs come in many forms shapes and sizes (ranging from usb/soft AP to actual physical Rogue APs). You need a system can monitors both the air and wired side and correlated the information from both sides of the network to deduce if a threat is actually present. It should be able to comb thru 100s of Ap and find the one that is plugged into your network
Rogue Ap is just 1 kind of wifi threat, how about your wifi clients connecting to external APs visible from your office. Wired IDS/IPS system can not fully protect against these kind of threats.
