How many IDS solutions that implement the recommendations and follow the guidelines we have already discussed are present on the modern wireless market? The answer is none.

There are many wireless IDS solutions that look for illicit MAC addresses and ESSIDs on the monitored WLAN. Some of these solutions are even implemented as specialized hardware devices. Although something is better than nothing, in our opinion such "solutions" are a waste of both money and time. They might also give you a false sense of security. Let's look at the available wireless IDS solutions that can be useful or at least hackable, so that you can modify the tools to take at least partial advantage of the observations we outlined and additional data constantly streaming from the wireless frontlines.

Commercial Wireless IDS Systems

On the commercial side, well-known wireless IDS solutions include AirDefense Guard and Isomair Wireless Sentry. These solutions are based on deploying an array of sensors around the monitored WLAN and centralizing their output to the management server or console. The server can be a specialized hardware appliance with a secure Web interface and SNMP management or a Linux server machine linked to the Windows-based management console. Some of these solutions can analyze non-802.11 wireless traffic or even the RF interference in the monitored band, which is useful.

It should be said that depending on the wireless network size and coverage zone, the deployment of wireless hardware IDS sensors can be essential. Every point of wireless access in the organization should be covered by an IDS sensor to provide efficient network monitoring. The higher the sensors' receiving sensitivity is (in negative dBm), the better. At the very least, the receiving sensitivity of the sensor should not be worse than one of your AP transceivers (but even that would not guarantee the reliable detection of attacks targeting wireless hosts at a sufficient distance from the AP). A great disadvantage of all commercial sensors we have seen is the inability to connect an external antenna to the sensor. Thus, the possibility of greatly enhancing the sensors' range and sensitivity is dramatically diminished. It is clear that companies would have to buy more lower-range and lower-sensitivity sensors to cover their wireless networks. However, one can charge more for more powerful sensors connected to appropriate antennas. Unfortunately, the current marketing trend seems to follow the first principle. Of course, you can hack the commercial sensor to wire up an antenna (and lose your warranty). Perhaps a better and more flexible solution is to build your own custom sensors using old PCs, laptops, or even PDAs;

WiSentry is a commercial software-only solution for WLAN monitoring and intrusion detection that does not require specialized hardware sensors. WiSentry creates a specific profile entry for each deployed wireless host. This profile is stored by the WiSentry software and is used to differentiate between trusted and nontrusted devices. WiSentry has a configurable IDS alerts database and supports 802.11a, b, and g networks.

Another commercial tool that combines both security auditing and IDS features is AirMagnet from Global Secure Systems. AirMagnet is available in handheld, laptop (must use Cisco Aironet cards), and "combo" editions. The distinctive feature of AirMagnet is a basic ISM band RF analyzer property, allowing the tool to discover 802.11b/g channels overlapping in the reception area, and it might detect possible interference. AirMagnet is able to flag out WEP-encrypted data packets with weak IVs and, in the latest versions, detect VPNs used on the scanned WLAN.

Proprietary software 802.11 protocol analyzers, such as NAI Sniffer Wireless and WildPacket's AiroPeek, also possess wireless IDS functionality. In fact, AiroPeek even supports the remote RFGrabber wireless sensor devices integrated with the AiroPeek sniffer software. This gives AiroPeek a distributed functionality similar to AirDefense/Isomair IDS systems. The full AiroPeek package includes the software development kit that allows customers to write their own AiroPeek filters in Visual Basic or C++. This wireless protocol analyzer is therefore partially hackable, despite being a commercial close source product.

Open Source Wireless IDS Settings and Configuration

The first such toolkit to be reviewed is WIDZ by Loud Fat Bloke (Mark Osborne). The version of WIDZ at the time of writing (1.5) supports the following:

• Rogue AP detection

• AirJack attack detection

• Probe requests detection

• Broadcast ESSID ("ANY")

• Bad MAC placement on a MAC block list

• Bad ESSID placement on an ESSID block list

• Association frames floods

WIDZ 1.5 uses the HostAP driver and works out of the box. It consists of two programs: widz_apmon, which detects APs not on the AP list (widz-ap.config), and widz_probemon, which monitors the network for possibly hostile traffic. The alerts that trigger the current WIDZ version widz_probemon include the following:

• alert1. Alerts if the ESSID field is empty. It then calls the Alert script and logs the next 100 packets from the suspicious source.

• alert2. Alerts if more than the maximum associations occur in less than a defined maximum associations time.

• alert3. Alerts if MAC is in the badmac file, which is a simple list of MACs in hex.

• alert4. Alerts if ESSID is in the badsids listing file.

Of course, this is a very limited list of alerts, but you can easily add alerts on your own. To use widz_apmon, first lift up your wireless interface with ifconfig, then use the widz_apmon |sleep_time| wlan0 generate command to produce the widz-ap.config AP list file. After that you can launch monitoring for rogue APs with widz_apmon |sleep_time| wlan0 monitor. The sleep_time variable refers to the time between scans in seconds. Using widz_probemon is just as easy. First edit the probemon.conf, badmacs, and badsids files. Then bring up your wireless interface, put it into RFMON mode, and run widz_probemon:

arhontus:~# ifconfig wlan0 up && iwpriv wlan0 monitor 2 && widz_probemon  wlan0  > logfile &  

The Alert shell script included with the IDS is executed automatically when a rogue AP or hostile traffic is detected. By default, the script sends a syslog message with the logger -p security.notice $1 command and writes the alert message to the current console. Alternatively you can make it send a warning e-mail, SNMP trap, add the offending MAC address to the ACL, and so forth—use your imagination.

An open source wireless IDS with more available features is wIDS by Mi Keli. This IDS tool does not care about the client card chipset or drivers; all wIDS needs is a wireless interface in RFMON mode. It also includes an automatic WEP decryptor (just place your WEP key in the Keys.lst) and wireless honeypot support (which unfortunately does not allow WEP on a honeypot yet). More important, wIDS can do the following:

• Analyze beacon intervals for every discovered AP.

• Analyze 802.11 frame sequence numbers.

• Discover probe requests from active scanning.

• Detect association request floods.

• Detect authentication request floods.

• Detect frequent reassociation requests.

• Dump the honeypot traffic into a pcap format file.

• Redirect the wireless traffic onto a wired interface.

The last option is very interesting, because by using it you can pipe the wireless traffic into Layer 3 and higher IDS tools such as Snort for further IDS analysis. Running wIDS is easy and straightforward:

arhontus:~#  wIDS

usage  : ./wIDS [-s] -i device [-l logfile -h honeypot] [-o device]

options  :

     -s          :use syslog (LOG_ALERT)

     -i device   :listen on the interface specified by device

                       (eth0, wlan0...)

                       (should be in promiscuous mode)

     -l logfile :file where honeypot packets  will be dumped

     -h honeypot :alert about traffic on the  specified honeypot

                 AP' MAC

     -o device    :device where decrypted traffic is sent for

                 IDS analysis

note    : "-s" option should be used.

exemple  :./wIDS -s -i eth1 -o eth0

        ./wIDS -s -i wlan0 -l ./wIDS.tcpdump -h  00:02:2d:4b:7e:0a

Finally, there is a new AirIDS wireless IDS that appears to be very promising. AirIDS has a GTK+ frontend and supports Prism and Cisco Aironet chipset cards. This tool is still in the beta development stage, but will support very flexible custom IDS rulesets, traffic injection to thwart WEP cracking, and active defenses from version 0.3.1 onward. To afford such features, AirIDS 0.3.1 and later versions will use heavily modified or rewritten Prism drivers (AirJack-style, perhaps) instead of the "usual" prism_cs/airo_cs modules it uses now.

A frequently overlooked and very powerful wireless IDS tool is Kismet. Kismet has come a long way from being a wardriver's tool to a full- blown client/server IDS. The most recent versions of Kismet implement the IDS recommendations derived from Joshua Wright's articles we referred to earlier. Find out which IDS features your version of Kismet supports by checking the Changelog. Don't forget that there is quite a difference between the Kismet-stable and Kismet-development trees: Kismet-development might have just implemented the most recent IDS feature you urgently need. The latest Kismet-development version at the time of writing included the following features:

• Deauthentication/deassociation frames flood detection

• 802.11 frame sequence analysis

• Flagging AirJack users in the monitored area

• Detecting NetStumbler probes and the version of NetStumbler running

• Detecting Wellenreiter ESSID dictionary attacks

• Packetcracker code to warn about FMS attack-vulnerable WEP

• Detection of probe-only clients that never join the network (Mini-Stumbler, Dstumbler, or simply lost and lonely misconfigured hosts)

• 802.11 DSSS / FHSS distinction

• Write data frames to a FIFO named pipe for an external IDS such as Snort

• Runtime WEP decoding

• Excessive RF noise detection

• Lucent Outdoor Router/Turbocell/Karlnet non-802.11 wireless network detection

