How To: Sniffing the Air

Preparing the Pig

Now that you have Snort Wireless up and running, the next step is to configure it for use on your particular network. When ipkg is run, Snort installs itself into the /etc/snort directory on your router. Like all good Unix-based programs, Snort uses an editable configuration file to give it information about its network environment and the different attack patterns that it should look for. This file is called snort.conf (Figure 5) and is located in the /etc/snort directory. Open it up in your favorite text editor (or download the program with ipkg if it is not available on the router by default).

The snort.conf configuration file as seen in vi

Figure 5: The snort.conf configuration file as seen in vi
(Click image to enlarge)

You can now configure all of the different variables for your specific network, including the wireless access point name that the IDS is running on and all of the relevant MAC addresses of clients that you wish to be masked from potential spoofers. There are a lot of preferences to configure here, so make sure you read all of them to make sure you've covered all that apply to your setup.

In particular, several things you may want to pay attention to are the Wi-Fi-specific preprocessors that Snort Wireless adds. These include the preprocessors for detecting passive network scans with programs like NetStumbler and MAC address spoofing attempts, among others. These preprocessors and what they do are outlined below:

  • AntiStumbler - Programs such as NetStumbler and MacStumbler (Figure 6) utilize null SSIDs in order to discover other access points. These are SSIDs that are set to 0 bits, which act as broadcast SSIDs (similar to broadcast ping requests) and coax other access points into returning their SSIDs to the broadcasting host. This is useful for wardriving and other network reconnaissance attempts. The AntiStumbler preprocessor identifies when too many null SSIDs are sent from a single MAC address and can then alert the IDS that a potential attack is occurring.NOTE!NOTE: This preprocessor cannot detect wardriving programs such as Kismet, as they simply listen for raw 802.11 frames instead of sending out requests

The AntiStumbler preprocessor can alert you to this type of recon attempt

Figure 6: The AntiStumbler preprocessor can alert you to this type of recon attempt
(Click image to enlarge)
  • DeauthFlood - The attack detailed in Humphrey Cheung's article on how to crack WEP uses a deauthentication flood to get hosts to disassociate with a given access point and attempt to reauthenticate, thereby generating more packets to help with a WEP cracking attempt. This can also be used as a Denial of Service (DoS) attack against the access point. DeauthFlood detects this kind of attack by looking for a specific number of deauth frames sent within a certain amount of time and then generating an alert.

  • AuthFlood - Similar to DeauthFlood, the AuthFlood preprocessor detects and alerts against authentication flooding attacks, which involve a client attempting to associate with the wireless network many times and can be used to DoS the access point.

  • MacSpoof - One of the most effective ways to limit access to an access point is to set up 'white lists' of MAC addresses that can associate with the access point, and include all others. Unfortunately, a savvy attacker can spoof a white-listed MAC address on his or her machine and authenticate with the AP. The MacSpoof preprocessor examines the sequence numbers of packets received for any anomalies that hint at spoofed MAC addresses and generates an alert.

  • RogueAP - Rogue access points are malicious access points that attempt to masquerade as benign access points in order to get a user to authenticate with them and unknowingly give up sensitive personal information. This preprocessor has not been implemented yet, but in future releases it will alert the user to rogue access points in the router's vicinity.

Additionally, Snort Wireless includes many preset rules for a wide range of situations. Depending on your network setup, some of these rules may come in handy, such as all of the web rules if your network runs a webserver. You just uncomment rulesets that you want Snort to use. Individual rulesets are kept in /etc/snort/rules by default, and you can view any of these rules in your favorite text editor. They follow the same pattern of Snort rules outlined earlier, and provide good examples for learning how to write your own rules.

A portscanning host is caught and logged by one of Snort's rules

Figure 7: A portscanning host is caught and logged by one of Snort's rules
(Click image to enlarge)