IDS mailing list archives
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort?
From: Jeremy Bennett <jeremyfb () mac com>
Date: Mon, 27 Apr 2009 08:28:47 -0700
Joel, You are correct about the weakness of MAC Address Fallback. This is exactly why 802.1x if not the perfect solution to the rogue AP problem. You further assert that anyone capable of changing the MAC address on an AP is also capable of evading a wireless IDS. This is not true. It is true that someone capable of changing the MAC address on an AP is probably also capable of making that AP nearly invisible to a wired scanner. This is why I don't think that wired-side scanning alone is sufficient to combat rogue APs. Evading a wireless IDS is much harder. The reason is that it is impossible to act as an AP without transmitting and, assuming sufficient sensor coverage, if a device transmits it will be detected using a wireless IDS. Of course, the clever attacker will try to avoid detection by moving to a channel outside the regulatory domain (as you mention) or by moving to a channel that is completely outside all regulatory domains, for example channel 162 falls between regulated channels. A good wireless IDS will scan all channels looking for APs. As an aside, receiving on a channel is not regulated, transmitting is, so a wireless IDS scanning for APs on non-regulated channels is not, as you imply, illegal. Our clever attacker will, also, spoof the MAC address of an authorized device on the wireless side as well as on the wired. The difference being the wired device (say a printer) is unplugged in order to plug in the rogue AP while the wireless device (say an authorized AP) will continue to transmit. Therefore a good wireless IDS will be able to determine that the MAC address spoofing is taking place. DoSing the valid AP makes the attacker more visible. -J On 4/27/09 2:05 AM, "Joel Snyder" <Joel.Snyder () Opus1 COM> wrote:
The reason is that you cannot completely deploy 802.1x today. If EVERY port required 802.1x authentication then you could argue that no unauthorized devices could be connected. The problem is that not all network devices support 802.1x today.Yes, this is true, but there is a common strategy in NAC where 802.1X fails over to MAC authentication. Thus, you would say that a printer with a known MAC address can connect to a particular port, but if someone attached a different device to the port (with a different MAC address), then the port would not open up. In Cisco-speak, they call this MAC Address Fallback, but all modern switches allow for it.Examples include printers, IP cameras, networked scanners, and (sadly) access points. So, because you need to provide for these exceptions you cannot guarantee that no excepted device has been unplugged and an unauthorized device plugged in in it's place.Now, of course, anyone with a strong knowledge of networking is aware that MAC addresses can be cloned (in fact, access points often make this easy to help work-around MAC limitations by broadband ISPs), and thus the use of the word "guarantee" is a very difficult one. But you might also claim (in fact, I'd be happy to claim this) that someone who is intentionally subverting network security would also be easily capable of avoiding a wireless IDS/IPS scanner. Thus a wireless IDS/IPS scanner might help to tune the window of vulnerability down, but at what potential cost? (I am not arguing against wireless IDS, by the way; I am just asking these questions to get some general ideas out on the table and see how domain experts in the PCI area are reacting--whether NAC provides a "guarantee" if implemented correctly, for example) As long as I'm throwing hard questions out there: how many people with wireless IDS/IPS are, perhaps illegally, using a different regulatory regime in order to catch the clever attacker who is using channel 120 in Fargo (an EMEA-only channel) or channel 165 (a US-only channel) in Florence? jms
Current thread:
- PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Taras P. Ivashchenko (Apr 23)
- RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Gary Everekyan (Apr 24)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Jeremy Bennett (Apr 24)
- RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Gary Everekyan (Apr 24)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Jeremy Bennett (Apr 24)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Joel Snyder (Apr 27)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Jeremy Bennett (Apr 27)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Joel Snyder (Apr 27)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Jeremy Bennett (Apr 27)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Jeremy Bennett (Apr 24)
- RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Gary Everekyan (Apr 24)
- RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Emm Maxim (Apr 27)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Nelson Murilo (Apr 24)
- RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Gary Everekyan (Apr 24)
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Leon Ward (Apr 24)
- <Possible follow-ups>
- Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Jeremy Bennett (Apr 27)