Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

{mospagebreak toctitle= Introduction}

Introduction

Wireless security - two words generally spoken in the same tone as "jumbo shrimp" and "government organization". Because of the nature of the technology, and the easily-broken encryption solutions that are currently out there, it becomes a question of not if, but when an attack will occur. Small- and home-office users are especially vulnerable, as they generally have more important things to worry about than securing their wireless assets and lack the resources of larger companies to devote to a security contact or team.

But all is not lost, as there are ways to verify the security of a wireless network despite the oxymoron that wireless security generally conjures to mind. Intrusion Detection Systems (IDS for short) provide a way to detect these attacks even before they happen, while the intruder is still casing the place. They are not the be-all-end-all to security, but when combined with firewalls and other security tools they can be very powerful. It is helpful to think of IDS as similar to burglar alarms: they will tell you that a break-in has happened, but leave it up to other systems to handle the break-in itself.

The namesake of the Snort IDS

Figure 1: The namesake of the Snort IDS

Snort is an open source IDS that can be custom-tailored to fit your wireless network. Calling itself "the de facto standard for intrusion detection", Snort is flexible, fast, and most importantly, free. All it takes is a little bit of elbow grease to get it up and sniffing away at wireless traffic.

Snort and other IDS can be especially effective when dealing with wireless attacks. In a previous series, Humphrey Cheung talked about how the Wired Equivalent Privacy (WEP) encryption scheme can be easily cracked. In addition to this, even more advanced encryption methods can be cracked and wireless authentication schemes broken by a determined attacker. This makes Snort a vital tool in detecting these kinds of attacks and stopping them before they begin.

There is a version of Snort available that is tailored specifically towards the wireless user. Appropriately titled Snort Wireless, this version contains rules that are suited to detecting some of the most common attacks against a wireless access point, and can also be custom-tailored to the specific needs of a wireless network. This article will give you a basic outline of Snort's operation and how it can be applied to your wireless network, leaving the specifics of deploying it up to you.


Snort 101

Snort is a very complex program. There are HOWTOs, books, and even lectures that all deal with how to set up and operate it. I will not get into the nitty-gritty details about Snort in this article, since that is best left to the more elaborate introductory materials and courses. But I will provide you with some fundamentals that will help you set the software up and then learn as you go.

Snort works by loading preset malicious traffic patterns called rules (Figure 2) that help it to identify which traffic on a network will be harmful. This is similar to anti-virus programs, and the similarity extends to keeping rules updated. Snort can only look for what it knows about, so diligence in updating the program on the part of the system administrator is a must.

A set of Snort rules just waiting to be broken

Figure 2: A set of Snort rules just waiting to be broken
(Click image to enlarge)

Rules follow a fairly simple syntax, outlined below:

<action> <protocol> <first host> <first port> <direction> 
 <second host> <second port> (<rule options>;) 

The actions can include alert, which generates an alert to the IDS which can then be acted upon, log, which simply logs the packet, or pass, which ignores the packet completely. Rule options include options pertaining to the content of a packet (such as a certain Byte content or size) as well as the message to include when logging it. Here is an example rule, which tells Snort to generate an alert if a machine is pinged:

 alert icmp any any -> 192.168.1.1 any (msg: "Oh snap it's a ping";)

This rule listens for a ping from any host directed towards the router (in this case, 192.168.1.1) and creates an alert with the message "Oh snap it's a ping". More complicated rules can include variables (such as for a range of IP addresses comprising a home network or an external network) or even other files to use. For a good introduction to the different facets of Snort rule writing, check out How to Write Snort Rules and Keep Your Sanity in the Snort manual.

In addition to rules, Snort can be configured with several pre-defined rules called preprocessors that scan traffic before the rules set in. Preprocessors are especially useful for routine or expected traffic such as portscans and pings that would cause a significant slowdown if they were passed to the more resource-intensive rules.


Setting up

Before you begin, you need a system that is capable of not only running Snort, but also acting as a wireless access point. The cheapest way to do this is with the venerable Linksys WRT54G wireless router [reviewed here]. The WRT54G runs open source firmware that can be replaced with many alternative distros that offer enhanced capabilities - including running Snort. Alternatively, if you have a spare machine, a wireless card, a normal Ethernet adaptor, and a lot of spare time, you can set it up as an access point.

Linksys WRT54G

Figure 3: Linksys WRT54G

