Re: [WIRELESS-LAN] Handling Wifi Deauth Attacks

gt; <scleme...@gmail.com> > Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Date: Tuesday, April 3, 2018 at 6:23 PM > To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU&

RE: [WIRELESS-LAN] Rogue Containment (Was Re: Handling Wifi Deauth Attacks)

@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Rogue Containment (Was Re: Handling Wifi Deauth Attacks) On Apr 3, 2018, at 10:42 AM, Kenny, Eric <eric_ke...@harvard.edu> wrote: > > §333. Willful or malicious interference No person shall willfully or > maliciously interfere with or cau

Rogue Containment (Was Re: Handling Wifi Deauth Attacks)

On Apr 3, 2018, at 10:42 AM, Kenny, Eric wrote: > > §333. Willful or malicious interference > No person shall willfully or maliciously interfere with or cause interference > to any radio communications of any station licensed or authorized by or under > this chapter or

Re: [WIRELESS-LAN] Handling Wifi Deauth Attacks

Eric, I’ve never heard of a consumer device deauthing STAs that aren’t associated to themselves. If you happen to get a packet capture I know some people that would be interested in looking at it. The only case of malicious deauths I’ve seen was from an enterprise vendor IPS. GT On

Handling Wifi Deauth Attacks

While investigating some “wifi is slow” and “wifi is dropping” complaints, we noticed deauth/disassociation flooding attacks reported by our wireless IDS. So far I’ve been able to identity a small percentage of these as local businesses and other local (non-university affiliated)