Most of can easily agree that our IT universe has been dominated over the past several months by cybersecurity discussions as we daily (sometimes it feels like hourly) see reports of the next cybersecurity event that has occurred in our nation, state, or sometimes with our peers. The obvious next questions that leap into all our heads is “am I next?” and “what can I do now to help minimize the risk to me and my organization?”
We have been discussing that proper cyber readiness in an organization is not a single tool or solution but requires an organization-wide, culture shift cutting across people (leadership and staff), policy, priorities, and systems all working together to both minimize risk and enable rapid recovery should a cyber event occur.
One system change that helps minimize the risk that seems to be part of every recent cyber expert’s presentation on the "top-10" risk management to-do’s for today’s cyber-ready organizations is implementing DNS Security. And the good news is that actually implementing DNS Security is a relatively small effort for any organization.
You can start implementing some very basic DNS Security without any cost other than configuration time and effort. I have written about those steps before and because of its timely nature its reprised again below.
However, one of the key principles in cyber protection is that you can’t fight what you can’t see. And while the basic DNS protection scheme outlined below is good, it still lacks any real visibility of what is happening on our networks. We assume the protection is working, but we really have no way to verify how well it is or is not working. While we have gained some ability to block known malware related DNS requests, we don’t know what other related risky DNS activity might be happening on our networks that we are completely unaware of that might be setting us up for other cyber events.
To that end, our team going to be exploring with some of our customer’s more advanced DNS security offerings over the next upcoming weeks. These offerings will provide all of us with additional tools to see snapshots of all the DNS activity coming from an organization and ways to tune DNS responses to eliminate some activity if desired. Stay tuned for more details on this and to hear our thoughts on the additional protections these more advanced DNS Security tools can add.
In the meantime, here are those DNS Security basics that if implemented will go a long way to helping reduce cyber risk in your networks:
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 the resolution of known bad addresses 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.