In my last tip I discussed providing additional protection to your DNS system for the ultimate purpose of improving...
security for Active Directory. The first consideration was to require all communications with DNS servers to be encrypted. The next two considerations are to monitor all network traffic and re-evaluate the open ports on your firewall.
By monitoring network traffic you should be able to determine when illegitimate or abnormal traffic patterns or content begin to enter your network. You must make the choice whether to perform real-time detection or rely upon historical reviews to detect attack attempts. Real-time detection will require an automated IDS system or audit scanning system actively looking for attacks. Historical reviews will re-examine log files of audited events or collections of DNS traffic packets. The former solution is preferred but it is often expensive. The latter solution will only provide post-incident detection not preventative or immediate response capabilities.
No matter what monitoring method you choose, look for specific DNS focused denial of service attacks, DNS system flooding, DNS poisoning attempts, unusually high amounts of traffic, abnormal amounts of traffic from a single host or to a single host, and abnormal levels of traffic of a single type (i.e. TCP sub-protocol, such as service or application protocols).
If you don't already have firewalls protecting the borders of your network. You have bigger issues to deal with right now than improving DNS security. When dealing with DNS traffic across firewalls, keep in mind that both DNS queries to resolve FQDN into IP addresses and DNS server to DNS server communications (such as zone transfers) both occur over UDP port 53. This port should be blocked, disabled, or turned off unless one of the following are true:
- Zone transfers must occur across the firewall
- A DNS server is authoritative for a delegated zone located across the firewall
- DNS clients communicate with DNS servers across the firewall
- DNS forwarders must communicate with DNS servers that are higher in the DNS namespace hierarchy across the firewall
Once you provided protection for DNS traffic, you can then begin securing the DNS data itself. That is the topic of the next tip.
James Michael Stewart is a partner and researcher for ITinfopros, a technology-focused writing and training organization.