The Security Configuration Wizard
With Windows 2003 SP1, you get a single, authoritative source of lockdown settings you can deploy with a single stroke that are fully supported by Microsoft.
You've just built a new server and now it's time to lock it down. You've armed yourself with stacks of Microsoft Knowledge Base articles, security white papers and PowerPoint slides from Microsoft webcasts.
You have checklists from SANS and a security INF template downloaded from the NSA. You've collected opinions from
everyone in the IT department,
including the summer intern who once ate in the same deli as Bill Gates.
You're fairly confident that your
lockdowns won't interfere with your installed applications, but five hours later, you're troubleshooting your brains out because several major
features won't work. Apparently, you triggered some undocumented response that removing the lockdowns doesn't resolve. You find yourself
wishing for two things—a different career, and a single, authoritative source of lockdown settings you can deploy with a single stroke that are fully
supported by Microsoft.
You got your second wish, at least. There's a little gem in Windows
Server 2003 SP1 called the Security
Configuration Wizard (SCW). This deceptively simple tool packs a huge XML database consisting of every service, feature and administration option from every server product
produced by Microsoft. It also
provides lockdown settings that are fully supported by Microsoft's major product teams.
With this tool, you can quickly and easily disable unnecessary services, remove unwanted IIS virtual folders, block unused ports, configure audit
settings and lock down access to critical system files. There's just one catch—the server running SCW and the servers you're going to modify must be running Windows 2003 SP1. With that in mind, let's see how SCW works.
Rock and Role
After you apply SP1 to a Windows 2003 machine, launch the SCW (Scw.exe) from the Administrative Tools menu. (There's also a command-line version called Scwcmd.exe.) SCW classifies servers based on roles. It analyzes the services enabled on the server to assign those roles. For example, if SCW sees IIS installed with the standard set of Web extensions, it assigns the Web Server role. If the ASP.NET extension is enabled, SCW also assigns the ASP.NET Session State Server role (see Figure 1).
|Figure 1. The Security Configuration Wizard (SCW) identifies roles based on the
services installed and enabled on a target server. (Click image to view larger version.)
Use the database viewer that comes with SCW to see details about a particular role. Figure 2 shows an example. To open the viewer in the GUI tool, click a button called View Configuration Database. From the command line, use Scwcmd with this syntax:
scwcmd view /x:%windir%\security msscw\kbs\main.xml
|Figure 2. The SCW database viewer shows details about a selected server’s role. (Click image to view larger version.)
SCW disables any services and ports not specifically tied to a defined role, which reduces the server's attack surface.
First you must ensure that all applications are running and correctly configured prior to running SCW. For example, the roles listed in Figure 1 show that Print Server is not enabled. That's because nobody has gotten around to installing a printer on the server.
Based on this role list, SCW would create a configuration file that permanently disables the Spooler service. If you apply that configuration file to another server that actually has printers on it, you'll disable the Spooler and folks will get irritated with you.
The lesson is clear: Install and enable all services and applications that you intend to use prior to analyzing a server with SCW. If you add a new role in the future, you can use SCW to modify the configuration file.
In addition to identifying server
services, SCW also identifies services that support:
- Client features, such as the DNS resolver
- Special administration options, such as Browsing and IPv6
- Third-party products
After selecting the services, features, options and third-party services you want to enable, SCW gives you a list of actions it will take to disable unneeded services (see Figure 3).
|Figure 3. SCW will disable unneeded services to lock down your server. (Click image to view larger version.)
Notice that many services are
disabled. Whacking lots of services
can have unexpected consequences. Fortunately, SCW has a rollback feature that quickly returns the server to its
SCW not only locks down services, it also lets you set a variety of other security options.
For example, you can authorize specific ports on a server, thereby blocking all others. This helps prevent arbitrary attacks. You can restrict ports to reply only to certain addresses and specify the NIC where the port will be active. This lets you lock down the public side of a server in a perimeter network.
SCW displays a list of ports based on identified roles and third-party services and asks you to confirm them (see Figure 4). Keep in mind that you must approve RPC applications (which use dynamically assigned ports) before they can get a port from the EndPoint Mapper.
|Figure 4. SCW requires you to confirm which ports will be left open, and locks down all others. (Click image to view larger version.)
Special Registry Settings
You can even use SCW to manage arcane Registry settings, like SMB
Signing, LDAP Signing, LanMan
Compatibility Mode and LanMan
Password Hash Storage.
These settings can be confusing.
You have to walk through several
windows and make lots of option choices that aren't well-documented. (To acces a flowchart that shows
how SCW arrives at its final
configuration decisions, click here.)
SCW lets you quickly and easily define the server audit settings. By electing to audit all successful and failed access attempts, SCW makes the changes shown in Figure 5. This can result in a spectacular number of entries in the Security log, so be sure to set the log size accordingly.
|Figure 5. SCW lets you define audit policy on a server. (Click image to view larger version.)
With SCW, you can manage IIS
extensions, remove unwanted virtual directories and block anonymous users from having Write access to virtual folders. This is a great way to lock down Web servers in one swoop (see Figure 6). It's also a great way to inspire dozens of angry webmasters to head for your cubicle with the first weapon they can find. Use these options with great caution.
|Figure 6. Blocking Write access for Anonymous connections can help lock down your Web servers. (Click image to view larger version.)
At this point, you've created an SCW configuration file based on the baseline server settings. You can now apply those settings to other servers, targeting them by name or based on a list or a target organizational unit (OU) in Active Directory. You'll need to use Scwcmd to target multiple servers. Here's an example: scwcmd configure /ou:"ou=Domain Controllers,dc=Company,dc=com" /p:LockedDownDC.xml
There are a couple of caveats about pushing out SCW configurations. You can roll back to pre-existing security settings, but it pays to test extensively prior to blasting out settings to dozens of servers. Rollbacks take a few
minutes and people get anxious when their servers aren't working. Also,
use the SCW to build a single
configuration file for each type of server. Don't try to layer different templates together. This makes it
very difficult to do a rollback.
To target the settings to a list of servers, you'll need to configure an XML file with the server names. SCW gives you an example file called
contains the following:
Machine Name="Server1" Policy="Policy1.xml" />
Machine Name="Server1.hq.com" Policy="Policy2.xml" />
Machine Name="126.96.36.199" Policy="Policy3.xml" />
You can also use Scwcmd to compare the security configuration of a server with an SCW policy file and save the differences in a report. This makes SCW highly useful as an auditing tool.
You can extend SCW by building your own XML files with settings for your
in-house applications. This requires manually configuring XML and is not something you're going to do in five minutes after a lunch break. Hopefully, later versions of SCW will include an editor to create custom XML templates.
SCW and Group Policy
You can only apply the SCW security configuration file to Windows 2003 SP1 servers with SCW installed. You may not want to install SCW on every server. You may want to use the baseline from a Windows 2003 SP1 server and apply it to other servers running previous versions of Windows. You
can do this by turning the XML
configuration file created by SCW into a set of Group Policy template files inside a Group Policy Object (GPO),
as shown in Figure 7. You can even
create the GPO on the fly if you have sufficient admin rights. The only
limitation is that IIS-based settings are not included in the transformation because IIS doesn't use Group Policy for managing Web sites.
|Figure 7. A list of modified System Services incorporated into the GPO. It was created by transforming an SCW policy file. (Click image to view larger version.)
The XML policy files created by SCW are stored in %windir% Security\Msscw\Policies. Use Scwcmd to transform an SCW policy file to a GPO using the following syntax:
scwcmd /transform /p:policyfile.xml /g:GPO_Name
One Giant Leap for Security
SCW reduces your reliance on paper-based security guides and .INF security scripts. The changes SCW makes are fully supported by all product teams at Microsoft, a critical element when trying to get product support services (PSS) to help you deal with a problem. You also can have different SCW policies for x64 and x32 platforms, which will come in handy as your organization makes the transition to 64-bit computing.
SCW is most useful when you have racks of identical servers. If each of your servers has a unique role in your organization, you can use SCW to
capture the security settings and save them as a baseline.
So if you haven't gotten a copy of Windows 2003 SP1 yet, download it soon. The SCW is just one of many cool new security features.
- For a list of SCW roles, including their related services, features and ports, click here (7 pages, PDF format).
|Figure A. This flowchart shows how SCW decides the settings for security-related Registry entries. (Click image to view larger version.)