Section 7.2. Enhancements to Security in Service Pack 1

7.2. Enhancements to Security in Service Pack 1

Windows Server 2003 Service Pack 1 includes not only all the security hotfixes and vulnerability corrections released to date, but also several enhancements to security operations. This particular release is akin to Windows XP's Service Pack 2, both in scope and in the degree of modification of the OS. Most of the security enhancements, including improvements in the user interface, of XP Service Pack 2 have been brought to Windows Server 2003.

The product contains the following fixes to some problems in the release version of Windows Server 2003:

A correction to the way Certificate Services provides service to Microsoft Outlook clients, resolving the problem where clients are asked multiple times for their passwords.
The ability to take advantage of the security of the Secure Sockets Layer (SSL) protocol while running IIS 6.0 in kernel mode. (Briefly, components running in kernel mode benefit from increased performance because the processes run closer to the core of the operating system and not in other "layers" of the OS.)
Improvements to the way errors are logged when accessing the API for the HTTP protocol in Windows Server 2003.
The Windows Firewall included in Windows Server 2003 SP1 includes support for IPv6.
Terminal Services connections can take advantage of SSL for server authentication. This is disabled by default, but you can enable it through the GUI. To use this, the server must have an SSL-compatible certificate with a private key, and the client must trust the root of the server's certificate.
On clean installations, inbound connections are blocked until an administrator acknowledges the status of Automatic Updates and the availability of updates on the Microsoft Update site.
The Automatic Updates interface, as well as the Windows Firewall, now sports the XP-style interface.

7.2.1. The Security Configuration Wizard

The single most important new feature of Windows Server 2003 Service Pack 1 is the Security Configuration Wizard (SCW ), which provides a roles-based way to lock down the surface of your Windows Server 2003 machines. It's a great way to navigate the maze of services found in the operating system and to safely decide which ones can be turned off without affecting functionality for you or your users.

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.

7.2.1.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 administratoreither a local administrator or a domain administrator. Follow these steps to complete the installation:

Open the Control Panel.
Double-click Add/Remove Programs.
Select Add/Remove Windows Components.
Select the Security Configuration Wizard checkbox, and click Next.
Click Finish when prompted.

7.2.1.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 7-2.

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 checkboxesin 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 7-2. 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 7-3 shows the first screen of this section, the Open Ports and Approve Applications screen.

Figure 7-3. 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 7-4), 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 7-4. 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 machineseither 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 choicesnone, 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 7-5.

Figure 7-5. 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.

If you choose to include the SCWAudit.INF template, you will not be able to roll back the file system access audit policy. The wizard will warn you of this.

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 described a bit earlier in the chapter. 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.

7.2.1.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.

Do not end the Security Configuration Wizard either through Task Manager or by shutting down the machine while it's applying a policy. A policy should instead be rolled back after it has been completely applied to the system.

7.2.1.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 SCWlet 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.
I'll cover security templates a bit later in the chapterjust remember the previous point for now.
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.