Windows Server 2003 : The Security Configuration Wizard

In essence, the SCW uses a backend XML database that includes detailed configuration information about Windows Server 2003 and all of its associated products, including enterprise applications such as Exchange, ISA, Identity Integration Server, and the like. Using this data, the SCW can help you make intelligent decisions about which services need to be running and which can be turned off.

The SCW supports what is in effect an auditing mode, which begins by examining a machine and reporting the roles assigned to it (those roles being the ones assigned through the Manage Your Server Wizard). This is a great way to check the configurations of your servers. You can go a few steps further with the active configuration mode, which allows you to simply tell the wizard what roles should be assigned to the server. The SCW will then configure the server itself, turning services and ports on and off as needed.

The SCW creates files called security policies, which are simply reports of the results the SCW returns when analyzing a machine. The first machine to create a security policy is known as the baseline machine. These security policies can be exported and then applied to any server that matches the configuration of the baseline machine.

Another neat feature is the ability to import and export configurations, which makes it a lot simpler to deploy the same configuration to multiple servers nearly simultaneously. Additionally, you can add information about your custom, homegrown applications to the XML database, (third-party software companies can do likewise), so that the SCW can integrate with non-Microsoft applications as well.

Let's briefly walk through the SCW and see how to install it, open it, and apply a configuration.

1. Installing the SCW

It's quite simple to add the SCW software to a machine that's already running Windows Server 2003 SP1. To install the SCW, you must be an administrator—either a local administrator or a domain administrator. Follow these steps to complete the installation:

2. Creating a Security Policy with the SCW

In this section, I'll describe the process of using the SCW to secure a machine running Windows Server 2003 and IIS 6.0 with a SMTP virtual server and POP3 services enabled. Of course, the results you get when running the SCW might differ depending on what roles your machine is assigned.

First, open the SCW itself. You'll be greeted with the introductory screen of the wizard. Clicking Next, the Configuration Action screen comes up. Here, choose to create a new security policy and then click Next to proceed through the wizard.

The next screen, the Select Server screen, asks you to select the server to analyze. This server will be used as the baseline for this new security policy, meaning that you can apply the file generated from the results of this analysis to any similarly configured machine. This is a great feature because it allows you to apply different security policies via the wizard to any number of machines from a single workstation. For the purposes of this example, choose the current server and then click Next.

The system will trundle for a bit, and then, when the processing is finished, you will be notified. Note that on that screen you can click the View Configuration Database button to be presented with the SCW Viewer application that reports the different roles, running applications, and open ports on that particular machine. This is handy to print and keep with your system configuration records. An example SCW Viewer report is shown in Figure 1.

To continue, click Next to view the roles assigned to this machine on the Select Server Roles screen. You'll note that some of the boxes are most likely prepopulated with checkboxes—in these cases, the wizard has detected that you are running some service or application associated with that role. Using the View list box at the top of the screen, you can toggle between seeing the roles currently installed on the machine, the roles not installed on the machine, all roles available, or the roles currently selected. It's a very granular, very thorough view of your system. Click Next to proceed.

The Select Client Features screen appears next. Because most every server also acts like a client in some situations, you'll need to allow the appropriate client services to run on the machine. Things like DNS client service, Active Directory domain membership,

Figure 1. A sample SCW Viewer report

and Automatic Updates client software all need to be accounted for within this portion of the wizard. Note that on this screen, you also have the View menu available to customize the display of services and applications. Once you've finished making your selections, click Next.

The next screen, called Select Administration and Other Options, asks you to select and enable other services and open other ports. These are primarily used for remote administration services. Again, you can toggle what you see within the display box, using the View list box. Once your list is correct, click Next.

Next, on the Select Additional Services screen, the wizard lists the services it detected that it doesn't know about by default. You can choose to turn these on or off on this page. Clicking Next, the wizard will then ask you what to do when it finds other services that it doesn't know about. You can choose to either disable those services, or else leave them in their current state and deal with it later. Once you've made your selection, click Next to confirm. On the last screen in the section, the wizard wants you to verify the changes you've outlined in the SCW thus far. Click Next to continue.

The Network Security section allows you to configure ports and applications on a more granular basis than allowed earlier in the wizard. Figure 2 shows the first screen of this section, the Open Ports and Approve Applications screen.