These features, together with a client/server structure, easy-to-use alert system (just press w to open a separate alert window and browse the warnings), great structured data logging mechanism, and the possibility of integration with remote sensors such as the Neutrino Distributed 802.11b Sensor make Kismet a great free IDS tool to deploy. Additionally, the capability to use multiple client cards and splitting the scanned frequencies among these cards further increase the value of Kismet in wireless network monitoring and intrusion detection.

A Few Recommendations for DIY Wireless IDS Sensor Construction

You might consider building Kismet-based remote wireless sensors yourself. Although an old PC running Linux or BSD might not look as sexy as one of the slim devices from Network Chemistry, et al. (but you can always use Zaurus or iPAQ!), there are plenty of advantages to hacking up a custom IDS sensor. First of all, it's cheap: Your costs could run as low as the cost of a PCMCIA-to-PCI adapter and an additional client card. In addition, we were always suspicious of low-gain omnidirectionals used by ready-made wireless sensors. How about a custom-built sensor linked to a 14.5 dBi omni sold at http://www.fab-corp.com for a very reasonable price? Does it always have to be an omnidirectional, considering the possible shape of your network coverage zone? How about a sensor using a high-gain directional next to the long-range point-to-point wireless bridge? Won't you want to detect the attackers along your whole link, not just around the wireless bridge area? Don't you want to boost the receiving sensitivity of your sensor by an extra 10 to 20 dBm?

Another interesting and useful thing to do is integrating both Layer 2 wireless and higher-layer IDS tools or systems (Snort, IpLog, PortSentry) in a single device. You can use wIDS -o flag, Kismet FIFO named pipe, or just trigger your higher-layer IDS-controlling scripts with Kismet in the same way Kismet runs play and festival for audio WLAN activity indication. Snort will refuse to run when launched on a wireless interface—check it yourself. However, this problem is easily bypassed using Kismet. The first thing you have to do is change one line in the kismet.conf file: Scroll to #fifo=/tmp/kismet_dump, uncomment this line, save the configuration file, and start the kismet_server. Once started, Kismet will lock the /tmp/kismet_dump file until it is picked up by Snort. Now, let's start Snort. Configure it to your liking, but add an additional -r /tmp/kismet_dump switch when you run it, so it will read data from the FIFO feed of Kismet. You can further install and run ACID for pleasant and colorful IDS log viewing. That's it! Enjoy your highly configurable wireless and wired IDS, in many aspects widely superior to its expensive commercial counterparts. After all, how many client/server flexible integrated wireless and wired commercial IDS solutions do you know of?

Of course, additional means can be used to analyze the pcap format Kismet dump files. The most obvious way is using Ethereal and applying specific filters to pick up signatures of common attacks we have already described. For example, the Ethereal filters for common active scanning tools attack signatures as outlined in Joshua Wright's "Layer 2 Analysis of WLAN Discovery Applications for Intrusion Detection" paper and verified by us include the following:

• Netstumbler:

      (wlan.fc.type_subtype eq 32 and llc.oui eq 0x00601d and llc.pid eq 0x0001) and (data[4:4]     
       eq 41:6c:6c:20 or data[4:4] eq 6c:46:72:75 or data[4:4] eq 20:20:20:20)   
      

• Dstumbler (active scanning):
  

    (wlan.seq eq 11 and wlan.fc.subtype eq 11) or (wlan.seq eq 12 and wlan.fc.subtype eq 00)  
  

• Windows XP probing:
  

      wlan.fc eq 0x0040 and wlan_mgt.tag.number eq 0 and wlan_mgt.tag.length eq 32 and  wlan_mgt    
      .tag.interpretation[0:4] eq 0c:15:0f:03    

• Wellenreiter probe requests (in ESSID brute-forcing):

      wlan.fc eq 0x0040 and wlan_mgt.tag.number eq 0 and wlan_mgt.tag.length eq 29 and  wlan_mgt    
      .tag.interpretation eq "this_is_used_for_Wellenreiter

Of course, now there are many more 802.11 frames sending tools to look at and create novel filters. Such tools include the latest versions of AirJack, wepwedgie, Wnet dinj and reinj utilities, FakeAP and its modifications, and Void11. The Ethereal attack signature filters are useful in both security research and intrusion detection. They can be even more helpful in the incident response procedure should a break-in occur (but keep in mind that a proper secure storage and integrity validation of the pcap files must be ensured beforehand). Finally, if you are adventurous, you can try to use them and/or Kismet output to deploy active defenses and attack back or at least confuse the attackers automatically. For example, when a NetStumbler user is detected in the area, appropriate Kismet output or packet matching an attack signature defined by a filter can turn on FakeAP with preset ESSIDs or MACs ignored by Kismet (to avoid the possible log overflow DoS).

