Viruses and malware are often stopped by software defenses that run on the desktop; in fact, the antivirus, antispyware, and other security suite software business has rapidly become a very lucrative industry. As useful as those protections are, however, the best solution would be such threats never getting a chance to access the network—like the old saying goes, "The quickest way out of something is to never have been in it."
In Windows Server 2008, there is a technology that allows computers to be examined against a baseline set by an administrator, and if a machine doesn't stack up in any way against that baseline, the system can be prevented from accessing the network—quarantined, as it were, from the healthy systems until the user fixes his broken machine. This functionality is called Network Access Protection (NAP).
You might know of NAP's predecessor, Network Access Quarantine Control, or NAQC. It debuted in Windows Server 2003 as a more limited form of quarantine protection. NAQC is limited to protecting your corporate network against remote users: it prevents unhindered access to a network for a remote user until after his computer has been verified as meeting certain baselines set by a network administrator.
Under NAQC, when a client establishes a connection to a remote network's endpoint, the client will receive an IP address, but Internet Authentication Service establishes a quarantine mode that is lifted only after health verification is complete. While NAQC is useful, it requires programming a baseline script to set up; its management facilities are next to none; and most critically, it offers no safeguards against infected machines inside the corporate campus.
NAP addresses these weaknesses and builds on the solid premise of NAQC—that stopping spyware and viruses dead, before they can ever reach the network, is the best line of defense. NAP in Windows Server 2008 can be considered in three different parts:
- Health policy validation
Validation is the process where the machine attempting to connect to the network is examined and checked against certain health criteria that an administrator sets. This criteria can include patch state, service-pack level, presence of AV software and so on.
- Health policy compliance
Compliance policies can be set so that managed computers that fail the validation process can be automatically updated or fixed via Systems Management Server or some other management software. This is an optional, but very useful, part of NAP. You can also set up mechanisms to ensure that compliance is ongoing and that machines are healthy for the entire time they're on the network.
- Limited access
Access limiting can be the enforcement mechanism for NAP. It's possible to run NAP in monitoring-only mode, which logs the compliance and validation state of computers connecting to the network. But in active mode, computers that fail validations are put into a limited-access area of the network, which typically blocks almost all network access and restricts traffic to a set of specially hardened servers that contain the tools most commonly needed to get machines up to snuff.
Here's the basic process for a NAP session and the various bits and pieces that are involved:
A client asks for access to the network and presents its current state of health to the Dynamic Host Configuration Protocol (DHCP) server, virtual private network (VPN) server, or a compatible switch or router.
The DHCP/VPN server or router/switch sends the health status, as presented by the client, to the Microsoft Network Policy Server, which is a machine based on the RADIUS protocol that replaces the Internet Authentication Service you might know from Windows Server 2003.
The Network Policy Server checks the health status against the criteria that the administrator sets and, based on the results of the check, does one of the following: if the machine does not comply with the IT policy, the client is put into a restricted virtual LAN; is disallowed, via IPsec rules or via 802.1x wire-level protection, from talking with healthy machines; or is given a very limited set of routes via DHCP. Regardless of the method of restriction, the unhealthy client can access a few (presumably specially hardened) servers that have the resources needed for a client to fix itself. Steps 1 through 3 are then repeated. If the machine complies with policy, the client is granted full access to the network.
On the client side, system health agents (SHA) and system health validators (SHV) are small pieces of code that ensure that the checks and validations are made on each individual client machine as necessary, as mentioned in step 1. Windows Vista includes default SHAs and SHVs that can be customized. Additionally, the NAP agent client piece takes the health status information provided by the SHAs and hands them to enforcement clients, or ECs, that actually do the enforcement on clients (limiting the scope of a DHCP route, verifying packet filters, and so on) depending on which enforcement mechanism you choose.
Take a look at Figure 11-13, which shows how all of the pieces of NAP fit together regardless of the type of enforcement you choose.
There are several ways that NAP enforces its access limiting capabilities with clients. Let's take a look at the five currently supported within Windows Server 2008.
Through DHCP-based enforcement, clients attempt to lease an IP address from a DHCP server with Windows Server 2008 and the Network Policy Server roles installed. That server checks the health of the client, and, if the client meets those requirements, issues a valid IP lease. If the client is judged to be unhealthy, the DHCP server issues a very limited lease that contains just an IP address, a subnet mask, and a set of host routes limited in scope to a few remediation servers on the restricted network. There is no default gateway. Once the client has been remediated, it pings the DHCP/NAP server to perform another round of checks and only at that point is a full DHCP lease issued.
With VPN enforcement, the behavior of NAP is more like its predecessor, NAQC. When the VPN client starts a connection with the VPN concentrator or server on your perimeter network, the VPN server (also running Network Policy Server) or another machine with those required roles checks the health of the potential client. If the client is healthy, it gets unfettered access to the network, but if it is not healthy, a set of packet filters is placed on the connection to limit access to only those servers that host the items needed to remediate the situation. The VPN server can later remove the packet filters once the client is deemed healthy by the appropriate host.
Via 802.1x enforcement, you get the advantages of NAP for hard-wired clients in a more tamper-proof way than with DHCP-based enforcement. 802.1x is the IEEE standard that defines behavior at a port-level, meaning the actual place that a network cable is plugged in. By authenticating devices at the port level, you achieve nearly instantaneous NAP enforcements and also enable any sort of device to be protected and enforced, depending on how you look at it, when on the network, and not just Windows clients or remote machines entering through a VPN. The drawback is that hardware compatible with enforcing NAP at the port level is expensive; the switch must be able to communicate with the Network Policy Server machine via an encrypted EAP session in order to learn whether or not transmissions capabilities on a certain port should be enabled when a device is detected.
IPsec enforcement is an interesting, and perhaps most realistic, mechanism of all of the ones we've discussed so far. For it to be effective, you must deploy IPsec policies to either all of your sensitive machines or all of the hosts on your network that limit them to accepting incoming communications only from machines that have a health certificate. Once the policies are in place, you can configure NAP simply to issue valid health certificates to healthy clients; those clients can then communicate with any host. But unhealthy clients aren't issued health certificates, and even though they (a) have a valid IP address, (b) have no scope-limited routes in place, and (c) there is no hardware mechanism for disabling their communications, because of the IPsec policies that are in place, machines will simply drop communications from that unhealthy client—fingers in the ears, if you will. To use this enforcement mechanism, you'll need the Health Registration Authority, which obtains health certificates for those healthy clients from a certification authority.
Finally, the TS Gateway mechanism allows you to place NAP enforcement for your remote Terminal Services clients, although you cannot currently autoremediate these types of clients.
Since NAP is so far-reaching and has the power to turn your network-connected machines into standalone, deaf PCs (which might limit productivity in more than a few scenarios), it's best to deploy NAP in phases, so that (a) your users know what's happening and aren't interrupted by its enforcement, and (b) you have a sense of the effects NAP will have on the machines on your network. Here's a sample progression that I recommend when introducing NAP into your network.
- Phase 1: Reporting only
In this phase, everything NAP does—checking clients, the results of health tests, what enforcement would have been put into place—is logged centrally, but no remediation or quarantining is actually performed. In this phase, the goal is to get a sense of what portion of your clients is unhealthy, how many users your eventual enforcement policy would affect, and what types of unhealthy states your clients are in. No one is cut off from network access in this phase, but you get a decent diagnostic of the health of the machines on your network.
- Phase 2: Reporting and remediation
After at least a month, and preferably more, in Phase 1, you can now enable remediation in addition to the reporting. This will probably fix a not-insignificant portion of the clients that were reporting as unhealthy in Phase 1, limiting the pool of machines that will be cut off to a smaller number, though they are still not completely quarantined from the network.
- Phase 3: Delayed enforcement
Once you have configured autoremediation and have monitored the reporting logs for a while, you can set up NAP to allow unhealthy clients to access the network for a limited amount of time. This helps clients who need patches to have access to the corporate network for enough time to download those patches before they are cut off. You can set up the delayed enforcement length to anything you choose; I suggest a window no smaller than a day and no longer than a week, since you want to reinforce the importance of healthy clients to your users without berating them endlessly about patching on what may be a busy workday for them. (Some organizations may choose to leave NAP in this mode permanently. I don't recommend this approach, as malware often needs very little time to infect your network, and if you are infested with a virus or worm while NAP is in deferred enforcement mode, what is the point of having NAP deployed in the first place?)
- Phase 4: Immediate enforcement
Finally, after everyone has patched up and all of your regular clients have had a chance to remediate themselves and get healthy, simply remove the grace period that Phase 3 allows and make NAP cut off unhealthy clients immediately if they cannot be autoremediated. Remember that NAP can automatically fix simple problems with a machine's state—if its firewall is off, for example—so in this sense you are only cutting off machines with more complex health state issues.
Any NAP deployment is centralized on the Network Policy Server, so let's start there and configure NAP with the 802.1X enforcement mechanism. Make sure that the Network Policy and Access Services role is installed on your machine before proceeding.
From Administrative Tools off the Start menu, choose Network Policy Server.
Let's get acquainted with this environment. In the left pane of the Network Policy server application, you'll see the Policies node and the Network Access Protection node, as shown in Figure 11-14. Under the Policies node, you can configure health policies that will be used as the baseline that clients must meet. You can configure the SHVs and any remediation servers under the Network Access Protection node. Additionally, we will need a RADIUS setup since we are demonstrating 802.1X authentication; the hardware switches we are using will be RADIUS clients.
Expand RADIUS Clients and Servers in the left pane, and right-click on RADIUS Clients; select New RADIUS Client from the pop-up context menu.
The New RADIUS Client screen appears, as shown in Figure 11-15. Here, we'll configure the switch that we are using, giving it a friendly name of "switch" and its IP address. Also, click the Generate radio button to have a shared secret automatically generated. You will need to copy and paste this secret into the switch's configuration as well. Click OK when finished.
Expand Policies in the right pane, and right-click on Health Policies; choose New from the pop-up context menu.
The Create New Health Policy screen appears, as shown in Figure 11-16. Here, you define what a healthy baseline is. You would create one policy for compliant computers, using the "Client passes all SHV checks" option and the Windows Security Health Validator SHV, and then another policy for noncompliant computers using any of the other options in the Client SHV Checks list.
Expand Policies in the left pane, and right-click on Network Policies; select New from the pop-up context menu.
The New Network Policy screen appears, as shown in Figure 11-17. Here, you name a network policy, use an "unspecified" type of network access server, and click Next.
The Specify Conditions page appears. Click the Add button to display the "Select condition" dialog, as shown in Figure 11-18. The health policies you defined in step 6 are used as conditions here, meaning that if one of the conditions (the health policies) matches the criteria, that network policy will be enforced. So, you would add one network policy for compliant, or healthy, machines, and another for noncompliant, or unhealthy, machines. Click Next.
The Specify Access Permission page appears. Here, you choose whether to grant or deny access if the conditions you configured in the previous step are matched. Click Next.
The Configure Authentication Methods screen appears, as shown in Figure 11-19. For 802.1x NAP enforcement, you need to add the Microsoft: Protected EAP (PEAP) option to the EAP Types list, so click the Add button and select it from the list. You can also choose to enable or disable some of the less secure authentication methods. Click Next.
The Configure Constraints page appears, as shown on Figure 11-20. Here, you can configure additional items relating to the network policy; if these items aren't satisfied, the NPS rejects access to the potential client. You can set up maximum idle time, maximum session time, a specific MAC address (called a Called Station ID in RADIUS terms), day and time restrictions, and the type of device being used. Click Next.
The Configure Settings screen appears. Here, you set up the specifics of the policy. We're particularly interested in the NAP Enforcement page, so click that in the left part of the screen and look in the resulting right part, shown in Figure 11-21. Here, you can choose what "phase" of NAP implementation should be used in conjunction with this policy—either full access, deferred enforcement, or limited access. Remember that this setting only falls under the scope of the policy you're creating, so you would choose "allow full network access" for your compliant policy and one of the other two options for your noncompliant policy. Also, for your noncompliant policy, you can tick the box under the "Auto remediation" section to set up automatic fixups where possible. Click Next, and then Finish on the next page of the wizard.
Now that your network and health policies are configured, set up the checks that the Windows System Health Validator will make by expanding the Network Access Protection node, clicking on System Health Validators, and double-clicking on Windows Security Health Validator in the right pane.
The Windows Security Health Validator Properties screen appears. Under the Error Code Resolution section, you can choose how the SHV will respond if certain conditions are met, including timeouts, connection difficulties, and error codes. At the top, the Configure button will take you to where you can set up the specific checks that are made for clients. Click Configure.
The Windows Security Health Validator screen appears, as shown in Figure 11-22. There are two tabs, one for Windows Vista, and one for Windows XP (Figure 11-23). Here is where you choose what you desire for firewall configuration, virus protection, spyware protection (for Windows Vista only), automatic updating, security update protection, and so on. Configure as desired, and click OK and then OK again to close out.
At this point, you have configured everything on the server end. Remember, you need two network policies—one for compliant machines, one for noncompliant machines—and two health policies—again, one for compliant and the other for noncompliant computers. Once you have those four policies, and have configured the Windows Security Health Validator with the appropriate security criteria, you just need to deploy a couple of settings to your clients. The simplest way to do this is via Group Policy—you'll find the required settings under Computer Configuration, Windows Settings, Security Settings, and Network Access Protection. Your options, shown in Figure 11-23, are:
DHCP Quarantine Enforcement Client
Remote Access Quarantine Enforcement Client
IPsec Relying Party
TS Gateway Quarantine Enforcement Client
EAP Quarantine Enforcement Client
Just choose the appropriate client, each of which corresponds to one of the enforcement mechanisms covered earlier in this chapter, and set it to enabled, and you are ready to deploy.
NAP is a truly great addition to Windows Server 2008. The advantages are numerous. You get very effective protection against malware before it can infiltrate your network, it is included in the licensing cost of the server product, and it presents another way for your users to take security seriously. If their systems aren't up to snuff, they can't get their work done, so system integrity becomes a unified priority across both IT and the user community alike.
That's not to say NAP is a golden ticket to security nirvana; there are indeed some disadvantages. One is that there are deployment scenarios that jeopardize the effectiveness of NAP. For example, DHCP-based protection (where few routes are assigned before health verification) is easily bypassed on the client—by users who know what they're doing—by simply entering a static IP address and DNS/router information.
Two, the element of detection of network devices coming online can be difficult to implement securely, particularly solutions that rely on detecting broadcast packets. And finally, the best deployment method—802.1x protection with compatible switch or router hardware—is expensive and requires a lot of time to test and bring online.
Can you rely on NAP? I think you certainly can, so long as it is deployed correctly and as part of a multilayered solution to security. Defense in depth still applies—NAP is not an end-all, be-all answer to your problems, in my opinion. But NAP can and should play a very central role to your approach to security.