Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

How to Use Security Templates to Secure Computers by Role

The first step in using security templates to secure computers by roles is to design a template that applies the baseline security for all servers on the network. The objective of the baseline template is to tighten every aspect of computer security. It follows the principle of reducing the attack surface. This principle increases security by relying on the simple fact that the less a server is doing, the fewer potential vulnerabilities or attack surfaces will be available. After the baseline security template is applied to a server, the server will still run, but it may not be able to perform the services for a specific network role.

NOTE: See Microsoft Documents for More on Securing Computers by Role

Microsoft's "Windows 2000 Security Operations Guide" introduced the concept of using baseline and incremental templates to secure Windows servers. You can download a copy of this guide and the templates from http://www.microsoft.com/downloads/details.aspx?FamilyID=f0b7b4ee-201a-4b40-a0d2-cdd9775aeff8&displaylang=en.

The second step resolves this problem by creating incremental templates that include the changes necessary to support specific roles. These templates may, for example, enable services that are required by a specific server role. A DNS incremental template, for example, enables and sets to automatic start at boot the DNS Server service, a service that is disabled in the baseline template.

Baseline and incremental templates are designed to be assigned in a hierarchical fashion. First, the baseline template is applied and then the appropriate incremental template. When multiple templates are applied to the same computer, settings are merged unless a conflict occurs. When a conflict exists, the most recent setting wins. This is why the baseline template can disable a service and the incremental template can enable the same service. A conflict exists, but because the incremental template is applied after the baseline template, its configuration for the specific service will win. Hierarchical assignment can be done either manually by applying the templates consecutively to each server, or automatically by importing the templates into Group Policy Objects. When Group Policy is used, a baseline template is applied at a top-level OU created for servers, and the incremental templates are applied to child OUs created for each server role. For example, a DNS incremental template is applied to an OU that contains the computer accounts for all DNS servers, and a file server incremental template is applied to an OU that contains all the computer accounts for file servers. Because of the way Group Policy works, the baseline template will be applied to all servers, and the incremental DNS template will only be applied to the DNS servers, and so on.

Although the basic templates provide examples that may be used to provide tighter security, none of them are baseline templates. Microsoft provides sample baseline templates, along with incremental templates. These templates can be downloaded with companion documents that detail the security settings they provide and discuss other sound security practices. The templates have been tested in many production networks. The documents and templates are available by download:

The "Windows Server 2003 Security Guide" provides templates and instructions for securing Windows Server 2003 (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=8a2643c1-0685-4d89-b655-521ea6c7b4db).

The "Windows XP Security Guide" provides instructions and templates that can be used to secure Windows XP (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=2d3e25bc-f434-4cc6-a5a7-09a8a229f118).

The "Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP" details every security setting (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=1b6acf93-147a-4481-9346-f93a4081eea8).

The "Windows 2000 Security Operations Guide" provides similar information and templates for Windows 2000 (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=f0b7b4ee-201a-4b40-a0d2-cdd9775aeff8).

NOTE: THE TRUE IMPACT OF SECURITY TEMPLATES

The templates and methodology of the "Windows 2000 Security Operations Guide" have been tested several times in "hacking" contests. One such contest was at the Microsoft Certified Professional Magazine Security Summit in July 2002. The Windows challenge consisted of an entire network hardened using the templates from the "Windows 2000 Security Operations Guide." The challenge network was put on the Internet for 48 hours and was subject to thousands of online attacksbut none of them broke through the defenses.

Building security templates for computer roles is not just a matter of picking and clicking within the template or using carte blanche templates provided by Microsoft or others. Each setting in the template must be set to fulfill the security policy of your network. The provided templates and documentation, however, provide an excellent starting point, ideas for discussion, and a system that has been tested and that works.

The approach described in the documents and discussed in this chapter is to separate computers by the roles they play on the network, apply a baseline template to all computers, and then apply incremental templates to each computer according to its role. Infrastructure servers, for example, may need to run DNS, DHCP, or other services, while domain controllers and ordinary file servers do not. File and print servers should not run these services, but they do need to run the print spooling service and have file sharing enabled. Finally, other tools and recommendations for security that cannot be implemented via the security templates will also need to be implemented. Instructions for infrastructure roles are documented.