Figure 2. The Open Ports and Approve Applications screen

You can select inbound ports to open by clicking the checkbox beside each applicable port entry. If you do not select a port, it will be closed once the policy is applied to the machine. By clicking the Add button, you can add a port or application to the list that isn't already present. And by clicking the Advanced button, you can restrict certain ports on the list to certain subnets or further secure the port using an IPsec filter. Click Next to continue once you've selected the appropriate ports. Confirm the port configuration on the next screen, and then click Next.

The Registry Settings section allows you to set the behavior of certain communications protocols, directly in the Registry, that are used to pass data between machines. These modifications protect against password cracking and man-in-the-middle attacks. On the first screen, Require SMB Security Signatures (shown in Figure 3), you need to indicate what level of update the oldest client on your computer currently has installed. You also need to tell the wizard what sort of excess processor capacity you have, which has a direct relation to whether the wizard will recommend that you turn on signing and encryption for communications to and from this computer.

Figure 3. The Require SMB Security Signatures screen

The Require LDAP Signing screen is next. Here, simply tell the wizard if your clients all have Windows 2000 Service Pack 3 or later, which will enable LDAP queries to be signed to prevent spoofing a query's source address. The following screen, called Outbound Authentication Methods, allows you to tell the wizard how the computer authenticates itself to remote machines—either via domain or local accounts or simple file-sharing passwords for older, Windows 9x-based clients. You'll then be asked several questions about your selection, each involving the update level of those remote machines. The wizard in this case is simply making sure that the signing and encryption options it integrates into the policy won't break the ability to communicate with any important systems on your network.

At the end of this section, you'll have an opportunity to confirm the changes to the Registry that you want to make. Click Next to continue.

Next, in the Audit Policy section, you have the opportunity to tell the wizard what level of auditing you'd like (you have three choices—none, success auditing only, or complete auditing), and then the wizard will automatically enable and disable certain parts of the auditing system for you. Once you've made your choice of auditing level, you'll be presented with a screen much like Figure 4.

Figure 4. The Audit Policy Summary screen

On this screen, you can see how the wizard applied your auditing level preference to the system's various audit-enabled areas: logins to an account, account management, directory service access, logon events, object access, policy change, privilege use, process tracking, and system events. You can see what the machine's current setting is and compare it to the proposed policy's setting. You also have the option to include a security template, SCWAudit.INF, which would automatically audit access of the file system.

Once you have proceeded through the wizard and answered all the questions, you will be given an opportunity to review the proposed policy in the SCW Viewer applet . Confirm all of your changes, and then select the location to save the policy. You can also elect to apply the policy to the current machine now, or simply save the policy and wait to apply it to this machine or others until a later time.

