Paranoid Penguin - Securing Your WLAN with WPA and FreeRADIUS, Part III
In the previous two Paranoid Penguin columns, I described how Wi-Fi protected access (WPA) can protect wireless LANs (WLANs) from unauthorized access and eavesdropping. I also began explaining how to use FreeRADIUS to implement WPA on your own WLAN. So far, we covered installing FreeRADIUS, creating a certificate authority (CA) and generating and signing digital certificates for WPA use. This month, I show you where to put those certificates, how to configure FreeRADIUS and how to configure your wireless access point and clients. With this information, you should be off to a good start in securing your WLAN.
In case you're new to this series of articles or simply need some reminders about precisely what we're trying to achieve, let's briefly review our purpose and scope. WPA adds powerful authentication functionality to the older, cryptographically broken WEP protocol in the form of the 802.1x protocol and its subprotocols, such as EAP, PEAP and EAP-TLS. WPA also adds dynamic session key negotiation and automatic key regeneration, by way of the TKIP protocol. If your wireless client software supports WPA—that is, if it includes a WPA supplicant—and your wireless access point supports WPA, you're two-thirds of the way there already. But if you want to take full advantage of 802.1x, you need a back-end RADIUS server, which is where FreeRADIUS comes in.
In the example scenario I established last time, we're configuring a FreeRADIUS server to authenticate Windows XP wireless clients connecting to any WPA-compatible wireless access point. Our 802.1x method is EAP-TLS. EAP-TLS, you might recall, uses the TLS protocol to authenticate wireless supplicants (clients) and your access point to one another by using X.509 digital certificates.
The tasks at hand in this column are:
To install the server and CA certificates we created last time onto our FreeRADIUS server.
To configure FreeRADIUS to use these certificates with EAP-TLS to authenticate users for our access point.
To configure our access point to redirect authentication to our FreeRADIUS server.
To install the client and CA certificates we created last time onto a Windows XP client and configure it to use WPA when connecting to the WLAN.
In Part II of this WPA series, we created three X.509 digital certificates: a certificate authority certificate, called cacert.pem; one server certificate, called server_keycert.pem; and a client certificate, called client_cert.p12. The server and client files contain both a certificate and its private key, so each of these must be handled carefully. The CA certificate, however, is stored separately from its key, so you can distribute cacert.pem freely.
FreeRADIUS stores its configuration files in either /etc/raddb/ or /usr/local/etc/raddb/, depending on your distribution. This directory contains a subdirectory, certs/—this, naturally, is where you need to copy your CA certificate and your server certificate/key. Make sure that cacert.pem is owned by the user root and that its permissions are set to -r--r--r--. server_keycert.pem, on the other hand, should be owned by the user nobody and its permissions set to -r--------. Listing 1 shows the long directory listings for these two files.
Listing 1. Ownerships and Permissions for Certificates in raddb/certs
-r--r--r-- 1 root users 1294 2005-02-10 01:05 cacert.pem -r-------- 1 nobody users 1894 2005-02-10 01:00 server_keycert.pem
As long as you're attending to file ownerships, you also should make sure that the file /var/log/radius/radius.log and the directory /var/run/radiusd/ are writable by nobody. If you compiled FreeRADIUS from source, these paths instead may be /usr/local/var/log/radius/radius.log and /usr/local/var/run/radiusd/. Both radius.log and radiusd/ may be owned by nobody.
Before we dive into FreeRADIUS' configuration files, we need to create two files that FreeRADIUS must have in order to use TLS. The first is a Diffie-Hellman parameters file, or dh file, which is used for negotiating TLS session keys. To create a dh file, change your working directory to FreeRADIUS' raddb/certs/ directory and issue this command:
# openssl dhparam -check -text -5 512 -out dh
The second file you need is a data file that contains a random bitstream that also is used in TLS operations. Do not simply stick the current timestamp or any other similarly nonrandom string into a file called random, as is suggested in at least one WPA procedure I've seen on the Internet. Rather, use the kernel's high-quality random number generator. From within raddb/certs, run this command:
# dd if=/dev/urandom of=random count=2
Both of these files need to be readable by the user nobody, but they should not be writable by anybody.
|HPC Cluster Grant Accepting Applications!||Jan 28, 2015|
|Sharing Admin Privileges for Many Hosts Securely||Jan 28, 2015|
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
|Ideal Backups with zbackup||Jan 19, 2015|
- Sharing Admin Privileges for Many Hosts Securely
- HPC Cluster Grant Accepting Applications!
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Designing with Linux
- Ideal Backups with zbackup
- Wondershaper—QOS in a Pinch
- Slow System? iotop Is Your Friend
- diff -u: What's New in Kernel Development
- Hats Off to Mozilla
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane