The Best Damn Windows Server 2003 Book Period- P74

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

37
lượt xem 2
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

The Best Damn Windows Server 2003 Book Period- P74:The latest incarnation of Microsoft’s server product,Windows Server 2003, brings many new features and improvements that make the network administrator’s job easier.This chapter will briefly summarize what’s new in 2003 and introduce you to the four members of the Windows Server 2003 family: the Web Edition, the Standard Edition, the Enterprise Edition, and the Datacenter Edition.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: The Best Damn Windows Server 2003 Book Period- P74

696 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 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 conﬁgured 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 conﬁgured 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 conﬁguration of WINS forward and reverse lookup records is performed on a per-zone basis.To conﬁgure WINS lookup records, go to the forward or reverse lookup zone for which you wish to conﬁgure WINS integration, go to the property pages for the zone, and click the WINS tab. Figure 20.13 shows the WINS tab property pages. Figure 20.13 WINS tab for a DNS Forward Zone Showing Advanced Conﬁguration Options There are a few things to note about the conﬁguration shown in Figure 20.13: I The two WINS servers are speciﬁed to improve fault tolerance in the event that the ﬁrst WINS server does not have the record or is unreachable.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 697 I The check box for Do not replicate this record is selected.The purpose of this conﬁg- 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. I Cache time-out and Lookup time-out values are conﬁgured 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 ﬁle: @ WINS LOCAL L2 C900 (192.168.100.20 192.168.179.3) The @ is a kind of shorthand used in DNS ﬁles 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 conﬁgure 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. Conﬁguring a WINS-R record in a reverse lookup zone is similar to conﬁguring a WINS record. Figure 20.14 shows the property pages of the WINS-R tab for a reverse lookup zone. Figure 20.14 The WINS-R Tab for a DNS Reverse Lookup Zone Showing Advanced Conﬁguration Options
698 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 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 identiﬁer. A WINS-R RR has a similar format to a WINS forward record in the zone data ﬁle: @ 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 conﬁgure 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 conﬁgure 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 conﬁguration to work in your environment, you need to populate the DNS sufﬁx search list on your DNS clients so that they will append the domain name of the WINS referral zone to unqualiﬁed queries (queries that do not use the FQDN). Figure 20.15 shows a possible conﬁguration of a DNS client to support WINS referral zones. Figure 20.15 DNS Client Sufﬁx Search List Conﬁgured to Support WINS Referral Zones
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 699 You should note that this conﬁguration overrides the default conﬁguration, which is to Append primary and connection speciﬁc sufﬁxes and Append parent sufﬁxes of the pri- mary DNS sufﬁx.The default conﬁguration allows a client to send a query for an unqualiﬁed host name based on the sufﬁx conﬁgured for it in the properties of My Computer and to devolve the domain name to the sufﬁx 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 ﬁrst append dev.teacteam.local to the name query. If the query fails, it will subse- quently devolve the sufﬁx to the parent domain and append tacteam.local to the name query. Overriding the default settings for the DNS sufﬁx 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 sufﬁx search list.You cannot use DHCP options to specify a custom DNS sufﬁx search list because Option 015 (DNS Domain name), which is used to specify the DNS domain name to append to unqualiﬁed queries, allows only one value. If you are imple- menting a custom DNS sufﬁx search list, you should keep this list as small as possible to reduce DNS trafﬁc 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-speciﬁc 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
700 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 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 conﬁgured 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 conﬁguration 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 trafﬁc. Figure 20.16 Conﬁguring a Primary Zone with a List of Secondaries Authorized to Do Zone Transfers Redirection A redirection attack occurs when an attacker is able to modify DNS records to redirect Web server or other trafﬁc to servers under the attacker’s control.This attack occurs when an attacker is able to write information to the zone ﬁle. 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 ﬁles 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 falsiﬁed.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.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 701 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 ﬂooded with trafﬁc 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 ﬂooded with recursive queries to the extent that they become unable to handle legitimate queries, or the DNS service is subjected to a buffer overﬂow attack speciﬁc to the DNS service. In an out-of-band DoS attack, the DNS server is the victim of an attack that is not speciﬁc to the DNS service, such as buffer overﬂow, 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 ﬁrewall 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 ﬁrewall access rules and packet ﬁltering should be conﬁgured to prevent any external
702 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy trafﬁc that is not related to the DNS service from reaching the DNS server. For example, a ﬁrewall that is in front of a DNS server in a DMZ should allow trafﬁc to reach the DNS server only on TCP and UDP port 53. Securing DNS Deployment In the preceding section, we identiﬁed 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 ﬁne-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 conﬁguration of the DNS servers them- selves, along with the implementation and conﬁguration of ﬁrewalls, 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 ﬁles 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 conﬁgura- tions of DNS are removed entirely.The effective security is none at all. As the Windows Server 2003 help ﬁles state, this kind of conﬁguration 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: I The DNS infrastructure is fully exposed to the Internet. I All the DNS servers in your network use standard DNS resolution. I All DNS servers are capable of performing queries to the Internet using root hints that point to the root servers for the Internet. I 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. I The default setting to prevent cache pollution is disabled on the DNS server. I Multihomed DNS servers (servers with multiple IP addresses) are conﬁgured to listen for DNS queries on all conﬁgured interfaces.
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 703 I All zones are conﬁgured to accept dynamic updates from DNS clients. I UDP and TCP port 53 are open on the ﬁrewall for both the source and destination address (that is, the ﬁrewall allows any DNS trafﬁc to traverse your ﬁrewall, 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 conﬁguration 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 ﬁles.The secu- rity features available through Active Directory-integrated zones are not employed here.The charac- teristics of medium-level security are as follows: I Exposure of your DNS infrastructure to the Internet is minimized. I Internal DNS servers are conﬁgured to use a limited list of forwarders when they cannot resolve names locally. I The default conﬁguration to limit zone transfers to DNS servers listed on the Name Servers tab is left in place. I In the case of multihomed DNS servers, the DNS servers are conﬁgured to listen on only speciﬁed IP addresses. I The default setting to prevent cache pollution is left in place. I No dynamic updates are allowed on any zones. I The ﬁrewall is conﬁgured to limit the trafﬁc traversing the ﬁrewall 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. I Only the external DNS servers in front of your ﬁrewall are conﬁgured with root hints to perform recursion. I 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
704 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy is an unlikely conﬁguration, 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: I No DNS communication is allowed between the Internet and internal DNS servers. I The internal DNS infrastructure deploys a private, internal root namespace and is authori- tative for all zones. I The root hints ﬁle on all DNS servers points to only the IP addresses of the internal DNS servers that are authoritative for the private root zone. I Zone transfers are limited to speciﬁc IP addresses, rather than just servers listed on the Name Server tab. I DNS servers are conﬁgured to listen on speciﬁc IP addresses. I All DNS servers run on domain controllers, with discretionary access control lists (DACLs) conﬁgured to allow only speciﬁc authorized individuals to perform administrative tasks on the DNS servers. I All DNS zones are conﬁgured as Active Directory-integrated zones, with DACLs conﬁg- ured to allow only speciﬁc authorized individuals to create, modify, or delete DNS zones. I All RRs stored in Active Directory-integrated zones have DACLs to allow only speciﬁc individuals to create, delete, or modify zone data. I No dynamic updates are allowed on the root and top-level domains. I 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 conﬁguration of ﬁrewalls 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: I Place all DNS servers in a DMZ or a perimeter network to ensure that access rules and packet ﬁltering on ﬁrewalls and routers tightly control source and destination addresses and
Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 705 ports. If possible, conﬁgure single-purpose DNS servers and allow trafﬁc on only UDP and TCP port 53 to reach these servers from the Internet. I Uninstall all unnecessary services from these servers, install current service packs, and harden the servers as much as possible. I 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. I Consider using a stealth primary server to update read-only secondary servers that are reg- istered with ICANN. I Allow zone transfers to only a speciﬁc set of IP addresses and consider using IPSec or VPN tunnels to enhance the security of zone transfer trafﬁc. I Do not enable dynamic updates on Internet-facing DNS servers. I Enable protection against cache pollution on Internet-facing DNS servers. I Disable recursion on Internet-facing servers. I Regularly monitor DNS logs and Event Viewer. Security Guidelines for an Internal DNS Infrastructure Conﬁdentiality, integrity, and availability of DNS data are primary considerations for an internal DNS infrastructure.The following are security guidelines to consider: I Consider using a separate, internal namespace to enhance security. I Do not allow external access from the Internet to your internal DNS servers. I Consider using a proxy server or a gateway to manage Internet DNS requests for internal clients. I Use Active Directory-integrated zones and allow only secure updates to these zones. I Specify and limit the servers that are able to receive zone transfers. I 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 conﬁguration fails. I 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 sufﬁcient 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