Security Advisor

Secure Network Access Control

Protect your corporate network by controlling which users and computers can access it at all.

• By Joern Wettern
• 06/01/2005

Access control has been an integral part of computer security since the days of the mainframe, ensuring only authorized users can access specific resources. Now another type of access control is available: control over which users and computers can access the corporate network at all.

You're already protecting resources, such as file shares, databases and mail servers from unauthorized access. Why would you need any other type of access restriction? Because hackers, worms and other threats can do a lot of damage without ever trying to directly access the resources you protect so diligently. Hackers can intercept valuable information by monitoring traffic transmitted on your network, and worms can spread to vulnerable computers regardless of password controls. Because of these threats, a growing number of tools allow you to control which users or computers can even send or receive packets across your network.

No widely used standard exists for implementing network access control, but several interesting approaches may solve problems you're facing, and give an indication of the future of network access technologies. Microsoft and Cisco, for example, are each at work on technology that aims to ensure only authorized clients with up-to-date security software are allowed to connect to the corporate network, even if those clients are connecting remotely via virtual private networks (VPNs).

Securing VPNs
A VPN connection to a network gives users the same access as a wired connection at the office, but there are important differences: For VPN users there's no receptionist to physically check the user's identity, and the computer that establishes the connection is frequently not managed by your company. Over the years, many methods have been developed to overcome the challenge of ensuring the identity of VPN users. Often companies employ two-factor authentication methods, such as smart cards, for this purpose. But no matter how sophisticated your authentication methods, they do little to ensure that the computers that connect via a VPN meet your corporate security standards.

Imagine this nightmare: An employee connects to your network from a computer running Windows 95 that has no anti-virus software installed. Needless to say, this computer has been infected by several viruses. Even worse, a hacker has installed a remote control program on this computer and uses it to freely download confidential data from your network while the unsuspecting user reads his e-mail over the VPN connection.

Microsoft's approach to this problem is VPN Quarantine. (VPN Quarantine was included in ISA Server under the rather unwieldy name "Network Access Quarantine Control." In ISA Server 2004, the feature was enhanced and renamed.) When a client computer connects, a script on the computer runs a number of checks to ensure that it conforms to current corporate security policies. If the checks are successful, the computer gets access to the network. If the computer doesn't pass, it gets disconnected.

Other VPN vendors have different solutions for the same problem. For example, Check Point allows administrators to implement corporate security policies that its VPN-1 SecuRemote client software enforces. You can configure a Check Point VPN server to only allow connections from client computers where the client software has verified that required configuration settings are in place.

One problem that all the VPN access control methods have in common is that they depend on some type of configuration check that's performed by the client computer. A malicious user with administrative privileges on the client computer can circumvent the checking mechanism. Doing so might be difficult, but you can't completely prevent the possibility of this happening.

Securing Wired Access
Controlling access to a wired corporate network is much more difficult than for VPN connections. Unlike VPN connections that go through a central gateway, wired connections can be established using a port on any of your switches or hubs. But it's not only the complexity that leads many administrators to ignore this aspect of network security; there's also the assumption that you can control access to your wired network simply by seeing which computer is connected.

The reality is that you don't always know which computers are connected to your network. For example, one of my customers is concerned about visitors plugging their laptops into a network tap in a meeting room. All of the company's computers are managed using Group Policy and other methods, but a visitor's computer is not subject to these controls, allowing him unauthorized access to data on the network.

To keep unauthorized computers off the customer's network, we implemented 802.1x-based access control as part of a broader PKI deployment. 802.1x is best known as a protocol that controls access to wireless networks, but can be used to control access to any type of network. Recent switch models from major vendors, such as Cisco, HP and Nortel, allow you to configure port-based access control using 802.1x.

802.1x works with a multitude of authentication methods. In effect, it relays any type of credentials between a client and RADIUS server and then waits for the RADIUS server's confirmation that authentication was successful. Computer authentication using 802.1x most often uses certificates. Because we were already deploying certificates to all computers in the customer's Active Directory forest, we could easily require authentication with a certificate issued by a trusted certification authority (CA). Because the CA only issued certificates to managed computers in the forest, we had the guarantee that only securely configured computers could connect to the network, and that visitors could not access the network by plugging in a laptop in a meeting room. Figure 1 illustrates what happens when a client computer with a valid certificate attempts to connect to the corporate network through a switch. If authentication fails, the switch doesn't forward any packets between the client and the network.