Keep in mind that the policy itself is simply an XML file, which means that you can make changes directly to the file without necessarily loading the wizard and walking through all of its steps. An excerpt from a sample policy looks like this:

    <?xml version="1.0" encoding="UTF-16" ?>
    - <SecurityPolicy Version="1.0">
    - <Rules>
    - <Rule Name="Microsoft.OS.Services" Version="1.0">
    - <Parameters>
    - <Parameter Order="1">
      <Service Name="EDI Subsystem" StartupMode="Disabled" />
      <Service Name="ENTSSO" StartupMode="Disabled" />
      <Service Name="Microsoft.BizTalk.KwTpm.StsBizTalkAdapter.StsBizTalkAdapterService"
    StartupMode="Disabled" />
      <Service Name="RuleEngineUpdateService" StartupMode="Disabled" />
      <Service Name="ListManager" StartupMode="Disabled" />
      <Service Name="DMLService" StartupMode="Disabled" />
      <Service Name="PredictorService" StartupMode="Disabled" />
      <Service Name="IMAP4Svc" StartupMode="Disabled" />
      <Service Name="RESvc" StartupMode="Disabled" />
      <Service Name="MSExchangeES" StartupMode="Disabled" />
      <Service Name="MSExchangeIS" StartupMode="Disabled" />
      <Service Name="MSExchangeMGMT" StartupMode="Disabled" />
      <Service Name="MSExchangeMTA" StartupMode="Disabled" />
      <Service Name="MSExchangeSA" StartupMode="Disabled" />
      <Service Name="MSExchangeSRS" StartupMode="Disabled" />
      <Service Name="MSPOP3Connector" StartupMode="Disabled" />
      <Service Name="UN2" StartupMode="Disabled" />
      <Service Name="DRDAResync" StartupMode="Disabled" />
      <Service Name="NVAlert" StartupMode="Disabled" />
      <Service Name="NVRunCmd" StartupMode="Disabled" />
      <Service Name="PO005" StartupMode="Disabled" />
      <Service Name="SnaDdm" StartupMode="Disabled" />
      <Service Name="DDM001" StartupMode="Disabled" />
      <Service Name="DDM999" StartupMode="Disabled" />
      <Service Name="MngAgent" StartupMode="Disabled" />
      <Service Name="MQBridge" StartupMode="Disabled" />
      <Service Name="DDM6DB" StartupMode="Disabled" />
      <Service Name="SnaRpcService" StartupMode="Disabled" />
      <Service Name="SnaBase" StartupMode="Disabled" />
      <Service Name="SnaNetMn" StartupMode="Disabled" />
      <Service Name="SnaPrint" StartupMode="Disabled" />
      <Service Name="SnaServr" StartupMode="Disabled" />
      <Service Name="TN3270" StartupMode="Disabled" />
      <Service Name="TN5250" StartupMode="Disabled" />
      <Service Name="ISACtrl" StartupMode="Disabled" />
      <Service Name="ADAM_ISASTGCTRL" StartupMode="Disabled" />
      <Service Name="Fwsrv" StartupMode="Disabled" />
      <Service Name="ISASched" StartupMode="Disabled" />
      <Service Name="ISASTG" StartupMode="Disabled" />
      <Service Name="MSSQL$MSFW" StartupMode="Disabled" />
      <Service Name="SQLAgent$MSFW" StartupMode="Disabled" />
      <Service Name="MIIServer" StartupMode="Disabled" />
      <Service Name="MOM" StartupMode="Disabled" />
      <Service Name="SBCore" StartupMode="Disabled" />
    ...


					  

As you can see, the SCW is a much-needed addition to Windows Server 2003 and appears at this point to be a worthy effort to help administrators harden their machines.

3. The rollback feature

If you applied a security policy with SCW that adversely affected some or all of the functionality of the machine, you can roll back the security policy that caused the problem and return the machine to an operational state. However, if you edit an SCW-applied policy in the Local Security Policy MMC after you apply it, the changes can't be rolled back to their preapplication state since the SCW has no way of tracking changes that were made through another interface. The server in question will remain in its current configuration.

For services and registry values, rolling back a policy restores settings that were changed during the configuration process. Windows Firewall and IPsec rollbacks consist of unassigning any SCW policy that is currently in place and reassigning the previous policy that was in place before the SCW policy was applied.

Also keep in mind that if you enabled file system access auditing, that policy cannot be rolled back. However, for most other policies, the rollback feature is a decent insurance policy that helps protect against recoverable mistakes.

4. Best practices

To achieve best results from using the SCW, consider the following:

• Run the SCW on each of your unique role-based servers and save the policies. There's no need to go all-out when you first run the SCW—let it walk you through and help you decide the policies you want to set, and then simply save the file. You can reuse it later on an unlimited number of machines, and saving the file will also give you a chance to learn the XML format the wizard uses and to double-check the settings and changes the wizard wants to apply before actually committing them to production systems.

• Roll out saved policies one by one on the appropriate machines. Once you've tested the policies you created in the previous step, start applying them individually to servers that are performing like roles. Start with your file servers, and then move to domain controllers, Exchange machines, SQL Server boxes, and so on. A controlled but steady deployment is your best bet for success.

• Don't forget to include your existing security templates if necessary. Remember that the SCW has full support for any existing security templates that you may have created There's no need for the SCW to obsolesce this. On the last step of the Create a New Policy portion of the wizard is a button called Include Security Templates that you can click to select the template file to wrap into the manifest of your new policy. Unfortunately, there's not a way to intuitively roll these back once you've applied them.
  

• Finally, beg your service vendors for updates to their software that support configuration through the SCW since the SCW's XML database is extensible. Do you have third-party services that the SCW doesn't know about? Get in touch with your vendor and demand this support.