Tightening Things Further

The recommendations so far in this chapter are sound ways to strengthen your servers security. However, the best principle to follow is to tighten things as much as you can and then check to see whether anything has stopped working. If something broke, you should gradually loosen restrictions on that component until it starts working again. This is an iterative and time-consuming process, and it sounds awfully ad hoc. However, you should apply the process during the initial specification and buildout of your systems ”whenever possible, you do this in the lab, not on production machines. An iterative approach is necessary if you want to get the best possible security. (Remember, good enough security might actually be good enough ”it all depends on the kinds of vulnerabilities you ve found!)

To make this approach work for you, you don t have to (and shouldn t) start randomly adjusting security settings. You can instead use a prebuilt template of security settings, as explained in the next section. Templates give you a secure starting point; after installing a template, you can tweak only those settings that are preventing some component of your system from working. In other words, apply the principle of least permissions: give the fewest permissions possible and then grant additional permissions as needed until everything works again.

Using Predefined Policy Templates

The Windows 2000 Server family of products (including Windows XP and Windows Server 2003) offers a useful feature: you can write template files (also known as .inf files) that can be imported to GPOs. By creating the right template, you can apply a predefined set of options and policy settings to a GPO, which in turn will be applied to computers and users in a domain, site, or OU. Windows 2000 Server itself ships with a number of templates in the %systemroot%\Security\Templates folder for various machine types (server, workstation, or domain controller) and security levels (basic, secure, and high-security). These templates are additive; to apply the high-security domain controller template, you must first import and apply the basic and secure domain controller templates.

Where to Get Templates

Because .inf files are plaintext, it s fairly simple to modify them, so a cottage industry of sorts has arisen for doing just that. There are several sources for prebuilt security templates that offer better security (but not always better compatibility) than a standard Windows installation:

• For Windows Server 2003, the Windows Server 2003 Security Guide is the canonical reference. It includes templates for three separate kinds of environments: networks with lots of legacy clients , more-or-less-standard enterprise deployments, and high-security deployments. There are separate templates for domain controllers, baseline servers, IIS servers, bastion hosts , file and print servers, and Dynamic Host Configuration Protocol (DHCP) and DNS servers. As of this writing, there aren t any specific templates for Exchange servers.

• For Windows 2000 servers, the Security Operations Guide for Windows 2000 includes templates for member servers and domain controllers. These templates are well-documented in the respective guides, and they re supported by Microsoft.

• The U.S. National Security Agency (NSA) is, among other things, responsible for developing security practices and standards for government computers. Their series of Security Recommendations Guides cover Windows 2000 Server network design, configuration (including specific recommendations for securing DNS, DHCP, Exchange, Internet Security and Acceleration, and Terminal Services servers), and management. Some settings they recommend can cause application compatibility problems, which they freely admit. Their Windows 2000 Server and Exchange 2000 Server suggestions are somewhat more permissive than those included in the Security Operations Guides. However, their documents are still worth a read because they cover ground not explicitly addressed anywhere else.

• The Center for Internet Security ( http://www.cisecurity.org ) provides baseline standards for a variety of operating systems and platforms, including Linux, Solaris, Windows NT, and Windows 2000 Server. Their Gold Standard recommendations were drawn from guidelines provided by the NSA, the U.S. Department of Defense, and Microsoft. Their current Level 1 benchmarks provide a reasonably secure default configuration. They ve promised to release stricter Level 2 guidelines in the future.

  Caution  

  The predefined templates produced by these organizations work well for most installations. However, this is not a guarantee they will work flawlessly for you. Do not apply them to production systems until you ve tested them in your own environment to verify they don t break anything. Before you apply them, make sure you have a system-state backup of the targeted machines.

Applying Templates

Once you ve chosen an appropriate set of templates, how do you apply them? The process is pretty easy, assuming you read the sidebar on GPO editing earlier in the chapter. To illustrate this, let s walk through the steps required to apply the Windows Server 2003 Security Guide template sets.

The first step, of course, is to identify which templates you need to apply. This involves choosing which security environment (legacy, enterprise, or high-security) your servers fall into, then selecting the correct set of templates to apply. Because templates are additive, you ll need to start with one of the baseline templates: Enterprise Client “ Member Server Baseline.inf for most users, or the legacy or high- security equivalents, followed by the appropriate template for the server s role.

Note  

Front-end and back-end servers are quite different, so it makes sense that the policy settings in the two templates would vary as well. The front-end template assumes that your front-end server is being used only for Outlook Web Access, not Internet Message Access Protocol (IMAP) or Post Office Protocol (POP), so it turns off the IMAP4 and POP3 services along with the Information Store and a number of supporting services (including the message transfer agent (MTA), the Exchange Management Service, and the Microsoft Exchange Site Replication Service). Remember, services that aren t running cannot be attacked . The back-end server, of course, needs the Information Store and other ancillary services that are not used on a front-end server, but its mix of service requirements is slightly different. See Chapter 14 for a longer discussion of why these services might or might not be needed in various circumstances.

The next step, of course, is to apply the policies. Begin with your domain controllers. You ll have to apply the baseline policy to one domain controller and then replicate it to others. Here s what to do:

1. Get the templates. For Windows 2000 servers, you should use the templates contained in the SecurityOps.exe file that came with your download of the Security Operations Guide for Windows 2000 Server. For Windows Server 2003, use the templates included in the Security Templates folder included with the Windows Server 2003 Security Guide.

2. Open the Active Directory Users and Computers snap-in (Dsa.msc). Right- click the Domain Controllers node, and select the Properties command.

3. Click the Group Policy tab. You should see the Default Domain Controllers Policy listed.

4. Click New. Name the new policy something sensible , like Baseline DC policy or something else that makes its purpose evident.

5. Right-click your new policy, and select No Override. This is necessary because the default domain controller policy turns off auditing, and because it s a higher precedence policy, its settings will suppress auditing unless you tell Active Directory not to allow policy overrides .

6. Click Edit. The Group Policy editor snap-in opens and displays your new policy.

7. Expand Computer Configuration Windows Settings. Right-click the Security Settings node, and select the Import Policy command. (If the shortcut menu doesn t show the Import Policy command, close the snap-in and repeat steps 5 and 6.)

8. In the Import Policy From dialog box, navigate to the location where you stored the template files in step 1. Double-click the appropriate template file (BaselineDC.inf for Windows 2000 Server, Enterprise Client “ Domain Controller.inf for Windows Server 2003).

9. Close the Group Policy editor and dialog box.

10. Force replication on your domain controllers by opening the Active Directory Sites and Services snap-in, expanding the domain controller on which you just created the policy, clicking the NTDS Settings node beneath that domain controller, right-clicking the appropriate connection in the right- hand pane, and selecting the Replicate Now command.

11. Check the application event log on any domain controller for event ID 1704, which indicates that the policy was successfully applied. If you don t see it there, you might need to reboot the domain controller. (Microsoft actually recommends rebooting each domain controller, one at a time, to verify that they ll boot OK after the policy change.)

Once you ve applied the baseline domain controller template, you re ready to add the Exchange DC incremental template to your Exchange servers. The steps to do this are almost identical, with the exception that in step 4 (after you create and name the policy), you need to move your Exchange-specific policy to the top of the list so that it s applied in the correct order. Follow the remaining steps to apply the domain controller policy and verify that it s been replicated properly.

Next, it s time to apply the Exchange servers policies. To do this, your Exchange servers must be segregated into separate OUs. In fact, because you need to apply the Baseline.inf file to all the servers in your domain, you ll need an OU tree that has a container for all member servers, plus nested child OUs for front-end and back-end servers. Figure 6-7 shows what this looks like, along with the templates that should be attached to each of the OUs: Baseline.inf for the Member Servers OU and the respective Outlook Web Access and back-end incremental templates for the nested OUs.

Figure 6-7: Apply the correct policies to each OU.

There s a wrinkle, though: for maximum safety, you should create the OUs and leave them empty, and then attach the templates to them and replicate the changes. After doing so, add a single machine to each of the OUs and force it to refresh its security policy with the secedit or gpupdate command (for Windows 2000 Server and Windows Server 2003, respectively).

This will do the trick nicely . Once the policy appears to have been applied, test the machine to ensure that the policy was indeed applied (remember to check for event ID 1704) and the server still works properly. When you re satisfied, it s safe to move additional servers into the correct OUs and use secedit to force them to update their policies.