Get the most out of Windows 2003 SP1's new server-hardening tool
The Security Configuration Wizard (SCW) is Microsoft's latest addition to its security configuration tool portfolio. SCW is included in Windows Server 2003 Service Pack 1 (SP1), which is currently planned for release in the first half of 2005. SCW guides administrators through configuring, editing, applying, and rolling back security policies on Windows 2003 SP1 servers. It specializes in easing the process of hardening servers that perform particular server roles, such as Microsoft IIS and Microsoft Exchange Server. Let's look at where SCW fits in among Microsoft's other security configuration tools and why you might want to use it.
SCW is role-based. It can generate XML-formatted security policy files that are tailored to a server's role (e.g., file server, Exchange Server front-end server, print server). SCW can deal with role dependencies. For example, if you select the Active Directory (AD) server role, SCW automatically adds the File Replication Service (FRS) server role because AD domain controllers (DCs) use FRS to replicate the Sysvol folder between them. SCW uses an extensible knowledge base that holds a list of preferred security settings for different Windows server roles. The SCW security policy files can configure a server's service, registry, audit policy, and Microsoft IIS configuration settings. You can enforce SCW policies by using SCW itself or by transforming SCW policies into Group Policy Objects (GPOs).
Three important reasons for Windows administrators to use SCW are:
- SCW reduces the time needed to create a baseline security policy for a particular server type. Instead of reading several hardening guidance documents, an administrator can leverage SCW's built-in knowledge base.
- Administrators can use SCW to create a security policy for a particular server role on one server, then automatically apply it to all the servers in their organization that have the same role.
- SCW is an important tool for reducing the attack surface of a Windows server system. As opposed to other Microsoft security policy configuration tools (Security Configuration Editor—SCE—and GPOs), it can lock down a Windows system's network ports, thwarting potential security breaches.
SCW is an optional Windows component included in Windows 2003 SP1. To install it, use the Add/Remove Windows Components option in the Add or Remove Programs Control Panel applet. After installation, the SCW icon will show up in the Administrative Tools folder. To start the graphical SCW from the command line, type
To run SCW on standalone machines, you need local administrator permissions; on domain-joined machines, you need local administrator or domain administrator permissions. A machine can be configured by using SCW only if it's running Windows 2003 SP1 and has SCW installed. You can run SCW against a machine locally or remotely. Before starting SCW, make sure that all applications that use inbound network ports are running.
When you run the graphical version of SCW, it guides you through a set of dialog boxes, each of which lets you perform a different security configuration step:
- Select whether you want to create a new policy, edit an existing policy, apply a policy, or roll back the last applied policy.
- Select the server you want to use as the baseline server for policy creation, the server on which you want to edit a policy, or the server on which you want to apply or roll back a policy.
- View the Security Configuration Database content, as Web Figure 1 (http://www.windowsitpro.com, InstantDoc ID 44992) shows. This is your chance to study or review which roles and services your server should provide before moving on to the actual generation of an SCW policy file or configuration of a server.
- Configure role-based services. Before you run through this SCW section, you must have a complete view of the roles and services a particular server should provide. This section comprises multiple steps, all of which let you enable or disable server services and block or unblock network ports by selecting or clearing the check boxes of server roles and configuration options:
- Configure network security. In this section of steps, you can define Windows Firewall and IP Security (IPSec) settings (i.e., you can define open or blocked inbound ports and the applications that are approved to use particular ports). SCW doesn't display all ports but rather filters ports based on the service and role options that you selected in the previous section. If you don't see a particular port, you can add it manually by clicking Add on the Open Ports and Approve Applications page. To configure IPSec settings for a particular port, click Advanced on the Open Ports and Approve Applications page. On machines with multiple NICs, you can disable or enable individual ports for certain interfaces by using the Local Interface Restrictions tab in the advanced port properties dialog box. Figure 2 shows the dialog box for restricting remote access to a local system port by using IPSec for a certain IP address, computer name, IP subnet, or range of IP addresses.
- Configure registry settings. In this section, you can configure a set of Windows communication protocol security options, including Server Message Block (SMB) and Lightweight Directory Access Protocol (LDAP) signing and the LM compatibility level setting. The latter is used to determine which versions of the NT LAN Manager (NTLM) authentication protocol are made available to server users. Web Table 1 summarizes the registry settings configurable through SCW.
- Configure audit policy. This section lets you set a Windows server's auditing options. The options are: don't audit, audit only successful events, and audit both successful and unsuccessful events. The auditing option you choose applies to the different Windows auditing categories (e.g., audit system events, audit logon events).
- Configure Microsoft IIS. This section is available only for servers on which you selected the Web server role. You can use this section to configure several IIS-related settings, including the supported Web service extensions (e.g., Active Server Pages—ASP), the retained virtual directories, and the blocking or unblocking of anonymous access to Web content.
- Save the security policy, view it, and include security templates. This section allows you to save and view the complete policy when you're done creating or editing it, as well as import existing security templates (.inf files) into the policy, as Figure 3 shows. This feature is needed because you can't use SCW to configure all the security settings that you can configure by using the security templates that SCE and GPOs use. The settings that SCW applies because of an imported security template can't be undone by using the SCW rollback option. Note in Figure 3 that you can import multiple templates into a single SCW policy and set an application priority order for them.
- Apply the policy now or later. The wizard lets you immediately apply the policy or save it for later application.
Select server roles, which include DC, DHCP server, DFS server, file server, and Exchange Server 2003 back-end server. To see the roles and services required for a particular role, click the triangle that points to the role, as Figure 1 shows.
Select client features. Client features are services that use services provided by other servers (e.g., the DHCP client service). To see the services required for a particular client feature, click the triangle that points to the role.
Select administration and other options. This step lists all options that you can install on a server (e.g., Alerter, Time Synchronization, UPS service). To see the services required for a particular administration option, click the triangle that points to the role.
Select additional services. These are services that aren't defined in the SCW database but that SCW found on the machine.
Handle unspecified services. This step lets you disable services that weren't specified in the previous SCW pages.
If you're creating a new policy, SCW by default displays the roles, client features, and administration options that are currently installed on the server on which you're running the wizard. If you're editing an existing policy, the wizard displays the roles, client features, and administration features enabled in the policy. To display, for example, all the roles defined in the SCW database, select the All Roles option in the View drop-down menu that Figure 1 shows. SCW can't configure security policy settings for the Internet Connection Sharing (ICS), Internet Security and Acceleration (ISA) Server, RRAS, or Small Business Server (SBS) roles because these roles aren't defined in the SCW database.
Running SCW from the Command Line
SCW comes with a command-line utility called scwcmd.exe. Table 1 lists the Scwcmd switches and their descriptions. Let's look at some Scwcmd command examples. To perform an Scwcmd analysis on the local machine by using the SCW security policy file fileserver.xml, you'd use the command
scwcmd analyze /p:%windir%\
(of course, when using this command and the ones below, you'd type them all on one line). To transform the output of an Scwcmd analysis that's stored in w2k3-dc1.xml into an XML document that's formatted according to the scwanalysis.xsl stylesheet, you'd use the command
scwcmd view /x:"c:\documents
Web Figure 2 shows some formatted analysis results.
To transform the SCW security policy file fileserver.xml into a GPO called FileServerPolicy, you'd use the command
scwcmd transform /p:%windir%\
The transformation creates a GPO folder for the newly created GPO object in the Sysvol folder. The GPO folder contains the following data:
- an .inf file for the security settings GPO extension
- a .pol file for the Windows Firewall GPO extension
- an IPSec blob for the IPSec GPO extension
SCW IIS settings don't survive an SCW-to-GPO transformation.
After you successfully create a GPO, you can link it to an AD organizational unit (OU) to apply the SCW settings to the machines stored in the OU. The transform operation must be initiated by a domain administrator on a machine to which the SCW security policy will be deployed. The target machine(s) shouldn't have SCW installed, but they do need Windows 2003 SP1 because Windows Firewall and Windows Firewall GPO configuration are supported only by Windows 2003 SP1 and later. To make sure the newly created GPO is applied only to Windows 2003 SP1 machines, you should ensure that the OU you're linking the GPO to contains only SP1 machines or create a GPO Windows Management Instrumentation (WMI) filter that excludes pre-SP1 machines from the GPO application.
Transforming your SCW security policy to a GPO is a must if your organization uses GPOs extensively. If you don't transform the SCW settings into a GPO, they might be overridden by the settings defined in other GPOs at the AD level.
One more, very interesting Scwcmd command example applies different SCW security policy files to different machines. When you execute the command
a local application of the SCW security policy is initiated on each of the remote machines as specified in the legaldepartment.xml configuration file, which Listing 1 shows.
SCW File System Folders and Documents
SCW-related data and files are stored in the %windir%/security/msscw file system folder. Important folders in the Msscw folder are:
- the Kbs folder, which holds the knowledge-base files for SCW-supported server roles. If you want to add new server roles, you must store the corresponding knowledge-base files in this folder. The kbreg.xml file, which Web Listing 1 shows, lists the registered SCW knowledge-base files.
- the Logs folder, which contains SCW log files.
- the Policies folder, which contains security policies created by using SCW.
- the Transformfiles folder, which contains XML stylesheets (.xsl files) that you can use to format SCW output files (as the second command example I mentioned and Web Figure 2 show).
Security Tool Overlap
SCW is an important addition to Microsoft's security policy management portfolio. The tool can be used for security policy authoring, application, and auditing. However, its introduction emphasizes the fact that Microsoft's security policy management portfolio—which now includes GPOs, SCE, and SCW—urgently needs some alignment. Each of these tools can manage different aspects of a Windows security policy, but none of them covers all Windows security-related settings.
Both SCW and SCE are security policy authoring tools. SCW is a specialized authoring tool for reducing a system's attack surface, and it has a knowledge base to leverage, which makes life a lot easier for administrators. Generally speaking, SCE has a broader scope than SCW, but it can't deal with system port configuration, and it lacks intelligence that can propose a preferred security configuration based on the machine's organizational role. SCE has good Help files that offer basic guidance, but administrators are still pretty much on their own for defining security policy settings.
Both SCW and SCE can be used for security policy auditing, but again, SCW focuses on reducing the attack surface and provides intelligent configuration help, and SCE has a broader scope and doesn't recommend settings.
In standalone machine environments, you can use SCW for security policy application on individual machines or groups of machines; the easiest way to do so is from the command line using Scwcmd. Using SCW for security policy application in Windows domain environments isn't recommended; here the best option is to transform the SCW security policy settings into GPO settings, then apply the security policies through GPOs. It's interesting that SCW doesn't natively support the .inf security configuration files that SCE and GPOs use. SCW uses XML instead. As I pointed out earlier, SCW XML files can be translated into GPO-compatible files, and .inf-formatted files can be imported into SCW.