The Best Damn Windows Server 2003 Book Period- P74 pps

Interoperability with WINS In a mixed environment that includes downlevel clients, such as Windows NT 4 and Windows 95, you must continue to support NetBIOS name resolution.The primary mechanism for supporting NetBIOS name resolution in a segmented network is through WINS, which allows clients on dif- ferent subnets to register and resolve NetBIOS computer names on WINS servers. In some situa- tions, it might be necessary for UNIX clients, which do not support NetBIOS, to connect to Windows NT 4 computers. In order to resolve the Windows NT 4 computer names, the UNIX hosts must use DNS. However, if the Windows NT 4 server is configured with a static IP address, it will not be able to dynamically register its host name and IP address in DNS. One way to support DNS resolution for NetBIOS computer names is to integrate WINS with DNS through WINS forward and reverse lookup records. When a DNS zone is configured with WINS forward or reverse lookup records, it will consult a WINS server to resolve host names for records that are not present in its zone data. As a result of this integration with WINS and DNS, it is not necessary for the DNS adminis- trator to manually update the DNS zones with A records for NetBIOS computers that are incapable of updating DNS data on their own.The configuration of WINS forward and reverse lookup records is performed on a per-zone basis.To configure WINS lookup records, go to the forward or reverse lookup zone for which you wish to configure WINS integration, go to the property pages for the zone, and click the WINS tab. Figure 20.13 shows the WINS tab property pages. There are a few things to note about the configuration shown in Figure 20.13: ■ The two WINS servers are specified to improve fault tolerance in the event that the first WINS server does not have the record or is unreachable. 696 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.13 WINS tab for a DNS Forward Zone Showing Advanced Configuration Options 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 696 ■ The check box for Do not replicate this record is selected.The purpose of this config- uration is to prevent the replication of WINS records to BIND secondaries that might encounter data errors or fail to load the zone if they encounter the proprietary WINS record in the replicated data. ■ Cache time-out and Lookup time-out values are configured in the Advanced proper- ties of the WINS tab.The Cache time-out value indicates the length of time the DNS server will cache WINS records.The Lookup time-out value indicates the length of time the DNS server will wait for a response from a WINS server. The WINS forward record has the following format in the zone file: @ WINS LOCAL L2 C900 (192.168.100.20 192.168.179.3) The @ is a kind of shorthand used in DNS files to indicate the domain name, also known as the origin for the domain, in this case tacteam.local.The LOCAL label indicates that the record should not be sent to secondary servers as part of zone replication.The L2 label refers to the lookup timeout value of two seconds.The C900 label indicates the cache timeout value of 900 seconds, or 15 minutes. Both of these represent the default values. If you have a relatively static environment, it can be advantageous to configure a longer cache timeout value of perhaps an hour or more. WINS Reverse Lookup Records Reverse lookup zones are used to resolve IP addresses to host names, rather than host names to IP addresses, as is the case with forward lookup zones. WINS records are not indexed by IP address. Therefore, the WINS server cannot do a reverse lookup. Consequently, in a reverse lookup zone,A WINS-R RR will cause the DNS server to issue a remote adapter node status query using the nbt- stat command to determine the NetBIOS name associated with an IP address. Configuring a WINS-R record in a reverse lookup zone is similar to configuring a WINS record. Figure 20.14 shows the property pages of the WINS-R tab for a reverse lookup zone. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 697 Figure 20.14 The WINS-R Tab for a DNS Reverse Lookup Zone Showing Advanced Configuration Options 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 697 As with WINS forward lookup records, you have the option of preventing the WINS-R record from replicating to secondary servers.This will prevent problems with BIND secondaries encoun- tering this record in the zone data. Note that the values in the WINS-R record are different. Instead of specifying the IP address of a WINS server, you specify the domain name that should be appended to the reverse lookup query response. Also, in the Advanced property page, you can check a box to Submit DNS domain as NetBIOS scope.This option should be used only if you are using NetBIOS scopes on a subnet. When this option is selected, DNS uses the host name as a NetBIOS computer name to query the remote adapter node status, but submits the domain name as a NetBIOS scope identifier. A WINS-R RR has a similar format to a WINS forward record in the zone data file: @ WINSR LOCAL L2 C900 (tacteam.local. ) The @ indicates the origin of the domain, in this case the 100.168.192.in-addr.arpa reverse lookup domain.The tacteam.local. value is the domain name that will be appended to the host name. WINS Referral Zones In a mixed DNS infrastructure where you are not replicating WINS RRs to secondaries, clients will get varying answers to queries if they query a secondary zone for a WINS record.To get around this problem and to provide a means of organizing and distinguishing between WINS and DNS records, you should configure a WINS referral zone. A WINS referral zone is a delegated child subdomain of the parent domain.The WINS child domain contains only the SOA for the child domain and the WINS RRs. For example, if the parent domain is tacteam.local, you would configure a child domain named something like wins.tacteam.local. If you have a large network with multiple WINS servers for different locations, you could use multiple child domains, such as dallas.tacteam.local and edmonton.tacteam.local. However, in order for this configuration to work in your environment, you need to populate the DNS suffix search list on your DNS clients so that they will append the domain name of the WINS referral zone to unqualified queries (queries that do not use the FQDN). Figure 20.15 shows a possible configuration of a DNS client to support WINS referral zones. 698 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.15 DNS Client Suffix Search List Configured to Support WINS Referral Zones 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 698 You should note that this configuration overrides the default configuration, which is to Append primary and connection specific suffixes and Append parent suffixes of the pri- mary DNS suffix.The default configuration allows a client to send a query for an unqualified host name based on the suffix configured for it in the properties of My Computer and to devolve the domain name to the suffix of the parent domain. For example, if the client FQDN is host1.dev.research.tacteam.local, and it issues a recursive query to resolve the name PServer1 to an IP address, it will first append dev.teacteam.local to the name query. If the query fails, it will subse- quently devolve the suffix to the parent domain and append tacteam.local to the name query. Overriding the default settings for the DNS suffix search list increases administrative effort. However, you can reduce the administration of DNS client settings by using Group Policy settings to supply the clients with a DNS suffix search list.You cannot use DHCP options to specify a custom DNS suffix search list because Option 015 (DNS Domain name), which is used to specify the DNS domain name to append to unqualified queries, allows only one value. If you are imple- menting a custom DNS suffix search list, you should keep this list as small as possible to reduce DNS traffic on your network. DNS Security Issues Security measures that you can take to mitigate risk to your DNS infrastructure include those avail- able to standard DNS implementations, such as disabling recursion on Internet-facing servers, as well as those available to Windows Server 2003 DNS only, such as using Active Directory-integrated zones for zone transfers and secure dynamic updates. As with developing any security policy, it is important to understand the nature and likelihood of the threats involved to determine the cost to the organization if a particular threat is realized, and then compare this cost with that of implementing countermeasures to mitigate the risk to the orga- nization. Certain trade-offs need to be considered. For example, to completely secure your DNS infrastructure from attacks launched from the Internet, the only completely reliable countermeasure is to not have an Internet connection. Obviously, many organizations could not survive without Internet access, so this particular countermeasure is not appropriate. In the next section, we will take a look at common threats to a DNS infrastructure.Then we will review the standard and Windows-specific countermeasures you can take to mitigate the risk from these threats. Common DNS Threats An unsecured DNS infrastructure is vulnerable to a number of common threats.These include foot- printing, redirection, and DoS attacks.These threats are described in the following sections. Footprinting Footprinting is the process whereby attackers gain information about your internal DNS RRs and are subsequently able to use this information to infer the identity and purpose of servers on your internal network. Footprinting often occurs when zone transfers are not secured and the attacker is able to per- form a name dump from authoritative servers using the nslookup command with the ls option or Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 699 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 699 the dig command with the afxr option—both of these commands initiate a zone transfer from the target domain. To mitigate the risk from footprinting, it is important to ensure that zone transfers are secured. At the very least, zone transfers should be allowed to only a predetermined list of IP addresses that can be configured in the properties of the primary zone on the DNS server, as shown in Figure 20.16.You should also remember to secure your secondary name servers from unauthorized zone transfers, not just your primary server. Keep in mind that a secondary name server can also transfer zone information. However, even this configuration is vulnerable. For maximum security of zone transfers, you should ensure that zone transfers occur only within Active Directory-integrated zones. If you must transfer zone information over the Internet, you should also consider the use of VPN tunnels or IPSec to secure this traffic. Redirection A redirection attack occurs when an attacker is able to modify DNS records to redirect Web server or other traffic to servers under the attacker’s control.This attack occurs when an attacker is able to write information to the zone file. For example, this might happen if dynamic updates are enabled on a zone that is located on an Internet-facing DNS server. For this reason, it is always prudent to disable dynamic updates on zone files that are accessible to clients on the Internet. Another common cause of redirection attacks is cache pollution (also called cache poisoning). Cache pollution can occur when a DNS server queries another DNS server and receives a reply from the queried DNS server that is outside the domain namespace in the original query. Unless counter- measures are taken, the DNS server will store this referral information in its cache, even though it did not originally request the information. DNS servers are vulnerable to cache pollution if an answer to a DNS query can be falsified.The consequences of cache pollution can be severe. Imagine what might happen if the poisoned cache of a DNS server redirected users to bogus Web site that contained malicious code designed to install Trojan viruses on client computers. 700 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.16 Configuring a Primary Zone with a List of Secondaries Authorized to Do Zone Transfers 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 700 When cache pollution protection is enabled, the DNS server will discard from its cache the records it receives in response to queries if those responses contain information unrelated to the domain subtree of the requested resource. In our example, if protection against cache pollution is enabled, the DNS server will cache the MX record for the mail server in sampledomain.com, but will not cache the record for the a.root-servers.net, since it is not part of the queried domain subtree. Cache pollution protection is a DNS server-wide setting (Secure cache against pollution) and is enabled by default on Windows Server 2003 DNS servers (see Figure 20.11 earlier in this chapter). Another way to mitigate the risk of cache pollution is to disable recursion on the DNS server. An attacker can use recursion to query the DNS server for resources in the attacker’s domain.The recursive name server is then forced to query DNS servers in the attacker’s domain that might attempt to pollute the cache of the recursive server. Denial of Service Attacks A Denial of Service (DoS) attack occurs when a DNS server is deliberately flooded with traffic to the extent that it cannot respond to legitimate requests. DoS attacks on a DNS can be in-band on UDP and TCP port 53 (the ports used for DNS queries and zone transfers), or they can be out-of-band.In the case of an in-band attack, DNS servers are flooded with recursive queries to the extent that they become unable to handle legitimate queries, or the DNS service is subjected to a buffer overflow attack specific to the DNS service. In an out-of-band DoS attack, the DNS server is the victim of an attack that is not specific to the DNS service, such as buffer overflow, SYN, and Smurf attacks. When a DoS attack occurs on a DNS server, mail servers and Web servers become unavailable as well, because the host names for these servers cannot be resolved to IP addresses. One approach to mitigate the risk of DoS attacks against your DNS server is to eliminate single points of failure by having multiple DNS servers that are located on separate subnets served by sepa- rate routers.Also, you can arrange to have secondary servers hosted offsite by a third party, such as your ISP. To provide further protection against in-band DoS attacks, you can disable recursion on Internet-facing DNS servers. Recursive queries take a relatively long time to process, making a DNS server that performs recursion vulnerable to a DoS attack that involves sending a large number of recursive queries to the DNS server. When you disable recursion on a DNS server, it will not respond to recursive queries issued by DNS clients. DNS clients will not be able to use this server to resolve names on the Internet. However, the DNS server will still respond to iterative queries issued by other DNS servers.This means that it will respond to queries for resources in zones for which it authoritative. Recursion is a server-wide DNS setting and is enabled by default. (You can also disable recur- sion for forwarding servers on a per-domain basis.) If you disable recursion for the entire DNS server, you will not be able to use that DNS server as a forwarder.You can see the Disable recur- sion (also disables forwarders) option in Figure 20.11, shown earlier in the chapter. On internal DNS servers, it is often not desirable to disable recursion. In this case, these DNS servers need to be protected by firewall access rules that prevent their use by DNS clients on the Internet. To provide further protection against both in-band and out-of-band DoS attacks, it is important to ensure that you apply the latest service packs and harden the servers as much as possible. In addi- tion, your firewall access rules and packet filtering should be configured to prevent any external Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 701 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 701 traffic that is not related to the DNS service from reaching the DNS server. For example, a firewall that is in front of a DNS server in a DMZ should allow traffic to reach the DNS server only on TCP and UDP port 53. Securing DNS Deployment In the preceding section, we identified some of the common threats to the DNS infrastructure and provided a number of countermeasures, such as securing zone transfers, disabling recursion, and enabling protection against cache pollution. However, securing a DNS infrastructure requires more than just fine-tuning settings of the individual DNS servers. Securing the DNS infrastructure starts with the design and implementation of your DNS namespace, and continues with the implementation and configuration of the DNS servers them- selves, along with the implementation and configuration of firewalls, routers, and other network devices that can serve to protect individual servers and the network itself. It is possible, for example, to use a private root zone on your intranet and tightly control DNS query access to the Internet. Using a private root in combination with a DNS security policy that restricts DNS queries to the Internet can result in enhanced security for your organization. DNS Security Levels To assist in the secure deployment of a DNS infrastructure, Microsoft has published guidelines on its Web site and within the Windows Server 2003 help files that categorize three basic levels of DNS security: low level, medium level, and high level. In the following sections, we will discuss each level in more detail. In considering these models, you should assume that they represent a set of ideal guidelines for the purposes of conceptualization and example. Many organizations do not want to slavishly abide by the models in their purest form. Low-level DNS Security The low level of DNS security is precisely that: low. In fact, some of the default security configura- tions of DNS are removed entirely.The effective security is none at all.As the Windows Server 2003 help files state, this kind of configuration should be used only when there is no concern for the integrity of your DNS data or there is no threat that the DNS data on a private network is acces- sible from the Internet.The characteristics of low-level security are as follows: ■ The DNS infrastructure is fully exposed to the Internet. ■ All the DNS servers in your network use standard DNS resolution. ■ All DNS servers are capable of performing queries to the Internet using root hints that point to the root servers for the Internet. ■ Zone transfers are allowed to any server, which represents a removal of the default setting to allow zone transfers only to servers listed in the Name Servers tab. ■ The default setting to prevent cache pollution is disabled on the DNS server. ■ Multihomed DNS servers (servers with multiple IP addresses) are configured to listen for DNS queries on all configured interfaces. 702 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 702 ■ All zones are configured to accept dynamic updates from DNS clients. ■ UDP and TCP port 53 are open on the firewall for both the source and destination address (that is, the firewall allows any DNS traffic to traverse your firewall, regardless of whether it is initiated by an external or an internal host). Some organizations may have such a deployment; however, it would be extremely unwise to deploy something like this yourself.Turning off cache pollution protection, in particular, exposes your DNS infrastructure to an unacceptable level of risk, relative to the cost of leaving the default configuration enabled. Medium-level DNS Security The medium level of DNS security takes advantage of the countermeasures that are available in a DNS infrastructure where zone data is stored in standard primary or secondary zone files.The secu- rity features available through Active Directory-integrated zones are not employed here.The charac- teristics of medium-level security are as follows: ■ Exposure of your DNS infrastructure to the Internet is minimized. ■ Internal DNS servers are configured to use a limited list of forwarders when they cannot resolve names locally. ■ The default configuration to limit zone transfers to DNS servers listed on the Name Servers tab is left in place. ■ In the case of multihomed DNS servers, the DNS servers are configured to listen on only specified IP addresses. ■ The default setting to prevent cache pollution is left in place. ■ No dynamic updates are allowed on any zones. ■ The firewall is configured to limit the traffic traversing the firewall to a limited set of source and destination addresses. Only the external DNS servers under your control are allowed to communicate with internal DNS servers. ■ Only the external DNS servers in front of your firewall are configured with root hints to perform recursion. ■ All name resolution required by a host on your internal network is performed by proxy servers or gateways. This represents a more reasonable and prudent approach to mitigating risk to the DNS infras- tructure than is offered by the low level, with a low cost of implementation relative to the advan- tages gained. High-level DNS Security A high-level security policy starts with the medium-level security policy and furthers enhances security by leveraging the security available with Active Directory-integrated zones. Furthermore, the high-level security policy assumes that there is no DNS communication with the Internet.This Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 703 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 703 is an unlikely configuration, but something like it might be implemented by organizations that have strict security requirements, and the risk of connectivity to the Internet is deemed to be too great. The characteristics of a high-level security policy are as follows: ■ No DNS communication is allowed between the Internet and internal DNS servers. ■ The internal DNS infrastructure deploys a private, internal root namespace and is authori- tative for all zones. ■ The root hints file on all DNS servers points to only the IP addresses of the internal DNS servers that are authoritative for the private root zone. ■ Zone transfers are limited to specific IP addresses, rather than just servers listed on the Name Server tab. ■ DNS servers are configured to listen on specific IP addresses. ■ All DNS servers run on domain controllers, with discretionary access control lists (DACLs) configured to allow only specific authorized individuals to perform administrative tasks on the DNS servers. ■ All DNS zones are configured as Active Directory-integrated zones, with DACLs config- ured to allow only specific authorized individuals to create, modify, or delete DNS zones. ■ All RRs stored in Active Directory-integrated zones have DACLs to allow only specific individuals to create, delete, or modify zone data. ■ No dynamic updates are allowed on the root and top-level domains. ■ Only secure dynamic updates are allowed on the child domains. For many organizations, none of these models will be adequate.The cost, for example, of not allowing DNS communication with the Internet, and hence connectivity, might be too great.The reality is that many organizations will want to develop and deploy a DNS security model that is hybrid of the medium-level and high-level security models. General DNS Security Guidelines In planning for the security of your DNS infrastructure, you will want to take into account the design of your DNS namespace, the number and type of DNS servers and zones you plan to deploy, and whether the DNS servers will be serving internal or external clients.You will also want to take into account the security already present or needed in your current infrastructure, such as the loca- tion, type, and configuration of firewalls that protect your network. Security Guidelines for an External DNS Infrastructure Integrity and availability of DNS data are primary considerations for an external DNS infrastruc- ture, and your design should be informed by these considerations: ■ Place all DNS servers in a DMZ or a perimeter network to ensure that access rules and packet filtering on firewalls and routers tightly control source and destination addresses and 704 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 704 ports. If possible, configure single-purpose DNS servers and allow traffic on only UDP and TCP port 53 to reach these servers from the Internet. ■ Uninstall all unnecessary services from these servers, install current service packs, and harden the servers as much as possible. ■ Eliminate single points of failure by hosting DNS servers on different subnets served by different routers. Consider hosting a secondary server at your ISP, for example.This will help mitigate the risk of DoS attacks. ■ Consider using a stealth primary server to update read-only secondary servers that are reg- istered with ICANN. ■ Allow zone transfers to only a specific set of IP addresses and consider using IPSec or VPN tunnels to enhance the security of zone transfer traffic. ■ Do not enable dynamic updates on Internet-facing DNS servers. ■ Enable protection against cache pollution on Internet-facing DNS servers. ■ Disable recursion on Internet-facing servers. ■ Regularly monitor DNS logs and Event Viewer. Security Guidelines for an Internal DNS Infrastructure Confidentiality, integrity, and availability of DNS data are primary considerations for an internal DNS infrastructure.The following are security guidelines to consider: ■ Consider using a separate, internal namespace to enhance security. ■ Do not allow external access from the Internet to your internal DNS servers. ■ Consider using a proxy server or a gateway to manage Internet DNS requests for internal clients. ■ Use Active Directory-integrated zones and allow only secure updates to these zones. ■ Specify and limit the servers that are able to receive zone transfers. ■ Eliminate single points of failure and consider how internal DNS clients will resolve names in the event that the primary DNS server in their TCP/IP configuration fails. ■ Consider that delegating authority of child domains can involve a security trade-off if dif- ferent administrators are responsible for the authoritative DNS servers. Monitoring DNS Servers An important task in maintaining a DNS environment is monitoring the DNS servers to ensure that they are resolving names and IP addresses properly, and to ensure that they have sufficient resources to handle their workload. Windows Server 2003 and the Windows Server 2003 DNS service pro- vide a number of tools for monitoring DNS servers.These tools include the Monitoring tab on the Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 705 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 705 . ensure that they have sufficient resources to handle their workload. Windows Server 2003 and the Windows Server 2003 DNS service pro- vide a number of tools for monitoring DNS servers.These tools. recursion on the DNS server. An attacker can use recursion to query the DNS server for resources in the attacker’s domain .The recursive name server is then forced to query DNS servers in the attacker’s. pollution is enabled, the DNS server will cache the MX record for the mail server in sampledomain.com, but will not cache the record for the a.root-servers.net, since it is not part of the queried domain