Designing security architectures is not an easy job. It takes great care, experience, and knowledge. Unfortunately, this book can't give you care and experience, but it can at least provide the requisite knowledge you need to secure your wireless network. This chapter does not provide a step-by-step guide to installing specific vendors' products. Vendors change their product lines and their user interfaces far too often to make that information relevant for more than a few months. Instead of providing a single secure configuration, we'd rather teach you how to put one together yourself. For those who like to tinker or build everything yourself, we will, however, explain how to use several open and free software projects to build your own secure wireless network. The details on these projects are still very new and will probably change, but we wanted to show a “nuts and bolts” approach to help you learn.
We start with general architecture guidance for some common situations, and then we explain how to use the open and free source projects.
We've touched on the many design issues needed for security, but now we boil these down to three key design principles for security architectures:
Isolate potentially hostile traffic from sensitive traffic.
Canalize[1] potentially hostile traffic through a small set of fixed entry points that are well protected and monitored.
Use a layered defense whenever possible.
Many of you will recognize these as the guidelines that apply to Internet connections. The firewall is an instantiation of these principles. It isolates and canalizes traffic through a fixed entry point, and it can apply additional layers of security through the use of a virtual private network or additional authentication requirements.
Wireless networks are somewhat more difficult to deal with than an Internet connection, however. Whereas an Internet connection enters the enterprise in only a few fixed locations, wireless access points must be located throughout the enterprise to provide reasonable coverage areas.
So what are our choices in providing isolation and canalization? Well, we could make each access point a firewall. While this certainly meets our goals, it also introduces a horrendous management burden in large enterprises and may not be the best approach in all situations. Certainly in small office/home office (SOHO) scenarios, this might make some sense because there is only one access point, however.
You can now recognize some of the tradeoffs you must make when designing security architectures. A good security architect must balance the threat, information value, and costs (both monetary and management) in designing the architecture. While the solution of making every access point a firewall-like device meets some of the design criteria, it introduces a potentially difficult management problem in some environments. As a result, you must select your equipment carefully.
You would be well served by working closely with your vendor or value-added reseller when choosing equipment. Don't blindly accept statements by either the vendor or their integrator that the equipment is secure. Ask them to define what they mean—for example, “Secure against what type of threat?” Be especially diligent if the vendor uses a proprietary solution. Ask who has reviewed the solution, and ask to see the details so you or someone within your organization can review it. These days, there are few reasons to use a proprietary solution because both WPA and RSN provide protection robust enough for almost all organizations. If you are extremely paranoid, you can add security using upper-layer protection, such as VPN.
Finally, remember, that WPA is an interim solution until IEEE 802.11i RSN is complete. It may be that the full RSN will become WPA2 in the future. The cryptographic primitives used in WPA are believed to be robust, but it takes time to ensure that an algorithm is secure. For instance, RC4 was known publicly for some time before the problems were found that decimated WEP. As such, you should (if security is important to you) plan on upgrading your infrastructure to the AES-based solution (RSN) as soon as you can.
If you already have a wireless local area network deployed in your organization, you need to take several steps (if you haven't already) to ensure that it is protected. First, apply the design principles discussed in the previous section: Isolate and canalize the traffic. Second, upgrade your equipment's firmware to WPA. Let's look at each of these in turn.
Isolating the traffic from access points may be the most difficult aspect of trying to improve the security of your network, unless you already have your access points on the same LAN segment.
Assuming that you haven't already isolated the traffic, you essentially have two choices. The first is to run new cables to your access points, placing them on the same LAN segment without additional enterprise traffic. The second is to use your current switches to create a VLAN (IEEE 802.10) to isolate your wireless equipment. The first choice is not optimal in terms of time and cost, as it requires a great deal of work and expense. The second approach is relatively painless if your equipment already supports VLANs. If it doesn't, you must balance the purchase of new switches with the cost of running new cable (remember our discussion on tradeoffs). A VLAN provides a moderate degree of isolation. However, the isolation is not complete when the switches are attacked via ARP spoofing and other means; see http://ettercap.sourceforge.net. But the protection provided by a VLAN is better than allowing the traffic from access points to co-mingle with traffic from the rest of the organization.
Once your traffic is isolated, it is easy to canalize it (see Figure 17.1). And depending on your threat model, you can use a network address translation box, a router, or a firewall on one or multiple entry points into the organization's network.
Hopefully, your installed base of access points and client cards can all be upgraded to WPA by simply reflashing the firmware on each device and by making some small configuration changes. If that's the case, you should perform that upgrade as soon as possible to support WPA.
Once you've upgraded to WPA, you can use WPA in one of two modes: preshared key (PSK) and server-based infrastructure. In PSK mode, you enter a password at each client and each access point and you're done, though you must also update client software from your vendor. While this approach is simple, it doesn't scale well beyond the home or small office. In those cases, you need to deploy an authentication server. Later in this chapter, we discuss what you'll need to do to deploy the infrastructure for supporting both WPA and RSN.
Of course, you must check with your equipment vendor for details on upgrading the firmware and client software.
The steps we've outlined involve a great deal of work and probably require you to spend money to improve things. What do you do if you can't make any of these suggested changes? The first and most important question you must answer is, “What is the utility of using wireless versus not using it?” Does it add value to your business? In addition, you have to consider the value of the information on your network. What can someone do (or get) if they break into your network? Finally, you have to consider the threat against your network. Is there a reason for someone to try and break into your network?
If you do that analysis, and you decide (and only you can make that decision) to keep using your wireless network, here are some steps that you can follow to mitigate the risks to your network. Our goals in providing this information are to help you protect yourself as best you can. Remember, however, that your network and all of the information on it will be vulnerable, and our recommendation is that you make the investment in time and equipment to get it right rather than relying solely on these pointers.
The whole idea is to make it as difficult as possible for someone to break into your network.
Use all available security measures provided by your equipment. That means use WEP, MAC address filtering, and shared key authentication. Yes. All of these can be broken, but not by everyone. Thus, you're reducing the threat. But, you do remain vulnerable. (Sorry, our lawyers made us shout that.)
Change your WEP key as often as possible.
Turn off the wireless network when it is not in use. This is probably only practical in a home or small office. But the point is to reduce the risk as much as possible.
Upgrade your equipment to at least WPA or, better yet, to RSN as soon as possible.
If you haven't yet installed a wireless network, life is a little simpler. You don't have to worry about retrofitting; you can start out the right way from the beginning.
Consider isolating and canalizing your wireless equipment. You must also evaluate the equipment you'll be purchasing from the vendor. For instance, if IEEE 8802.11i RSN (based on AES) isn't out yet, can you upgrade the equipment you purchase later? Is the upgrade via software or hardware? (Most likely, it will be a hardware upgrade.) Also, look very carefully at proprietary vendor solutions. Ask to see the details of the proprietary solution, and who has evaluated it besides the vendor. If the vendor won't share the details with you or can't answer the question, think carefully before using that solution. Finally, if RSN is available, there is very little reason to use a proprietary solution unless you have a very specific need that RSN does not directly meet.
If you have a medium to large deployment, install an authentication server infrastructure to centralize user management and accounting, which we describe next. Finally, the biggest single thing that you must do is to turn off support for WEP. As long as WEP is enabled, you are susceptible to a down-grade attack, in other words, an attacker can associate using WEP and crack the key (see Chapter 15).
A significant amount of infrastructure is required to support WPA when you are not using preshared keys. The effort required to set up the infrastructure is, unfortunately, nontrivial. However, it is only a one-time cost, and setting it up properly will save you time in the long run.
As with everything in security, the devil is in the details, and setting up your infrastructure is no exception. Because vendor products change, it is difficult to provide a step-by-step cookbook for you. So instead, we describe in general what you must do and provide pointers to more detailed guidance, usually on the Web.
The central arbiter for all access and authentication decisions in WPA is the organization's RADIUS server. It's likely that this is exactly how your Internet service provider (ISP) makes access decisions when you dial up the service. You can obtain a RADIUS server in many ways. For example, the software package Microsoft Windows 2000 Server includes a RADIUS server, and several vendors sell RADIUS servers for various operating systems. There is also an open source RADIUS server available known as FreeRADIUS, which we describe later in this chapter.
Managing a RADIUS server is an extremely important task because the server makes all of the security-relevant decisions. As a result, improper configuration can lead to breaches in your security. Fortunately, an excellent text has been recently written that describes how to install and configure FreeRADIUS (Hassell, 2003).
To use WPA to its fullest, you need to use EAP/TLS as an authentication mechanism, and this requires using public key certificates based on the X.509 standard. Issuing and managing these certificates requires that a public key infrastructure (PKI) be established within your organization, if it hasn't been already.
Setting up a PKI has been the subject of several books, and we can't cover all of the nuances involved. We will, however, show how to use an open source cryptographic package to make certificates suitable for testing purposes or for use at home or in very small offices later in this chapter.
To gain the full benefit of WPA, you need to upgrade your clients to use the IEEE 802.1X protocol for authentication and access control. At the time of this writing Microsoft Windows XP is the only operating system to include the client portion, the supplicant, as part of the operating system. However, your vendor will probably provide software to support older versions of Windows and the Apple Macintosh. For UNIX, you can use supplicant software developed at the University of Maryland and released under both the GPL and BSD style licenses. The software is located at www.open1x.org and runs under FreeBSD, OpenBSD, and Linux.
To install the software, you have to review the documentation for the clients you use, and you have to generate and add public key certificates to each client. This is mandatory to support the EAP/TLS protocol.
This section walks you through some of the steps of building open source applications that you can use for setting up and evaluating a WPA or RSN network. “There is no such thing as a free lunch” and the hidden cost of using the open source projects is that you need substantial system knowledge and, to some extent, an understanding of computer programming. The vast majority of people choose instead to purchase commercial solutions and obtain professional support for installation. However, we'll take the time here to show how you can set up a test environment and even create a real operating network from tools that can be downloaded over the Internet, and we're also going to show you how to build an access point yourself using UNIX.
Our goals are to help anyone who likes to tinker and is somewhat familiar with UNIX. If that does not describe you, consider skipping this section.
We cover two versions of UNIX in this section. For the open source access point, we use the OpenBSD operating system (www.openbsd.org), and for the infrastructure, we use Red Hat Linux. For more information please see our Web site (www.wpa-security.org).
This section shows how to use open source projects to create your own infrastructure. There are two reasons for this step. First, you may find that the open source project actually provides what you need to protect your network. Second, even if you eventually plan to use a commercial server, the exercise of seeing how the open source project is structured should be informative.
There are two specific projects that we're going to discuss: OpenSSL and FreeRADIUS:
OpenSSL provides cryptographic primitives as well as some command line tools for creating and manipulating public key certificates. We use OpenSSL to help build a limited PKI.
We use FreeRADIUS to provide the authentication server using the RADIUS protocol as the central point of our infrastructure.
If you're going to be using WPA with server-based keys in a medium to large organization, you'll need a public key infrastructure. There are several commercial products available, but fortunately, there are also a few open source projects. The most significant is the OpenCA effort found at www.openca.org/, but it is somewhat wanting, unfortunately. Rather than focus on the details of establishing an entire certificate authority, we're going to show you how to build self-signed certificates using OpenSSL. This approach is sufficient for testing, or for a small-to-medium-sized network. The point is to show you what is involved without having to get lost in the details of a PKI.
You can download the latest version of the OpenSSL from www.openssl.org. At the time of this writing, the most recent version was 0.9.7a. This is the version we'll use in our examples, but you should be able to use later versions when they are released. Before using a newer version, check with the FreeRADIUS site to see whether an older version of OpenSSL is required; the two projects are not well synchronized at the moment. You also only need the base OpenSSL distribution; you don't need the OpenSSL-engine file unless you plan on using specialized cryptographic support. In that case, you probably don't need these instructions anyway.
Once you download the file, you need to change your working directory to the location where you place source code, in other words, /usr/local/src, and check the digital signature on the following file and untar it.
cd /usr/local/src tar xvfz openssl-0.9.7a.tar.gz
The OpenSSL development team has made the compilation of OpenSSL easy and straightforward, as shown in the following syntax. This syntax works using Red Hat 7.3 and 8.0. But, you must use a different method for OpenBSD; see www.cs.umd.edu/~arunesh/bsd/openssl.html. Also, you need to be careful not to overwrite the current installation of OpenSSL when using Red Hat because that will break some of the precompiled programs in your operating system distribution. The following commands install OpenSSL in the /usr/local directory so you don't overwrite the previous installed version.
cd openssl-0.9.7a ./config shared --prefix=/usr/local/openssl make make install
All of the previous commands should complete without error messages.
Once OpenSSL is installed, you need to make some minor changes to the configuration files to make it easier to make certificates (see the next section). The file that requires editing is /usr/local/openssl/ssl/openssl.cnf. The changes only involve modifying the default values for some of the options in certificate requests. If you're going to generate only one or two certificates, you don't really have to make these changes. If you're going to generate more certificates than that, you definitely should make these changes. You may also want to consider increasing the length of time a certificate is valid as well. The changes you want to make are all in the lines that have “default” as a portion of the identifier in the first column. An excerpt from the openssl.cnf file follows, with the changes we made in bold.
# req_extensions = v3_req # The extensions to add to a certificate request [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = US countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default= Maryland localityName = Locality Name (eg, city) localityName_default = College Park 0.organizationName = Organization Name (eg, company) 0.organizationName_default= University of Maryland # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default= World Wide Web Pty Ltd organizationalUnitName= Organizational Unit Name (eg, section) organizationalUnitName_default= Department of Computer Science commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 # SET-ex3 = SET extension number 3 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 challengePassword_default= ChangeMe! unstructuredName = An optional company name
There are several steps involved in created certificates that you can use with 802.1X. First, you need to create a certificate authority certificate. This is self-signed; in other words, the certificate authority attests to the validity of itself. While this might surprise you, it is the commonly accepted method for creating a root certificate. Once the certificate authority, or root, is created, you need to create a server certificate for your RADIUS server. Then, you create certificates for all of your clients.
Several people, most recently Raymond McKay (www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm), have created scripts to automate the commands needed to create a certificate authority using OpenSSL. The following script creates the self-signed root certificate.
CA.root file
#!/bin/sh
SSL=/usr/local/openssl
export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH}
export LD_LIBRARY_PATH=${SSL}/lib
# private key into the CA directories
rm -rf demoCA
echo "**************************************************************"
echo "Creating self-signed private key and certificate"
echo "When prompted change the default value for the Common Name field"
echo "**************************************************************"
echo
# Generate a new self-signed certificate.
# After invocation, newreq.pem will contain a private key and certificate
# newreq.pem will be used in the next step
openssl req -new -x509 -keyout newreq.pem -out newreq.pem –passin
pass:whatever -passout pass:whatever
echo "**************************************************************"
echo "Creating a new CA hierarchy (used later by the "ca" command)"
echo "and private key created in the last step"
echo "**************************************************************"
echo
echo "newreq.pem" | CA.pl -newca >/dev/null
echo "**************************************************************"
echo "Creating ROOT CA"
echo "**************************************************************"
echo
# Create a PKCS#12 file, using the previously created CA certificate/key
# The certificate in demoCA/cacert.pem is the same as in newreq.pem.
# Instead of using "-in demoCA/cacert.pem" we could have
# used "-in newreq.pem" and then omitted
# the "-inkey newreq.pem" because newreq.pem contains both the
# private key and certificate
openssl pkcs12 -export -in demoCA/cacert.pem -inkey newreq.pem –out
root.p12 -cacerts -passin pass:whatever -passout pass:whatever
# parse the PKCS#12 file just created and produce a PEM format
# certificate and key in root.pem
openssl pkcs12 -in root.p12 -out root.pem -passin pass:whatever
-passout pass:whatever
# Convert root certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in root.pem -out root.der
#Clean Up
rm -rf newreq.pem
You create the self-signed root certificate now by executing:
/bin/bash CA.root
and answering all of the questions.
To perform a mutual authentication between the RADIUS server and the supplicant, you must have a public key certificate for the server. This section provides the set of commands that you must execute to request a certificate and then have it signed by your root certificate.
An important part of creating the server certificate, and the client certificate that you create in a few moments, is ensuring that the certificate has the appropriate OIDs to support Microsoft Windows XP. Now, you're probably asking, “What is an OID?” Well, don't worry, all you really need to know about them is that they're essentially a capability, indicating what type of service the holder of the certificate may use.
The OIDS needed for certificates for use with Windows XP follow. The script creating both the client and server certificates assumes that the OIDs are included in a file named xpextensions located in the same directory as you run the script.
xpextensions file
[ xpclient_ext]
extendedKeyUsage = 1.3.6.1.5.5.7.3.2
[ xpserver_ext ]
extendedKeyUsage = 1.3.6.1.5.5.7.3.1
CA.server file
#!/bin/sh
SSL=/usr/local/openssl
export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH}
export LD_LIBRARY_PATH=${SSL}/lib
echo "*****************************************************************"
echo "Creating server private key and certificate"
echo "When prompted enter the server name in the Common Name field."
echo "*****************************************************************"
echo
# Request a new PKCS#10 certificate.
# First, newreq.pem will be overwritten with the new certificate request
openssl req -new -keyout newreq.pem -out newreq.pem –passin
pass:whatever -passout pass:whatever
# Sign the certificate request. The policy is defined in the
# openssl.cnf file.
# The request generated in the previous step is specified with the
# -infiles option and
# the output is in newcert.pem
# The -extensions option is necessary to add the OID for the extended
# key for server authentication
openssl ca -policy policy_anything -out newcert.pem –passin
pass:whatever -key whatever -extensions xpserver_ext –extfile
xpextensions -infiles newreq.pem
# Create a PKCS#12 file from the new certificate and its private
# key found in newreq.pem
# and place in file specified on the command line
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12
-clcerts -passin pass:whatever -passout pass:whatever
# parse the PKCS#12 file just created and produce a PEM format
# certificate and key in certsrv.pem
openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:whatever –passout
pass:whatever
# Convert certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der
# Clean Up
rm -rf newcert.pem newreq.pem
Save the script above to the file CA.server, and then create the server certificate by invoking the script with the name of the server (without spaces or special characters) as follows.
/bin/bash CA.server <servername>
When you are asked to enter the common name, you must enter the same name as you used in executing the script, for example, <servername>.
Now that you've created the certificate for the RADIUS server, you can create your client certificates (we'll discuss installing them on clients shortly). The following script shows the commands necessary to request and sign individual client certificates. Remember to have the proper OID file so you can use the resultant certificate with a Windows XP client as well.
CA.client file
#!/bin/sh
SSL=/usr/local/openssl
export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH}
export LD_LIBRARY_PATH=${SSL}/lib
echo "****************************************************************"
echo "Creating client private key and certificate"
echo "When prompted enter the client name in the Common Name field."
echo " This is the same name used as the Username in FreeRADIUS"
echo "****************************************************************"
echo
# Request a new PKCS#10 certificate.
# First, newreq.pem will be overwritten with the new certificate request
openssl req -new -keyout newreq.pem -out newreq.pem –passin
pass:whatever -passout pass:whatever
# Sign the certificate request. The policy is defined in the
# openssl.cnf file.
# The request generated in the previous step is specified with
# the -infiles option and
# the output is in newcert.pem
# The -extensions option is necessary to add the OID for the
# extended key for client authentication
openssl ca -policy policy_anything -out newcert.pem –passin
pass:whatever -key whatever -extensions xpclient_ext –extfile
xpextensions -infiles newreq.pem
# Create a PKCS#12 file from the new certificate and its private
# key found in newreq.pem
# and place in file specified on the command line
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12
-clcerts -passin pass:whatever -passout pass:whatever
# parse the PKCS#12 file just created and produce a PEM format
# certificate and key in certclt.pem
openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:whatever –passout
pass:whatever
# Convert certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der
# clean up
rm -rf newcert.pem newreq.pem
You use the previous script, saved to the file ca.client, to generate your client certificates by invoking the script with the following command without spaces or special characters in <username>.
/bin/bash ca.client <username>
Be sure to use the <username> as the common name when you create the certificate. You'll also use the same name when you create the RADIUS files.
Make a copy of the files created by executing the previous scripts, root.pem and <servername>.pem, and copy them to the directory /usr/local/1x/etc/. You'll probably have to make that directory first. You also need to save the files root.der and <username>.p12 for installation on the client machine. We describe that process a bit later in this chapter when we describe how to set up the client.
FreeRADIUS is the most widely used open source RADIUS server found at www.freeradius.org. RADIUS is a complicated protocol that can be configured in a large number of different ways. In this section, we discuss only a very basic configuration. If you're planning on using FreeRADIUS as part of your infrastructure, you definitely want to obtain a more detailed guide such as the O'Reilly book RADIUS by Jonathan Hassell (2003).
You can download the most recent version of FreeRADIUS from the Web site www.freeradius.org/getting.html. The most recent version at the time of writing is 0.8.1. This version has complete support for both authentication and dynamic keys. Make sure you download the signature of FreeRADIUS as well. The developers of FreeRADIUS used a detached signature (file ending in .sig) rather than an ASCII armored signature (file ending in .asc). Verifying this signature is very similar to the approach shown in Appendix B. The only difference is that you will be asked to enter the name of the file you want verified.
Now, change your working directory to your source directory and untar the FreeRADIUS source.
cd /usr/local/src tar xvfz freeradius-0.8.1.tar.gz
Compiling FreeRADIUS is similar to compiling OpenSSL except that you have to make a few changes to the files to support EAP-TLS. First, you configure the source code by using the configure program.
cd freeradius-0.8.1 ./configure --prefix=/usr/local/radius
Once the source is configured, you must make one small change to a makefile included with the source to ensure that FreeRADIUS can find your version of OpenSSL and compile EAP-TLS properly. The file that you must modify is the subdirectory src/modules/rlm_eap/types/rlm_eap_tls/ under your main FreeRADIUS directory. The changes you need to make are to ensure that the header and library files from OpenSSL can be found. A modified makefile follows.
# Generated automatically from Makefile.in by configure. TARGET = rlm_eap_tls SRCS = rlm_eap_tls.c eap_tls.c cb.c tls.c RLM_CFLAGS = $(INCLTDL) -I../.. –I/usr/local/openssl/include HEADERS = eap_tls.h RLM_INSTALL = # NOTE: You may have to switch the order of –lssl and –lcrypto below RLM_LIBS += -lssl -lcrypto RLM_LDFLAGS += -L/usr/local/openssl/lib $(STATIC_OBJS): $(HEADERS) $(DYNAMIC_OBJS): $(HEADERS) RLM_DIR=../../ include ${RLM_DIR}../rules.mak
You'll end up adding “-I/usr/local/openssl/include” to the line beginning with RLM_CFLAGS, and an entirely new line beginning with RLM_LDFLAGS, and you may have to switch the order of –lssl and –lcrypto.
Now, you can compile the FreeRADIUS source just like we did OpenSSL with the following two commands from the main FreeRADIUS directory.
make make install
The compile and install should complete without errors.
Now, you're ready to make the changes to the various FreeRADIUS configuration files. There are three files that you must modify (remember you're only doing a basic setup here), and they are all located in the directory /usr/local/radius/etc/raddb. The files are clients.conf, radiusd.conf, and users.
The clients.conf file is responsible for determining who/what can connect to the RADIUS server to authenticate users. In your case, you want the access points to be able to connect. There are two ways to enter the access point information. First, list each access point individually. Second, list a subnet. A key point for security here is that if you decide to use the subnet approach, all of the access points will use the same password—not the best idea from the standpoint of security; however, if you have hundreds of access points, a separate password for each becomes a management nightmare. The choice is yours.
You can specify an access point at a time by using the following template.
client <ipaddress> {
secret = <password>
shortname = <descriptive_name_for_accounting_purposes>
}
You would create a copy of the template, above, for each access point, entering the IP address, password, and name for each into your clients.conf file.
The second approach is to use a single entry for an entire local area network of access points. You do this using the following template.
client <subnet>/<mask> {
secret = <password>
shortname = LAN
}
You enter the subnet and mask along with the globally shared password into the previous template and place it in the clients.conf file. Remember, you need to use only one of the approaches we outlined.
You need to change only a few parts of this file. But, you need to create two new files, /usr/local/radius/etc/raddb/DH and /usr/local/radius/etc/raddb/random, as part of the changes. The contents of both of these files need to be random so you use the Linux random device to create files with the following commands.
dd if=/dev/random of=/usr/local/radius/etc/raddb/random count=1 bs=128 dd if=/dev/random of=/usr/local/radius/etc/raddb/DH count=1 bs=128
This creates two files with 128 random bytes each. The device /dev/random may block if there is insufficient entropy (randomness) available. If one of these commands hang, you can do one of two things. First, you can wait a while until the entropy pool is refreshed, or second, you can use the /dev/urandom device instead, which will not block (at the cost of the bytes being generated by a pseudorandom function).
Once you've created these two files, you need to make your changes to radiusd.conf. The first set of changes is to the following Extensible Authentication Protocol section. The items in bold were changed from the original file.
# Extensible Authentication Protocol
#
# For all EAP related authentications
eap {
# Invoke the default supported EAP type when
# EAP-Identity response is received
default_eap_type = tls
# Default expiry time to clean the EAP list,
# It is maintained to co-relate the
# EAP-response for each EAP-request sent.
timer_expire = 60
# Supported EAP-types
# md5 {
# }
## FIXME: EAP-TLS is highly experimental EAP-Type at the moment.
# Please give feedback.
tls {
private_key_password = whatever# CHANGE THIS TO YOUR PASSWORD
private_key_file = /usr/local/1x/etc/<servername>.pem
# Sometimes Private key & Certificate are located
# in the same file, then private_key_file & certificate_file
# must contain the same file name.
certificate_file = /usr/local/1x/etc/<servername>.pem
# Trusted Root CA list
CA_file = /usr/local/1x/etc/root.pem
dh_file = /usr/local/1x/etc/DH
random_file = /usr/local/1x/etc/random
#
# This can never exceed MAX_RADIUS_LEN (4096)
# preferably half the MAX_RADIUS_LEN, to
# accomodate other attributes in RADIUS packet.
# On most APs the MAX packet length is configured
# between 1500 - 1600. In these cases, fragment
# size should be <= 1024.
fragment_size = 1024
# include_length is a flag which is by default set to yes
# If set to yes, Total Length of the message is included
# in EVERY packet we send.
# If set to no, Total Length of the message is included
# ONLY in the First packet of a fragment series.
include_length = yes
}
}
Change your EAP section to match the previous script, being sure to change the private_key_password and the names of the private_key_file and certificate_file attributes to your file names. You also need to ensure that the paths are set to where you've placed the files you generated using OpenSSL.
Now, you need to make changes to the authorization section and uncomment the eap line so the section looks like the one that follows. The important part is that eap must be added as supported.
# Authorization. First preprocess (hints and huntgroups files),
# then realms, and finally look in the "users" file.
# The order of the realm modules will determine the order that
# we try to find a matching realm.
# Make *sure* that 'preprocess' comes before any realm if you
# need to setup hints for the remote radius server
authorize {
#
# The preprocess module takes care of sanitizing some bizarre
# attributes in the request, and turning them into attributes
# which are more standard.
#
# It takes care of processing the 'raddb/hints' and the
# 'raddb/huntgroups' files.
#
# It also adds a Client-IP-Address attribute to the request.
#
preprocess
#
# The chap module will set 'Auth-Type := CHAP' if we are
# handling a CHAP request and Auth-Type has not already been set
#
# chap
# counter
# attr_filter
eap
suffix
files
# etc_smbpasswd
}
Now, you make your last change to the Authentication section, uncommenting the reference to EAP. Again, the important part is that EAP (eap in bold above) be uncommented.
# Authentication.
#
# This section lists which modules are available for authentication.
# Note that it does NOT mean 'try each module in order'. It means
# that you have to have a module from the 'authorize' section add
# a configuration attribute 'Auth-Type := FOO'. That authentication type
# is then used to pick the appropriate module from the list below.
#
# The default Auth-Type is Local. That is, whatever is not included
# inside
# an authtype section will be called only if Auth-Type is set to Local
#
# So you should do the following:
# Set Auth-Type to an appropriate value in the authorize section. For
# example chap
# will set Auth-Type to CHAP, ldap to LDAP etc
# After that create corresponding authtype sections in the authenticate
# section below
# and call the appropriate modules (chap for CHAP etc)
authenticate {
# pam
unix
# Uncomment it if you want to use ldap for authentication
# authtype LDAP {
# ldap
# }
# mschap
eap
# Uncomment it if you want to support CHAP
# authtype CHAP {
# chap
# }
# Uncomment the following if you want to support PAP and you
# extract user passwords from the user database (LDAP,SQL, etc).
# You should use the 'files'module to set 'Auth-Type := PAP' for
# this to work.
# authtype PAP {
# pap
# }
#
}
Open the users file in your favorite editor and search for the string “John Doe”. Now, enter a line for each of your client certificates using their full name, as follows:
"<clientsfullname>" Auth-Type := EAP
You can also add the following line for testing purposes, but make sure to remove it after your testing is completed.
"test" Auth-Type := Local, User-Password == "test"
Now, you're ready to test your installation. Because FreeRADIUS may be using a different version of OpenSSL than the one installed on your system, you need to build a custom shell to start the FreeRADIUS daemon in a way that it can find the OpenSSL libraries. Use the run-radiusd script created by Adam Sulmicki, as follows.
#!/bin/bash -x export LD_LIBRARY_PATH=/usr/local/openssl/lib export LD_PRELOAD=/usr/local/openssl/lib/libcrypto.so /usr/local/radius/sbin/radiusd $@
Now, start FreeRADIUS in debug mode from a shell, as follows:
run-radiusd –X –A
You'll see a great deal of output, and eventually the last line should read “Ready to process requests.” You can now test the installation with the following command:
/usr/local/radius/bin/radtest test test localhost 0 testing123
If you get Access-Accept, everything is configured properly and you can delete the test line from the users file. You may also want to delete the entry for localhost in the clients.conf file. If, however, you get no response or Access-Reject, you need to review the configuration files. You may also have to either disable your packet filtering firewall (in other words, iptables), with the command service iptables stop or add a rule to permit the RADIUS requests to work on port 1812.
In this section, we're going to show you how to build an access point yourself using UNIX. The access point you'll build won't have WPA support (it wasn't completed at the time this book was written), but we'll provide links and how-to's on our Web page, www.wpa-security.org, once the work is finished.
If you are building your own access point, there's a limited amount of hardware you can use. The easiest, and most expensive, is to use a laptop. An alternative is to use a low-cost single-board computer running an Intel-compatible CPU such as those available at www.soekris.com.
In the next section, we're going to assume that you're using a laptop.
Linux, FreeBSD, and OpenBSD all have the capability of running as an access point using a WLAN card based on the Intersil Prism2 chipset. These cards are the most common cards available, with manufacturers such as Samsung, Compaq, and others shipping PCMCIA WLAN cards based on the Prism2 or Prism2.5 chipsets. At the time of writing, a list of companies using the Intersil Prism 2 chipset was available at: www.intersil.com/design/prism/prismuser/index.asp
We cover how to use both OpenBSD and Linux as access points.
For the first step, you need to install the latest version of the OpenBSD operating system. The installation files and instructions can be found at www.openbsd.org. Once the operating system is installed, you can begin setting the system up as an access point. You're going to be amazed at how easy it is to turn a laptop into an access point, albeit an expensive one.
The first step is to set up your wired network connection, assuming that you'll be using your access point to connect to a wired network and not as a stand-alone server. Details on how to do this can be found at the OpenBSD Web site.
The second step is to insert your Prism2 WLAN card into the laptop. The console window should display several lines of information about wi0. This is the operating system kernel recognizing the card you just inserted. One of the lines should start with “wi0: PRISM 2”. If not, the card you are using may not be a PRISM2-based card, and these instructions will not work for you.
At this point, it would probably help if you familiarized yourself with the manual page for the wicontrol command by typing:
man wicontrol
The command wicontrol configures Prism2-based wireless cards. As you could see from the manual entry, you are able to select normal station mode, ad-hoc mode, or hostap mode. The last mode, hostap, is what we're discussing here. wicontrol also allows you to set the channel, MAC address (remember earlier when we said it was easy to clone MAC addresses? You use wicontrol.), WEP, and the WEP keys. Unfortunately, right now the default distribution of OpenBSD (and the other open source UNIX-based projects) supports only vanilla WEP. The University of Maryland MISSL group, however, is working on incorporating WPA into OpenBSD. While it is too early to describe this work in this book, we'll have more details on the MISSL Web page (www.missl.cs.umd.edu), and on the Web page for this book (www.wpa-security.org).
Okay. Now that you're familiar with wicontrol, we can configure and turn on our home brew access point using the following commands as root.
wicontrol wi0 –e 1 –k "Hello" –p 6 –f 11 –n myap # Make sure the IP_address is on the same subnet as your wired device ifconfig wi0 inet <IP_address> netmask <Net_mask> # Or you can use DHCP to configure the IP address brconfig bridge0 add <wired_device> add wi0 up
The first command enables WEP encryption using the key “Hello” as well as hostap mode on channel 11, and the command assigns the network name of “myap”. In the second command, we're manually configuring the IP address for the machine. You could also use DHCP for this as well. The third and final command enables bridging between the wireless interface (our AP) and the wired interface just like the commercial access points.
That's it. We're done. If you set up the wired device with routing and so on, and you have a DHCP server running, you can start up a client and associate and start using your new AP!
You should, however, add additional security to the AP by using the built-in IPsec implementation. You can start learning about this from the OpenBSD documentation, and several how-to's that you'll find linked to our Web site.
You can also use Linux as your base operating system, and we've used Linux Red Hat 8.0 and the hostap software by Jouni Malinen at www.hostap.epitest.fi/. The hostap software is another implementation of a prism2/2.5/3 driver for UNIX. Hostap, however, includes support for MAC access control lists, IEEE 802.1x, dynamic WEP rekeying, RADIUS, and minimal support for interaccess point protocol support (IAPP).
The hostap software has a large number of capabilities, and covering them all here would be difficult. Therefore for the sake of brevity, we won't cover much about hostap here. But, we will post more information on our Web site (www.wpa-security.org).
Now that your server infrastructure is built, we can talk about configuring your access points to use your servers. Given the large number of access points available on the market today, we can't present configuration information for all of them. Therefore, we've picked one of the more common access points. While we're not covering many access points, we will include links to sources of information about other access points on our Web site.
We're also only going to describe configuring Microsoft Windows XP for the very same reasons, but again we will provide links to a how-to for configuring an open source supplicant, Xsupplicant, at the end of this chapter and on our Web site.
Currently, not all of the commercial access points support IEEE 802.1X. That will change as WPA becomes more widely available. Until then, IEEE 802.1X is currently only supported by the major wireless vendors such as Cisco, Agere, and a few others. If you're going to buy a new access point, you must be certain that it supports IEEE 802.1X if you want to use the best security available.
The following sections give some practical examples of configuring the Cisco products via their Web interface. Note that we cannot guarantee the accuracy of this information because products change, and you should consult the documentation provided with the product for definitive information.
Configuring a Cisco AP to use IEEE 802.1X is straightforward and involves only a few changes to the AP configuration. This section uses the Web management interface, but you can do this configuration via the console as well.
First make sure that you're running at least firmware version 11.08T to ensure that IEEE 802.1X support is available.
From the home page of the Web-based interface, select Setup to open the menu shown in Figure 17.2.
Select Security at the bottom of the screen to open the screen shown in Figure 17.3.
Select the fifth item from this screen, Authentication Server, to set up the server, as shown in Figure 17.4.
This screen is the first of the two screens in which you do all of your work. In the first column, enter the IP address for your FreeRADIUS server. Now select RADIUS from the Server Type dropdown menu. Enter the port number, 1812, into the Port column, followed by the shared secret that you used when you set up the file clients.conf as part of the FreeRADIUS configuration earlier. Finally, set the timeout to the default 20 seconds. Click OK, and return to the Security Setup screen. Now select Radio Data Encryption (WEP) (Figure 17.5).
Select Open for both Accept Authentication Type and Require EAP. Now, go back to the Security Setup screen, and select Radio Data Encryption (WEP) again. You should see the screen shown in Figure 17.6.
In the first dropdown menu, make sure you select Full Encryption; if you do not make this selection, Windows XP will not associate with your access point. Now, you need to select the first WEP key and enter a value for the key. This key is the multicast key only, and will be used only when the AP transmits multicast data. Clients will still negotiate pairwise keys.
802.1X supplicant (or client) support is currently only built into Windows XP. However, several vendors are now supporting previous versions of Windows, and an open source implementation is available for most open source UNIX-based operating systems.
There are two steps in configuring Windows XP SP1. The configuration for XP SP1 is slightly different from that for XP, but you should be able to work through those differences. The how-to's listed at the end of this chapter cover XP configuration, so XP SP1 configuration is covered here to show you how to use 802.1X with your infrastructure. In the first step, the certificates you generated earlier are installed on the client. The second step involves configuring the wireless device on Windows XP.
You should update your version of Windows XP to Service Pack 1. SP1 contains an important security patch that can prevent a man-in-the-middle attack due to a malformed packet. Therefore, the remaining instructions assume a SP1 installation.
For this step, we need the root.der and <clientusename>.p12 files you created earlier. Copy both files to the Windows XP client. Now, double-click the root.der file to display the popup window shown in Figure 17.7.
Click the Install Certificate button to open the Certificate Import Wizard. Click the Next button to open the window shown in Figure 17.8.
Select the option Place all certificates in the following store and click Browse to open a browser, as shown in Figure 17.9.
Select Trusted Root Certificate Authorities and click OK and then Next and Finish. Answer Yes when you're asked if you want to import the certificate. Now, you should see a message that the certificate was imported successfully.
Now, double-click the <clientusername>.p12 file. The Certificate Import Wizard appears once again. Click Next and leave the filename alone and click Next again. Now, you are asked to enter the challenge password you used when generating the certificate. Click Next. Select the option “Automatically select the certificate store based on type of certificate” and click Next. Wait for a message indicating that the certificate was imported successfully, and then click Finish. A popup window will tell you that you imported the certificate correctly.
Now you can set up the wireless device.
Open the Wireless Configuration Panel by double-clicking on one of the terminals icon in the lower-right corner of your screen. You can find the correct icon by moving your mouse over the icons until one says “Wireless Network”. That is the icon you need to double-click (see Figure 17.10).
Select your network, and check the Advanced tab to open the panel shown in Figure 17.11.
Select your network and click the Authentication tab to open the window shown in Figure 17.12.
Now select the Enable network access control using IEEE 802.1X radio button and ensure that the EAP type is listed as Smart Card or other Certificate. Click the Properties button to open the Smart Card or Other Certificate Properties window shown in Figure 17.13.
Select the options Use a certificate on this computer and Validate server certificate, and ensure that the Trusted root certificate authority option is set to the root certificate you imported earlier.
If everything works (which we know always is the case), you'll be connected to your network using WPA.
This chapter explained how to build your own small enterprise or test network using open source software as well as some commercial products. We should stress, at this point, that the point of this exercise was to make you familiar with how to build a working wireless network that uses WPA. If you plan to use this setup operationally, you should consider doing many other tasks beyond the scope of this book.
Portions of this chapter are based on the how-to's from Adam Sulmicki, Mike van Opstal, and Raymond McKay.
This section provides a pointer to using a Windows Server instead of Open Source.
Mike Van Opstal of the University of Maryland has written an excellent how-to on using a Windows 2000 as a RADIUS and DHCP server. Rather than duplicate that material here, you can find Mike's how-to at www.cs.umd.edu/~mvanopst/8021x/howto/server.html and a link to it at our site www.wpa-security.org/Windows/server.html.
Adam Sulmicki's how-to can be found at www.missl.cs.umd.edu/wireless/eaptls/ and Raymond McKay's how-to can be found at www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm. Finally, you can find more information about using OpenSSL at the following URL: www.pseudonym.org/ssl/ssl_cook.htm, and in the book by John Viega, Matt Messier, and Pravir Chandra (2002) entitled Network Security with OpenSSL.