Detection of Rogue Access Points
Gentlemen, An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways: 1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network. 2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network. These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first. I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware. Any ideas? Thank you for your time, Jonathan Rogers
-- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers <quantumfoam@gmail.com>wrote:
Gentlemen,
I'm looking for innovative ideas on how to find such a rogue device,
Check ARP tables for MAC address of wireless devices (first few nybbles show manufacturer.) Or for ports with multiple devices where you know there aren't switches.
ideally as soon as it is plugged in to the network.
That's going to take some decent scripting. Left as an exercise...
-- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network.
There was a SIGCOMM paper a few years back that described a scheme based on measuring the the ACK delays of TCP sessions. In a nutshell, you can detect nodes on the wireless network by looking for the extra delay added by the radio link. It had very good accuracy, and caught new nodes quickly. It didn't require any prior knowledge of the network. I don't have a copy of the paper at hand, and I don't remember the title/author or the publication date (2007ish?), but maybe this will ring a bell for someone else on the list who does. --lyndon
On Sun, 14 Oct 2012, Lyndon Nerenberg wrote:
There was a SIGCOMM paper a few years back that described a scheme based on measuring the the ACK delays of TCP sessions. In a nutshell, you can detect nodes on the wireless network by looking for the extra delay added by the radio link. It had very good accuracy, and caught new nodes quickly. It didn't require any prior knowledge of the network.
I don't have a copy of the paper at hand, and I don't remember the title/author or the publication date (2007ish?), but maybe this will ring a bell for someone else on the list who does.
do you mean http://conferences.sigcomm.org/imc/2007/papers/imc122.pdf ? Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
On 2012-10-14, at 14:56 PM, Matthias Waehlisch wrote:
do you mean http://conferences.sigcomm.org/imc/2007/papers/imc122.pdf ?
That's the one!
Scan for devices with open port 80 as these are managed by a GUI. -----Original Message----- From: Jonathan Rogers [mailto:quantumfoam@gmail.com] Sent: Sunday, October 14, 2012 3:59 PM To: nanog@nanog.org Subject: Detection of Rogue Access Points Gentlemen, An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways: 1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network. 2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network. These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first. I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware. Any ideas? Thank you for your time, Jonathan Rogers
Scan the local network from the local network. From: Aaron C. de Bruyn [mailto:aaron@heyaaron.com] Sent: Sunday, October 14, 2012 5:44 PM To: Kenneth M. Chipps Ph.D. Cc: nanog@nanog.org Subject: Re: Detection of Rogue Access Points On Sun, Oct 14, 2012 at 3:27 PM, Kenneth M. Chipps Ph.D. <chipps@chipps.com> wrote: Scan for devices with open port 80 as these are managed by a GUI. That'd be tough if they plug the WAN port into your network and remote access isn't enabled. -A
On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers <quantumfoam@gmail.com> wrote:
Gentlemen,
An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways:
1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network.
This is actually a really tough problem to solve without either total dictatorial control of your switchports or lots of telemetry and monitoring. At $DAYJOB, we detect the transparent bridge case by having a subset of AP hardware setup as "monitors" that listen to 802.11 frames on the various channels, keeping a log of the client MAC addresses and the BSSID that they're associated with. Then, by selecting out only those client MAC addresses that are not associated to a known BSSID that we control, we compare that set of "unknown" client MAC addresses to the Ethernet L2 FIBs on our switches and look for matches. If we see entries, than there is some 802.11 device bridging clients onto our network and we hunt it down from there. I've yet to see a solid methodology for detecting NATing devices, short of requiring 802.1x authentication using expiring keys and one-time passwords. :p Cheers, jof
restricting the number of mac addresses per switch port to one for your dhcp pool too, though more than one ap clones mac addresses. and make it unpopulr for the usual use cases by firewalling off stuff like dropbox, siri and icloud. there is of course commercial wips gear like this .. http://www.airtightnetworks.com/home/solutions/wireless-intrusion-prevention... On Monday, October 15, 2012, Jonathan Lassoff wrote:
On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers <quantumfoam@gmail.com<javascript:;>> wrote:
This is actually a really tough problem to solve without either total dictatorial control of your switchports or lots of telemetry and monitoring.
At $DAYJOB, we detect the transparent bridge case by having a subset of AP hardware setup as "monitors" that listen to 802.11 frames on the various channels, keeping a log of the client MAC addresses and the BSSID that they're associated with. Then, by selecting out only those client MAC addresses that are not associated to a known BSSID that we control, we compare that set of "unknown" client MAC addresses to the Ethernet L2 FIBs on our switches and look for matches.
If we see entries, than there is some 802.11 device bridging clients onto our network and we hunt it down from there.
I've yet to see a solid methodology for detecting NATing devices, short of requiring 802.1x authentication using expiring keys and one-time passwords. :p
Cheers, jof
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On 10/14/12, Jonathan Lassoff <jof@thejof.com> wrote:
I've yet to see a solid methodology for detecting NATing devices, short of requiring 802.1x authentication using expiring keys and one-time passwords. :p
Or implement network access protection, w IPsec between the hosts and the resources on the LAN; the systems behind the rogue NAT device won't be able to prove their identity, pass system health checks for antimalware, and get the x509 certificates required to communicate with hosts on the LAN... Packet sniffer, and look for packets sourced from hosts on the LAN with a TTL not matching the default TTL of OS'es in use on the network. Monitor ARP traffic. Start with the assumption that all devices are NAT devices, or malicious/unauthorized devices. Use TCP probes, to detect devices listening on common ports which can be identified as OSes (eg Windows, Printers, etc), which are known hosts on the network with a known user, or known purpose, and known to not be NAT devices. Delete known devices from the list of assumed rogue IP addresses. All the remaining IPs have to be investigated, and get their MAC address, hostname, and purpose documented. Once MAC addresses of all _known_ hosts are documented and manually verified, by process of elimination, you can detect any unknown IP addresses/MAC addresses, which might be any kind of unauthorized device. A NAT device is one example..... another example of an unauthorized device could be an unauthorized hardware keylogger/ network backdoor, with unauthorized connectivity to the LAN, and possible covert channels/backdoors/firewall bypasses.
Cheers, jof -- -JH
SSL throughout the network, with access control enforced using certificates is certainly a good idea. But most of the problem you face is metrics and inventory control of authorized devices. Commercial WIPS gear does a lot of this heavy lifting without your having to script it all yourself. On Monday, October 15, 2012, Jimmy Hess wrote:
A NAT device is one example..... another example of an unauthorized device could be an unauthorized hardware keylogger/ network backdoor, with unauthorized connectivity to the LAN, and possible covert channels/backdoors/firewall bypasses.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On Sun, 2012-10-14 at 16:59 -0400, Jonathan Rogers wrote:
An issue has come up in my organization recently with rogue access points.
No-one has said this yet, so I will - why are people working around your normal network policies? This is often a sign of something lacking that people need in their daily work. You can often reduce this sort of "innocent thievery" down to a manageable minimum simply by making sure that people have the tools they need to work. Sometimes it's cheaper to give people what they want than to prevent them taking it. Maybe at least consider that as an option. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On Mon, 15 Oct 2012 13:11:00 +1100, Karl Auer said:
No-one has said this yet, so I will - why are people working around your normal network policies? This is often a sign of something lacking that people need in their daily work. You can often reduce this sort of "innocent thievery" down to a manageable minimum simply by making sure that people have the tools they need to work.
Sometimes it's cheaper to give people what they want than to prevent them taking it. Maybe at least consider that as an option.
Amen to that - detecting rogue access points is one thing, but in order to make the users stop doing it, you're going to need either a sufficiently large carrot or a sufficiently large stick. If you don't deploy at least one, the problem *will* keep recurring.
Well, quite frankly they have the tools they need. Our remote sites do not have any devices that require wireless. They don't have company-issued laptops, and personal laptops are not allowed. The policy is on the books but it isn't my department to make sure people know about it and follow it. Our end users at these branch offices are typically not very technically inclined and have no idea what a security risk this is (especially considering that we have EPHI on our network, although I can't really say more in detail than that). The person who put in the WAP I discovered doesn't even work for us any more. Port-based security might work, but our edge switches are total garbage (don't get me started, not in my control). I didn't find this WAP via nmap...it didn't show up. I believe it probably didn't have a valid management interface IP for some reason. We saw suspicious entries in the router's ARP table and starting looking around the office from there. --JR On Mon, Oct 15, 2012 at 11:05 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 15 Oct 2012 13:11:00 +1100, Karl Auer said:
No-one has said this yet, so I will - why are people working around your normal network policies? This is often a sign of something lacking that people need in their daily work. You can often reduce this sort of "innocent thievery" down to a manageable minimum simply by making sure that people have the tools they need to work.
Sometimes it's cheaper to give people what they want than to prevent them taking it. Maybe at least consider that as an option.
Amen to that - detecting rogue access points is one thing, but in order to make the users stop doing it, you're going to need either a sufficiently large carrot or a sufficiently large stick. If you don't deploy at least one, the problem *will* keep recurring.
Why not give them wireless Internet access only? That will keep all the smartphone users happy. On 10/15/2012 8:12 AM, Jonathan Rogers wrote:
Well, quite frankly they have the tools they need. Our remote sites do not have any devices that require wireless. They don't have company-issued laptops, and personal laptops are not allowed. The policy is on the books but it isn't my department to make sure people know about it and follow it. Our end users at these branch offices are typically not very technically inclined and have no idea what a security risk this is (especially considering that we have EPHI on our network, although I can't really say more in detail than that). The person who put in the WAP I discovered doesn't even work for us any more.
Port-based security might work, but our edge switches are total garbage (don't get me started, not in my control). I didn't find this WAP via nmap...it didn't show up. I believe it probably didn't have a valid management interface IP for some reason. We saw suspicious entries in the router's ARP table and starting looking around the office from there.
--JR
...
On Mon, Oct 15, 2012 at 8:54 AM, Roy <r.engehausen@gmail.com> wrote:
Why not give them wireless Internet access only? That will keep all the smartphone users happy.
Maybe because he has 130 sites and 130 truck rolls is not cheap. Also company policy says no. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
On Mon, Oct 15, 2012 at 12:00 PM, Joe Hamelin <joe@nethead.com> wrote:
Maybe because he has 130 sites and 130 truck rolls is not cheap. Also company policy says no.
You are correct that deploying to a number of sites isn't cheap, but the actual relevant question is how does this cost compare to the cost of the original request to detect these things. In this case almost all forms of detection/prevention except possibly looking at TTL will require new equipment to be deployed at the site(s) anyways based on the information we have, negating much of the extra cost. Any active detection on the RF side of things is generally done using WAPs in a managed network or standalone devices that are pretty much repurposed WAP hardware anyways, but cost a lot more. Both of those costs must then be compared to the cost of doing nothing. What happens if a user takes things in to their own hands and either leaves the AP open or uses some useless form of security (MAC filtering, WEP, WPA2 w/ WDS, WPA2 w/ weak password and a common SSID, etc.) allowing an attacker in to the network? If company policy says no, maybe company policy should be re-evaluated if enforcing said policy would cost more than the other options. Policy isn't supposed to be written in stone, it should adapt to the realities of the world as they change. Obviously this depends on the situation. Small business that uses mostly "cloud" services and doesn't have much if any local content to secure? Probably not worth doing anything. Three-letter agency? Worth every penny to detect and lock out unauthorized devices. Most will be somewhere in between, you have to evaluate the actual choices and decide the best path.
On Mon, Oct 15, 2012 at 4:06 PM, Sean Harlow <sean@seanharlow.info> wrote:
You are correct that deploying to a number of sites isn't cheap, but the actual relevant question is how does this cost compare to the cost of the original request to detect these things. In this case almost all forms of detection/prevention except possibly looking at TTL will require new equipment to be deployed at the site(s) anyways based on the information we have, negating much of the extra cost. Any active detection on the RF side of things is generally done using WAPs in a managed network or standalone devices that are pretty much repurposed WAP hardware anyways, but cost a lot more.
I think it would be cheaper to have a script written that would grab the ARP table of each site and then compare to what is known. Kind of an ARP tripwire. Sure you'll have to take the time with early runs to hunt down non-company owned MACs but that is going to be a lot cheaper than managing a 130 site roll-out. Even if you did put RF monitoring equipment in each site you would still have to monitor and manage it. Either way, you'll be getting a current inventory of devices. From what I read, he wants to detect non-company equipment on his network. It's just WiFi that is the main problem. Even just watching the DHCP leases, which I assume the little Cisco router is providing, will catch most of the rouge devices. Get someone that knows networking and perl on the task for a month. If they don't have the local talent there are a lot of people that would love to take the contract, considering most of it could be done remotely. Jonathan stated that they have health data on the network and only company issued devices are allowed. I would suggest to him that he inventory the equipment via MAC address (I'm guessing that it's mostly standard issue stuff that would be easy to recognize) and then lock down unused ports and setup up monitoring. If a new MAC appears on the network, then it better have been sent there by IT. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
On Mon, Oct 15, 2012 at 7:31 PM, Joe Hamelin <joe@nethead.com> wrote:
Jonathan stated that they have health data on the network and only company issued devices are allowed. I would suggest to him that he inventory the equipment via MAC address (I'm guessing that it's mostly standard issue stuff that would be easy to recognize) and then lock down unused ports and setup up monitoring. If a new MAC appears on the network, then it better have been sent there by IT.
I won't argue with that. When no official wireless network is involved, a MAC whitelist can be very effective. It'll catch any casual user attempting to homebrew a WiFi setup and significantly increase the odds of detecting an actual attacker. Even if the switches are at the lowest end of "smart" and only expose a web interface it's not too hard to rig up a screen scraper to list the connected devices on a regular basis and alert if anything new is seen. I'd expect that there are probably at least a dozen commercial and/or open source tools that already exist for the purpose, actually.
On Mon, Oct 15, 2012 at 04:31:34PM -0700, Joe Hamelin wrote:
I think it would be cheaper to have a script written that would grab the ARP table of each site and then compare to what is known. Kind of an ARP tripwire.
Netdisco does this, and more (reports on ports which have more than 1 MAC address, devices from known wireless manufacturers, search MAC address by manufacturer, etc). http://www.netdisco.org/
On Mon, Oct 15, 2012 at 4:06 PM, Sean Harlow <sean@seanharlow.info> wrote:
On Mon, Oct 15, 2012 at 12:00 PM, Joe Hamelin <joe@nethead.com> wrote:
Maybe because he has 130 sites and 130 truck rolls is not cheap. Also company policy says no.
You are correct that deploying to a number of sites isn't cheap, but the actual relevant question is how does this cost compare to the cost of the original request to detect these things. In this case almost all forms of detection/prevention except possibly looking at TTL will require new equipment to be deployed at the site(s) anyways based on the information we have, negating much of the extra cost. Any active detection on the RF side of things is generally done using WAPs in a managed network or standalone devices that are pretty much repurposed WAP hardware anyways, but cost a lot more.
Both of those costs must then be compared to the cost of doing nothing. What happens if a user takes things in to their own hands and either leaves the AP open or uses some useless form of security (MAC filtering, WEP, WPA2 w/ WDS, WPA2 w/ weak password and a common SSID, etc.) allowing an attacker in to the network?
If company policy says no, maybe company policy should be re-evaluated if enforcing said policy would cost more than the other options. Policy isn't supposed to be written in stone, it should adapt to the realities of the world as they change.
Obviously this depends on the situation. Small business that uses mostly "cloud" services and doesn't have much if any local content to secure? Probably not worth doing anything. Three-letter agency? Worth every penny to detect and lock out unauthorized devices. Most will be somewhere in between, you have to evaluate the actual choices and decide the best path.
This solution - the "don't care" solution - almost fails the negligence test for certain security regimes including PCI (credit cards) and possibly SOX for retail data locations (and HIPPA for hospitals / medical locations, etc). That is not to say that there aren't still large numbers of poorly configured branch offices or retail locations out there at any number of retailers that fail those tests. Reality is painful. But if someone sticks in a WAP, starts sniffing credit card #s floating by, and your business finds itself on the arse end of a large painful data breach, you will regret not paying more attention beforehand. Not all networks are public networks. That said, adding another DSL line and router and public WAP just so that the store employees and the public's smartphones are happy is a perfectly reasonable service to offer. Separate from the security-critical data, or with really good firewalling / tunneling / whatever. -- -george william herbert george.herbert@gmail.com
On Mon, Oct 15, 2012 at 8:44 PM, George Herbert <george.herbert@gmail.com>wrote:
This solution - the "don't care" solution - almost fails the negligence test for certain security regimes including PCI (credit cards) and possibly SOX for retail data locations (and HIPPA for hospitals / medical locations, etc).
Of course, and this is where the situational judgement comes in to play. The low-security environments I was envisioning are those more like my own office, where the only on-site server is basically a homebrew NAS storing music/movies for slow days. We've jumped head first in to the Google Apps system so all files, mail, etc. are there. Payments and any other customer-facing services are on servers hosted in a proper datacenter, never coming close to the office LAN, so our actual risk is basically the same as that of a home user. The boss using his laptop on public WiFi worries me a lot more than someone gaining access to our network. If you take payments on-premise and transmit them over the network, it's obviously another story entirely.
On Mon, Oct 15, 2012 at 09:00:56AM -0700, Joe Hamelin wrote:
On Mon, Oct 15, 2012 at 8:54 AM, Roy <r.engehausen@gmail.com> wrote:
Why not give them wireless Internet access only? That will keep all the smartphone users happy. Maybe because he has 130 sites and 130 truck rolls is not cheap. Also company policy says no.
So stick a pre-configured device in the post, with instructions on how and where to plug it in. -- David Cantrell | top google result for "topless karaoke murders" "Cynical" is a word used by the naive to describe the experienced. George Hills, in uknot
On 10/14/12, Karl Auer <kauer@biplane.com.au> wrote:
No-one has said this yet, so I will - why are people working around your normal network policies? This is often a sign of something lacking that people need in their daily work. You can often reduce this sort of While that's no reason to stop looking for rogues... It's a good point that policy and planning there is a crucial element; more important than managing all network devices; or even having antivirus or firewalls.
Because humans are a weak point -- every enterprise has them: there are ways the humans can be exploited unwittingly, humans might sometimes follow an improper procedure, the eventual occurrence of an incident related to human weakness may be inevitable. "Lacking something they need" is not likely. If it's really true that a forbidden thing is needed for their work -- they should be able to persuade their org's leadership to create a variance from the policy, or implement a solution. It's more likely the network user introduces rogue devices because (1) The rule wasn't written down.. E.g. It was actually an unwritten policy never carefully formulated into writing, that nobody may just plug in whatever network device wireless AP, 5 port switch, or Linksys router, even with a "good reason" to; the network users had no document to follow to explain mandatory steps required to introduce a new device. (2) The people don't know what the policy, standard, or directive actually is: They haven't been administered adequate training and been quizzed appropriately on the relevant policies, standards, and guidelines; their role with regard to the policy is not understood properly. (3) The organization hadn't made commitment to the pertinent IT policy clear. For example: The network user do not have high certainty that audit controls and procedures will be in place will detect their infraction and remove unauth'd equipment. If they are made certain a violation will be detected, and receive investigation, the rate of non-compliance could be expected to decrease.
Sometimes it's cheaper to give people what they want than to prevent them taking it. Maybe at least consider that as an option.
That depends on what 'they want'; and what regulations apply to the organization. The feds may force various organizations into saying no, even if network users want it, and the org. would prefer to allow it. If what the network users want is an unmanaged personal device on a corporate intranet, there are security considerations, which have a non-zero level of risk, that might be judged too high. Bandwidth and potentially firewall user licenses for i-devices to have continuous Facebook and Youtube access are not free. The possibility of required incident management for potential abuse cases. Possible SOX requirements to archive Twitter/Facebook "status update" message traffic.... etc. etc.
Regards, K. Karl Auer (kauer@biplane.com.au) -- -JH
On 10/14/2012 1:59 PM, Jonathan Rogers wrote:
Gentlemen,
An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways:
1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network.
2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network.
These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first.
I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware.
Any ideas?
Thank you for your time,
Jonathan Rogers
Install your own Access Points for official use and have them scan for SSIDs in the vicinity. Kills two birds. One you now have official wireless access and your AP can detect rogue SSIDs.
On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers <quantumfoam@gmail.com>wrote:
Gentlemen,
An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways:
1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network.
2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network.
There are wireless IDS/IPS products available that monitor not only the airspace, but the wire as well. Many of these products will also actively defend the airspace. Search for "wIDS" and/or "wIPS". Often the cost of purchasing and deploying these products is more expensive than the cost of implementing simple 802.1x port authentication though. If nothing else, set up guest wireless piped to a cheap broadband connection and create and/or enforce proper acceptable use policies on your LAN. The less you fight your users, the easier your job is. Of course all of this is dependent on the business and legal jurisdiction you are in. -Jon
Do the layer 2 switches include sFlow instrumentation? http://sflow.org/products/network.php The following paper describes how IP TTL values can help identify unauthorized NAT devices. http://www.sflow.org/detectNAT/ Peter On Sun, Oct 14, 2012 at 1:59 PM, Jonathan Rogers <quantumfoam@gmail.com> wrote:
Gentlemen,
An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways:
1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network.
2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network.
These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first.
I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware.
Any ideas?
Thank you for your time,
Jonathan Rogers
How about some of the free network auditing tools like nmap even Spiceworks to detect the devices on your network? Martin On Sunday, 14 October 2012, Jonathan Rogers wrote:
Gentlemen,
An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways:
1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network.
2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network.
These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first.
I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware.
Any ideas?
Thank you for your time,
Jonathan Rogers
-- -- Martin Hepworth, CISSP Oxford, UK
On Sun, 14 Oct 2012 16:59:12 -0400 Jonathan Rogers <quantumfoam@gmail.com> wrote:
I'm looking for innovative ideas on how to find such a rogue device,
Here is an old post that describes some techniques, while date, should still be at least partially effective and help form part of a more comprehensive solution: <http://www.merit.edu/mail.archives/nanog/2003-02/msg00247.html> John
Some very good points were made in the thread. I've dealt with this problem a few times. I'll admit, the only perfect solution I've found is to install a Internet-only (its own router interface or VLAN, firewalled off from everything else) AP for people to use because, frankly, consumer-grade APs are just too easy to install. On the technical side, to reiterate what others have suggested: - Scan MACs from the router ARP table or DHCP logs, flag anything from a common wireless vendor - Script to pull new DHCP leases, check each with NMAP, alert on anything suspicious - Port security, if you can - Scanning the air The only *real* way to detect rogue APs is to actually scan the airwaves. There's a bunch of vendors who sell hardware/software solutions for this, and there are also a lot of APs that support it, especially if you can deal with something manual. Ubiquiti Networks sells some sub-$100 USD access points that do a nice "site survey" as well as a spectrum analyzer, and could be used to get this info. Of course that becomes more of a burden if there are multiple other wireless networks within range of you (should be fine if your branches are on their own property, could be a problem if they're in commercial/professional buildings). I don't know if the Ubiquiti products are easily scriptable, but they *do* offer a SDK and with some amount of effort, it would probably be possible to pull this data via a script. The times that I've done this, we've just grabbed a bunch of decommissioned corporate laptops with wireless & wired ethernet interfaces, put Linux on them, and written a script that scans for visible wireless networks every 5-30 minutes, and emails any changes to us. Laptops were configured for DHCP, and just plugged in and nestled somewhere in the wiring closet. Net cost $0 (well maybe some patch cables), and worked fine for us. -Jason On 10/14/2012 04:59 PM, Jonathan Rogers wrote:
Gentlemen,
An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways:
1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network.
2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network.
These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first.
I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware.
Any ideas?
Thank you for your time,
Jonathan Rogers
I like the idea of looking at the ARP table periodically, but this presents some possible issues for us. The edge routers at our remote sites are Cisco 1841 devices, typically with either an MPLS T1 or a Public T1 (connected via an IAD owned by Centurylink; router to router, so dumb). Aside from manually logging in to those individual routers (all 140 or so of them) and checking them on a schedule, can anyone think of a good way to capture that information automatically? If I had to I could probably come up with a script to log in to them and scrape the info then process it but...eww. Another possible option (although costly) is installing a Ruckus device at each location; we have a Ruckus infrastructure at our HDQ and it works great (almost too good, it's super sensitive) at picking up rogues. A Ruckus WAP could talk to our ZoneDirector appliance and do that for us at each site, I think, but it may be difficult to justify the cost. --JR On Thu, Oct 18, 2012 at 9:15 AM, Jason Antman <jason@jasonantman.com> wrote:
Some very good points were made in the thread. I've dealt with this problem a few times. I'll admit, the only perfect solution I've found is to install a Internet-only (its own router interface or VLAN, firewalled off from everything else) AP for people to use because, frankly, consumer-grade APs are just too easy to install.
On the technical side, to reiterate what others have suggested: - Scan MACs from the router ARP table or DHCP logs, flag anything from a common wireless vendor - Script to pull new DHCP leases, check each with NMAP, alert on anything suspicious - Port security, if you can - Scanning the air
The only *real* way to detect rogue APs is to actually scan the airwaves. There's a bunch of vendors who sell hardware/software solutions for this, and there are also a lot of APs that support it, especially if you can deal with something manual. Ubiquiti Networks sells some sub-$100 USD access points that do a nice "site survey" as well as a spectrum analyzer, and could be used to get this info. Of course that becomes more of a burden if there are multiple other wireless networks within range of you (should be fine if your branches are on their own property, could be a problem if they're in commercial/professional buildings). I don't know if the Ubiquiti products are easily scriptable, but they *do* offer a SDK and with some amount of effort, it would probably be possible to pull this data via a script.
The times that I've done this, we've just grabbed a bunch of decommissioned corporate laptops with wireless & wired ethernet interfaces, put Linux on them, and written a script that scans for visible wireless networks every 5-30 minutes, and emails any changes to us. Laptops were configured for DHCP, and just plugged in and nestled somewhere in the wiring closet. Net cost $0 (well maybe some patch cables), and worked fine for us.
-Jason
On 10/14/2012 04:59 PM, Jonathan Rogers wrote:
Gentlemen,
An issue has come up in my organization recently with rogue access points. So far it has manifested itself two ways:
1. A WAP that was set up specifically to be transparent and provided unprotected wireless access to our network.
2. A consumer-grade wireless router that was plugged in and "just worked" because it got an address from DHCP and then handed out addresses on its own little network.
These are at remote sites that are on their own subnets (10.100.x.0/24; about 130 of them so far). Each site has a decent Cisco router at the demarc that we control. The edge is relatively low-quality managed layer 2 switches that we could turn off ports on if we needed to, but we have to know where to look, first.
I'm looking for innovative ideas on how to find such a rogue device, ideally as soon as it is plugged in to the network. With situation #2 we may be able to detect NAT going on that should not be there. Situation #1 is much more difficult, although I've seen some research material on how frames that originate from 802.11 networks look different from regular ethernet frames. Installation of an advanced monitoring device at each site is not really practical, but we may be able to run some software on a Windows PC in each office. One idea put forth was checking for NTP traffic that was not going to our authorized NTP server, but NTP isn't necessarily turned on by default, especially on consumer-grade hardware.
Any ideas?
Thank you for your time,
Jonathan Rogers
I like the idea of looking at the ARP table periodically, but this presents some possible issues for us. The edge routers at our remote sites are Cisco 1841 devices, typically with either an MPLS T1 or a Public T1 (connected via an IAD owned by Centurylink; router to router, so dumb). Aside from manually logging in to those individual routers (all 140 or so of them) and checking them on a schedule, can anyone think of a good way to capture that information automatically? If I had to I could probably come up with a script to log in to them and scrape the info then process it but...eww.
NetDisco knows how to scan networks for mac addresses, arp addresses, ip addresses, etc. It keeps track of deltas. It may have be able to email deltas or something similar. Or run a query against the database, as I seem to recall it seems to hold historical data. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers <quantumfoam@gmail.com> wrote:
I like the idea of looking at the ARP table periodically, but this presents some possible issues for us.
Is it just WAPs that you are worried about or any rouge device at the remote sites? If you're doing medical data then I would think that any non-company device would be suspect. If that is the case then ARP scraping is the better way. Basically you need an inventory of what is at the sites. This you should already have and if you don't, that is your first step. A bit of perl and expect scripting would get you a long way to your goal. Like I mentioned before, if you don't have the time/talent to script the task, call out for a coder-for-hire. I feel that concentration just on WAPs is missing the bigger issue. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
On 18/10/12 15:12, Joe Hamelin wrote:
On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers<quantumfoam@gmail.com> wrote:
I like the idea of looking at the ARP table periodically, but this presents some possible issues for us.
Is it just WAPs that you are worried about or any rouge device at the remote sites? If you're doing medical data then I would think that any non-company device would be suspect. If that is the case then ARP scraping is the better way. Basically you need an inventory of what is at the sites. This you should already have and if you don't, that is your first step.
A bit of perl and expect scripting would get you a long way to your goal. Like I mentioned before, if you don't have the time/talent to script the task, call out for a coder-for-hire.
You should be able to get the ARP table off a router using SNMP, which would be much cleaner than using expect to login to a router's management interface... HTH, Chris
I, uh...don't actually know how to do that. I've not done very much with SNMP other than working with power management devices. If someone could direct me to a good tutorial, that would be much appreciated. --JR On Thu, Oct 18, 2012 at 12:31 PM, Chris Boot <bootc@bootc.net> wrote:
On 18/10/12 15:12, Joe Hamelin wrote:
On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers<quantumfoam@gmail.com> wrote:
I like the idea of looking at the ARP table periodically, but this
presents some possible issues for us.
Is it just WAPs that you are worried about or any rouge device at the remote sites? If you're doing medical data then I would think that any non-company device would be suspect. If that is the case then ARP scraping is the better way. Basically you need an inventory of what is at the sites. This you should already have and if you don't, that is your first step.
A bit of perl and expect scripting would get you a long way to your goal. Like I mentioned before, if you don't have the time/talent to script the task, call out for a coder-for-hire.
You should be able to get the ARP table off a router using SNMP, which would be much cleaner than using expect to login to a router's management interface...
HTH, Chris
Raymond Burkholder (ray) writes:
NetDisco knows how to scan networks for mac addresses, arp addresses, ip addresses, etc. It keeps track of deltas. It may have be able to email deltas or something similar. Or run a query against the database, as I seem to recall it seems to hold historical data.
Yes, NetDisco will do this, and it has query interface for looking up MAC <-> associations, and where they were last seen. Netdot (netdot.uoregon.edu, just mentioned it in an earlier mail) also offers this functionality, and stores the information in the database for querying/searching. Jonathan Rogers (quantumfoam) writes:
I, uh...don't actually know how to do that. I've not done very much with SNMP other than working with power management devices. If someone could direct me to a good tutorial, that would be much appreciated.
It's probably easier to use one of the tools mentioned than to start writing your own. To do that, you'd have to retrieve the L2 forwarding table from switches, and the ARP tables from L3 devices. You have to query all active devices regularly and build/update your DB from that. There are tools such as SNMP::Info http://search.cpan.org/~maxb/SNMP-Info-2.01 that make this easier, but still some amount of coding would be required. It's then a matter of querying the DB, and looking for the MAC addresses of suspected rogue devices, if they keep on showing up (you will see many one-times that don't reappear, which also grows the DB significantly over time). Phil
Nevermind, it appears SNMP is turned off on our routers and I do not have control over that. I can at least present this as a possible option to the person that does. Thank you very much for your suggestions, everyone. I'm so glad I joined this list; I've learned so much and it's great to talk to people who like to share their knowledge and experience. --JR On Thu, Oct 18, 2012 at 4:21 PM, Phil Regnauld <regnauld@nsrc.org> wrote:
Raymond Burkholder (ray) writes:
NetDisco knows how to scan networks for mac addresses, arp addresses, ip addresses, etc. It keeps track of deltas. It may have be able to email deltas or something similar. Or run a query against the database, as I seem to recall it seems to hold historical data.
Yes, NetDisco will do this, and it has query interface for looking up MAC <-> associations, and where they were last seen.
Netdot (netdot.uoregon.edu, just mentioned it in an earlier mail) also offers this functionality, and stores the information in the database for querying/searching.
Jonathan Rogers (quantumfoam) writes:
I, uh...don't actually know how to do that. I've not done very much with SNMP other than working with power management devices. If someone could direct me to a good tutorial, that would be much appreciated.
It's probably easier to use one of the tools mentioned than to start writing your own. To do that, you'd have to retrieve the L2 forwarding table from switches, and the ARP tables from L3 devices. You have to query all active devices regularly and build/update your DB from that. There are tools such as SNMP::Info http://search.cpan.org/~maxb/SNMP-Info-2.01 that make this easier, but still some amount of coding would be required.
It's then a matter of querying the DB, and looking for the MAC addresses of suspected rogue devices, if they keep on showing up (you will see many one-times that don't reappear, which also grows the DB significantly over time).
Phil
On Thu, Oct 18, 2012 at 7:00 AM, Jonathan Rogers <quantumfoam@gmail.com> wrote:
I like the idea of looking at the ARP table periodically, but this presents some possible issues for us. The edge routers at our remote sites are Cisco 1841 devices, typically with either an MPLS T1 or a Public T1 (connected via an IAD owned by Centurylink; router to router, so dumb). Aside from manually logging in to those individual routers (all 140 or so of them) and checking them on a schedule, can anyone think of a good way to capture that information automatically? If I had to I could probably come up with a script to log in to them and scrape the info then process it but...eww.
quite a few people have leveraged RANCID (http://www.shrubbery.net/rancid/) for doing stuff like this. it is made to pull configs from routers on a cycle and produces text files that can be worked with. you can use the tools that are there to pull specific information, such as arp tables, and then process the resultant files with your scripting language of choice. check the mail list for examples of this kind of thing.
Another possible option (although costly) is installing a Ruckus device at each location; we have a Ruckus infrastructure at our HDQ and it works great (almost too good, it's super sensitive) at picking up rogues. A Ruckus WAP could talk to our ZoneDirector appliance and do that for us at each site, I think, but it may be difficult to justify the cost.
--JR
james
participants (25)
-
Aaron C. de Bruyn -
Chris Boot -
David Cantrell -
George Herbert -
james machado -
Jason Antman -
Jimmy Hess -
Joe Hamelin -
John Kristoff -
Jon Sevier -
Jonathan Lassoff -
Jonathan Rogers -
Karl Auer -
Kenneth M. Chipps Ph.D. -
Lyndon Nerenberg -
Martin Hepworth -
Matthias Waehlisch -
Peter Phaal -
Phil Regnauld -
Raymond Burkholder -
Roy -
Ryan McBride -
Sean Harlow -
Suresh Ramasubramanian -
Valdis.Kletnieks＠vt.edu