Focus on IDS
PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 23 2009 07:50PM
Taras P. Ivashchenko (taras securityaudit ru) (2 replies)
RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 23 2009 10:04PM
Chris Waters (cwaters paglo com) (1 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 06:43PM
Leon Ward (leon rm-rf co uk)
RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 23 2009 09:20PM
Gary Everekyan (Gary Everekyan consumerinfo com) (4 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 07:40PM
Jason (securitux gmail com)
RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 07:27PM
Emm Maxim (maxus infosec ru) (1 replies)
RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 08:57PM
Gary Everekyan (Gary Everekyan consumerinfo com)
RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 06:35PM
Thiago Musa (klawiq gmail com)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 06:04PM
Jeremy Bennett (jeremyfb mac com) (2 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 08:22PM
nelson pangeia com br (Nelson Murilo)
RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 06:48PM
Gary Everekyan (Gary Everekyan consumerinfo com) (1 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 24 2009 07:00PM
Jeremy Bennett (jeremyfb mac com) (2 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 25 2009 08:01AM
Joel Snyder (Joel Snyder Opus1 COM) (1 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 26 2009 07:41AM
Jeremy Bennett (jeremyfb mac com) (1 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 27 2009 09:05AM
Joel Snyder (Joel Snyder Opus1 COM) (1 replies)
Re: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 27 2009 03:28PM
Jeremy Bennett (jeremyfb mac com)
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 (at) Opus1 (dot) COM [email concealed]> 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
>

[ reply ]
RE: PCI DSS 11.1 - ".. deploying a wireless IDS/IPS..". Kismet+Snort? Apr 25 2009 05:04AM
Emm Maxim (maxus infosec ru)


 

Privacy Statement
Copyright 2010, SecurityFocus