Hack 43. Control Wireless Access by MAC

Restrict your wireless client access using a hardware address set in FreeRADIUS.

Sometimes, you don't want just anybody using your wireless access point (AP). Most APs available now feature hardware-addressbased (MAC) access control. With this feature enabled, only wireless devices with MAC addresses that you specify will be allowed to associate with the AP.

It's important to note here that MAC access control is not foolproof. It can be defeated by someone who is using a wireless scanning program such as Kismet [Hack #29]. Once an attacker has a valid MAC address, it is trivial to spoof that address and gain access to your network. You need to consider using a wireless encryption protocol such as WPA on all of your access points in addition to any access control that you choose to enable.

Many APs allow you to store a list of allowed MAC addresses in the AP itself. This is good enough if you have a small, infrequently changing set of allowed clients. The downside is that in order to change the list in the AP, it's usually necessary to use some special configuration utility and reset the AP (thus kicking all of the current users off) in order for the changes to take effect. The AP itself also usually has a limit on the number of access control entries that it can store.

There is a way around this problem, though: some APs, including the Apple AirPort line and the Linksys WAP54G, have the ability to query a RADIUS server for the access control information. This has several advantages, the most obvious being that changing the access control list means (at worst) restarting the RADIUS server. Nobody currently using the AP is kicked off when you change the access control list. The second advantage is that you can have a much larger set of allowed clients than can be easily managed on the AP itself.

There is also one disadvantage: using a RADIUS server for access control means that it has to be up in order for anyone to use the access point. All of the APs I've tested fail closed; that is, when they can't contact the RADIUS server, nobody gets in.

If you've decided that RADIUS-based access control is for you, it's time to set it up. The examples here assume an Apple AirPort AP and a FreeRA-DIUS server running on a Linux or Unix system on the same network. FreeRADIUS source code can be found at http://www.freeradius.org, and it is available as a package for most Linux and BSD distributions.

3.5.1. FreeRADIUS Configuration

First, let's get the RADIUS server set up. FreeRADIUS is so flexible that it would really take a whole book to cover it. Thankfully, you need only the tiniest subset of its functionality for this hack.

Whether you've installed from a vendor-supplied package or built from source, there will be a directory that holds the configuration files. On our example system, it's /etc/raddb. Hopefully, your out-of-the-box configuration is amenable to just modifying the files mentioned in this hack. The distribution configuration files are full of helpful comments as well; they're probably the most accessible parts of the FreeRADIUS documentation set.

The first order of business is to allow the AP to talk to the RADIUS server. This setup happens in the /etc/raddb/clients.conf file. On my network, my AP is 10.1.1.253; its stanza in clients.conf looks like this:

client 10.1.1.253 { secret = letmein shortname = travellingcircus }

The shortname field is optional; I use it to keep track of which AP is which in the clients.conf file. Standard shell-style (#) comments are also supported, so you could keep track that way as well.

Now, it's time to set up your access control lists of user MAC addresses. These entries go in the /etc/raddb/users file. There's a decision you need to make here. There are two different MAC address formats to choose from: the Lucent/Agere format or the Cisco format. Apple's Airport Admin Utility calls these Default and Alternate, respectively; don't worry if you can't remember the differences, because the configuration pane has a helpful explanation for each.

The Default (Lucent/Agere) format has the address formatted as xxxxxxxxxxxx for the user name, and the password is the shared secret that you used in /etc/raddb/clients.conf. The Airport card in my PowerBook has a MAC address of 00:30:65:24:E6:63, so the Default-format entry for it in the users file looks like this:

003065-24e663 Auth-Type := Local, User-Password == "letmein"

It's important that the hex digits of the MAC address be in lowercase. The Default format has the advantage of being slightly more flexible; if you have multiple APs with different shared secrets, you can use that to restrict who can associate with the different APs. On the other hand, if you don't want that degree of access control but still want your APs to have different shared secrets, the Default format can make adding new users slightly more painful.

The Alternate (Cisco) format is a little simpler. Both the address and the password are simply the MAC address, all in lowercase, with no delimiters. My PowerBook's Alternate format entry in /etc/raddb/users looks like this:

00306524e663 Auth-Type := Local, User-Password == "00306524e663"

Now that the files are all set up, it's time to see if the configuration is correct enough to allow the server to start. FreeRADIUS has excellent (and copious) debugging output. Most problems can be located by reading the debug output carefully.

Initially, start radiusd with the -X flag to get a non-forking single server instance with debug output on stderr (your terminal). If all goes well, you'll see output at the bottom:

Listening on authentication *:1812 Listening on accounting *:1813 Ready to process requests.

If you don't see that Ready to process requests line, or if you get a prompt back, make sure you used the -X flag, and carefully read the debug output starting from the bottom up.

3.5.2. Access Point Configuration

Assuming that your RADIUS server started up, it's time to configure your AP. These examples configure an Apple AirPort Express using Apple's Air-Port Admin Utility. If you have a different model AirPort, don't worry; the interface is the same. And if you have a different kind of AP, they will all need the same information to function with RADIUS.

Start the AirPort Admin Utility and select your AP from the list. Supply the admin password and you should see a panel-like interface with tab buttons along the top. Select the Access Control tab and you should see a screen that looks something like Figure 3-5.

Figure 3-5. Access Control tab

There are four pieces of information you need to specify: the query format to use, the IP address of your RADIUS server, the port it's listening on, and the shared secret. The shared secret should match what you put in to the /etc/raddb/clients.conf file. The port number to use is the one that radiusd reported as its authentication port when you saw the debug output. The Primary IP Address is the IP address of the system running radiusd. The address format you pick is up to you. As shown in Figure 3-6, the data that you need to enter is the same for both.

Figure 3-6. A full Access Control configuration

Click the Update button, wait for your AP to reboot, and then try to associate with it. The RADIUS server should keep you well apprised of the packets that it's receiving and sending. Here's some output from a successful association. As you can see from the following below, I'm currently using the Alternate format:

rad_recv: Access-Request packet from host 10.1.1.253:1812, id=28, length=70 User-Password = "00306524e663" User-Name = "00306524e663" NAS-Identifier = "10.1.1.253" NAS-IP-Address = 10.1.1.253

This is a dump of the incoming RADIUS authentication packet. The NAS-Identifier comes from the AP, and the NAS-IP-Address is the AP's IP address. You could use this in your user file to further restrict access if you desired.

If you've gotten this far, the hard part is over. Now, arrange for your radiusd to start at system bootup, start it without the -X flag, and Bob's your uncle!

As I mentioned before, you'll need to restart the RADIUS server after adding or deleting access control entries. You can get around that requirement by storing the users entries in an SQL database, but that's significantly more effort, and would require a book of its own.

Cloyce Spradling