The content of this blog is archived. No comments may be made, and no further content will be published. Thank you for your ongoing readership! -Ryan
The best of a bad lot

« Review: Sharpie Liquid PencilRIT's 19th Undergraduate Research and Innovation Symposium »

Hanging out with my PEAPs: Wireless Access Control with IEEE 802.1x, PEAP, and RADIUS

Permalink 08/15/10 14:53, by Ryan, Categories: Howto , Tags: , , , , , , ,

I’ve been having some weird kernel lockup problems when using the authenticated WPA2 network at RIT.  Since I can’t effectively bring my kernel bug troubleshooting tools to campus, I decided I needed to bring the wireless network home.  This meant converting the home wireless network from the usual shared-secret configuration to a Protected Extensible Authentication Protocol (PEAP)-based system.

Access Point Configuration

Belkin F5D7230-4 in its natural habitatMy access point is a Belkin F5D7230-4, a humble piece of crap that I wouldn’t recommend unless you enjoy rebooting or power-cycling network infrastructure.  What did I do wrong to get cursed with such terrible wireless networking problems?

I digress.

The access point is set up with Channel and SSID configured in a working fashion, along with Use as Access Point and System Settings adjusted to disable NAT and give the access point a usable LAN IP (192.168.1.2).  The real magic is under the Security tab.

  • Allowed Client Type: WPA2 Only
  • Authentication: 802.1X
  • Session Idle Timeout: 0
  • Re-Authentication Period: 0
  • Quiet Period: 10
  • Server-IP: 192.168.1.10
  • Server-Port: 1812
  • Secret Key: a long, random string used as a shared secret with the RADIUS server
  • NAS-ID: wifi-sodtech1  (I’m an optimist)

In this case, 192.168.1.10 is the IP address of a local server that I’m going to use for RADIUS.  The RADIUS server doesn’t have to be local, but it should be reliably reachable.

FreeRADIUS

Next thing you will need is a RADIUS server.  I chose FreeRADIUS as the current best-of-breed RADIUS server for this application, since it supports EAP “out of the box” and has a configuration format much less treacherous than my last RADIUS server.  If you are looking to use your distribution’s packages, note that FreeRADIUS 2.1.8 or above is required, which means Ubuntu 10.04 LTS (Lucid) is the way to go.

To install it: apt-get install freeradius freeradius-mysql.  Ding, fries are done.

After you install it, the first thing you want to do is add a test user and try it out.  FreeRADIUS has an excellent introduction to this process on their wiki.  Note that you can certainly use the users file to maintain your user’s credentials: it’s quick, it’s easy, and it works just fine.  I chose to use a MySQL database, however, since I eventually want to make a pretty web front end for managing users.  But we’ll get there.

An important thing to note: FreeRADIUS must have access to the cleartext version of the password in this scenario.  It cannot do what it needs to do with a crypted or hashed password.  This may be a problem in some circumstances.  MSCHAPv2 does include mechanisms for challenge-response authentication without cleartext being stored on the server or transported over the network, most commonly implemented by using Active Directory as an authentication oracle.

The next thing you will need to do is add an entry to clients.conf for your access point.  Based upon the well-documented entry for the localhost test client, I created a client stanza for my access point:

[gist:github:525614]

I also chose to change the logging from destination = files to destination = syslog, to reduce log file creep.  And, just for paranoia’s sake, I changed the secret for the localhost test client.  At this point, restart your FreeRADIUS server, reboot your access point, and create a new connection from your laptop.

Wireless configuration for PEAP on Ubuntu + Network Manager

Easy as pie.  Note that the CA Certificate option on your client should be left blank at this point, because you’re using the standard auto-generated SSL certificate.

A “real” SSL Certificate

To generate a new one, I use DigiCert’s nifty OpenSSL CSR Wizard to create an openssl command line.  For the Common Name, I chose wifi.sodtech.net, although it doesn’t really matter as long as you can get a certificate signed to that CN.  I then sent the resultant CSR to CAcert.org, which sent a signed certificate back.  You could, of course, use a local CA or a commercial CA depending on your situation.  It’s pretty much the same as setting up an SSL’d web server.

I stuck the .crt in /etc/ssl/certs/ and the .key in /etc/ssl/private/, adjusting permissions as appropriate.  I then adjusted the symlinks in /etc/freeradius/certs/ to point at these files instead of the default snake oil certificate.  Upon restart of FreeRADIUS, I could point my laptop’s configuration at /etc/ssl/certs/cacert.org.pem and verify that I wasn’t attaching to some rogue network.  Hooray!

Storing Credentials in a Database

There’s nothing wrong with using the users file to store your users, especially if you only have a few.  But, if you have a lot of users or want to automate various things, some sort of database backend is crucial.  FreeRADIUS supports a wide variety of SQL servers, along with LDAP and Active Directory.  All it needs is to know how to get a cleartext password for a particular username (or some other way to get a yes/no answer for a session with the information it has, which is possible with AD).

The FreeRADIUS wiki covers SQL configuration nicely, including importing the schema found in /etc/freeradius/sql/mysql/schema.sql, but here’s the summary of my configuration changes:

  • radiusd.conf
    • modules {
      • Uncomment $INCLUDE sql.conf
  • sites-available/default
    • authorize {
      • comment out unix (optional)
      • uncomment sql
      • comment out expiration, logintime (optional)
    • accounting {
      • comment out unix (optional)
      • comment out radutmp (optional)
      • uncomment sql
    • post-auth {
      • uncomment sql
  • sites-available/inner-tunnel
    • authorize {
      • comment out unix (optional)
      • uncomment sql
    • post-auth {
      • uncomment sql
  • sql.conf
    • In sql{}, change the server credentials as required.
  • users
    • Comment out the original test user!

And there you go.

Is PEAP for you?

Probably not.  However, when I set out to configure it, I was expecting it to be a lot more complicated than it was.  If you have an access point that speaks 802.1X and RADIUS, you might want to give this a try to add it to your box of enterprise tools.  For a security-minded organization, this can be one part of reducing the risk of a wireless network.  On a home network, however, it is probably overkill.

Oh… and the kernel lockup bug?  Doesn’t happen here.  Dang.


Edit 2010/08/15: Clarified cleartext password requirement; added mention of (and links to) Active Directory-related configuration.

No feedback yet

Comments are closed for this post.

Blog posts come from a can. They were put there by a man in a factory downtown.

Recent Twitterings

    Stalk me with RSS

    Search the Blog

     

    Support the Beer Fund

    Powered by Linode: Life's too short for crappy hosting

    [Powered by Linode]

    multiblog engine

    © 1962-2015 by Ryan Tucker (Public Key)

    Contact | Help | Blog theme by Asevo | free blog software | hosting