Keeping up with my theme on DNS related posts, this week I will again reprise a post from over a year ago on the importance of implementing proper control of DNS as part of your malware protection program. It remains as valuable part of your overall all network and security management policies.
In the weeks ahead we will also take a look at some other records for you DNS to help strengthen the protect e-mail flowing to and from your end users and your e-mail domain.
For now, the prior post…….
DNS lookups and / or the hijacking of DNS lookups are an often-used tool by many malware agents to help enable the success of their intended attacks. Malware can use specially crafted DNS lookups to specific Internet based DNS servers designed to return the proper information for the malware downloads or command-and-control activities. Phishing site attack’s use of DNS can be seen in highjacked DNS responses to take the victim to a site that at first glance looks and feels like the intended legitimate site but in fact is the phishing site waiting for the victim to enter their credentials or other confidential information.
One of the simplest ways to help harden your organization and protect it from the use of DNS to facilitate malware attacks is to tightly control the configuration and use of DNS inside your networks. If the malware can’t properly resolve how to “phone home” the intended attack has been blunted.
Some best practices that CSI has been sharing for the past several years:
- Separate your domain’s authoritative DNS servers (the ones that tell the Internet about the locations of your web, mail and other servers) from the DNS servers your internal devices use for DNS lookups. Your authoritative servers should just perform that function and nothing else – no other lookups.
- Internal device DNS lookups should be restricted to using only prescribed DNS servers INSIDE your organization. For most of us that are in a Windows world that means restricting DNS lookups to your defined Active Directory Domain controllers.
- For all internal DNS servers, the use of the default DNS root servers for external lookups should be disabled.
- Instead of using the root servers for external lookups, define the use of DNS forwarders, and then only use the publicly available Cisco Umbrella (formerly OpenDNS) DNS resolvers as forwarders for your internal DNS servers. These servers are at IP’s 208.67.222.222 and 208.67.220.200. BTW – these IP’s are not single hosts but will automatically map you to the nearest operational server location by anycast routing.
- Use your firewall to disable all outbound DNS lookup requests that don’t originate from your defined internal DNS servers and are not destined for the two Umbrella DNS resolvers.
One of the main advantages of using the Umbrella DNS resolvers besides speed is that they will not resolve DNS for known malware sites. And these servers are constantly being updated with new information to reject resolution to newly uncovered malware sites on an ongoing basis.
While steps 1 -4 above have been easily implemented for most of our clients, it is step 5 that is really required to complete the protection, but remains elusive regarding completion at many sites.
Many of you still have standalone devices that use other external DNS servers, for instance the ever-popular Google DNS servers 8.8.8.8 or 8.8.4.4, mostly I suspect because they are easy to remember. Implementing the firewall block in step 5 will make DNS stop working on these devices until they are reconfigured. But completing this step is critical to providing complete DNS control and all the protection you can gain from it.
We still see the occasional DNS request to other than an Umbrella DNS resolver on many of the daily Firepower IPS reports that we review so we know that in many cases the last step in the process remains undone.
While not a foolproof method, proper DNS control is an often overlooked but relatively simple way to add some additional malware protection to your organization. And in today’s Internet we can use all the protection we can get.
You must be logged in to post a comment.