I’ve been meaning to write about the new functionality in Windows Server 2003 service pack 1 (SP1) for a while now, but various distractions led to this post sitting on ice for several months. I thought about dropping it altogether, but then I changed my mind because even though Windows Server 2003 release 2 (R2) is now generally available, SP1 information is still pertinent for two reasons:

• R2 is installed on top of an SP1 baseline.
• Many organisations will wait before implementing R2 – so SP1 is still highly relevant to a large chunk of the market (especially those still using Windows 2000, many of whom were waiting for the first Windows Server 2003 service pack before upgrading).

At last year’s Microsoft Technical Roadshow, John Howard presented a Windows Server 2003 SP1 technical overview session, at which he explained that, like Windows XP SP2, Windows Server 2003 SP1 is basically a security update. In producing SP1, Microsoft’s goal and vision was to respond to customer challenges around security, reliability and performance, making it simple both to cope with current threats and to secure a system ready for future threats. Robustness is addressed through some changes to increase performance (e.g. http.sys now runs in kernel mode for IIS servers) and reliability is about allowing systems operation with the minimum of downtime. Most importantly, tools like the security configuration wizard can be used to decrease the attack surface, exposing fewer ports and services so that organisations that have disabled a potentially vulnerable service can patch at their leisure, rather than having to schedule emergency downtime to cope with a major threat.

SP1 addresses security concerns with a number of new features, which I’ll describe in the rest of this post.

Data execution prevention (DEP) is implemented both in hardware – where no execute (NX) support is provided – and in software (functional on any process supporting Windows Server 2003). Controlled using a boot.ini /noexecute=policylevel switch, four policy levels can be selected:

• OptIn – hardware DEP on, applications can select whether or not to use it.
• OptOut – DEP is on, unless an application opts out.
• AlwaysOn – DEP is on (for all applications).
• AlwaysOff – DEP is off (for all applications).

As for many boot.ini file settings, this DEP can also be controlled through the GUI (system properties).

Post setup security updates (PSSU) is a feature designed to protect servers between the first boot and application of the most recent security updates, opening on the first administrative logon (if Windows Firewall was not explicitly enabled using an unattended installation or group policy) and blocking all inbound connections until the PSSU dialog box is completed (at which time all updates will have been applied).

PSSU offers links to install critical security updates (from Windows Update), as well as the opportunity to configure automatic updates and will re-open on the next login if not fully completed before the computer is restarted (or if forced to close using Alt and F4, which will leave the Firewall enabled). PSSU is invoked during a slipstreamed installation, but is not applied when existing servers are upgraded or when the Windows Firewall is enabled or disabled through group policy.

Unlike Windows XP SP2, the Windows Firewall is not enabled by default on Windows Server 2003 SP1 (unless PSSU is in effect). Microsoft say that this is because the primary purpose of a server is to accept inbound connections, although I would counter this by saying that the software should be secure by default and an administrator should have to take action to open ports and allow services. The boot-time security provided by the firewall is non-configurable, offering basic networking only (domain controller lookup, DHCP client, etc.) until the server is fully online. Like the XP SP2 firewall, multiple network profiles are supported (e.g. more aggressive control when away from the corporate network) and is the Windows Server 2003 SP1 firewall is integrated with the netsh command line utility.

Role-based configuration and lockdown is facilitated with the security configuration wizard (SCW). Although best practice, many administrators view reducing the attack surface on a server as difficult, time consuming, risky (services might be broken) and involving a whole load of documentation to review. Using the SCW, the process is simplified, using a role-based metaphor to disable unnecessary services and IIS web extensions, block unused ports, secure open ports using IPSec, reduce protocol exposure and configure audit settings.

SCW can be installed from the Add or Remove Programs Control Panel applet (appwiz.cpl), or by setting scw=on in unattend.txt. Command line support is included (scwcmd), as are rollback (scwcmd rollback), view (scwcmd view) and analysis (scwcmd analyze) capabilities. Although the security policy is not set through group policy, it can be applied to multiple servers as the configuration can be saved to an XML file for re-use (or converted to a group policy using scwcmd transform /p:filename.xml /g:policyname).

Incidentally, best practice would be to avoid saving the configuration file by server name as this would be useful information for a would-be hacker (and can be overwritten by later updates). The SCW viewer is also a good reference for port numbers, etc. used by various Windows services.

Other new security features include IIS 6 metabase auditing, VPN quarantine functionality and Internet Explorer security enhancements (as per Windows XP SP2 – described in the application compatibility testing and mitigation guide). RPC and DCOM are also enhanced (as for XP SP2) to reduce the attack surface with no more anonymous inbound RPC, restrictions on outbound RPC (both of these may be overridden with a registry key) and only administrators can invoke DCOM components remotely.

Another new Windows feature (which I believe NetWare administrators have had for years) is access based (directory) enumeration (ADE). ADE hides directories on a share based on a user’s access rights. The service pack version of ABE needs to be programmatically enabled (John Howard’s blog carries a link to an unsupported Microsoft utility which will enable this) but since SP1 was released, ADE has been made available for download from the Microsoft website with GUI and command line support (abecmd). It is fully described in the accompanying white paper and for those who would like to see a demonstration, John Howard has recorded an ADE blogcast.

I’m sure there are some other enhancements within SP1 that I’ve missed, but these are the major security improvements. Windows Server 2003 was already pretty good and with SP1 it got better. Add Windows Server 2003 R2 to the mix and there are also some great new features.