Security Advisor

Boot-Time Security

Boot-up is a dangerous time for your systems, a time before security policies to protect them may be active. Avoid danger with persistent policies.

• By Roberta Bragg
• 06/01/2004

Though each operating system’s instructions may vary, there’s an explicit start-up routine followed by all Windows computers, and in this routine there’s a vulnerability an attacker can take advantage of.

This vulnerability doesn’t lie within the startup code; I’m not going to be revealing some new buffer overflow or programming error. The nature of this vulnerability goes to the heart of several security principals. It has to do with threat modeling, risk evaluation, defense in depth and securing information systems by role. Before you implement my proposed mitigation, you’re going to need to think about whether or not you need it—something you should be doing for every security option.

The Threat
To protect sensitive communications, you may have opted to create IPSec policies for specific systems on your network. You may be blocking telnet, encrypting remote administration tasks, or limiting SQL Server access to communications from a Web application. IPSec’s ability to prevent unnecessary traffic from entering or leaving a Windows system, or to protect data traveling between two devices on the network is, I hope, a key strategy in your network security architecture.

But there is a problem. IPSec policies can’t be enforced until both the IPSec driver and the IPSec policy agent service starts. Since network access to the computer is possible before the IPSec policy agent service starts, there is a possibility of a successful attack during this time. Fooey, you claim? Remember, today’s attacks aren’t generated by some mad, long-haired, smelly criminal who’s targeted your systems for entertainment and who hacks by entering keyboard-based commands one after another. Many automated attacks strike during the brief time period between the startup of network drivers and the full awareness of services. If someone really wants to own a specific box, or simply destroy your carefully constructed Web or wired communications protection, the capability to launch an attack that takes advantage of this vulnerability already exists.

To put it simply, the problem exists because any protected system isn’t protected when the protection is not in effect. Just as locks on doors don’t prevent entry until they’re engaged, an IPSec policy, like any security measure, can’t protect a system if not in effect. This can happen during boot, and it can also happen if Group Policy is used to implement the policy and, for some reason, Group Policy is unable to distribute the policy. Remember too, that by default, when a computer is started in Safe Mode with networking, the IPSec service doesn’t start, so no policy is in effect.

When a Windows XP, Windows 2000 Server or Windows Server 2003 computer starts, three distinct periods need to be considered and protected.

First, after power on and until the IPSec driver is started, no network access is available. This is because the TCP/IP driver and the IPSec driver are started at the same time. No network communication protection is necessary since no network communication can occur.

Second, during the time between the start of the IPSec driver, but before the IPSec Policy agent service starts, network traffic can be both received and sent. Set the IPSec Driver Startup Mode to protect this period. “More on this later.”

Third, after the IPSec Policy Driver starts, but before it can apply the local- or domain-configured IPSec policy, the system is vulnerable. Before you consider the application of a solution to this dilemma, consider your entire network communications protection policy. Before applying the following solution, know that the netsh ipsec commands are only applicable to Windows 2003. Before giving up on XP and Win2K, however, consider the need for some defense, and consider your alternatives; you may find there’s a solution that fits your requirements.

Mitigation: Defense in Depth
Defense in depth is a simple principal that requires more than one layer to be built in the security model. It also assumes that more than one protective device or activity may be present in each layer. Should one part of the defensive strategy fail, many others still stand between the attacker and his goal. For communications protection, the model might include:

Keeping intruders segmented from the communications areas of the network:

—Using firewalls and/or packet-filtering routers.

— Inspecting communications allowed to transit borders, including anti-virus software, anti-spy-ware, attachment blocking and packet inspection for adherence to application requirements (is it really a URL issuing a legitimate page request, or a doubly-encoded hexadecimal expression that might allow an attacker access to system folders? Is it data entry for a SQL query or a SQL injection attack?)

— Requiring authentication for network access.

Protecting the communication itself:

— Requiring mutual authentication between devices before any data can be accessed or shared.

— Implementing integrity checks to ensure packets haven’t been captured and altered somewhere on their journey.

— Enforcing encryption to provide confidentiality, so captured packets don’t reveal their contents without serious brute force attacks on the encryption.

— Requiring packet signing to ensure those received actually came from the indicated computer.

— Protecting from data replay. Checking for time, packet number and/or other data that allows the system to recognize the information has been seen before and drop it.

Protecting the host:

— Blocking unnecessary communications at the host by blocking ports or refusing passage, preventing the egress (sending) and ingress (receipt) of packets.

— Requiring and providing host-level protection whenever network communications may be possible. If there are gaps, fill them.

Your threat modeling exercises should help identify weaknesses in all these layers, and you should seek mitigation. If you use IPSec, you must also consider the operating system boot process and layer protection for it, as well.

Group Policy Issues Group Policy is an excellent way to distribute an IPSec policy to many computers in a standard and efficient manner. The security problem lies not with the design of Group Policy, but in the nature of things. If a Group Policy has been applied to a member computer, it doesn’t matter if the computer can’t access a domain controller and refresh policy during boot—the IPSec policies are cached in the local Registry and can be used when a DC isn’t available at boot. The problem is that any change to Group Policy can’t be implemented if there’s a problem with the distribution of Group Policy. If that change is a new IPSec policy, then the new policy won’t be in effect until the Group Policy problem is resolved. A similar problem might occur if for some reason the locally-cached Group Policy is corrupted or can’t be applied. The answer to this dilemma—how to ensure that Group Policy problems don’t interfere with IPSec-based protection—is the same as the solution to the boot issue explained in the article. —Roberta Bragg

Use IPSec Driver Startup Mode
There are three IPSec driver modes: startup, operational and diagnostic. Implementation of the first two are straightforward: the driver is loaded in startup mode during boot and changes to operational mode at the direction of the IPSec Policy agent service. The netsh command can be used to invoke IPSec driver diagnostic mode (netsh ipsec commands are defined in the Windows 2003 product documentation).

During startup mode, three possible communication options are available:

Permit. IPSec doesn’t process any IP packets. This is the default driver startup mode when no IPSec policy has been assigned, or if the IPSec policy agent is disabled or set to Manual.

Block. Only DHCP packets or those that match filters configured to be used during Block mode are allowed. All other inbound and outbound packets are dropped.

Stateful. Outbound traffic is permitted. Inbound traffic is dropped (including unicast, broadcast and multicast traffic) unless in response to outbound traffic. If IPSec policy is assigned, and the IPSec Policy Agent Service is set to automatic startup, the startup mode will be Stateful. Stateful mode can protect communications during startup, but only if startup mode filters are appropriately set.

To properly secure network communications during startup mode, set the startup mode to Block or Stateful and create startup mode filters. To set the startup mode:

Modify the startup mode by assigning an IPSec policy and setting the IPSec Policy Agent Service to automatic. This will set the startup mode to Stateful.

Modify the startup mode using the following netsh ipsec command:

Netsh ipsec dynamic set config bootmode value={stateful | block | permit}

Modify the startup mode by adding and setting the DWORD value OperationMode under the key below. Use a value of 0 to set Permit mode, 1 for Block mode and 3 for Stateful mode.

HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\IPSEC

To set startup filters that can be used in block or stateful mode, use:

Netsh ipsec dynamic set config boot exemptions

Persistent Policies
Persistent IPSec policies can be used to add, modify and maintain IPSec policies permanently. Persistent polices, which are stored in the local machine’s Registry and loaded by the IPSec driver, are in effect whether or not Group Policy policies can be used. Persistent policies can be used to protect computers during startup, override local or Active Directory-based IPSec policies, and provide a smooth transition from startup to operational mode. Appropriate uses for persistent policies include providing unique protection for specific computers when a Group Policy-based policy provides blanket protection for a large number of computers, or providing protection for times when the Group Policy-based policy is not, or cannot, be applied. Persistent policies are the only type of additional policy that can be applied to a Windows computer that already has an IPSec policy assigned. Remember, in general only one IPSec policy can be assigned per computer; a persistent policy is the exception to this rule.

When the IPSec Policy Agent service starts, it sets the IPSec driver to operational mode. If startup mode filters are in use, they’re discarded. Operational mode can’t be modified through commands. Three operational modes exist:

Secure. IPSec filters defined in the assigned IPSec policy are enforced. The IPSec Policy agent applies any persistent policies first, then any assigned Active Directory IPSec policy or assigned Local IPSec policy is applied. (If no persistent policy is applied, no protection from IPSec is available until the assigned policy can be applied. This means that even if the threat of an attack during the brief boot process isn’t considered a valid risk, a successful attack is possible if there’s a problem with Group Policy operation.)

Permit. IPSec doesn’t process packets and therefore no IPSec protection is provided. If the IPSec Policy Agent service is manually stopped, the operational mode is Permit.

Block. No inbound or outbound traffic is allowed. All packets are dropped. Any filters, even those applied for startup mode, are not applied. If a persistent policy is configured, but can’t be applied, Block mode is applied.

To use operational modes to protect communications, you can rely on the correct operation of the IPSec Policy Agent service and Group Policy to set the mode to Secure, or you can set a persistent policy. Not only will you gain protection while the system is loading the IPSec policy assigned by Group Policy, but if the persistent policy can’t be applied, no communications will occur. If an attacker, IPSec Group Policy misconfiguration, Group Policy failure or system error voids your carefully designed communication protection, there will be no communication.

To apply a persistent policy, use the netsh ipsec command to create a policy and assign the policy. Next, use the netsh store command to make the policy persistent. If, for example, you wish to ensure telnet is blocked, do the following:

1. Enter IPSec static mode with the command:

netsh ipsec static

2. Create the policy using netsh. The commands are listed in Table 1.

3. Assign the policy using netsh:

Set policy name="telnet" assign=yes

4. Make the policy persistent:

Set store location=persistent

Table 1. Commands to Create a Policy to Block Telnet

Step Code Enter IPSec Static mode Netsh ipsec static Add the policy name and description Add policy name=”telnet” description=”block all telnet”CSP Selection Add the filter Add filter filterlist=”telnet block” scraddr=Any dstaddr=Me description =”block telnet” protocol= TCP mirrored=yes srcmask=24 dstmask=24 srcport=Any dstport=23 Add the filter action Add filteraction name=”block it” inpass=yes action=block Add the rule Add rule name=”telnet” policy=”telnet” “telnet filterlist=block” filteraction=” block it” description= “this rule blocks telnet”

Determining if Threat=Risk
I can tell you the steps you’ll need to take to provide protection during startup. You’re going to have to decide whether or not to use them and on which computers to use them and carry out the implementation plan. My personal preference would be to apply this additional protection to any computer to which you’ve already applied an IPSec policy. I’d also recommend taking a couple of test machines and learning how to do so. The ease with which you can accomplish it may help in making the decision and in preventing an error in application—or omission—from occurring.

One of the best ways I know to determine the applicability of any security recommendation is to think about the risk. When communications are involved, it’s all about thinking differently about what you’re trying to protect and dividing computers into groups of high, medium and low risk of attack. In this case, you might decide that some startup protection is a good idea for two types of computers:

All computers that exist on the edge of your network or in perimeter zones you’ve established. Your firewall, for example, is perimeter defense. What’s protecting it during boot? Computers within the DMZ are also at higher risk. Should an attacker compromise the firewall, or find a way around it, these systems are the next logical targets.

Laptops are highly vulnerable to these types of attacks, as their users plug them into hotel, partner, conference or miscellaneous wireless hotspots.

Finally, are systems often moved out of, then back into, production use? A system not up to date with its patches may be more vulnerable to attack. Regardless of your policy requiring re-purposed or idle machines updating off the network, you may need to find some technical control to enforce that. Wouldn’t it be great if you could block their communications with your network until they were brought up to date?

I’m not advising you to implement the procedures above for every system—at least not without careful analysis of where the system risk lies and not before evaluating your options. But I’m also not suggesting that you ignore the implications of startup issues on your communications security defense. I’m simply asking you to:

Follow proper procedures.

Understand the threat.

Evaluate the risk to your systems.

Evaluate the cost of applying the solution.

Determine which—if any—systems should be protected.

And apply the proper solution. Don’t forget to test the application of IPSec policies by using the IP Security Monitor, or by using the netsh ipsec dynamic show command.

Another, Simpler, Solution
Your network can benefit from a security policy that requires any systems needing protection from network communications during boot to get a persistent policy. Other at-risk systems, though, can be easily protected without using a scripting solution. The best approach for XP computers, especially those that connect directly to the Internet or other untrusted networks (hotels, partners, hotspots) is to enable the built-in Windows firewall. When the firewall’s enabled, it applies startup protection. There’s no difference between this protection and a persistent policy.