Deauth

Sorta. Deauth is not really an "attack" in that it does not directly lead to unauthorized wireless access or DoS (denial of service). It's a means of forcing the AP and client to re-associate, thus generating a larger number of "interesting" packets suitable for use in recovering the pass phrase. Note that for deauth to be useful, both the client and AP traffic must be captured and filtered by airedump. If they get lucky and grab both sides of a re-association, it can usually be replayed (using aireplay) to gain access.

For defense, it makes no sense for a non-connected client to initiate a disconnect. The MAC address of a connected client and AP have to be spoofed. That can be detected. The AP would need to maintain a table of connected client states, and reject multiple disconnect packets. The attacker could still initiate a single disconnect, but all subsequent deauth packets from that MAC address would be ignored. This doesn't really solve the problem, but does reduce the number of reconnections, thus limiting the usefulness of this attack in collecting "interesting" packets suitable for replay. I don't think anyone has done that since it's not really 100% effective.

Cisco has a wireless intrusion detection system, which is overkill for the home user. It doesn't prevent attacks, but does detect most of them:

This is a bit old, but the references at the bottom are still useful:

I forgot to mention a defense that mostly works. Use WPA-RADIUS encryption and authentication. With a shared WPA-PSK key, every client gets the same key. Eventually, that can be recovered. With RADIUS, the key is generated automatically by the RADIUS server, and only used once per session. No way to recover or replay that type of key exchange. The problem is that you need a RADIUS server, which is usually found in the form of a PC running probably FreeRADIUS:

This is probably more than what you want to deal with, but may be practical with a sufficiently small server. There are also various free and for pay online RADIUS server services. For example:

Unfortunately, it will not prevent the deauth attack from initiating a disconnect. As long as the attack continues, your client is useless.

802.11w is the spec that addresses such a concern, but I don't know whether there exist any actual commercially available implementations. We support a prestandard scheme (MFP, Management Frame Protection); it requires a Cisco Aironet AP and a client that supports CCXv5 (of which there are few.)

All that said, if a radio near your AP wants to DoS it, it's pretty trivial for it just to jam your channel; 802.11w/MFP won't be able to save you from that.

Aaron

Ah yes, I should have mentioned that I'd read about 802.11w previously. For the record, this house is running Ubuntu, XP Pro and an Amiga 1200 BBS (!) - all cabled together with my Netgear DGN2200 - ideally I would have a hassle-free wireless connection to my mother who is literally over the road, but in the past we have had issues with Aireplay-kiddies in the neighbourhood. Truly random and annoying. At worst I'll run CAT5e across the main road heh.

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

How difficult would it be to trace the location of these deauth. attacks? Can it be done with backtrack associated tools or would you need special hardware? I notice netstumbler has a provision for GPS location, is that of any help in such a trace?

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

How difficult would it be to trace the location of these deauth. attacks? Can it be done with backtrack associated tools or would you need special hardware? I notice netstumbler has a provision for GPS location, is that of any help in such a trace?

Very difficult and probably impossible. If the attacker has bothered to spoof their MAC address, nothing of value can be found by sniffing. If the attacker is lazy, and uses their real MAC source address, it might be possible to identify the maker and model of the device.

However, a deauth and arping attack generates quite a bit of traffic from the client. That makes it very easy to trace with direction finding.

Nope. Backtrack is a badly named Linux live CD that does many things, but little to help trace the source of attacks.

If you mean for direction finding, yes. A big dish, step attenuator, and a really well shielded radio. For sniffing, anything that does promiscuous or monitor modes will work. Forget about doing anything useful with Windoze.

No. The attacker would need to voluntarily broadcast their position in order for that to be effective. I doubt anyone is dumb enough to do that, although it might be possible by accident.

Meanwhile, at the alt.internet.wireless Job Justification Hearings, Desireless chose the tried and tested strategy of:

You could consider 5GHz [11a] - that might put off some kiddies. Also, if it's just the backhaul you're worried about, use non-wifi wireless, like Ubiquiti Airmax, eg pair of Nanostation Loco M5s, £66 a pop:

They can also be used in Wifi mode if the non-wifi mode doesn't suit.

Sorry for the delay in replying. To answer the original post, we have two blocks of flats closeby and think that's where it originates from - which really is the pain in the buttocks.

Why is 5GHz better? Or please direct me to a webpage to study :)

Meanwhile, at the alt.internet.wireless Job Justification Hearings, Desireless chose the tried and tested strategy of:

Merely on the basis of security by obscurity, as 5GHz kit is less common than 2.4GHz - your tormentors may only have 2.4GHz adaptors. Range is worse

- they many not be able to reach you. There is more bandwidth available at

2.4GHz than 5GHz, too.

NDIS 6.x (Windows Vista/7) and MS Network Monitor 3.4 is quite usefull.

Supports Monitor Mode.