Each role that a Windows computer plays within your network may entail many different security configurations. Although not all security can be configured through templates, it is important to use templates wherever you can because you can more efficiently configure, apply, and maintain a large number of security settings. The simple discussions within this chapter should not be your only source for determining the security necessary for these computers. However, this chapter provides you with a framework on which to build appropriate security for a specific network.

Creating and Manipulating Templates

Security templates are text files and can be created from scratch. However, while much of the syntax that must be followed is straightforward, in some areas (such as permissions), it is difficult to correctly enter the information when working within a text file. Instead, a better way to get started is to copy a template that is close to what you need and then adjust it. To copy the template, first create a Security Templates console as described in the section, "Security Templates," then perform the following instructions. Using this method ensures the resulting file syntax will be correct. A good practice is to create a secure folder to store custom templates in and use it for your development work. In the following examples, it's assumed that a "custom templates" folder has been created, but the folder can have any name.

To create the new template, first add the path to the new folder, and then copy the template:

After a copy of the template is made, revise it as necessary. To modify a template, follow these steps:

Templates should be modified by using the GUI whenever possible; however, there are three reasons to make changes directly to the template file:

Comments should always be added to templates that have been modified. Doing so provides documentation on how the template was changed and where important elements lie within it.

Unnecessary information should be removed. A template may be created for a simple purpose, such as setting permissions on a few registry keys and/or files. Removing the extraneous information, such as information on settings that are "not defined," can make it easier to work with the template and understand what it's doing. An example of such a template is the iesacls template, as shown in Figure 11-3. The only settings in this template are for the registry keys displayed. All other sections will be noted as "Not Defined."

Additional registry keys can be added. Registry changes not represented in the GUI of the template can be added to the template by adding them to the template file. Any registry change added to the template file will be made when the template is applied.

The addition of comments and the removal of extraneous information can be done by simple editing. New registry changes, however, must be added to the proper section. To do so:

Create Baseline Templates to Secure All Servers

The first step in the process is to create a baseline template to secure all servers. A good place to start is to examine the security templates provided by Microsoft for this purpose.

Microsoft Sample Baseline Templates

The "Windows Server 2003 Security Guide" provides two baseline templates, one for server and one for domain controllers, for each of three categories:

Legacy clients
The domain may have a wide range of Windows clients and servers, including Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional, and Windows Server 2003.

Enterprise clients
Only Windows 2000, Windows XP, and Windows Server 2003 may exist in the domain.

High security
Only Windows 2000, Windows XP, and Windows Server 2003 may exist in the domain, and the template applies tighter security than the enterprise client templates does.

In addition, templates are defined for infrastructure servers, file servers, IIS Servers, Print servers, bastion hosts, IAS servers, and Certification Authorities. The templates provide solid security guidance; you should also look for additional generic baseline checklists. Here are some good sources:

www.Microsoft.com/technet/security/tools/w2ksvrcl.asp

The National Security Agency web site, www.NSA.gov

The Center for Internet Security, www.cisecurity.org

SANS Organization, www.sans.org

WARNING: The Meaning of Baseline Can Be Different

Some security baseline providers also provide preconfigured security templates that match their recommendations. However, those templates are not designed to work in the hierarchical design presented in this chapter. The meaning of "baseline" may also be different because it may mean "minimum security baseline" instead of the strict maximum-security baselines developed by the Microsoft strategies and described in the following sections.

The Microsoft baseline template for servers is not designed to be used for domain controllers. Some of the services disabled in the server template are required, additional file, folders, and registry keys need protection, and areas that may have been locked down, such as TCP/IP properties, need to be relaxed. The baselineDC.inf template is designed to accommodate what it can of these settings. The specifics of security for domain controllers are discussed in Chapter 10, "Securing Active Directory."

One specific change in the domain controller template enables the DNS service. It is not necessary to install DNS on a DC. However, if separate infrastructure servers do not run DNS for the Windows domains, the logical place is on the domain controller. Also, when dcpromo is used to create the first domain controller in the domain, if you do not have DNS services available, you may want to choose the option to create the DNS server during dcpromo. If you do so, dcpromo installs DNS and populates the DNS server with the records needed for smooth function. If DNS is not installed on a DC, disable DNS in your domain controller baseline template.

Review Sample Templates and Adjust for Your Environment

Not all baseline security settings can or should be in baseline templates. Others may need to be adjusted to meet your security policy. When evaluating the baseline templates, and when attempting to configure security for computers, keep this in mind.

Specifically, consider what should reside elsewhere and what must be configured elsewhere. Even when your analysis of templates is complete, your work on a baseline security for servers is not:

Configuring an alternative name for the administrator account should not be done in a template that will be applied to all servers in the domain. Instead, each server should have a unique replacement name.

The password policy for the domain is configured in the default domain GPO, not in the baseline templates. A password policy for local accounts on member computers, however, can be configured in a template designed for the OU where these computer accounts reside.

File, folder, and registry permissions should not be set within baseline templates because a large number of settings can interfere with the efficiency of replication.

Security settings are not entirely located in templates. Some settings, such as Public Key Policy and IPSec policies, are part of GPOs but not security templates. Other settings are applied directly, such as in the Property pages of services.

Templates are divided into sections. Review each section and make sure you understand it, why the settings have been set the way they are, and how you might need to change them to meet your policy and needs.

Account Policies

Account Policies are Password Policies, Account Lockout Policies, and Kerberos Polices. Kerberos Polices are used only in the default domain GPO. Likewise, password policies, such as those shown in Table 11-2, are not configured in the baseline template because the password policy for the domain must be configured in the default domain GPO, and password policies for the local accounts of member servers should be configured in the GPO of the OU where they reside. The table presents and defines the parts of a security template. In addition, Microsoft recommendations in its security guide for different settings dependent on the security models are provided in the center column. If no difference is provided, N/A is listed.

User Rights

User rights for the domain are set in the default domain controller GPO; however, user rights are also defined in server baseline templates and/or in templates for use with specific server roles. Table 11-3 defines user rights in the baseline template.

Security Options

Security Options are a collection of security features. Table 11-4 provides only a listing of Security Options that are changed in the templates. It also does not include settings that are covered elsewhere, such as settings specific to domain controllers.

In addition to those security settings visible in the security template GUI interface, the Microsoft templates provide additional security settings. These settings are defined in the template text file. You can also add settings to the text file. If a security setting is implemented by modifying the registry, it can be added to a security template file and will be applied when the template is applied. Settings must be added to the [registry values] section of the template. The settings listed in Table 11-5 (and are defined following the table) are present in the Microsoft Enterprise Client and High-Security baseline templates. Most of these settings harden TCP/IP against network attacks. By applying these settings, the template helps mitigate certain types of network attacks, especially DoS attacks. These settings are recommended for any computer that may be Internet-facing. All settings in the table fall below the HKEY_LOCAL_MACHINE\CurrentControlSet\path.

TIP: Adding Custom Security Options

This technique, adding a registry setting to the [Registry Values] section of a template file, can be used with any registry setting. Instructions for doing, so are in the article, "How to Add Custom Registry Settings to Security Configuration Editor," which helps you understand how to perform this task. You can find it at http://support.microsoft.com/?kbid=214752.

Following the table is a list of all settings added to the templates and an explanation of each.

The following TCP/IP settings are added to the templates:

TCPMaxPortsExhausted
This number is a total of how many dropped connect requests before the SYN-ATTACK protection is operated. A SYN-ATTACK works because connections are opened and not used, eventually exhausting the number of connections that the server can have. Open and unused connections will eventually be closed, but in many cases, not before a DoS has occurred. This setting allows the administrator to control when the SynAttackProtect parameter is triggered.

TcpMaxDataRetransmissions
When data is sent and not acknowledged, it is resent. An attacker could take advantage of this by not responding, thus keeping the server busy resending packets. Set at three, the number of transmissions is reduced, hopefully enough to reduce the impact of an attack.

TcpMaxConnectResponseRetransmissions
If a connection request is not acknowledged, TCP attempts the connection again. In a SYN flood attack, the attacker continues to send a stream of connection requests, or SYN packets, but does not respond.

SynAttackProtect
When set, connection requests time out more quickly, thus mitigating the effect of a DoS attack.

PerformRouterDiscovery
This setting allows a DHCP client to receive routes from the server via the ICMP router discovery protocol. An attacker could spoof these messages and cause the computer to use routes that do not exist, are not correct, or that redirect packets to the attacker.

KeepAliveTime
TCP attempts to verify if a connection is intact by sending a "keepalive" packet, which is then acknowledged by the remotely connected machine if it is still connected. Establishing many connections could cause a DoS condition. By making this setting low, such as five minutes, inactive sessions are discovered sooner.

EnablePMTUDiscovery
This setting causes a system to attempt to find the largest possible packet size over the path to another host. If necessary, the packets to be sent are fragmented. Without this setting, an attacker might attempt to force the MTU to a small value and overwork the stack by forcing the fragmentation of many packets.

EnableICMPRedirect
Set to disabled to prevent ICMP overriding Open Shortest Path First (OSPF) router-generated routes. Otherwise, the ICMP override could prevent traffic from going where it should because the timeout on this action is 10 minutes.

EnableDeadGWDetect
Set to disabled. When enabled, an alternative gateway may be used if many connections are having problems. An attacker might force the use of an alternative gateway of his choosingthat is, redirecting traffic in a manner that suits his purpose.

DisableIPSourceRouting
IP source routing allows the sender to determine the route a packet will take through the network. An attacker could obscure the route his attack has taken.

NoNameReleaseOnDemand
When set, Windows ignores Windows name release request unless they come from WINS servers. (An attacker could pose as a legitimate system by using its name. Dupliciate names are not allowed on the network, so the attacker may try to get the legitimate computer to release its name.)

AFD
There are four AFD settings (MinimumDynamicBacklog, MaximumDynamicBacklog, EnableDynamicBacklog, and DynamicBacklogGrowthDelta). Afd.sys handles connection attempts to services such as FTP and web servers. These modifications help afd.sys handle large numbers of connections by creating a dynamic backlog.

The following entries, which are not related to TCP/IP hardening, are also added to the template:

Disable8dot3NameCreation
Prevents 16-bit scripts and others that rely on 8.3-style names from running, preventing the automatic creation of 8.3 names. The REG_DWORD value is set to 1 for HKLM\System|currentControlSet\Contol\FileSystem\NtfsDisable8dot3Name Creation.

NoDriveTypeAutoRun
Disables autorun so that a possible introduction of a virus or Trojan from inserting a CD-ROM does not happen. If the value is set to 0xFF at HKLM\Software\Microsoft\WIndows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun, AutoRun is disabled for all drive types (removable, CD-ROM, hard drive, etc.).

ScreenSaverGracePeriod
Reduces the time between when a screen saver is activated and when it locks the system. If the password feature of the screen saver is enabled, the string value is set to 0 for the registry entry HKLM\Software\Microsoft\Windows\CurrentVersion\Winlogon\ScreenSaverGracePeriod.

WarningLevel
Warns when the security log is near capacity. (To use this setting, the security log must be set to not overwrite events.) To set the percentage of log fullness at which to warn the administrator, the number 90 is set for the value at HKLM\system\currentControlSet\Services\EventLog\Security\Warninglevel.

SafeDllSearchMode
Enables a safe DLL search order. DLLs should be searched for first in the system path, and then in the current working folder. This means a regular system file will be used, and an attack that places a malicious DLL with the same name will not be run. The value is set to 1 at HKLM\system\CurrentControlSet\Control\SessionManager\SafeDllSearchMode.

Services

Although Windows Server 2003 does not install some services and disables others by default, there are many Windows services present and running after a default system install. The presence of additional software on any service can represent a vulnerability. Vulnerabilities may exist because of the potential use of the service or because of some as-yet undiscovered vulnerability in the code of the service. Templates can be used to improve security by setting the startup mode of unnecessary services to "disabled." The problem, of course, is which services are unnecessary? Caution must be used when disabling services, as some application or other service running on a server may need them.

NOTE: Startup Modes

The startup mode of each service is configurable and can be either manual (must be started by a program, command, or by manual access to the services console), automatic (started at boot), or disabled (cannot be started). When evaluating the risk presented by services, remember that it is not necessary to use the GUI to start services set to manual.

The baseline server security template enables the services listed in Table 11-6. All other services should be marked as disabled in the console, even if they are not installed. This can prevent or cripple rogue installations of a service. In developing a baseline template for a specific network, you may decide to disable additional services as well. For example, if the Automatic Updates service or the Volume Shadow Copy Service will not be used on the majority of servers, disable these services. The baseline template should disable as many services as possible, and then incremental templates should be used to enable services that may be required by specific computer roles.

Using Incremental Templates and Other Techniques to Provide Security for Infrastructure Servers

The baseline template locks down servers. It is applied to all servers. To secure infrastructure servers (DNS, DHCP, WINS servers), two types of security configuration must be done. First, incremental templates are required in order to enable services that infrastructure servers require and that are disabled in the baseline template. Second, specific security configuration in and outside of the security templates is necessary. All these settings become part of an infrastructures baseline security, even though not all of them can be applied using a baseline security template.

Using Incremental Templates

Some changes should be made for all infrastructure servers, and others are specific to the type of infrastructure server. An incremental template for infrastructure servers is part of the Windows Server 2003 Security Guide, but it only sets the status of infrastructure services from disabled to automatic. This template does not configure Auditing, User rights, Security Options, or Event Log Settings because these settings are configured in the baseline policy, and no formal recommendations exist for change.

However, you may want to modify the template for your specific environment. The incremental infrastructure template sets the DNS server, DHCP server, and WINS services to automatic. For example, if you do not use WINS servers, the WINS service should not be set to automatic.

Another approach would be to use separate incremental templates for each class of infrastructure server: one for DNS, one for WINS, and one for DHCP. Each template would include settings that fit the specific server type. However, note that most changes specific to infrastructure servers either cannot be made in the templates or should not be shared across multiple machines.

Techniques for All Infrastructure Servers

Here are changes that need to be made for all infrastructure servers:

Secure service accounts

Protect well-known accounts

Block ports using IPSec filters

Secure Service Accounts

Wherever possible, don't run services using domain accounts. When services use domain accounts and the server is compromised, the domain account password can be obtained from the Local Security Authority (LSA) Secrets database. (This area is protected from normal access, but tools such as Bindviews lsadump2 can be used to obtain its contents.) If a domain account password is obtained, it might be used to attack other computers in the domain. Instead of using a domain-level account, use the built-in network service or local service account. If a domain account must be used, configure the logon rights for specific computers to deny it the ability to access any servers it does not need access to.

TIP: Prevent the Use of LSADUMP2

LSADUMP2 is a tool available from http://www.bindview.com/Support/RAZOR/Utilities/Windows/lsadump2_readme.cfm. This tool can be used to examine the contents of the LSA Secrets database. The Debug privilege is required to successfully use this tool. By default, only administrators have this right. You can protect servers from attack via LSADUMP2 by removing the Administrators group from the Debug Programs user right. However, the application of some Microsoft patches requires that the person updating the computer has the Debug Programs user right.

Block Ports Using IPSec Filters

IPSec filters can block ports on infrastructure servers. IPSec filters can be used to allow only those connections that are desirable based on IP address and/or port number or to block specific connections. For example, an IPSec policy could be implemented in a GPO on an OU that blocks the use of telnet services on all servers within the OU. Alternatively, all ports except DNS ports might be blocked on a standalone DNS server. Policies can be created with multiple filters to allow and block ports as required. Information on writing IPSec policies is in Chapter 15, "Protecting Data in Flight." Command-line scripts for producing policies for infrastructure servers can be downloaded with the "Windows Server 2003 Security Guide."

The following list includes recommendations for implementing a protection policy for DHCP servers. The list could be adapted for use with other infrastructure services:

Blocking all traffic to all TCP ports on the DHCP server. (The DHCP service uses UDP ports 67 and 68.)

Allowing all traffic to port 3389 on the DHCP server to allow management using terminal services. Blocking all ports prevents management tools that use RCP ports such as the DHCP administration console. Leaving port 3389 open allows management via terminal services.

Adding a filter to allow any traffic from the DHCP server to a Microsoft Operations Manager (MOM) server if one is used.

Adding additional filters as required to support additional applications on the servers or additional management products.

Protect Well-Known Accounts

Attempts are often made to use two well-known accounts, the Guest account and the Administrator account, to attack Windows systems. The Administrator account should be renamed. The Guest account should be disabled and renamed. Although the Guest account is a typical low-privilege account, it can be used to find information that may assist an attacker with another attack.

To protect the built-in Administrator account, perform these tasks:

Rename the accountmany scripts hard-code the user account Administrator, so if the account does not exist under that name, the script will fail. Newer scripts use the well-known SID for the administrator account instead of the name Administrator, so changing the Administrator account name does not protect against those scripts. However, changing the name is still a valid opportunity to prevent some scripts from running and to prevent casual snooping.

Require and use different replacement names on each server.

Require and use different Administrator passwords on each server.

Change the account descriptions!

Record changes and store in a safe location.

Use the Security Option Accounts: Administrator account status to disable the Administrator account. (The account is still usable in Safe Mode.) Disabling the Administrator account should not be done until an alternative is determined, such as using a domain level account or creating another local account and giving it membership in the Administrators group.

Create an ordinary user account and give it membership in the Administrators group to use it for administration.

Neither the Guest account nor the Administrator account is renamed in the baseline or infrastructure templates. This is done to encourage the use of different account names for different servers. If the same name is used, the attacker's job is easier.

Techniques Specific to Infrastructure Role

In addition to general infrastructure role hardening, each infrastructure role, DNS, DHCP, and WINS, must also be hardened.

Secure DNS Servers

DNS is a primary attack target because DNS servers contain sensitive information that can be used to attack the network and because a successful denial of service attack can prevent computers from accessing resources. The types of attacks that are usually attempted are

Footprinting
Learning about your network computers and the services they offer

Denial of Service
Preventing access to DNS information

Redirection
Redirecting DNS enquiries to rogue servers

Data modification
Changing information that therefore may result in clients using rogue services instead of legitimate ones

To rebuff or mitigate the impact of these attacks, the Windows Server 2003 DNS server is preconfigured with several security features. In addition, other actions can be taken to protect DNS. Several recommendations for securing DNS have to do with the design of your DNS infrastructure, others have to do with DNS server configuration, and still others rely on changes made at the client level.

The infrastructure should be designed to provide a secure base for DNS. Several items should be considered. Here are the recommendations:

Host a separate internal DNS infrastructure to manage name resolution for internal computers. Use a different DNS server and zone to manage name resolution information that must be provided externally, such as addresses for email servers, web servers, and the like. This allows you to host your internal DNS servers inside the firewall and prevent access to them from external sources. It also prevents exposure of internal addressing information to external sources.

Set the internal DNS servers to use forwarders to forward requests for external name resolution to the external DNS infrastructure. Figure 11-5 shows the DNS server property page (in the DNS console, right-click the server and select Properties, and then select the Forwarders tab) where forwarders are configured.

Configure routers and firewalls to allow only external traffic to the internal DNS server but to allow traffic to and from the external DNS server.

Use Active Directory integrated zones. This provides the ability to use secure dynamic updates and to secure zones using DACLs set in the Active Directory. By setting permission in AD, permissions are set uniformly. The type of zone is configured on the property page for the zone. (In the DNS console, right-click the zone, select Properties, and then click the Change button next to Type). Figure 11-6 shows the location on the General page; Figure 11-7 shows the Change button.

Secure DNS Clients

DNS clients can be configured with the IP address of the DNS server, or if they obtain their IP address from a DNS server, they can obtain the DNS server address from DHCP as well. Specifying static DNS server addresses and alternative addresses directly in the client configuration is preferred. Although it is more convenient to allow the client to download this information from the DHCP server, if a rogue DHCP server is on the network, or if the DHCP server is compromised, the client may receive an incorrect DNS server address. You can also limit the clients that can use the DNS server by configuring clients with the DNS server's IP address and by configuring the DNS server to only listen on that address.

Secure DNS Zones

To secure zones, secure the Registry DNS entries, configure secure dynamic updates, and restrict zone transfer. To secure Registry DNS entries, modify the DACLs on the registry keys. Registry entries for DNS are at

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS

Configure Secure Dynamic Updates

Configure secure dynamic updates, as shown in Figure 11-7. Using secure dynamic updates prevents a rogue computer from changing zone information. To update a record, a computer must be authenticated by and joined to the Active Directory domain where the DNS server resides. Further restrictions are placed by the ACLs configured on the zones. Although pre-Windows 2000 clients cannot update their own DNS records, DHCP can be configured to do so for them.

When DNS zone information is stored in Active Directory, setting the DACLs in the DNS administration console has the same affect as changing ACLs on the Active Directory objects. If different administrators manage DNS than those that manage Active Directory, care should be taken to ensure that ACLs are consistently set.

Restrict Zone Transfers

Zone transfers allow the coordination and sharing of zone information across multiple DNS servers. This provides redundancy and backup. However, should zone transfer to an unauthorized DNS server take place, it might make available information that could be used to mount an attack on your network. This technique, obtaining DNS information, is called footprinting. If DNS is Active Directory-integrated, zone transfers are not used. Instead, zone information is stored in and replicated as part of the Active Directory database. However, in a standalone DNS server, by default, zone transfers only occur between the DNS servers listed in the name server (NS) resource records of a zone. To further secure zone transfers, change this setting to only exchange zone information with specific IP addresses. Should a resource record be compromised and an IP address of a name server be changed, the IP address will still be correct in the configuration, and an unauthorized zone transfer will not occur. Take care to ensure that authorized changes to the IP address of a name server are also made in the zone configuration.

To restrict zone transfers to specific IP addresses perform these steps:

Alternatively, the dnscmd command can be used at the command prompt or in a script. The command must specify the name of the DNS server, the name of the zone, and the IP address. To allow a zone transfer, the command takes the form:

Dnscmd dnserver_name zone_name /SecureList Secondary_IP_address

Consider carefully before delegating zone authority. Management of part of the DNS information for the organization can be delegated by allowing zone delegation to another DNS server that is managed by different individuals. Whenever control over sensitive information or objects is changed, the implications should be weighed against the convenience.

Back up zone information so that it can be recovered if necessary. Zone information includes information on which server is authoritative for each zone and which domain controllers house application partitions for DNS zone information when DNS is integrated with Active Directory.

Monitor and Adjust Security Settings in DNS Configuration

By default, the Secure Cache Against Pollution Setting is enabled. This helps to prevent incorrect IP addresses received in response to a query from being cached. When the cache is secured against pollution, only IP addresses received from the DNS server authoritative for their domain are stored. Additional DNS settings that can be configured for security are

Disable recursion
Recursion is enabled by default so that the DNS server can provide recursive queries for its clients. If a DNS server will not be required to do so, recursion can be disabled. (DNS servers use iterative queries to communicate with each other.) An attacker might flood a DNS server with recursive queries and therefore successfully deny service to legitimate clients. Recursion is necessary if DNS servers use forwarders.

Root hints
If an internal root exists in your DNS infrastructure, configure the root hints on other DNSs to point to this root rather than Internet root servers. This prevents internal information from going to the Internet.

Secure DHCP

DHCP servers should be protected because an interruption in their service can mean the inability of clients to obtain an address. Two areas to be concerned about are preventing or mitigating a denial of service attack and being able to monitor the access and use of the DHCP server and its service. In addition to applying the baseline and infrastructure template, the DHCP server should be configured to

Turn on extended DHCP logging. By default, events are logged on startup and shutdown.

Secure log access.

Configure DHCP servers in pairs to provide redundancy and partial protection from a denial of service attack.

Turn On Logging

To enable extended DHCP logging perform these steps:

The DHCP server creates a log file at %windir%\system32\DHCP. This log contains detailed information about the activities of clients and does include both Media access control (MAC) and IP addresses. This information may help in finding the source of an attack or problem. Although not foolproof (MAC and IP addresses can be spoofed), the information is invaluable in managing DHCP.

Secure Log Access

Limit access to this log by changing the DHCP folder access control list (ACL). By default, Administrators have Full Control, and Server Operators and Authenticated Users have read access. Remove the groups Server Operators and Authenticated Users so that only Administrators have access to the logs.

Frequently archive the log because it can grow quite large. By default, the system will stop logging when there is less than 20 MB of free disk space left. This setting can be changed.

Configure DHCP Servers in Pairs

To configure the IP address scope of the DHCP pair, use the 80/20 rule. Split the address range that must be serviced by giving one DHCP server 80 percent of the addresses and 20 percent to the other. Remember, the idea is to ensure that if one server is under attack, there is still a DHCP server service on the network.

Create IPSec Policies

Blocking all access except that needed to provide management and functionality of the DHCP server can provide additional security. The following IPSec filters should be created:

A filter to allow access from the DHCP server to all domain controllers from any port to any port.

A filter to allow any traffic from ANY address, UPD port 68 to the DHCP server on port UDP 67 (DHCP service).

A filter to block all inbound traffic.

Secure WINS

To secure the WINS server, create IPSec policies that limit the type of traffic the WINS server will respond to. Blocking all access except what's needed to provide management and functionality of the WINS server can provide additional security. The following IPSec filters should be created:

A filter to allow access from the WINS server to all domain controllers from any port

A filter to allow access from ANY computer on ANY port to port 1512 TCP (WINS Resolution server) on the WINS server

A filter to allow access from ANY computer on ANY port to port 1512 UDP (WINS Resolution server) on the WINS server

A filter to allow access from ANY computer on ANY port (WINS client or server) to port 42 TCP (WINS Replication Partner) on the WINS server

A filter to allow access from ANY computer on ANY port (WINS client or server) to port 42 UDP (WINS Replication Partner) on the WINS server

A filter to block all inbound traffic

Extend the Concept to Other Roles

A number of other computer roles exist in the network that can be secured in the same fashion. An incremental template can be created for each unique server role. An example of such a role is the File and Print Server role.

The File Server template disables the DFS and File Replication Services and enables File and Print Sharing. The Print Server template enables the Print Spooler service and sets it to automatic. If these services are used in your organization, do not disable them.

It may be tempting to combine the functions of file and print; however, you should consider that a combination file and print server may be subject to a disk space DoS. In this type of attack, the disk is filled by sending a large number of print jobs to the server. Likewise, a busy file server might eventually leave little space for print spooling. If the disk can be filled, the server may become unavailable to other clients. You must judge whether the risk of such an attack is high enough to warrant splitting these roles if you do not already.

File servers must open ports that are generally considered to be problematic. Many known attacks use these ports, and they cannot be blocked or the servers will become useless. However, IPSec blocking policies can still be used to protect the server from attacks using other ports. If all inbound traffic is blocked, the following traffic should be allowed:

Destination ports 445 TCP and 445 UPD for CIFS

Destination ports 137 TCP and 137 UDP for NetBIOS

Destination ports 138 UDP and 139 TCP for NetBIOS

Destination port 3389 for terminal services (if used for administration)

Any local source ports for traffic to the domain controllers