Working for a security services vendor provides me the opportunity to work with a variety of cool tools in our quest to develop new and innovative security services. The most recent project I was deeply involved in is the development of a DNS security service called SecureSurf. The foundational goal of the design of this service was to provide a policy-based DNS filtering platform that is unrestricted (not based upon IP whitelisting), globally distributed and lightning fast. Standard DNS security practices frown upon the practice of unrestricted DNS cache servers connected to the Internet. In our case, we had to provide a means for the mobile worker and those with dynamic IP addresses to be able to seamlessly connect. During our initial development and deployment, we learned a great deal about what works and doesn’t work in securing an application as vital as DNS. As soon as we deployed our initial roll-out, we noticed three immediate concerns:
- Unrestricted DNS resolvers are very quickly discovered by miscreants.
- Once discovered, these DNS resolvers can be commandeered to participate in a variety of malicious activities.
- Malicious activity can quickly degrade end-user experience.
Most DNS cache servers are secured at the application layer (layer 7) by incorporating access lists, effectively ignoring queries from sources that are not explicitly allowed. The newest versions of Bind and Unbound have configuration option that can rate limit queries. Additional security controls include firewall rules limiting connectivity to DNS application servers from the outside world (layer 3) and IDS/IPS inline protection (layer 2-7). Unfortunately, these controls have limited ability to protect DNS interfaces that are essentially open to the world. In addition, we observed a variety of attacks, some well-known and some not, that are typically not addressed early enough in the DNS resolution process to be effective in securing DNS services. Our goal in securing DNS services included ensuring availability not only of the DNS services but also the integrity of the answers provided. The main malicious exploitations we observed were:
- DNS Amplification Attacks
- Slow DNS Reflection (aka DGA Domains or Domain Fluxing)
- Bad Query Name Format
- Malformed DNS packets
- Data Exfiltration Via DNS
- DNS Requests from Known Malicious IPs
- DNS Resource Exhaustion
- DNS Flood Attacks (DDoS)
Each of these malicious activities has different impacts on service level, so we set out to design a system that would allow us to mitigate the bulk of these attacks at the transport layer (layer 4). The tools we chose to incorporate include F5 Big IP devices, iRules (TCL), Graylog, Elasticsearch, Kibana and NXLog. In upcoming posts, I will break down the technical details of these various components and provide an overview of how we combined these parts in building out a monitoring and protection platform for our DNS resolvers. I will be giving a talk at BSides Las Vegas entitled “DNS Hardening - Proactive Network Security Using F5 iRules and Open Source Analysis Tools” that covers an overview of this solution. If you are attending BSides Las Vegas, please be sure to stop by!
About the Author: Jim Nitterauer, CISSP is currently a Senior Security Specialist at AppRiver, LLC. His team is responsible for global network deployments and manages the SecureSurf global DNS infrastructure and SecureTide global SPAM & Virus filtering infrastructure as well as all internal applications and helps manage security operations for the entire company. He is also well-versed in ethical hacking and penetration testing techniques and has been involved in technology for more than 20 years. Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc. Save
