Wireless Authentication and Encryption with Zeroshell Linux (Part 2)

Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In part 1 we got our FreeRADIUS server up and running on Zeroshell Linux, and learned how to configure wireless access points to pass authentication requests to FreeRADIUS. Zeroshell eases the process considerably by streamlining user management, encryption key management, and setting up your WAPs. Today we’ll configure Linux clients to authenticate to your stout FreeRADIUS server, and point the way to some good Mac OS X and Windows client howtos.

Linux Wireless Clients

Way back in the bad old days, all of this stuff had to be configured by hand. In plain text files. Uphill both ways. Now there are some good Linux GUI clients such as Network Manager and KWlan, so everyone should be happy because they can use whichever one they want. Except they don’t always work, so I’ll show you the olden method, and then GUI users can easily figure out what to do from there. It’s all the same configuration parameters; they’re just arranged a little differently.

To enter a secured wireless network you need a supplicant. The name was chosen deliberately, with its connotations of humbly requesting access. Linux users need the wpa_supplicantpackage. You also need to copy the server’s public key and each user’s private key to their PCs. This is the part where a some admins wail about it being too much work, having to do all that copying. I am unsympathetic. This is the strongest authentication security you can implement on a wireless connection. Once it’s all set up you don’t have to lift a finger, nor do your users; it just works. Users don’t even have to hassle with a password.

One important thing to keep in mind is this only encrypts traffic between the client, the authentication server, and the access point. Once it’s authenticated and roaming your LAN, it’s in the clear. Then you need the same authentication tools as any wired LAN client — OpenSSL for Web pages, SSH for secure remote administration, and so forth. There is no such thing as LAN-wide encryption — encryption always takes place between two specific endpoints.

The first step is to go into your Zeroshell Web control panel and export the server’s public certificate. Start at Security -> X.509 CA -> Trusted CAs. Select it and then click the Export button, and save it to a local file, USB stick, network share- anywhere that’s convenient for you to distribute it. It’s safe to share it freely. You can verify that it’s a public key by clicking the View CA button, and scroll down to where it says BEGIN CERTIFICATE. Private keys say BEGIN RSA PRIVATE KEY and should never ever be shared. Zeroshell’s export command ensures that you won’t accidentally get private and public keys mixed up.

You may name this certificate anything you want, as long you export it in PEM format and preserve the .pem extension. PEM stands for Privacy Enhanced Mail, because originally it was intended to be a mail encryption protocol. It’s a plain-text encoding format for X.509encryption certificates, and is the most widely-supported format for certificate files. DER and PKCS#12 are binary formats that are also well-supported, but not as much as PEM.

Now export the user’s keys. Go to the Users page, select a user, and click the X.509 tab. For Linux users use the PEM file format. This combines both their public and private keys in a single file, so you must protect it carefully. For Windows clients export it to PKCS#12 format. I like to copy them to a USB stick, since I’ll probably end up making a personal visit for final tweaks and testing anyway.

Copy the two keys to your Linux clients. I like to put them in a directory called /etc/radiuscerts. Change the ownership on the user’s private key to username:root, read-only by owner:

# chown alrac:root alrac.pem
# chmod 0400 alracs.pem

Configuring wpa_supplicant

Copy this entry, substituting your own ssid, login, and certificate names:

## /etc/wpa_supplicant.conf
ctrl interface=/var/run/wpa_supplicant

Let’s take a walk through this configuration file and see what it all means.

ssid is required; you have to enter the SSIDof your wireless network. You may enter any number of different networks in this file, using this format to set them apart:

 network={ } 

Use scan_ssid=1 when your access point doesn’t broadcast its SSID. There is nothing to be gained by not broadcasting the SSID, but some admins think it adds security. No it doesn’t. The default is scan_ssid=0, so use it only when you need it.

key_mgmtspecifies which key management protocol to allow. Don’t allow any that you don’t want used.

proto lists your accepted protocols. We’re being very restrictive, so only WPA2is permitted.

pairwisenames your allowed unicast ciphers. CCMP (AES in Counter mode with CBC-MAC, which you look up yourself) is the strongest.

groupnames your allowed broadcast ciphers.

eap tells which EAP(extensible authentication protocol) method or methods to accept.

identityis the user’s FreeRADIUS login name.

ca_cert and private_key, I do believe, are obvious. The wpa_supplicant documentation is abundant but a bit scattered, so be sure to refer to its man pages and example wpa_supplicant.conffile to learn more.

Test Your Setup

Now run a quick command-line test to see if it works. Shutdown your wireless interface first. You need to know which wireless driver you’re using; this examples uses the Madwifi drivers for Atheros-based interfaces:

# ifdown ath0
# wpa_supplicant -i ath0 -c /etc/wpa_supplicant.conf -D madwifi -w

If you see something like “WPA: Key negotiation completed…CTRL-EVENT-CONNECTED” you did it right and everything is working. Your final step is to set up wpa_supplicant to start when your wireless interface comes up. On Debian, Ubuntu, and all the rest of the Debian family, add these lines to the pertinent interface stanza in /etc/network/interfaces. In this example the interface receives a DHCP assignment:

auto ath0
iface ath0 inet dhcp
pre-up wpa-supplicant -i ath0 -D madwifi -Bw -c /etc/wpa_supplicant.conf
post-down killall -q wpa_supplicant

On Fedora, CentOS, Red Hat, and the rest of gang, add this line to /etc/sysconfig/network/network-scripts/ifup-wireless:

wpa_supplicant -i ath0 -c /etc/wpa_supplicant.conf -D madwifi -Bw

Of course you will use your own file location and interface name. See man wpa_supplicantfor the names of other drivers and command options.

Windows Clients

Windows is a bit of a mess when it comes to this stuff. Support for WPA2 and EAP-TLS is limited across the various Windows incarnations. Vista’s networking configurator is pretty good, and it performs respectable levels of auto-detection. To get both EAP-TLS and WPA/WPA2 support you need Windows XP SP2 or Vista. Nope, no Windows 2000 or anything older. Service Pack 4 for Windows 2000 provides EAP-TLS, but not WPA/WPA2.

There are all kinds of howtos for setting up Windows clients to use WPA2/EAP-TLS, so refer to Resources for these. The only thing you need to remember is to export the user’s private keys from Zeroshell as PKCS#12 format.


Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends, and analysis.

Latest Articles

Follow Us On Social Media

Explore More