802.1x on Linux with xsupplicant

Many of the well-known problems in 802.11 security are quite old and can be addressed by using 802.1x appropriately. Here's the client side.

When WEP's flaws became apparent, the wireless industry started developing new protocols to address the published weak points. These new protocols grew up around the IEEE 802.1x framework, which is a way of using the Extensible Authentication Protocol (EAP) and all of its methods on a LAN link. 802.1x client software programs, called supplicants, were brought to market by operating system vendors as well as by third-party developers.

Linux, however, initially was left out of the 802.1x frenzy. Network administrators who supported power users were forced to rely on manual WEP-based solutions with MAC address filtering or VPNs to secure Linux before supplicants were widely available. Happily, now two open-source supplicants are bringing high-quality wireless security to Linux. This article describes the process of setting up xsupplicant, which is also known as Open1X.

Wireless Extensions

The wireless extensions API originally was designed to provide a unified way of having programs interact with drivers. Like any API, it saves developers from having to know the details of how to interact with every card. 802.1x supplicants, for example, are able to use a wireless extensions system call to set keys, rather than using card-specific calls for every card that exists.

The wireless extensions interface has gone through several versions. WPA support was added in wireless extensions version 18 (WE-18). Some distributions using the 2.6 kernel already have WE-18 support. Older kernels need to be patched, however. My test laptop runs Slackware, which still is using the 2.4 kernel. The 2.4 kernel has support for version 16 of wireless extensions, but patches are available for version 2.4.30. Patch download locations appear in the on-line Resources for this article. Begin by applying two patches to the kernel source:

# patch -p1 ~/iw249_we17-13.diff
patching file include/linux/netdevice.h
patching file include/linux/wireless.h
patching file include/net/iw_handler.h
patching file net/core/dev.c
patching file net/core/wireless.c
# patch -p1 ~/iw240_we18-5.diff
patching file include/linux/wireless.h
patching file net/core/wireless.c

To keep modules straight, I often find it helpful when patching kernels to edit the Makefile to include an extra version number in addition to the patch level. My wireless extensions 18 kernel is built as 2.4.30WE18.

The most common tools used with wireless extensions are the wireless toolset, and the most common tool you will use is iwconfig. Wireless tools version 28 is the current version and supports WE-18. Grab the source code from the Web site (see Resources). A simple make command builds the tools.

Getting the Driver Going

Many cards are supported under Linux, but a handful of drivers have captured the bulk of the popularity:

  • MADwifi, the Multi-band Atheros Driver for Wi-Fi: Atheros-based cards have some of the best hardware support for 802.11a networking. Chances are good that if your card supports 802.11a, it uses an Atheros-designed chip.

  • Intel IPW drivers for Centrino chipsets: Intel sponsors open-source driver development projects for the various Centrino chipsets. Due to the sheer number of Centrino chipsets on the market, these drivers are widely used.

  • orinoco_cs: the first widely used 802.11 card was the Orinoco Gold card, based on the Hermes chipset. These cards were sold under a variety of names, and they all performed quite well in their day. Although the radio performance and throughput of these cards is no longer cutting-edge, the driver is well understood and often serves as a testbed for new ideas.

This article is not meant to be a definitive treatment of working with drivers. I use Atheros-based cards because I have an 802.11a network at home and want a dual-band card for packet analysis. Therefore, I am writing about MADwifi.

MADwifi has not released any packaged source files. To use the driver, you must download the code from CVS. The build files distributed with MADwifi use your current kernel. If you have patched the kernel to update wireless extensions, reboot before building MADwifi:

$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:
↪/cvsroot/madwifi co madwifi
$ cd madwifi
$ make

root@bloodhound:/home/user/madwifi# make install

Atheros-based cards do not use firmware. Instead, they have a binary-only object called the hardware abstraction layer (HAL). Atheros has interpreted FCC regulations in such a way that requires the HAL to be kept closed-source. The HAL serves the same purpose as firmware on other cards—it implements low-level operations for the driver. The HAL is distributed as a uuencoded file, so you must install the uudecode program to install the HAL. It probably is in the shell archive utilities package for your distribution, but the location may vary. The OpenBSD Atheros driver includes an open-source, reverse-engineered HAL, but it has not been ported yet to Linux.

The kernel modules built as part of the process are installed in your modules directory. The driver includes its own 802.11 support layer composed of the modules wlan, wlan_wep, wlan_tkip and so on. The hardware-specific part of MADwifi is composed of modules that begin with the prefix ath_: the driver ath_pci, the HAL ath_hal and rate adaptation algorithms (ath_rate_*). All the modules are installed in the net/ directory.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Unable to get Xsupplicant to work

Satish's picture

Hi,

I am not able to get Xsupplicant to work for me.
Can somebody help?

Here are the network details:
SSID (Network Name: TTUnet
WEP data encryption Enabled
Automatically provided WEP key Enabled
IEEE 802.1x authentication Enabled
EAP type: Protected EAP (PEAP)
Protected EAP Authentication Method Secured password (EAP-MSCHAP v2)
EAP MSCHAP v2 Properties - Automatically Login Disabled

Here is the content of my /etc/xsupplicant.conf

network_list = all
default_netname = TTUnet
startup_command = echo "some command"
first_auth_command = dhclient %i
reauth_command = echo "authenticated user %i"
logfile = /var/log/xsupplicant.log
TTUnet
{
allow_types = all
identity = msg
eap-peap {
root_cert = NONE
chunk_size = 1398
random_file = /path/to/random/source
allow_types = all # where all = MSCHAPv2, MD5, OTP, GTC, SIM
eap-mschapv2 {
username = user
password = "passwd"
}
}
}

And I am using SUSE Enterprise Desktop Linux 10
I have my wireless adapter configured and works well with normal WEP/WPA networks.

Thanks

Xsupplicant error

Jack's picture

why I have this error with starting ?

===-------------------------------------------------------
syntax error:

startup_command = /sbin/iwconfig eth1 essid aeriusEAP enc open
^
General Parse error!
There was a problem with the config file. We cannot continue.

wrong version

Anonymous's picture

remove the command, if you are using version 1.2.6 like i am then that command doesn't work for some reason. Remove it and other like "first_auth_command", then give it a try.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix