A typical TCP/IP network that uses DHCP is defenseless against individuals who can find a network drop and plug into it. Suddenly, the network graciously grants the unauthorized computer an IP address, and the attacker is able to launch a variety of attacks—such as breaking into specific servers, eavesdropping on network packets, and unleashing a worm or Denial of Service (DoS) attack. An Internet attacker breaching your firewall would have the same level of access.
An interesting solution to such problems is 802.1x. Although its more common application involves the security of Wi-Fi networks, 802.1x can protect any Ethernet network, including wired networks. In this article, I show you how to implement this wireless standard on your wired network so that you can guard against unauthorized individuals exploiting physical access to a network drop. In fact, 802.1x can even protect you against malware-infected vendors or contractors that connect to your network.
A Little Background
Historically, we've relied on physical security to limit access to network drops and used fully switched networks to derive a degree of protection against eavesdropping. However, malicious users can use Address Resolution Protocol (ARP) redirects to fool switches into facilitating eavesdropping attacks. I've heard many stories about unauthorized individuals plugging into a company's network and attacking resources. All it takes is one branch office, connected to the corporate intranet, that fails to control access to network drops at its location. What's to prevent consultants, sales representatives, or maintenance personnel from plugging into the corporate network? In the worst-case scenario, an attacker would connect a wireless Access Point (AP) to your network, then leave the building to access your network wirelessly. Securing DHCP servers from leasing IP addresses to unauthorized computers simply isn't practical or effective. An attacker can find unused IP addresses easily.
The 802.1x standard bridges the security gap between your directory service (e.g., Active Directory—AD) and ports on your network switches. When you implement 802.1x, clients must authenticate to the switch before the switch can begin routing packets to and from the client. 802.1x uses two other protocols: Remote Authentication Dial-in User Service (RADIUS) and Protected Extensible Authentication Protocol (PEAP). RADIUS facilitates communications between the switch and your directory service, and PEAP carries the authentication traffic between the client and your directory service. Figure 1, page 2, shows an overview of the components you need to implement 802.1x. Windows 2000 and later offers excellent support for 802.1x, and it's simple to set up. In fact, you'll be able to make 802.1x authentication transparent for your domain users by leveraging the domain account with which they log on to their workstation.
For the purposes of this article, I've implemented 802.1x in an existing Windows network of Active Directory and Windows XP Service Pack 2 (SP2) workstations. Although you can use 802.1x with Windows 2000 and pre-SP2 XP, I base this discussion on XP SP2 for simplicity's sake. A Windows Server 2003 system, as well as a switch that supports 802.1x, are also involved in this solution. I used a Cisco 2950 switch, but any 802.1x-compliant switch should work. The project has three main steps. First, configure Microsoft Internet Authentication Service (IAS) on the Windows 2003 system to provide RADIUS connectivity between the switch and AD. Second, set up the switch to use 802.1x. Third, set up 802.1x on your workstations.
Configure IAS
IAS is Windows' built-in RADIUS server and functions as the go-between for your switch and AD. When a client connects to a port on the switch, the switch communicates via RADIUS with the IAS server to determine whether the client is authentic and should be allowed to use the network. To complete the authentication process, the switch acts as a middle man (authenticator, in 802.1x terminology) between the client (supplicant) and the IAS server (authentication service). The client and IAS server communicate via EAP with the switch, simply encapsulating the EAP traffic within RADIUS packets between itself and the IAS server. EAP lets you implement just about any type of authentication you want, including one-time password tokens, smart cards, and—in the case of this article—the password of the user and/or computer. The switch doesn't know or care what type of authentication occurs; it merely passes the EAP messages back and forth between the client and IAS server until IAS informs the switch whether the client is authorized. However, EAP by itself doesn't compensate for vulnerabilities in different authentication types. For example, password-based challenge/
response protocols can be subject to cracking, replay attacks, and so on. Therefore, Microsoft uses PEAP to add another layer of encapsulation. Inside the EAP conversation, Windows creates a Secure Sockets Layer (SSL) tunnel and performs the actual authentication within the tunnel.
Before installing IAS, you need to install Certificate Services so that IAS can obtain a certificate, which PEAP requires. PEAP requires this certificate for setup of the SSL tunnel and, optionally, for authentication of the IAS server to the client. After you install Windows 2003 and join it to your domain, you'll need to install Microsoft IIS with Active Server Pages (ASP) enabled, then install Certificate Services as an enterprise root. (For information about Certificate Services, see "Uncover PKI and Certificate Services in Windows Server 2003, InstantDoc ID 42172.) You can install both components from the Control Panel Add or Remove Programs applet.
Now it's time to install IAS. (In this article, I named the IAS server IAS-1, which will appear in some of the figures.) Open the Control Panel Add or Remove Programs applet and click Add/Remove Windows Components. Drill down into Networking Services, select the Internet Authentication Service check box, and click OK, then Next. When the IAS installation is finished, open the Microsoft Management Console (MMC) Internet Authentication Service snap-in, which you'll now find under Administrative Tools.
First, to make sure your IAS server has sufficient access in AD to authenticate users and computers, you need to register the server. Right-click the root of the tree pane, Internet Authentication Service (Local), and select Register server in Active Directory. Next, you need to enable IAS logging, which will help you troubleshoot your setup. Right-click the root of the tree pane again, and select Properties. On the Services tab of the Internet Authentication Service (Local) Properties window, select both check boxes so that the server logs both rejected and successful authentication requests.
Now, let's get down to the business of setting up RADIUS communications between IAS and the switch. First, you need to configure a RADIUS client record for the switch so that IAS will accept authentication requests from the switch. Right-click RADIUS Clients in the snap-in's tree pane and select New RADIUS Client to start a wizard. On the wizard's first page, enter a descriptive name for the switch, as well as its IP address or DNS name, then click Next. On the final page, you need to secure the communications between the switch and the IAS server. Enter a long, complex password in the Shared Secret and Confirm Shared Secret fields. Select the Request must contain the Message Authenticator attribute check box. Also, change the Client-Vendor field from RADIUS Standard to Cisco (or whichever brand of switch you're using). If your vendor isn't on the list, just select RADIUS Standard. Setting the switch vendor isn't absolutely necessary, but it can come in handy if you later implement multiple remote-access policies. Click OK. Now, if you open the properties of the RADIUS client you just created, you should see a dialog box that resembles Figure 2.
The next step is to create a remote-access policy for requests from the switch. With the remote-access policy, you define the type of authentication that the end user must pass, as well as a host of other optional restrictions. Because a RADIUS server such as IAS can service requests from a variety of devices—including dial-up servers, VPN servers, wireless APs, and switches—IAS needs a way to associate each request with the appropriate remote-access policy. You have a variety of ways to set up remote-access policies. In this case, we'll keep it simple and use the client-vendor attribute as the selection criteria. That way, requests that have Cisco defined as the client-vendor have this remote-access policy applied to it, but the policy will ignore other RADIUS clients you define (e.g., a Microsoft RRAS server).
To create the policy, right-click Remote Access Policies and select New Remote Access Policy, which starts a wizard. Select Use the wizard to set up a typical policy for a common scenario, enter a descriptive policy name (e.g., Switch Port Access Control), and click Next. On the Access Method page, select Ethernet and click Next. On the User or Group Access page, add Domain Users and Domain Computers to the Group name list. You need to add domain computers so that when a workstation boots up, it can access the DC for time synchronization, Group Policy, and authentication requests from the DC when users attempts to log on with a domain account. However, we're going to configure our workstations so that when users log on, they won't be able to access the network unless they also authenticate to the switch. Don't worry, the authentication will be transparent for an authorized domain user. This measure is important because an intruder who has physical access to a workstation can easily use a tool such as Ntpasswd to hack the local administrator account. (For information about Ntpasswd, see "Access Denied: Reset the Administrator Password on a Locked-Out Machine," InstantDoc ID 20911.) By configuring the workstation to reauthenticate after a user logs on, you ensure that such an attack would fail.
Click Next to access the wizard's Authentication Methods page. Select Protected EAP (PEAP), and click Next. The resulting summary page should resemble Figure 3. Click Finish. You've created the remote-access policy that will let users and computers in your domain access your wired network, but we need to make one change. Open the properties for the remote-access policy. You'll notice that the first policy condition requires NAS-Port-Type to match Ethernet. However, the Cisco 2950 switch doesn't report its port type as Ethernet, which IAS expects from 802.1x-enabled switches. Therefore, simply delete the policy condition. But you need a way to link this policy to requests that come from the switch. Assuming you don't have other Cisco devices acting as clients to this IAS server, add a new policy condition that requires the Client-Vendor attribute to match Cisco. Remember that you configured the switch's RADIUS client record with the same parameter. Click OK to close the policy. Your IAS server is now ready to service requests from your switch. Let's move on to the switch.
Set Up the Switch
I'll assume your switch is still in the box. Switch configuration can vary, but they all follow the same basic steps. When you power up a new Cisco 2950, your first task is to assign it an IP address on your network. The easiest way to do that is to put the switch into its express-configuration mode. Press and hold the mode button on the front of the switch for 3 seconds. You'll know the switch is in the proper mode when all three lights are illuminated. Now, connect a PC with DHCP enabled to one of the switch's ports with a patch cable. After your PC obtains an IP address, start your Web browser and direct it to 10.0.0.1, which displays the switch's Web configuration page. Configure the switch with an available static IP address from your network, and enter the appropriate subnet and default gateway, then save the configuration. The switch will reset and begin using the new static address. Connect the switch to your network and—from a PC connected to your network—open your browser again but point it to the switch's new address, as Figure 4 shows. Enable Telnet Access and enter a strong password in both the Switch Password and Telnet Password fields, making sure to remember the password so that you can access the switch later. Click Save.
We'll use Telnet to finish the remainder of the configuration. Open a command prompt and enter
telnet <switch address>
Enter the Telnet password and the following commands:
Configure terminal Aaa new-model Aaa authentication dot1x default group radius dot1x system-auth-control Aaa authentication login default enable
The above commands enable RADIUS and 802.1x for the switch, then make an exception for Web and Telnet access to the switch so that you can still log on with the passwords we defined earlier. Now, 802.1x is enabled on the switch itself, but you still must specify which ports on the switch should require 802.1x authorization from clients who connect. At this point, you should require 802.1x only on ports that terminate at network drops that lack sufficient protection. For example, don't require 802.1x on ports that connect to servers in a secured computer room, and certainly don't enable 802.1x on the port that connects the switch to the IAS server. The Cisco 2950 has a total of twenty-four 10/100 ports and two 100/1000 ports. For the purposes of this article, I required 802.1x on the first 16 ports, then left the remaining eight ports and the two high-speed ports without 802.1x. To configure a port for 802.1x, you would enter the following commands:
Interface FastEthernet0/1 switchport mode access Dot1x port-control auto
To configure additional ports, repeat the above commands but replace the 1 with the appropriate port number.
Now, you need to configure the switch to use your IAS server. Assuming your IAS server's address is 10.42.42.1 and the password you entered in the RADIUS client record is Djlk33EU3dj39dEE4, you would enter the following commands:
Radius-server host 10.42.42.1 auth-port 1812 key Djlk33EU3dj39dEE4
Once you've completed configuring the switch, enter
end
You can verify your settings by entering
show running-config
and you can save the settings by entering
copy running-config startup-config
Your switch is ready to go. Now, let's configure an XP client.
Set Up Workstations
On your workstation, open the Control Panel Network Connections applet and access the properties of your wired Ethernet connection. Select the Authentication tab, which Figure 5 shows, and select the Enable IEEE 802.1x authentication for this network check box. In the EAP type dropdown list, choose Protected EAP (PEAP) and select the Authenticate as computer when computer information is available check box. So far, you've enabled 802.1x for this network connection and enabled the computer to use its computer account to authenticate to the switch until a user logs on. That way, the workstation will be able to apply Group Policy and access the DC when a user logs on with a domain account. Next, click Properties. In the Protected EAP Properties dialog box, which Figure 6 shows, clear the Validate server certificate check box. This validation is more important on wireless connections, for which an attacker can set up rogue APs. Make sure the Select Authentication Method dropdown list is set to Secured password (EAP-MSCHAP v2). Click Configure. In the EAP MSCHAPv2 Properties dialog box, make sure the Automatically use my Windows logon name and password (and domain if any) check box is selected.
You've configured the workstation to use either its own domain account password or the user's password to authenticate to the switch. Click OK to close all the dialog boxes. If you have Windows Firewall enabled on this workstation, you need to enable Ping requests for the testing you're about to perform. To enable your workstation to reply to pings, reopen the properties of your network connection and select the Advanced tab. Click Settings to display the Windows Firewall dialog box. Select the Advanced tab, then click Settings in the ICMP dialog box. In the ICMP Settings window, select the Allow incoming echo request check box and click OK to close all the dialog boxes. Shut the workstation down for the time being.
Test Your Setup
Let's test our work! First, you should verify that the switch is blocking access to unauthorized accounts. To do this, you need to revoke remote-access permission from the workstation's account. Open the Active Directory Users and Computers snap-in, and open the properties of the computer account you want to use for testing. For this article, I named the computer Workstation1. Go to the Dial-In tab and select Deny access under Remote Access Permission (Dial-in or VPN). Close the account. Now, when the computer tries to authenticate via IAS, IAS will find that remote-access permission is denied for the account, then inform the switch to deny port access to the workstation.
With the workstation powered off, connect the workstation to one of the 802.1x-enabled ports on the switch and power up the workstation. After the workstation fully powers up, refrain from logging on. Instead, go to another computer and obtain the workstation's address from your DHCP server. Attempt to ping the workstation. The ping should fail. Wait a minute or two and try again. If the ping still fails, the test is probably successful, but let's make sure. Open Event Viewer on the IAS server, and select the System log. You should see a recently logged warning event ID 2 with source IAS. When you double-click the event, you should see details that resemble those in Figure 7, page 5. As you can see, Workstation1 attempted to authenticate through the switch but failed because it lacked the remote-access permission. This event proves that our setup is blocking unauthorized computers from accessing the network in any way.
Now, let's see if our setup correctly allows authorized computers. Open the workstation's computer account in the Active Directory Users and Computers snap-in again, and change the Remote Access Permission (Dial-in or VPN) setting to Control access through Remote Access Policy. After you do so, IAS will be solely in charge of granting or denying access to this computer, according to the remote-access policy you defined in IAS earlier. Close the computer account, and restart the workstation. After it fully boots, try pinging it again from another computer. If it initially fails, the computer might not have authenticated to the switch yet. Give it another minute, and ping again. If the ping succeeds, IAS has evidently authorized the computer, but to make sure, check the System log on the IAS server for event ID 1 from source IAS. You should see an event similar to the one that Figure 8 shows, reporting that the workstation was granted access.
At this point, the workstation can access domain services for applying Group Policy and authenticating domain users when they attempt to log on at the workstation's console. For the best security, though, when a user logs on to the workstation, the user should be forced to reauthenticate to the switch. Such a measure protects against the situation I described earlier, in which an unauthorized user gains access to an authorized computer and uses a local account such as Administrator to successfully log on. According to Microsoft documentation, XP should disconnect network access within 2 minutes of a user logon, unless the user succeeds in authenticating to the switch.
Because you selected the Automatically use my Windows logon name and password (and domain if any) check box earlier in the article, the user authentication to the switch should be transparent. This setting causes XP to simply use the credentials with which the user logged on to authenticate to the switch. As long as the IAS server's remote-access policy authorizes the credentials, the user will continue to have network access without interruption or interaction with XP. However, in my testing, XP failed to drop network access when an unauthorized user logged on. As long as the workstation successfully authenticated to the switch, unauthorized users who subsequently logged on were still able to access the network. I wasn't able to determine whether the cause was related to XP or the switch, but I did come up with a workaround. I simply enabled reauthentication on the switch. Reauthentication is an 802.1x feature that requires the client to reauthenticate at a specified interval. To enable reauthentication on port 1 of the switch every 5 minutes, I accessed the switch through Telnet and entered the following commands:
configure terminal interface fastethernet0/9 dot1x reauthentication dot1x timeout reauth -period 300 end copy running-config startup-config
With these settings in place, the switch will force the client to reauthenticate every 5 minutes. After logging on with a domain user account, you'll see new occurrences of event ID 1 in the IAS server's system log every 5 minutes, but now the user will reflect the user's account instead of the workstation's. If an unauthorized user logs on, he or she will have less than 5 minutes of network access before the switch blocks access.
Another negative aspect of this solution is that you must manually configure each workstation's network connection for 802.1x. By all rights, you should be able to configure all your workstations centrally through a Group Policy Object (GPO), but unfortunately Group Policy supports the configuration of only wireless—not wired—802.1x connections, which is a gap that Microsoft should address. If you have many workstations to configure, you should look into writing a simple WMI script that uses the Win32_NetworkAdapterConfiguration and Win32_NetworkAdapter classes.
Cool Solution
Other than the user-reauthentication and client-configuration problems, using 802.1x to secure switch port access is a pretty cool solution. In future articles I'll show you how to set up access for guests so that when consultants and other business partners visit you with their laptops, they can obtain Internet access from any drop on your network without being able to access systems on your network.
