RE: Detecting AIRsnorting guys


From: Clint Todish (ctodish_at_crayon.com)
Date: 2002-10-02 06:07:25 UTC


Is your intention to write this application to increase security of wireless nets or just to write an AirSnort detection application for the fun of it? There are far more effective ways to make sure a network is secure than to watch for Airsnort users (especially since aps like Kismet don't actually have to make an association to find/snoop your network). One way is using IPSec or PPTP to a single gateway machine on or behind your HostAP box, turning off bridging on the wireless side ("prism2_param wlan0 ap_bridge_packets 0") so other wireless hosts are layer 2 inaccessable from the same wireless net and applying a healthy dose of iptables. *Authenticated* users on the wireless side will still be able to access each other over what ever tunnel methodolgy you use. WEP is really not protection you want to trust in its current state and with a system that relies on stronger security running further up, who cares if airsnort users waste their time. On my network (which serves several friends in the neighborhood), WEP is diabled, a user receives an IP/DNS and default GW via DHCP, iptables makes sure only 1 IP is reachable and even redirects ALL other IP traffic to that one host:

-A PREROUTING -i wlan0 -d 10.100.0.1/32 -j ACCEPT
-A PREROUTING -i wlan0 -s 10.100.0.0/24 -j DNAT --to-destination 10.100.0.1

where 10.100.0.1 is a windows 2000 box running DHCP/DNS and RAS (PPTP) and has very restricted IP Filters on the wireless side NIC. If a passing user were to get an association, they would get an IP address on the 10.100.0.0/24 network via DHCP - but would be unable to get to any other wireless devices on the net. DNS works, but pinging any outside resolved addresses results in the user pinging 10.100.0.1. The logic behind this is : there is a web server running on 10.100.0.1 telling unauthorized users to go away which they will promptly see if they open a web browser. Authorized users know to 'dial-in' to the network via PPTP and if you set up the automatic internet connections for windows users, this happens automagically, too. The w2K machine also dumps all event log traffic to an internal linux box via syslog that parses for people who might have 'forgotten' their login credentials. You could easily replace the w2K in this example with one HostAP linux machine as a single (DNS/DHCP/HTTP/PPTP/IPSec/HostAP/Firewall) "secure 802.11b access point" system.

Not saying detecting Airsnort users is pointless, rather, there's always the bigger picture to consider.

good luck.
-C

/*
Hi,

I'm trying to write a wireless security program that would detect initial net stumbler activity (looking out for probe requests), save the mac address, discard the mac address if authentication was successful. If no authentication is done, actively check whether the client is still within range.

Detecting netstumbler can be done by going into monitor mode, so can authentication detection.

However, I'm not too sure how to check whether the client is still around (WEP cracking, passive sniffing). What I was thinking of doing is sending my own RTS packet out to the sleeper and checking for CTS. Hopefully RTS/CTS response is firmware level and nothing can be done in software level to avoid response.

How do I frame my own RTS packets and send it through host AP? DOes host AP in monitor mode display RTS packets?

Thanks

Seng Oon Toh
Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gte746m_at_prism.gatech.edu
*/



This archive was generated by hypermail 2.1.4.