mcse exam 70-293 planning and maintaining a windows server 2003 network infrastructure phần 5 doc

One way to mitigate the risk of using BIND servers for dynamic updates is to create subdomains to host the AD DNS data. For example, if the domain name is mycompany.com, you can create a separate zone called ad.mycompany.com.To create this zone, you must issue a zone statement specifying the zone name and the location of the files in the named.conf file on the BIND server. However, Microsoft Active Directory-inte- grated zones still provide a much higher level of security. For this reason, it is preferable to use Active Directory-integrated zones. BIND administrators can delegate authority to a subdomain hosted in Active Directory-integrated zones and configure BIND servers as sec- ondaries to this zone to enhance fault tolerance and availability. Split DNS Configuration Many organizations want to use the same name on their internal network as they do on their publicly available external network. For example, suppose that a company’s name is mycompany.com and its Web server and e-mail servers located in the DMZ use this domain name in their FQDN.The company also wants to use this name for its AD domain on the internal network.This situation creates a number of challenges. Foremost among these is security of internal DNS records. It is not desirable to expose internal host names and IP addresses to external clients, even if these hosts cannot be reached by external clients because of restrictions on the firewall. Also, it is not a recommended DNS best practice to include any record in a zone file for a host that is unreachable. At a minimum, a properly secured DNS configuration requires that the DNS records for the internal namespace be accessible to internal clients only and not accessible to external clients. Furthermore, internal clients should be able to resolve queries for external hosts on the Internet so that e-mail servers are able to send mail to external hosts and users are able to connect to the Internet. Finally, the bastion hosts (computers that can communi- cate with both the Internet and the intranet) that are responsible for delivering e-mail to the internal network should be able to successfully locate and communicate with the appropriate internal servers through the firewall. This situation implies the use of a split DNS configuration. A split DNS configuration requires two sets of name servers for the same namespace. For example, suppose that a set of DNS servers in the DMZ contains records for the hosts, such as the A records for the Web servers, the MX and A records for the mail servers, and the NS and A records for the DNS servers in the DMZ. Another set of authoritative DNS servers that contains records for internal hosts is configured in the internal network for the same namespace.The DNS servers configured on the internal network are not accessible to external clients for name resolution. Internal clients should also be able to gain access to the company’s publicly available Web servers. Depending on the configuration of the infrastructure, this can create some challenges. For example, if the company is using ISA Server as its firewall and making a Web server in its DMZ available to external clients via Web server publishing rules, internal clients might not be able to connect to the internal Web server if the internal DNS uses an A record for the Web server that points to an external address. Supporting this kind of con- www.syngress.com 398 Chapter 6 • Planning, Implementing, and Maintaining a Name Resolution Strategy 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 398 figuration requires that the internal DNS servers use A records that point to the internal IP address of the Web server and not the external IP address that is used to publish the Web server for external clients. In other words, the A records for the Web server will differ in the internal and external DNS servers that are authoritative for the zone. Figure 6.16 shows a possible configuration for a split DNS to allow internal clients to connect to the publicly available Web server. NOTE Supporting a split DNS configuration involves more effort on the part of the DNS administrator. For example, the DNS administrator might need to manually update separate DNS servers that are authoritative for the same zone. In addition, the DNS administrator must ensure that no records for the internal network appear in the publicly available DNS server. 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 mech- anism for supporting NetBIOS name resolution in a segmented network is through WINS, which allows clients on different subnets to register and resolve NetBIOS computer names on WINS servers. In some situations, it might be necessary for UNIX clients, which do not www.syngress.com Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 399 Figure 6.16 Split DNS Configuration to Allow Internal Clients to Connect to the Web Server in the DMZ DMZ 192.168.1.0/24 ISA Server ISA Server External DNS for tacteam.net A record for www.tacteam.net = 2.2.2.1 Internal Network: 192.168.2.0/24 Internal DNS for tacteam.net A record for www.tacteam.net = 192.168.1.5 www.tacteam.net 192.168.1.5 Internet 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 399 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 dynami- cally 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. For example, suppose that a UNIX host needs to send a print a job to Windows NT 4 server named PServer1.tacteam.local.The UNIX host sends a query for PServer1.tacteam.local to the DNS server authoritative for the tacteam.local zone.The DNS server does not find a record for PServer1 in its zone data, so it performs a WINS lookup to the IP address of the server listed in its WINS forward lookup record.After receiving a reply from the WINS server, it sends the information to the UNIX host.The DNS server that performs the NetBIOS resolution will keep the record in its cache for a configurable interval (the default is 15 minutes), so that if it receives a query for the same name within the interval, it can resolve the name from its cache. As a result of this integration with WINS and DNS, it is not necessary for the DNS administrator 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 6.17 shows the WINS tab property pages. www.syngress.com 400 Chapter 6 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 6.17 WINS tab for a DNS Forward Zone Showing Advanced Configuration Options 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 400 There are a few things to note about the configuration shown in Figure 6.17: ■ 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. ■ The check box for Do not replicate this record is selected.The purpose of this configuration 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 properties 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 nbtstat 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 6.18 shows the property pages of the WINS-R tab for a reverse lookup zone. www.syngress.com Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 401 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 401 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 sec- ondaries encountering 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. NOTE NetBIOS scopes are used in certain, rare circumstances when it is necessary to iso- late legacy computers from communicating with other groups of computers on the same subnet. 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. www.syngress.com 402 Chapter 6 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 6.18 The WINS-R Tab for a DNS Reverse Lookup Zone Showing Advanced Configuration Options 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 402 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 environ- ment, 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 6.19 shows a possible configuration of a DNS client to support WINS referral zones. 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 primary 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 www.syngress.com Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 403 Figure 6.19 DNS Client Suffix Search List Configured to Support WINS Referral Zones 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 403 to the name query. If the query fails, it will subsequently 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 implementing 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 should always be a primary consideration in the deployment of any network ser- vice.This is also true of the implementation of a DNS infrastructure. DNS is an open stan- dard that is used throughout the Internet. Over the years, a number of exploits have appeared that can compromise an unsecured DNS infrastructure.When DNS is compro- mised, hackers can learn information about your internal network that they can subse- quently use to launch other attacks. Furthermore, if a DNS server is vulnerable to DoS attacks, hackers can prevent name resolution from occurring for critical servers such as your Web and mail servers. Finally, an unsecured DNS server can be compromised with the addition of false records that redirect traffic to bogus Web and mail servers. Security measures that you can take to mitigate risk to your DNS infrastructure include those available 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 organization. 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 counter- measure 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 footprinting, redirection, and DoS attacks.These threats are described in the fol- lowing sections. www.syngress.com 404 Chapter 6 • Planning, Implementing, and Maintaining a Name Resolution Strategy EXAM 70-293 OBJECTIVE 2.7.4 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 404 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. Attackers can use this information in a variety of ways to compromise the organization. For example, an attacker can use this information to launch data modification attacks using spoofed IP addresses to compromise critical servers and data on the internal network.Another possibility is that, because host names are often informative, the attacker could use this information to infer confidential information about the internal operations of the company, such as products that are under development. Footprinting often occurs when zone transfers are not secured and the attacker is able to perform a name dump from authoritative servers using the nslookup command with the ls option or 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 6.20.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. www.syngress.com Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 405 Figure 6.20 Configuring a Primary Zone with a List of Secondaries Authorized to Do Zone Transfers 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 405 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 acces- sible 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 countermeasures are taken, the DNS server will store this referral information in its cache, even though it did not originally request the information. For example, suppose that your DNS server issues a query for the MX record in the sampledo- main.com domain.The authoritative DNS for the sampledomain.com server responds with the MX record, but it also replies with a bogus record for a.root-servers.net, listing its own IP address for the A record.Your DNS server now has a bogus record for a root-level DNS server in its cache. DNS servers are vulnerable to cache pollution if an answer to a DNS query can be fal- sified.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 mali- cious code designed to install Trojan viruses on client computers. 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 unre- lated 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 set- ting (Secure cache against pollution) and is enabled by default on Windows Server 2003 DNS servers (see Figure 6.15 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. DoS Attacks A 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- www.syngress.com 406 Chapter 6 • Planning, Implementing, and Maintaining a Name Resolution Strategy 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 406 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 elimi- nate single points of failure by having multiple DNS servers that are located on separate subnets served by separate routers. Also, you can arrange to have secondary servers hosted offsite by a third party, such as your ISP. NOTE Recently, Microsoft’s own DNS servers were the victims of a DoS attack that made a number of Microsoft Web sites inaccessible. The reason that Microsoft’s DNS servers were vulnerable is that all of them were placed in the same physical loca- tion behind a single router, hence exposing a single point of failure. 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 recursion 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 recursion (also disables forwarders) option in Figure 6.15, 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 addition, your firewall access rules and packet filtering should be configured to prevent any external 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 infrastruc- ture and provided a number of countermeasures such as securing zone transfers, disabling www.syngress.com Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 407 255_70_293_ch06.qxd 9/10/03 5:42 PM Page 407 [...]... to use the same namespace for the intranet and Internet, or a split DNS namespace for the intranet and Internet If your internal namespace includes a private root zone, you can further enhance the security of the DNS infrastructure Security Guidelines for an External DNS Infrastructure Integrity and availability of DNS data are primary considerations for an external DNS infrastructure, and your design... www.syngress.com 255 _70_293_ch06.qxd 9/10/03 5: 42 PM Page 429 Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 nerships that can be configured between WINS servers: push/pull (also known as full), pushonly, and pull-only (also known as limited).You can set up a replication partnership manually or implement it automatically Automatic Partner Configuration Automatic partner configuration... 9/10/03 5: 42 PM Page 432 Chapter 6 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 6.26 Manually Starting Push Notification In certain rare situations, it might be desirable to use a push-only replication partnership for one-way replication, for example, from a head office to a branch office For example, suppose that WINS -A in the head office configures WINS-B in the branch office as... database For example, a name release update will not propagate as quickly as a name registration update because it is more common for a name-to-IP address mapping to be reused by the same computer, even in an environment that uses DHCP Since this kind of update is not as urgent as a new name registration, the WINS server provides it with a greater latency period for replication Along with these factors,... Servers Windows Server 2003 provides three command-line utilities for maintaining and monitoring DNS servers: www.syngress.com 255 _70_293_ch06.qxd 9/10/03 5: 42 PM Page 417 Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 I NSLookup This is a standard tool used for monitoring and troubleshooting DNS servers It provides a means to obtain detailed results for queries performed against... running on a single-processor Pentium II with 128MB of RAM and a standard IDE hard drive.The server was able to process approximately 300 registrations per second and 350 queries per second.WINS is a disk- and CPU-intensive service, and these estimates will vary depending on the hardware that is in place A dual-processor CPU will increase WINS performance by up to 25 percent Placing the WINS database on... be safe to block inbound traffic on TCP port 25 to prevent zone transfers from all but authorized 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. .. 255 _70_293_ch06.qxd 408 9/10/03 5: 42 PM Page 408 Chapter 6 • Planning, Implementing, and Maintaining a Name Resolution Strategy 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. .. Confidentiality, 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 www.syngress.com 411 255 _70_293_ch06.qxd 5: 42 PM Page 412 Chapter 6 • Planning, Implementing, and. .. the server service, and [1Ch] for the domain name I IP Address The IP address for the registered name I State The state of the registration, such as Active, Released, or Tombstoned www.syngress.com 255 _70_293_ch06.qxd 9/10/03 5: 42 PM Page 423 Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 I Static Indicates if record is a static mapping (column entry marked with an x) . 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 addition, your firewall access. security takes advantage of the countermeasures that are avail- able in a DNS infrastructure where zone data is stored in standard primary or secondary zone files.The security features available through. resolution infrastructure that ensures clients can always resolve NetBIOS names in a fault-tolerant and www.syngress.com Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 6 417 EXAM 70-293 OBJECTIVE 2.8 255 _70_293_ch06.qxd