Secure Network Access Control
Protect your corporate network by controlling which users and computers can access it at all.
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).
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
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.
The VPN Quarantine feature in Windows Server 2003 and ISA Server 2004 depends on a number of components that all work together to keep insecurely configured client computers off your network:
Script. This script runs on the client computer immediately after the user is authenticated. It contains all configuration checks that you require, such as verification of anti-virus signatures and installed security patches. Creating this script tends to be the most challenging task in the VPN quarantine process since its contents depend on your organization's specific security policies. A script should also inform users why they can't connect and guide them in fixing the issues that prevent them from connecting.
Connection Manager Profile. You create this profile with the Connection Manager Administration Kit (CMAK), an optional component of Windows Server 2003. The profile contains all connection information for the client, except for the user name and password, and additional files, including the script and supporting files. It is also responsible for launching the script once authentication is complete. Once a user installs the profile, it appears in the Network Connections folder, giving users an easy way to establish a VPN.
Remote Access Quarantine Client (RQC.exe). This is a small program that is called by the script if all security checks are successful. RQC.exe then sends a message to the VPN server, indicating a configuration that meets your security requirements.
Remote Access Quarantine Server (RQS.exe). This small service runs on the remote access server and listens for messages from the client component (RQC.exe). If it receives such a message, it notifies the Routing and Remote Access (RRAS) service or the ISA Server Firewall Service that the client meets the security requirements.
Routing and Remote Access Service (RRAS). If you're using VPN quarantine without ISA Server 2004, RRAS controls the routing to limit client access to a small subset of network locations until it receives the notification from the Remote Access Quarantine Server. Once the message is received, the client computer gets full network access. If RRAS does not receive this notification, it disconnects the client after a timeout period that you define.
ISA Server 2004. If you're using ISA Server, the Remote Access Quarantine Server notifies ISA Server when it receives a client message. ISA Server controls access to resources before and after this happens, and can apply much more fine-grained control over which resources a client computer can access before and after it has cleared the quarantine checks. If ISA Server doesn't get notified of a successful configuration check within a timeout period, it instructs RRAS to disconnect the client connection.
Customization. The RQC and RQS components communicate without mutual authentication or encryption. To achieve a higher level of security, these components can be replaced with alternative solutions, but few alternatives are available today.