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 pre-built 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 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 family of products (including Windows XP and Windows .NET) 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 itself ships with a number of templates in the %systemroot%\Security\Templates folder for various machine types (server, workstation, or domain controller) and security level (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 plain text, it’s fairly simple to modify them, so a cottage industry of sorts has arisen for doing just that.

Several sources for prebuilt security templates offer better security than a standard Windows 2000 installation:

  • The Security Operations Guides for Windows 2000 and Exchange 2000 include templates for Exchange 2000 servers and the 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 network design, configuration (including specific recommendations for securing DNS, Dynamic Host Configuration Protocol [DHCP], Exchange, ISA, and Terminal Services servers), and management. Some settings they recommend can cause application compatibility problems, which they freely admit. Their Windows 2000 and Exchange 2000 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. 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 Security Operations Guide for Windows 2000 Server template sets.

The first step, of course, is to identify which templates you need to apply. Because templates are additive, you’ll need to start with one of the baseline templates: Baseline.inf for Windows member servers and BaselineDC.inf for domain controllers. The next template depends on what role the server you’re securing is playing. Table 6-4 shows the templates that must be applied after you apply the appropriate baseline template.

Table 6.4: Choose the Correct Template for Your Server’s Role

Server Role

Template to Apply

File and print

File and print incremental.inf

IIS

IIS incremental.inf

Exchange back-end server

Exchange back-end incremental.inf

Exchange Outlook Web Access front end

OWA front-end incremental.inf

Domain controller used by Exchange

Exchange DC incremental.inf

DNS, DHCP, or Windows Internet Naming Service (WINS) server

Infrastructure incremental.inf

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 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. Uncompress the SecurityOps.exe file that came with your download of the Security Operations Guide for Windows 2000 Server.

  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 BaselineDC.inf.

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

click to expand
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 command:

secedit /refreshpolicy machine_policy /enforce

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.




Secure Messaging with Microsoft Exchange Server 2000
Secure Messaging with Microsoft Exchange Server 2000
ISBN: 735618763
EAN: N/A
Year: 2003
Pages: 169

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net