Figure 1. Using 802.1x in concert with PKI ensures that only authorized clients can gain access to the network. (Click image to view larger version.)

Implementing 802.1x-based access control for wired clients requires a few elements to be in place:

• A PKI infrastructure that issues computer certificates to all domain members and maps the certificates to AD accounts. This is the hardest element to implement, because properly deploying such an infrastructure requires significant planning.
• Client computers that can use 802.1x for authenticating a connection.
• A switch that supports 802.1x and is configured as a RADIUS client.
• A RADIUS server that forwards authentication requests to a domain controller.
• Domain controllers that ensure client certificates correspond to valid computer accounts. We decided to use the same computer as a domain controller and a RADIUS server because the Internet Authentication Service (IAS), the RADIUS service of Windows Server, doesn't place a heavy load on the processor.

As usual, the details of this solution proved to be more complicated than the concept. For example, we had to make provisions for devices, such as network printers, that don't support the 802.1x protocol. This required us to configure exceptions on specific switch ports. We also ran into security limitations of the 802.1x protocol itself. The specification only requires an access control check when the connection is established, such as when a computer is plugged into a port on a switch. You can also require periodic re-authentication, such as once an hour. However, once authentication has occurred, switches only control access based on a computer's hardware (MAC) address. Because these addresses are easy to spoof, there are several scenarios in which a hacker could gain network access through a port on a switch where a legitimate computer has previously been authenticated. (This is not an issue with wireless access using 802.1x, by the way, because all communications across the channel, between the wireless access point and the client computer, are authenticated by using encryption keys.)

Cisco has developed an approach to wired access control that is similar to VPN quarantine solutions. Cisco's Network Admission Control (NAC) program is a framework for clients and access devices, such as switches, to communicate with each other to enforce administrator-defined security settings. NAC can be used by third-party applications, such as anti-virus programs, and NAC-enabled devices can apply detailed security policies based on a client configuration.

The Future of Network Access Control
One of the biggest limitations of network access control is the lack of industry-wide standards for controlling access based on specific configuration settings. 802.1x doesn't support any detailed configuration checking, and other solutions only control access for a single vendor's devices. Cisco's NAC holds a lot of promise, but without tight integration into the client operating system, a determined hacker can bypass the mechanism by changing files or Registry settings to create the appearance of a secure configuration on an insecure computer.

Microsoft's strategy is to take its current VPN access control mechanism, extend it beyond VPN connections and integrate it more closely with the operating system. This will be done using Network Access Protection (NAP), a planned feature of Longhorn, the next major version of Windows Server. Current plans for NAP include quarantine and access control for acquiring DHCP addresses and VPN connections. In addition, NAP will automatically issue certificates to clients that allow them to communicate with other computers using IPsec.

As Microsoft is working toward Longhorn, Cisco is further developing NAC, and both companies have industry partners promising support of the respective platforms. To be truly effective, however, the configuration inspection on the client computer must be enforced by the OS and integrate with the access control mechanism for a switch, wireless access point or VPN server.

Cisco can deliver technology that controls access at the switches. Microsoft can deliver the OS component that ensures client-side checks can't be bypassed. So the two companies are now working together toward the next generation of network access control. This includes the sharing of technologies and pledges to make NAC and NAP interoperable.

Once these plans lead to actual products, network access control should become much more feasible to implement. For example, you'll be able to easily configure everything you need in order to enforce a policy that requires a client computer have the latest anti-virus signatures installed. The client computer will be able to retrieve the latest policy settings, query the anti-virus program for the signature status, and report the results back to the switch. The switch will then check the policy settings to determine whether to allow access, deny it, or place the client into a quarantine state with limited access. The switch, OS and anti-virus program will be able to communicate securely. Best of all, configuring everything won't include writing complex scripts, as support for access control will be built into all components.

Which Method Is Best for You?
If you're using VPN connections today, see if your VPN vendor offers any quarantine or similar access control capability, and consider implementing it. If you're looking to purchase a new VPN solution, these capabilities should be an important factor in your buying decision.

When it comes to access control for wired networks, things get more complicated. If you already have a PKI infrastructure in place, you should definitely explore whether you can implement 802.1x-based access control. However, if the required infrastructure isn't in place, you'll most likely find that doing a full-blown PKI implementation only to get network access control isn't worth the cost. Instead, you should closely observe how the solutions by Microsoft, Cisco and others are developing and be ready to implement them when they're ready for prime time.