If for some reason you prefer not to use the Kismet + Snort combination, you can opt for the Snort-Wireless project. Snort-Wireless is a patched Snort capable of 802.11 frame understanding and Layer 2–related alert sending. At the moment, Snort-Wireless allows NetStumbler traffic detection via the AntiStumbler Preprocessor. Edit your snort.conf by adding preprocessor antistumbler: probe_reqs [num], probe_period [num], expire_timeout [num] where:

• probe_reqs is the number of probe requests that triggers an alert.

• probe_period is the time period (in seconds) for which the NULL SSID probe request count is kept.

• expire_timeout is the time (in seconds) before the detected offender is removed from the stumbler list.

Besides, rogue APs and ad hoc network detection are supported via the CHANNELS and ACCESS_POINTS variables, also defined in snort.conf. Although many features supported by the Kismet + Snort combination are not included in Snort-Wireless yet, due to the flexibility of the project and the possibility of writing 802.11-related rules the same way the standard Snort rules are written, the Snort-Wireless project has great potential.

Don't forget that many "industry-standard" wireless IDS sensors still use telnet and SNMPv1 as the means of remote administration and transmit captured wireless data without encryption and integrity checks. Did anyone just mention the default SNMP communities? We have encountered commercial wireless IDS sensors remotely controlled via the read-write "public/private" community by default! Unfortunately, even system administrators often do not change the default settings of network devices. We expect that a long time will pass before these devices will start supporting SSHv2, not to mention IPSec. On the other hand, custom-built sensors can employ any kind of traffic protection and access control you choose. For example, you can build a network of custom-built sensors linked to the centralized IDS server via the host-to-network VPN topology.

The choice of a hardware platform for your sensors can vary. One interesting possibility is using suitable Soekris boards (http://www.soekris.com). Because these boards support optional hardware-based encryption, they can be highly suitable for the solution just suggested. Several Soekris-based custom-built wireless sensors wielding appropriate high-gain antennas and capable of transmitting large volumes of data via AES-encrypted IPSec tunnels to the centralized IDS server integrating Kismet, Snort, and a few other traffic and log analysis tools make a dream distributed and affordable wireless IDS, indeed! Soekris boards were designed to run Free/Net/OpenBSD or Linux. Check the documentation on various board versions and their capabilities at the Soekris site.

Another interesting and fanciful wireless IDS sensor platform is an old iPAQ PDA with a double PCMCIA client card cradle. One cradle slot would hold an Ethernet client card for wired connectivity, and the other one would carry a wireless client card (we recommend Cisco Aironet 350 with double MMCX connectors to avoid the need for software channel hopping and plug in an appropriate antenna). You can install Familiar or a similar distro on the iPAQ, download and install the .ipkg Kismet package, and set up SSH- or VPN-based connectivity to the central IDS monitoring server. An iPAQ-based sensor would be the only wireless IDS sensor with a "local" display to view WLAN events. Envision a company that has the main IDS server in its central office and branch offices with monitored wireless networks at remote locations. With iPAQ-based sensors, system administrators at the remote locations will be able to monitor wireless activity for their location locally, and the chief network security and administration staff can observe the events in all sites at the central IDS server and verify them with branch admininstrators. To make the use of such sensors more convenient for less experienced local branch technicians, a GUI for Kismet (WireKismet) can be installed on the client or the sensor itself. In this case you might want to enhance security features of such a sensor.

Unfortunately, there is no double client card cradle for the Sharp Zaurus yet. One could try to use the CF and SD slots of this wonderful PDA for wireless and wired connectivity. There are wireless SD client cards manufactured by SanDisk and Socket that can be used in a Zaurus-based wireless IDS sensor connected to the central IDS server via a CF Ethernet card. We don't have experience using these SD cards and aren't aware of their practical receiving sensitivity and the possibility of wiring up an external antenna.

Finally, a custom-built wireless gateway or access point can contain a built-in IDS sensor or server. In fact, you can add several sensors to such an AP (e.g., one for ISM and another for the UNII bands). All that limits you in this case is the number of PCI slots on the sensor's main board and the availability of wireless client devices to plug in. Again, Soekris boards can be used for deploying efficient and affordable VPN-enabled secure wireless gateways implementing additional network monitoring and intrusion detection functions.

The possibilities for the experimental building of custom 802.11 or Bluetooth sensors or sensor, AP, and gateway combinations using open source software are incredible. The only thing you have to keep in mind is that there is still no perfect IDS for wireless networks. Thus it doesn't matter how good the deployed IDS is; nothing can substitute for knowledge and a trusted wireless protocol analyzer should suspicious events take place.