This article will use examples using a WRT54G router running OpenWRT RC 2 (codenamed 'White Russian'). There are many Linux distributions for wireless routers available (something I hope to cover in a future article), but I chose OpenWRT because it is simple, lightweight, and comes with a package system similar to Debian Linux.

OpenWRT in action

Figure 4: OpenWRT in action
(Click image to enlarge)
NOTE!Disclaimer: Loading OpenWRT, Snort Wireless or other alternative firmware onto your WRT54G will void your warranty.

SmallNetBuilder, Pudai LLC and I are not responsible for any damage that the information in this article may cause to your WRT54G.

So download a copy of the current firmware before you start, and don't go trying to get help from Linksys if you break it.

I won't go into the details of installing OpenWRT, since there is very good installation documentation on the OpenWRT website. Once the install is complete, you can Telnet into the router [instructions here] and poke around.

Once OpenWRT has been set up on the router, the Snort Wireless program may be downloaded and installed. This can be done through OpenWRT's aforementioned package manager system, ipkg, with the following command:

ipkg install http://nthill.free.fr/openwrt/ipkg/testing/20041204/snort-wireless_2.1.1-1_mipsel.ipk

Note that this package is nearly a year out of date. This is all right, as all of the basic functionality that we want in an IDS is still there, and all of the latest Snort rulesets may be downloaded with ipkg (see the OpenWRT tracker page for details on the latest packages). For those of you running a dedicated machine as an access point, you can get a copy of the Snort Wireless source and compile that on the machine. Take special care to add the --enable-wireless flag when you configure, otherwise the Wi-Fi-specific preprocessors will not function.

Snort Wireless works in a similar way to Snort itself, but is intended to be deployed on a wireless access point to defend against wireless attacks. In particular, it contains a new rule protocol (entitled wifi) to allow the IDS to properly identify traffic associated with common wireless attacks such as Netstumbler traffic or WEP cracking attempts. Using the wifi protocol for rules in Snort Wireless follows the same pattern as writing normal Snort rules, with one notable exception: instead of specifying the IP addresses and ports of the first and second hosts, their MAC addresses are used.


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)

Blast off!

Once your snort.conf file has been configured, you can start running Snort. It can be started with a number of different options that specify everything from output to how it should be run. For now, though, let's just run it with the following command, entered via a Telnet connection into your Snort-enabled system:

 snort -D -A full

This command runs it as a background process so that other things can be done and logs full packet information when an alert is generated.

Now that Snort is up and sniffing away at packets, there are many more things you can do to bolster its ability to protect your wireless network. Kismet is a tool similar to Snort that can be deployed as a secondary intrusion detection system. Snort only operates on Layer 3 - the network layer, responsible for IP and other traffic - while Kismet operates on Layer 2 - the datalink layer, responsible for Ethernet frames. So deploying both these programs in tandem can greatly increase the effectiveness of your system.

Kismet in action

Figure 8: Kismet in action
(Click image to enlarge)

You can also configure Snort to log to a database for easier log analysis. Daniel Walther has written a tutorial on how to do this with MySQL and PostgreSQL. And if you are running Gentoo Linux on your access point machine, this can be taken one step further by including Apache and making the log files web-based. The Gentoo Wiki has a detailed HOWTO for setting this up.

Web-based Snort logs via MySQL, ACID, and Apache

Web-based Snort logs via MySQL, ACID, and Apache
(Click image to enlarge)

Conclusion

I have only touched the tip of the Snort iceberg in this article. While I've laid the groundwork for you to deploy a basic version of Snort on your AP, there are still many ways that you can expand on it and much more about Snort to learn. In particular, you may want to read over more of the specifics of how to write effective Snort rules, as this will allow you to better adapt Snort to your network environment.

Finally, the most effective thing you can do to protect your wireless network is keep up to date with Snort's patches and rules updates. Keep tabs on the Snort Wireless homepage, as well as the ipkg package tracker (for OpenWRT-based installations) or the Snort rules page (for other installations), to get the latest program and rules updates.

As with all security tools, Snort should not be looked at as the final step in defending your network as much as a single brick in the wall of network security. Snort is a tool, and tools are only as good as their users. If you truly want to secure your network, no number of intrusion detection systems and firewalls will keep everyone out. Common sense and diligence in your day-to-day monitoring are still the rules to live by for effective network security.


For further reading