Rogue computers are some of the scariest things to infest your network. You go to great lengths to build a protected network, you keep your clients current with updates and anti-malware signatures, and yet you still suspect that these non-conforming machines are causing problems in your network. Forthcoming technologies like Network Access Protection (NAP) promise to help control this soon. But what can you do right now to mitigate the risks posed by rogue machines?
Using 802.1X to control who can access a network is an increasingly popular solution. 802.1X is a port-based access control method defined by the Institute of Electrical and Electronic Engineers (IEEE) that can be configured to require mutual authentication between the client and the network. If there’s no authentication, no communications are permitted. 802.1X works with Extensible Authentication Protocol to authenticate the client to the network and the network to the client, ensuring that both sides are communicating with recognized entities.
As a technology to control admission of authenticated computers into a network, 802.1X works very well. Your computer must possess the correct authorization to be allowed to join the network. However, 802.1X is insufficient for complete protection from rogue machines because it lacks a full end-to-end authentication and authorization mechanism. There’s a shortcoming in wired 802.1X that reduces its effectiveness at keeping out rogue machines.
How 802.1X Operates
802.1X is designed to work over just about any kind of network: wired, wireless, barbed wire, even bongo drum. 802.1X requires a supporting infrastructure, namely clients, LAN switches, and wireless access points that can participate in 802.1X, a RADIUS server, and some sort of account database (such as Active Directory).
A client, called a supplicant, makes an initial connection to an authenticator, the LAN switch or a wireless access point. The authenticator is configured to require 802.1X from all supplicants and will ignore any incoming connection that do not conform. The authenticator asks the supplicant for its identity, which it will forward to the authentication server (RADIUS).
RADIUS follows whatever mechanism it needs to authenticate the incoming client. Generally this involves setting up an EAP conversation between the supplicant and the authentication server (the authenticator is just a pass-through device here) and establishing an authentication method inside the EAP conversation. Note that EAP itself doesn’t define any kind of security on its own—the authentication protocols used must incorporate their own security.
Using 802.1X for Wired Security
For 802.1X to be effective in wired networks, all of the switches in your network—or at least those that clients and servers connect to—must support 802.1X. You also need a PKI if you don’t have one: PEAP requires a digital certificate for the RADIUS server; EAP-TLS requires digital certificates for all computers. Save yourself some money and build a Windows enterprise certificate authority. All of your domain-joined computers will trust this CA and will therefore trust the certificates it issues.
All of your clients need to have an 802.1X-capable IP stack, such as the stack built into Windows XP. If you can’t upgrade to Windows XP yet, there is an option: Microsoft has released an 802.1X stack for Windows 2000 (http://support.microsoft.com/kb/313664). However, in both Windows XP and Windows 2000 wired 802.1X networks, there’s a known problem that can occur if all of these conditions are true:
• You’ve configured 802.1X only for machine (not machine and user) authentication
• You’ve configured 802.1X only for machine (not machine and user) authentication
• You’re using PEAP (not EAP-TLS)
• Your computer’s machine account password has expired
The result? The computer won’t be able to log onto the domain. If this describes your environment, then consider longer expiration times on machine passwords. This really isn’t all that bad since they’re randomly generated and very strong. If you’re using EAP-TLS, the problem doesn’t exist because authentication is handled through a different set of DLLs. If you’re using PEAP with machine and computer authentication, then the machine password will get reset when user authentication succeeds.
Why 802.1X on Wired Networks is Insufficient
802.1X is an ideal foundation for wireless security, which we’ve explored many times in the past at conferences and in documentation on Microsoft’s Web site (http://www.microsoft.com/wifi). But deploying 802.1X alone to secure wired networks against rogue machines has some significant drawbacks, including lack of manageability. In AD group policy, several group policy objects exist for you to manage 802.1X on wireless networks. These GPOs don’t exist for wired interfaces, and there are no published APIs for managing wired 802.1X client computers. Some architectural reasons prevent adding GPOs to Windows 2000 and Windows XP for wired 802.1X. Because of this lack of centralized management capability, large-scale 802.1X deployment on Windows isn’t feasible currently and will be expensive to maintain.
Finally, the protocol has a major weakness: It authenticates only at the establishment of a connection. Once a supplicant authenticates and the switch port opens, further communications between the supplicant and the switch aren’t authenticated, making it possible for an attacker to join the network. Setting up the attack does require physical access to the network, so in some respects this attack is a bit esoteric. An attacker needs to disconnect a computer (let’s call this the “victim”) from its 802.1X-protected network switch port, connect a hub to the port, connect the victim to the hub, and connect an attack computer (which we’ll call the “shadow”) to the hub. This is trivially easy if the attacker is physically inside your facility and if your Ethernet jacks are accessible. Or the attacker could connect an unmanaged access point to the hub and then conduct the attack from your parking lot.
The brief disconnection of the victim from the network won’t interfere with the attack’s success. When the victim computer is reconnected, it authenticates to the switch again. It doesn’t matter that a hub is in the way now, because a hub is little more than a wire with ports in it. Electrically, the victim is still connected to the switch.
Next the attacker configures the shadow computer’s MAC and IP addresses to be the same as those on the victim computer. A little network sniffing will quickly reveal this. The attacker also configures a host firewall to drop all inbound traffic that isn’t a reply to communications that it initiated.
Now, here’s how the attack works. After the victim computer has authenticated and the switch port is open, the attacker can connect to resources on the protected network. This is because there is no per-packet authentication of the traffic once the port is open. Since the shadow computer has the same MAC and IP addresses as the victim computer, it appears as if there’s a single computer connected to the port.
So What Should You Do?
First, understand the scope of the attack. Wireless networks aren’t vulnerable because 802.1X+EAP creates mutually authenticated sessions with per-supplicant encryption keys (this is called “dynamic WEP.”) Because the keys are never sent over the air, the shadow computer attack won’t work—it has no way of acquiring the key. The shadow is unable to connect to the access point where the victim computer is already connected. So, in a sense, wireless networks with 802.1X+EAP are actually more secure than wired ones.
But for wired networks consider what it is that you’re trying to protect. If the goal is to prevent rogue machines from infecting other machines on the network, then an end-to-end protection mechanism is necessary. 802.1X alone doesn’t give you this. It will stop an attacker from conducting bandwidth denial-of-service attacks, which might be important to you, although generally it’s computers, not networks, that are the target of DoS attacks. But the unstated premise of 802.1X is that all potential computers allowed to connect to the network have the same trust level.
I strongly encourage you to use IPsec. IPsec stops an attacker from getting to other IPsec-protected resources and allows you to define “zones” of trust. It’s the protocol’s connection and packet authentication that make it better suited to addressing the threat. If Alice’s computer is unable to create the proper IPsec security association with Bob’s server, then Alice can try all she likes but she won’t be able to compromise Bob. It could be that Alice’s computer is completely untrusted, or that her computer is in a different trust zone than the server. And this works even if Alice’s computer is mobile and not directly connected to the network, since IPsec controls can move with the host.
IPsec isn’t a silver bullet, of course. It does require hosts that are capable of performing IPsec. This shouldn’t be a problem for most organizations, though, since IPsec has been in Windows for some time now and is also supported by many other popular operating systems. IPsec won’t stop an attacker from getting an IP address or from communicating over your LAN—but you could, of course, just disable the switch port of someone trying to DoS your network. Or you might consider deploying both 802.1X and IPsec if you want to address a range of threats; some of our customers have begun doing this now.
IPsec Vs. 802.1X?
This does not mean it is a battle between IPsec and 802.1X. When you think of 802.1X as a way of “preventing entry” and IPsec as a way of “preventing access,” it becomes evident that they attempt to solve the rogue machine problems in different ways. You have to analyze your threats, consider your risk stance, and understand the differences in the technologies to decide which is better for your organization.
