Both the DNS and the WINS service, by their nature, contain information about the organization s infrastructure. Failure to secure either of these two services could compromise your infrastructure by allowing an attacker to discover information about your company or by allowing them to create an attack that will cripple the name resolution services, thus stopping your clients from being able to perform their functions.
As with any network service, you need to identify potential security threats. The buzz around Microsoft recently has been their implementation of security at all levels of their products. This security initiative is a good thing for administrators because now the software giant is trying to plug the holes that attackers like to take advantage of, which makes the administrator s job that much easier.
Although many key features of Windows Server 2003 have taken on a secure-by-default posture , DNS is not one. Some of the settings are turned on by default, such as the Secure Cache Against Pollution setting, but due to the open nature of DNS, you will have to perform some tasks to lock down your DNS infrastructure.
DNS attacks come in the following forms:
Data Modification Data modification is also known as IP spoofing. An attacker modifies the IP address in IP packets that are sent to a DNS server. Because the IP address appears valid, the data is accepted on the network and passed to the DNS server where its attack can be implemented. If this type of attack is successful, data can be modified or damaged, a denial-of-service (DoS) attack can be implemented, or the attacker can implement the first step of a redirection.
Denial-of-Service Attacks When an attacker attempts a denial-of-service (DoS) attack , the DNS server is inundated with queries. The attacker is hoping that the DNS server will not be able to handle all of them. When the server cannot handle all of the requests, valid requests may not be able to be processed and the services that rely on DNS for name resolution will not be able to function correctly.
Footprinting Footprinting is the process of capturing enough DNS data to build a network map that includes IP addresses, computer names, and domain names. Once this data is collected, the attacker can try to determine which computers are running services within the infrastructure and target attacks at vital services. One of the easiest methods of footprinting a network is for an attacker to request a zone transfer from a DNS server. If the DNS server is not secured and allows the attacker to successfully obtain the zone file, the data could point the attacker directly to important systems. The SRV records that are contained in the zone data will give the attacker the names of the domain controllers and global catalog servers, and the address records will supply the attacker with the IP addresses.
Redirection Clients rely on the data from a DNS server to be accurate. When a client receives a response to a query, they use the information in the response to locate the correct server for which they are trying to connect. If an attacker is able to change the data in a DNS server, the record could direct the attacker to a server that is under the attacker s control. If the attacker successfully changes the data and the client is unaware of the change, the client has been the victim of a redirection attack.
If you want to protect yourself from any of these attacks, you need to identify which systems are susceptible to each type of attack and determine what level of protection you will apply. The level of protection you decide upon will become your DNS security policy. Although this is not a policy that you apply to a system as you would the local security policy or a Group Policy object, it is a written policy that you need to follow for each of the DNS servers. A DNS security policy identifies the level of protection you need to apply to your DNS server infrastructure to keep it protected from attacks. You could have multiple DNS security policies that identify the security that will be applied to DNS servers that are used internally and those that are accessible from the Internet. Microsoft has identified three levels of DNS security, appropriately named low-level, mid-level, and high-level.
The low-level DNS security policy is not concerned about attackers gathering data about your internal network or attacks that could damage the DNS infrastructure. Organizations that do not have any type of connectivity to outside networks, the Internet especially , can take advantage of this policy. However, if you are at all concerned about the integrity of your DNS data and DNS infrastructure, and external users have access to your network, you should not use this policy level.
When using the low-level DNS security policy, you allow all of the servers to perform standard DNS name resolution. This means that the DNS servers listen for queries on all of the IP addresses bound to each network card, will respond to queries from all clients, and are configured to point to the root servers on the Internet for all external name resolution. At the same time, zone transfers are allowed to any server that requests the transfer. This policy level does not take advantage of the Secure Cache Against Pollution setting and allows dynamic updates for all zones. Your infrastructure will also allow port 53 to remain open on the firewall so that all UDP and TCP traffic bound for the DNS server is allowed through.
The mid-level DNS security policy increases the level of security from what is allowed with the low-level DNS security policy. The mid-level DNS security policy allows an administrator who is running third-party DNS servers or DNS servers that are not domain controllers to have more control over their DNS infrastructure. Although this policy level does give you more control over your DNS environment, it still leaves a few security holes. You may want to implement this policy level if you still want to maintain some level of communication with the Internet.
Standard DNS resolution is not allowed at this policy level. Instead, the DNS servers are configured to use forwarders to assist in resolving hostnames. Conditional forwarding can be designed to allow the queries to be sent to the DNS servers that are name servers for specific domains. Zone transfers are not allowed to all servers, only those that are name servers for the domain. Only internal clients are allowed to send queries to the internal DNS servers because the DNS servers are configured to listen for queries only on specific IP addresses. To control the data that is within the DNS server cache and to protect the clients from redirection attacks, the Secure Cache Against Pollution setting is enabled on all zones.
The network infrastructure is designed to control access to the DNS infrastructure by placing servers that can perform Internet resolution within a perimeter network. The internal DNS servers are configured with forwarders that will forward queries to the DNS servers in the perimeter network that have root hints configured. The firewall is configured with rules to control the DNS traffic so that only the DNS servers are allowed to communicate with one another through the firewall. Client access to the Internet is controlled by using proxy servers.
The high-level DNS security policy is the extreme lock-down policy. When using this policy, access to the Internet is extremely limited. You may have users who need to access websites and e-mail that needs to be routed, but other means of performing those tasks are configured instead of allowing the DNS infrastructure to be visible.
A typical high-level DNS security policy does not allow any type of Internet access through the internal DNS server. The DNS servers are configured to have their own DNS root namespace so that they can provide resolution for internal clients to internal resources. All DNS servers are configured to listen for queries on specific IP addresses. To protect from any type of redirection attacks, the Secure Cache Against Pollution setting will remain on.
This policy level controls who is allowed to configure and modify the DNS server and the zones. All zones at this policy level are Active Directory “enabled so that the data is not stored as a file, it is secured within the Active Directory database. Because the DNS zone is stored in Active Directory, permissions can be set that will control which users have the ability to create, delete, or modify DNS zones and records. Rights can be assigned to control who has the ability to administer the DNS server also.
If clients do need to have access to websites, a proxy server is configured to control Internet access. Placing the proxy server in the perimeter network will allow it to use an external DNS server for resolution. For e-mail, the internal e-mail servers will use internal DNS to route messages within the organization, any external e-mail can be forwarded to a smart host within the perimeter that is configured to resolve Internet addresses from an external DNS server. The firewalls can be configured to limit traffic only from specified servers over specific ports.
Once you have chosen the policy level that you want to use for you DNS infrastructure, your need to determine how you will design the security for both internal and external DNS servers.
Because the external DNS servers are exposed to the Internet, you will want to pay special attention to them, especially because you will want to secure them as much as possible. But to allow them to perform the functions that they are intended to perform, they will need to have lighter security settings in some cases. Internal servers could be placed under a lighter policy, but make sure that they are properly protected from outside influence.
If you have to host DNS servers that are exposed to the Internet, make sure they reside within the perimeter network. If they are on the internal network, you will have to open up ports on the firewall that will allow unwanted traffic into your infrastructure. If you have servers within the perimeter network that need to resolve hostnames for internal resources, plan on deploying multiple DNS servers, one for public information and another that hosts private information. You can allow Internet resolution to the public DNS server so that your web servers and SMTP mail servers can be found by external users, and have another DNS server that will host internal DNS records so that the servers residing in the perimeter can resolve internal names of servers that they need to interact with. Figure 10.7 illustrates a perimeter network that hosts two DNS servers and the servers that provide functionality for external users.
Always make sure that you have redundancy built into your design. If you do not, you run the risk of alienating users when they cannot resolve hostnames for your organization. You can host multiple DNS servers that share the same zone information, or you could have an ISP act as your backup should your DNS server fail. In either case, if you are the recipient of a DoS attack, you will have additional servers to take over should one become unavailable. And remember, if you want to your data to be available at all times, you should have redundant hardware.
Secure communication between DNS servers that reside within the perimeter network and those that reside in the internal network should be maintained . Most of the DNS servers within the perimeter network will not be Active Directory “enabled; the zone transfers between DNS servers should use IPSec or a VPN technology to encrypt the data. Using an encryption method keeps attackers from intercepting packets and footprinting the internal network. This also allows you to open IPSec or VPN ports on the firewall instead of UPD and TCP port 53. Once you have protected the zone transfer traffic, don t forget to restrict the servers to which zone transfers are allowed. You can allow transfers to all name servers, but the more secure method is to control by specific IP addresses instead.
Tip | If you are allowing zone transfers to DNS servers that reside within a perimeter network, make sure that none of the SRV records that are used for Active Directory are included within the zone data. |
Internal DNS servers are critical to the operation of your network. Without them, Active Directory will become useless. As with any critical resource, you should have redundancy built in so that the failure of a single component will not cause the entire infrastructure, or even a portion of the infrastructure, to become unavailable. All servers and clients should be configured to use multiple DNS servers for name resolution. Also review the network infrastructure to make sure that the devices that interconnect the clients and servers can withstand the loss of a service.
You should plan for all of your zones within the internal network to be made Active Directory “integrated as soon as possible. This will alleviate the need for zone transfers; all of the updates will be sent by Active Directory replication. Using Active Directory “integrated zones will also allow you to enforce secure dynamic updates, which give you the ability to control the clients that can update resource records within your zone.
With either of the external or internal DNS servers, you should make it a point to continually monitor the DNS logs and the Event Viewer for DNS- related exceptions. Proactive management can aid you when you are determining if your DNS infrastructure is failing or compromised.
As with the DNS service, you should make sure that the WINS servers are secure. For the most part, WINS is not utilized for Internet access and by nature, the WINS servers are usually protected because they reside within the internal network. However, you may have WINS servers placed within the perimeter network to assist with NetBIOS name resolution for computers and applications that rely on NetBIOS. You may also have parts of your organization located in different geographic locations that communicate through the Internet. If replication between the WINS servers at these locations is required, you will need to find a method for securing the communication. Failure to do so could compromise the data being sent and the WINS server could fall victim to the same types of attacks that are listed previously for DNS servers.
As mentioned previously in this chapter, WINS replication is controlled by the administrator. Once the replication partners have been identified, the administrator creates the replication connections. Unless an attacker has already gained access to the internal network, the servers should not be replicating with any other servers than those identified in the design. If you must use a NetBIOS name resolution method and the LMHOSTS file will not accommodate it, you should place the WINS server that the perimeter clients will use within the perimeter network so that none of the internal data will be available from the perimeter network.
The replication data passing between servers in different sites could become compromised if an attacker captures it. For this reason, any replication data that travels on an unsafe network should be encrypted. Consider using a VPN to encrypt the contents of the replication traffic. Make sure that you take advantage of the highest level of encryption available for the VPN solution that you are using.