For any corporate wireless infrastructure to remain secure, using 802.1x for authentication is a must - after all, it provides much more granular control of authentication credentials and can provide accounting for wireless LAN usage. Setting everything up can be a complex process fraught with choosing the right EAP type that both your clients and your RADIUS server supports in addition to putting in place the PKI infrastructure that some EAP types require. During this whole process one thing can often be overlooked - the security of the RADIUS server itself.
Unfortunately, this is a very important aspect of any secure WLAN deployment since the RADIUS server is the key to the whole operation. The RADIUS server (and its data store or authentication backend) is what controls access to the network and additionally supplies the keys used by the AP and wireless client to encrypt a given station's traffic.
The first place to start is to secure the system being used for the RADIUS server. There are various techniques to use for this, but at the most basic level you should dedicate a single server to the task. This limits the exposure of the RADIUS server and insures that vulnerabilities in other services running on the system do not lead to the RADIUS server being compromised. Accounts that are allowed to login to the server should be limited too.
The next thing to be done is to limit what can communicate with your RADIUS server. In order to operate, the RADIUS server needs to be able to communicate with your authentication backend (eg, an LDAP or SQL server) and each of your Network Access Servers (NAS), which in the case of a wireless network are your APs. So with this in mind, firewall rules should be put in place to enforce this requirement and ensure that no other systems can communicate with your RADIUS server, save systems on your management LAN.
Additionally you'll want to protect the communications between your RADIUS server, authentication backend, and APs with encryption. For the connection between your RADIUS server and authentication backend this will likely mean either SSL or IPsec. For instance if you're using an LDAP directory to store authentication information, you can easily use SSL to encrypt traffic to and from it. If you're using a backend that isn't so easily amenable to using SSL then you can use IPsec (using 3DES or AES ciphers). Similarly, you should encrypt communications between your APs with IPsec as well.
Last, but not least in importance, is your RADIUS shared secret. This is used by the RADIUS server and the NAS devices to secure the traffic between them. If you're able to use IPsec between the server and the APs, then this is just an extra layer of defense. However, if you're not able to do that then it's crucial that you choose unique shared secrets for each of your APs and make sure that you use strong passwords that include letters, numbers, and symbols. In addition you should use a password that is the maximum length allowed by your RADIUS server and APs.
Using any one of these methods will increase the security of your RADIUS server and by extension your wireless LAN deployment, but taken together as a layered approach they are much stronger.
Andrew Lockhart is lead security analyst at Network Chemistry, author of O'Reilly Media's Network Security Hacks, and author of Snort-Wireless, an open source project adding wireless intrusion detection to Snort. He is also an editorial board member of the WVE. This article appeared in Network World