Specifically, we’ll discuss each of the following:
- Computer startup security
- Stronger Diffie-Hellman group support
- NAT traversal
- Netsh IPSec context
If you missed the first part in this series, click here to read Part 1.
Computer Startup Security
With earlier versions of Windows, there was a “security” gap during computer startup, before the IPSec policy was applied. Now, with Windows Server 2003, stateful filtering is used to prevent unsecured traffic from crossing the network. With this enabled, the computer only permits outbound traffic that it initiates during startup, inbound traffic that is a direct response to that outbound traffic, and DHCP traffic (which is necessary for the computer to obtain an IP lease and TCP/IP configuration information if it is a DHCP client). This increases security because other unsolicited inbound traffic is not allowed.
However, this doesn’t limit you if there is specific inbound traffic that you do want to allow during startup. You can specify exempt traffic types. For even greater security, you can block all inbound and outbound traffic during startup. Configuration is done via the netsh command in ipsec context, which we will discuss a little later in the article.
Diffie-Hellman Enhanced Security
IKE negotiates the Diffie-Hellman “group” to be used for cryptographic operations during main mode (or phase 1) of the IPSec negotiation process. The group determines the strength of the master key used in the key exchange process. Windows 2000 supports only Diffie Hellman groups 1 and 2. Windows Server 2003 supports a third group, called group 2048.
The key strength of each group is as follows:
- Diffie-Hellman group 1: 768 bit key
- Diffie-Hellman group 2: 1024 bit key
- Diffie-Hellman group 2048: 2048 bit key
Obviously, group 2048 provides the best security. Now, when IPSec communications take place between two members of the Windows Server 2003 family, they can be secured with a 2048 bit key. Note, however, that Windows 2000 and XP do not support group 2048. If you configure the Windows Server 2003 computer to use group 2048, the IKE negotiation will fail and the two computers won’t be able to communicate using IPSec (they might or might not be able to communicate at all, depending on whether the IPSec policy settings require or only request secured communications).
The Diffie-Hellman group is set via the IP Sec Policy Management console. You double click the policy for which you want to set the group, click Settings on the General tab, click Methods on the Key Exchange Settings dialog box, then select a security method and click Edit. In the Diffie-Hellman group field, select Low (1), Medium (2) or High (2048) from the drop down box, as shown in Figure A, and click OK to close each dialog box.
Figure A
NAT Traversal
Probably one of the most welcome improvements in Windows Server 2003 IPSec is its support of NAT traversal, a technology that allows ESP packets to work with Network Address Translation (NAT) devices that allow UDP traffic. With Windows 2000, IPSec and NAT were incompatible. This was quite a problem at times, since NAT is an increasingly popular method of providing Internet access to local area networks.
Now, IKE can detect that a NAT is present and encapsulate ESP packets in UDP so the IPSec traffic can go through the NAT. This also means clients behind NATs can now use L2TP/IPSec for VPN connections.
There’s nothing that you have to configure for your Windows Server 2003 system to support NAT traversal; this functionality is built in and solves many problems related to IPSec-NAT incompatibility that administrators encountered in the past.
The Netsh Command’s Ipsec Context
The netsh utility was provided for use with Windows 2000, and allowed administrators to configure such OS services as routing, remote access services, WINS and DHCP at the command line. The tool works by calling “helper files” (dll files) that are used for placing netsh in a specific “context” according to the service to be configured or managed (for example, the DHCP context).
New to Windows Server 2003 is the IPSec context for netsh, which allows you to configure and administer IPSec from the command line. This not only makes it possible for you to use scripting to configure IPSec, it also provides some functions that you can’t do with the IPSec Policy Management console (the GUI interface for configuring and administering IPSec). These tasks include:
- Configuring IPSec diagnostics
- Specifying default traffic exemptions
- Configuring IKE (Oakley) logging
- Setting logging intervals
- Configuring startup security and startup traffic exemptions
- Configuring strong CRL checking
To use the tool for managing IPSec, you must first put it in ipsec context. To do so, open a command prompt window (Start | Run and type cmd), and enter: netsh ipsec.
Within the ipsec context are two subcontexts: dynamic and static. IPSec static commands are used to perform the same functions you can do with the IPSec Policy Management and the IPSec Monitoring MMCs. Static commands don’t immediately affect the configuration of whatever IPSec policy is currently active. Static commands allow you to do such things as view, add, set or delete filters, filter lists and filter actions and policies and rules, or export and import policies. For a list of available static commands, type netsh ipsec static at the command prompt, as shown in Figure B.
Figure B
If you want to make immediate changes to the active policy, you can use the dynamic commands. The changes you make are lost, however, when the IPSec service is stopped. With dynamic commands, you can add, delete, set or view main mode and quick mode policies, rules and filters and show statistics.
NOTE: Netsh ipsec is only supported on Windows Server 2003. You can, however, configure IPSec on XP computers by using a different utility, Ipseccmd.exe. It’s not installed by default; you’ll find it on the XP installation CD in the \Support\Tools directory.
Summary
These are only some of the new features for IPSec that Microsoft has included in Windows Server 2003. Others include:
- The ability to set persistent policies so you can still have secure communications even if the local or domain IPSec policy isn’t applied. A persistent policy is applied first (before local and AD policies).
- By default, only IKE traffic (necessary to establish an IPSec connection) is exempt from filtering. In Windows 2000 and XP, broadcast, multicast, Kerberos and RSVP traffic was also exempt. This makes for better security.
- You can use certificate-to-account mapping to limit computers belonging to specific domains, or that have certificates from a particular CA, or that belong to a specific group from accessing the Windows Server 2003 computer. You can also specify individual computers that are to be blocked.
- You can exclude the name of the issuing CA from certificate requests to prevent others from knowing the name of the computer that is serving as CA.
- IPSec is now more fully integrated with Network Load Balancing (NLB).
- There is now an IPSec extension to the Resultant Set of Policies (RSoP), so you can use RSoP to view IPSec policies and for planning purposes.
It all adds up to increased security and usability – two of the goals Microsoft had in mind when developing Windows Server 2003.
