|
Re: [Fwd: [WEB SECURITY] TJX pwned via wifi]: msg#00032security.wireless
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 1. Couldn't you do some things to VLAN the AP's away from the main network? > 2. Wouldn't a combination of MAC-address filtering help? > 3. Does turning off the broadcast beacon help at all against this newest > hack? > 4. What is the recommended next step for a small company where > implementing LEAP is seen as "too cumbersome" and not supported by the > barcode scanners? > Conclusion: I suppose we have to get the vendor to support WPA2 or > similar in the next firmware release? Right? Everything you can do adds a little bit of security to a WEP network, but the only real fix is migrating to WPA/2. NB: I'm going to ignore the LEAP indication as the "desirable" authentication protocol. If that wasn't a typo, we can move this conversation to a new thread. One practice I recommend to customers is to use WEP just for the devices that can only support WEP (handheld scanners, VoIP phones and the like) and profile what the traffic patterns are using Wireshark (just take a big Wireshark capture of the traffic in monitor mode and specify the WEP key with Wireshark to decrypt, or get a wired packet-capture). Once you know exactly what the minimum traffic is for the WEP-only devices, you can setup firewall rules to grant _only_ that access. This may include DNS, DHCP, SIP and RTP for VoIP devices, but you get the idea. In Wireshark, you can click on the packet representing traffic you want to allow and click "Analyze --> Firewall ACL Rules", then select your type of firewall device and Wireshark will create the rule for you automatically (I think that's a cool feature). This implements the Policy of Least Privilege, and ensures only the permitted protocols are allowed on the network if the network is compromised. However, we can take this one step further and blacklist anyone who violates this policy. Since your handheld scanners/VoIP phones shouldn't be doing anything outside of their defined policy, we can blacklist any device that tries to access something not expressly permitted (e.g. hacker compromised WEP, associates and accesses HTTP/80 or port-scans a device; they get blacklisted). The blacklisting itself has little value since the attacker can select another MAC address and try again, but it is a terrific WIDS indicator that someone is actively breaking the network use policy (e.g. now your WIPS reaction is to find a guy with a big stick and beat-down the attacker). For legacy/fat Cisco networks, I've implemented this by adding a "deny any any log" to the end of the ACL to generate logging notices any time the policy is violated, and used a monitoring tool like SWATCH [1] on the syslog server to execute a shell/perl/RUBY/Python script whenever the logging message is observed. The script can do whatever you want, from logging into a firewall and adding an ACL to blacklist a MAC, or just notifying you that something fishy is going on. With my employer's architecture (Aruba Networks), we call this a role change event, and it's a very easy thing to setup without SWATCH, scripting or any other hackery. Other transport providers may provide similar features. It's not that I don't recognize that there are legacy devices out there that can't do WPA/2, but promoting something that will be easily (and transparently) evaded by attackers while advocating that it makes retailers PCI compliant is, well, it's just wrong. Comments welcome, thanks! - -Josh [1] SWATCH; http://swatch.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iQIVAwUBRkBS+jWX3FIa1TkuAQLavw//Smcn0pCIVGD+RhSiJypiLPFwcshU9/Fd WkJfP8uGIuHY5EGaKXh3mCTfex5r4B0HDSlzUI37aQDzgt4d3tP0EIaDBblDGblS 4T7w4iKjwhD+G+yrIssh3jCGTLi+/lUfcCskIvuc1V5JKDcPBqScu0X6ua0hJkr0 DZpwiySom/XWd3znvJ8PJsmFn70sNA685kWeLXaCElkyg/GQz7QezXdf9RXvYWQb d+VdJxEstbPCGcT09SyrAlT8lstkEqAQhz9rf9ZBpbnAuAX9iJ73NAcDEWL4vgU1 r9DW7twO6GBVBlVD3Xcr1oX50i8y34tEaHqFOmY2RKuSuQfzvLx6rlNBQ0nxqvWk FBZ1rOyy7BKAVjvSB3ICmzZ4ofPJm7lNFrODkMnql9pHZS2qwpMgN3RBOuoGlftQ 9s7Cx7hiIPE31P4rpEpiN8C3xaEaPXLeEgPUhfiVD+Z7ecUwg4lJr/Y/iaqlCf0h 2TO2a1iypsiYIw2xvdY+PA0BhynhV1yTP3lr78+uN+fWCNwmp3kglwoG+ZYgTkkO 3hQ8vwS79caFzm3Bx11P1UPCm78c5QtrQPTNy6IONUj3Z7NQPq/iK+2Cg+zEKHEH Q9vECc9FPsl8azo4xY5VcphLjhHlt9ZngR0TFVijgT+/+mzGJeqH8aRU42u8F6w8 yggp5ZuSr+c= =e4oQ -----END PGP SIGNATURE----- |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | RE: Perpetuating weak wireless security: 00032, Nico Darrow |
|---|---|
| Next by Date: | Re: Perpetuating weak wireless security: 00032, nick leachman |
| Previous by Thread: | Re: [Fwd: [WEB SECURITY] TJX pwned via wifi]i: 00032, Tyrel McMahan |
| Next by Thread: | Re: [Fwd: [WEB SECURITY] TJX pwned via wifi]: 00032, Cedric Blancher |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |