Relevant Group Policy Settings
The following table lists the Group Policy settings that are relevant to the DHCP Server role service. Use these Group Policy settings to enforce the appropriate security configuration for your environment. The Group Policy settings in the following table are in the following location in the Group Policy Object Editor:
Computer Configuration\Windows Settings\Security Settings\Restricted Groups
Table 4.2 DHCP Server Role Service Group Policy Settings
Policy object
|
Description
|
Windows Server 2008 default
|
DHCP Administrators
|
Add user accounts as required to this group. If you add an account to this group, but do not add the same account to this policy object, the account is automatically removed and an ID 637 event is logged in the Security log if you have enabled auditing for this policy object.
|
Not created.
|
DHCP Users
|
Add user accounts as required to this group. If you add an account to this group, but do not add the same account to this policy object, the account is automatically removed and an ID 637 event is logged in the Security log if you have enabled auditing for this policy object.
|
Not created.
|
More Information
The following resources on Microsoft.com can provide you with further security best practice information about how to harden server computers that perform the DHCP Server role:
Antivirus Defense-in-Depth Guide.
Dhcploc Overview.
Dynamic Host Configuration Protocol (DHCP) NAP Components.
Netsh commands for DHCP.
Network Access Protection.
The DHCPv6 Protocol.
Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.
Services and Service Accounts Security Planning Guide.
Step-by-Step Guide: Demonstrate DHCP NAP Enforcement in a Test Lab.
"Virus scanning recommendations for computers that are running Windows Server 2003, Windows 2000, Windows XP, or Windows Vista": Knowledge Base article 822158.
Chapter 5: Hardening DNS Services
Domain Name System (DNS) is a system for naming computers and network services that is organized into a hierarchy of domains. To make using network resources easier, name systems such as DNS provide a way to map the user-friendly name for a computer or service to other information that is associated with that name, such as an IP address. When a user types a user-friendly DNS name in an application, DNS services resolve the name to its numeric address.
DNS is a required service in domains that use Windows Server® 2008. This is because domain controllers and client computers in an Active Directory® domain use the DNS service and other services advertised through Active Directory.
The DNS Server service and DNS Client service in Windows Server 2008 include the following security-related enhancements that did not exist in previous versions of Windows Server®:
Background zone loading. DNS servers hosting large DNS zones that they store using Active Directory Domain Services (AD DS) can now respond to client computer queries more quickly after a restart because the zone data now loads in the background. The DNS server can use background zone loading to begin responding to queries almost immediately after it restarts, instead of waiting until its zones are fully loaded. The DNS server can respond to queries for the nodes that it has loaded or that it can retrieve from AD DS. Background zone loading helps circumvent potential denial-of-service (DoS) attacks launched by simply rebooting DNS servers that have large zones.
Support for read-only domain controllers (RODCs). The DNS Server role in Windows Server 2008 provides support for primary read-only zones on RODCs. This makes it possible for DNS zones to replicate on RODCs located in perimeter networks, branch offices, or other unsecured environments.
This chapter provides prescriptive guidance for hardening the DNS Server role. The DNS Server role has no subordinate role services.
Attack Surface
The DNS Server role is susceptible to many of the same security attacks as any server computer that provides DNS services. To determine the attack surface of this role service, you need to identify the following:
Installed files. The files that are installed as part of the DNS Server role.
Running services. The services that are installed as part of the DNS Server role.
Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.
Firewall rules. The firewall rules that the DNS Server role uses.
Role dependencies. The dependencies for the DNS Server role.
The details of the attack surface for the DNS Server role are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this server role, on the DNS tab of the workbook, view the sections that correspond to each of the items in the previous list.
Security Measures
This section describes the security measures that you can incorporate into your DNS Server role configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the DNS Server option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.
Configuration Checklist
The following table summarizes the recommended security configuration tasks for hardening servers performing the DNS Server role. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.
Table 5.1 Configuration Checklist
|
Configuration tasks
|
|
Deploy a Server Core installation of Windows Server 2008.
|
|
Protect DNS zones in unsecured locations by using read-only domain controllers (RODCs).
|
|
Combine the DNS and AD DS server roles on the same server.
|
|
Configure zones to use secure dynamic updates.
|
|
Restrict zone transfers to specific server computers running DNS.
|
|
Deploy separate server computers for internal and external DNS resolution.
|
|
Configure the firewall to protect the internal DNS namespace.
|
|
Enable recursion to only the appropriate DNS servers.
|
|
Configure DNS to ignore non-authoritative resource records.
|
|
Configure root hints for the internal DNS namespace.
|
Deploy a Server Core Installation of Windows Server 2008
Deploying Windows Server 2008 using the Server Core installation option reduces the attack surface of the operating system by limiting the number of required files and services. The advantage of the Server Core option is that it does not install files and services required for the graphical user interface (GUI).
When you use the Server Core installation option of Windows Server 2008 to deploy the operating system, you can only locally manage the server using command-line tools. To manage the server using GUI-based tools, you must install and run these tools on another computer with a Windows-based GUI.
You can use the following command line management tools to manage the DNS Server role:
To install the DNS Server role, run the following command:
start /w ocsetup DNS-Server-Core-Role
To configure the DNS Server service, run the following command:
sc config dnsserver start = auto
Note A space is required between "start" and "=". Also, a space is required between "=" and "auto".
To start the DNS Server service, run the following command:
net start dnsserver
To configure DNS zones, run the following command:
dnscmd
To uninstall the DNS Server role, run the following command:
start /w ocsetup DNS-Server-Core-Role /uninstall
For more information about installing and managing the DHCP Server role using the Server Core installation option, see the Server Core Installation Option of Windows Server 2008 Step-By-Step Guide. And for more information about managing DNS zones by using dnscmd, see the Dnscmd Overview on the Microsoft Windows Server TechCenter.
Protect DNS Zones in Unsecured Locations by Using RODCs
Because of their importance, Microsoft recommends physically securing the DNS servers in your environment in locations that are accessible only to qualified administrative staff. If your organization must provide DNS services in unsecured locations, such as branch office locations, protect the DNS zones using Active Directory Integrated zones replicated to RODCs.
RODCs contain a replicated, read-only copy of the application directory partitions that DNS uses to store Active Directory integrated zones, including the domain partition, ForestDNSZones and DomainDNSZones. This ensures that the DNS server running on the RODC has a read-only copy of any DNS zones stored on a centrally-located domain controller in those directory partitions. An administrator of a RODC can only view the contents of the read-only copy of the zone. However, an administrator can change the contents of the zone on a domain controller that has write access.
AD DS relies on DNS to provide name-resolution services to network clients. The changes to the DNS Server role service are required to support AD DS on a RODC.
Note Any computer stored in a location that is not physically secured represents a security risk to an organization.
Combine the DNS and AD DS Roles on the Same Server
Microsoft recommends installing the DNS Server role on the same server computer that performs the AD DS role in your environment. Combining these roles on the same server allows it to secure dynamic updates of DNS records.
However, Microsoft recommends avoiding combining the DNS Server role with server roles other that the AD DS role to minimize the attack surface of the server. Minimizing the attack surface of the DNS and AD DS roles on the same server computer is important, because the functionality of the entire forest or domain depends on the services this server performs.
In some smaller organizations, budget considerations compel administrators to combine roles. If this is required in your organization, you can combine a RODC and DNS with other server roles. Only RODCs allow the delegation of local administration of the computer without delegating administration of AD DS.
However, Microsoft recommends only combining domain controllers with write access with the DNS Server role if you need to manage the DNS zones on the domain controller. This is because you cannot create writable versions of Active Directory Integrated zones on a RODC.
Configure Zones to Use Secure Dynamic Updates
Windows domains often include hundreds or thousands of DNS clients that must be registered, including servers, domain controllers, and workstations. Because maintaining these resources manually can be very time consuming, DNS supports dynamic updates. Dynamic updates ensure that the DNS client is responsible for its own updates, which also reduces administrative overhead.
However, dynamic updates can be used to attack a computer environment. Introducing rogue DNS clients to the network can fill the DNS database with false entries. Secure dynamic updates mitigate this risk by requiring all DNS clients to be members of the Windows Server 2008 domain. Secure dynamic updates require the server to use Active Directory with DNS. For this reason, you cannot take advantage of this security measure when DNS is installed on a stand-alone computer.
Restrict Zone Transfers to Specific Computers Running DNS
You can specify which servers can transfer zones. By default, any DNS server can transfer zone information to any other DNS server. However, you can restrict which servers can request zone transfer by modifying the properties of the DNS server.
Active Directory integrated zones replicates zones by using Active Directory replication, which keeps the zones more secure. Also, Active Directory automatically replicates to all other domain controllers in the domain. For this reason, you cannot restrict zone transfers for Active Directory Integrated zones.
However, in cases where zone information must traverse a public network, or where you cannot use AD DS domain controllers, you need to use another mechanism to limit zone transfers. One such option is to use IPsec for DNS server communication, which allows you to protect zone transfer information across the network.
Deploy Separate Server Computers for Internal and External DNS Resolution
Microsoft recommends hosting your internal DNS namespace on DNS servers located behind the firewall of your network. Manage an external-facing DNS presence using a DNS server in a perimeter network (also known as DMZ, demilitarized zone, or screened subnet).
To provide Internet name resolution for internal hosts, you can configure your internal DNS servers to use a forwarder to send external queries to external DNS servers. A forwarder is a DNS server on a network that forwards DNS queries for external DNS names to DNS servers outside of that network. You can also forward queries according to specific domain names using conditional forwarders. For more information about forwarders, see the Using forwarders page on Microsoft TechNet.
Note In many environments there is no need for internal computers to resolve Internet-based names. And in situations where such computers need to resolve Internet-based names, a proxy server can resolve Internet-based names for internal computers. For more information about this topic, see Configuring DNS Servers for ISA Server 2004.
Microsoft recommends configuring your DNS servers to resolve queries on their own, instead of forwarding queries to untrusted DNS servers. However, in some instances, such as resolving domain name spaces for Internet-based hosts, this may not be possible. For the DNS servers in your network that are exposed to the Internet, restrict DNS zone transfers to either DNS servers identified in the zone by name server (NS) resource records, or to specific DNS servers in your network.
Configure the Firewall to Protect the Internal DNS Namespace
To prevent anyone outside of your organization from obtaining information about your internal DNS namespace, configure your routers and firewalls to only allow only outbound DNS traffic between your internal DNS servers and external DNS servers in an extranet or on the Internet. This configuration allows your internal DNS servers to forward DNS queries outward, but prevents external requests from being sent to your internal DNS servers. If you are using Microsoft Internet Security and Acceleration (ISA) Server, you can use block filters to define the traffic allowed through the ISA Server.
If your proxy server has two network interface cards (NICs)—one for the intranet and one for the Internet—and the proxy server is also performing the DNS Server role, you can configure the server to only listen for DNS traffic on the IP address that the intranet NIC uses.
Enable Recursion to Only the Appropriate DNS Servers
Only servers that respond to DNS clients directly need to have recursion enabled. DNS servers use iterative queries to communicate. Microsoft recommends disabling recursion on the DNS servers in your environment that do not respond to DNS clients directly, and that are not configured to use forwarders.
As an alternative, you can deploy the following types of DNS servers:
Servers that host a specific set of names for other name servers to resolve.
Servers that resolve names by finding an authoritative server.
To enable or disable recursion, on the Advanced tab of the Properties page of the DNS server, select the Disable recursion check box. For more information about this topic, see "Configure a DNS server to use forwarders" in the Help and Support for Windows Server 2008.
Configure DNS to Ignore Non-Authoritative Resource Records
DNS servers should ignore resource records from servers that are not authoritative for those records. Such nonauthoritative resource record information is known as name pollution. You can protect your DNS from name pollution by ensuring that the Secure cache against pollution check box on the Advanced tab of the DNS server properties dialog box is selected, which is the default configuration. Also ensure that the Secure cache against pollution check box is selected on all DNS servers in your environment.
Configure Root Hints for the Internal DNS Namespace
If you have a private internal DNS namespace and the computers on your intranet do not need to communicate with the Internet, configure the root hints on your internal DNS servers to only point to DNS servers that host your internal root domain, not the DNS servers that host the Internet root domain.
|
