Paranoid Penguin - Securing Your WLAN with WPA and FreeRADIUS, Part III
The next step is the easiest part of this entire process: configure your wireless access point to use WPA and to point to your FreeRADIUS server. This requires only two pieces of information, the RADIUS secret you entered in your FreeRADIUS server's clients.conf file and the IP address of your FreeRADIUS server.
How you present those two pieces of information to your access point depends on your particular hardware and software. My own access point is an Actiontec DSL router with WLAN functionality. From its Web interface I clicked Setup→Advanced Setup→Wireless Settings and set Security to WPA. I then configured it to use 802.1x rather than a pre-shared key. I also provided it with a Server IP Address of 10.1.2.3, my FreeRADIUS server's IP and a Secret of 1sUpErpASSw0rD, as shown in Listing 4. I left the value for Port to its default of 1812.
Speaking of which, if your access point and RADIUS server are separated by a firewall, you need to allow the access point to reach the RADIUS server on UDP ports 1812 and 1813. Doing so also allows the RADIUS server to send packets back from those ports.
And that brings us to configuring a Windows XP wireless client to use your newly WPA-enabled access point. This being a Linux magazine, I'm not going to describe this process in painstaking detail—for that you can see section 4.3 of Ken Roser's HOWTO, listed in the on-line Resources. In summary, you need to:
Run the command mmc from Start→Run....
In Microsoft Management Console, select File→Add/Remove Snap-in, add the Certificates snap-in and set it to manage certificates for My user account and, on the next screen, only for the Local computer.
Copy your CA (cacert.pem) certificate to your Windows system's hard drive, for example, to C:\cacert.pem.
From within MMC, expand Console Root and Certificates - Current User and right-click on Trusted Root Certification Authorities. In the pop-up menu, select All Tasks→Import. Tell the subsequent wizard to import the file C:\cacert.pem and to store it in Trusted Root Certification Authorities.
Copy your client certificate/key file to your Windows system, for example, to C:\client_cert.p12.
From within MMC→Console Root→Certificates, expand Personal and right-click on Certificates. In the pop-up menu, select All Tasks→Import. Tell the subsequent wizard to import the file C:\client_cert.p12.
The certificate-import wizard then prompts you for the certificate's passphrase. In the same dialog, it offers the option to enable strong private key protection. Unfortunately, enabling this breaks WPA, so be sure to leave this option unchecked. Also, leave the option to mark this key as exportable unchecked—you're better off backing up the password-protected file you just imported rather than allowing the imported nonprotected version to be exportable.
In the subsequent screen, let the wizard Automatically select the certificate store.
Now your Windows XP system is ready to go—all that remains is to create a wireless network profile. This, however, varies depending on your wireless card's drivers and which Windows XP Service Pack you're running. On my Windows XP SP1 system, using a Centrino chipset and XP's native WPA supplicant, I created a wireless network profile specifying my WLAN's SSID. I set Network Authentication to WPA, Data encryption to TKIP and EAP type to Smart Card or other Certificate. Windows automatically determined which client certificate I used—this is because we took pains to create a client certificate that references Windows XP's extended attributes (see my previous column).
After you configure your wireless network profile, your Windows system should connect automatically to your access point and negotiate a WPA connection. If this succeeds, Network Connections should show a status of Authentication succeeded for your Wireless Network Connection entry.
I hope you've gotten this far successfully and are off to a good start with WPA. WPA isn't perfect—the world needs WPA supplicants that can handle passphrase-protected client certificates without storing passphrases in clear text. But, wireless networking is, it seems, finally headed in a secure direction.
Resources for this article: /article/8200.
Mick Bauer, CISSP, is Linux Journal's security editor and an IS security consultant in Minneapolis, Minnesota. O'Reilly & Associates recently released the second edition of his book Linux Server Security (January 2005). Mick also composes industrial polka music but has the good taste seldom to perform it.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide