Hardening DNS Against Reflection Attacks

Generally, the most prevalent types of attacks and the ones which are most likely to target a DNS infrastructure are reflection/amplification attacks (which generally use a DNS servers resources against other third-parties).  Understanding the attack-vector employed in most reflection attacks is necessary in order to understand how to harden an environment against these types of attacks.

In a typical DNS reflection attack, attackers send a large number of queries from a spoofed source address.  The address which is spoofed is typically that of the victim.  When the requests are received by the nameserver, all ensuing responses to these queries are directed back towards the spoofed IP of the victim.  The amplification factor comes into play in these types of attacks because the attacker will typically query for a record of a large size, typically that of a root record which by it’s very nature is very large in size.  By simply sending in small queries, on the order of around 90 Bytes, an attacker can typically get a multiplication factor of five times that of the original query.  This allows an attacker to use a smaller number of hosts in the botnet and cause considerably more impact than would otherwise be possible if these devices were sending traffic directly towards the victim.

Due to the fact that the purpose of this attack is to reflect packets back towards the victim, all of the source IPs of the DNS queries contain the same address.  This makes it fairly easy to spot a reflection attack utilizing your infrastructure.  A simple observation of a spike in DNS queries from a singular IP is a clear indication that this is going on.  One would think that these types of attacks can be mitigated fairly easily by implementing simple ACLs on routers to prevent the incoming queries from those spoofed IP, and in fact that is a method commonly used by network administrators to protect against these types of attacks.  However, most security experts suggest that the filtering should actually be implemented on the nameserver itself – in fact this has been considered an industry best practice for quite some time now.  The reason for this is that implementing an ACLs on a router is largely a reactive countermeasure which can only be deployed after the fact.  An administrator will still need to identify the target of the attack before filters can be put in place; furthermore these types of filters only serve to cause a legitimate Denial of Service when that particular victim actually attempts to query anything for which the nameserver is actually authoritative for.  As an alternative to ACLs, some proposed configurations below can be used to eliminate this problem in it’s entirety.

At the very onset of your investigation into the vulnerabilities of your DNS infrastructure and potential remedies one of the very first things a network administrator must determine is if the nameservers allow anyone on the outside world to query for root (.).  Using the example below, one can easily check to see if their nameserver responds with a root-referral when queried for root.  If you see something along these lines, you can be fairly certain your nameserver is responding with a root-referral:

Normally, most Internet-facing authoritative nameservers should not respond to recursive third-party queries for root.  If an authoritative nameserver responds to queries for root with a root-referral, attackers will likely use your nameservers as an amplification vector to launch attacks.  It is better to remove the temptation altogether, by not allowing these in the first place.  Furthermore, instead of responding with the root-referral, nameservers should be configured to respond with REFUSED or SERVFAIL or another similar type of message.  The reason for this is simple – a REFUSED message is only on the order of around 50 Bytes.  If a countermeasure such as this is not employed, attackers can send in a relatively small spoofed query and will get roughly a 512 Byte response.  However, if we respond with a REFUSED message, the amplification factor is on the order of 1:1.  From an efficiency standpoint this does not provide much if any amplification, and therefore the attackers will simply look for other providers whom don’t apply such stringent security measures.

NOTE: Of course if you are in the business of providing recursive DNS service, that is an entirely different story – if that is the case, network administrators should take extra precautions by strictly enabling this function on the Recursive DNS servers (not the Authoritatives) and combining firewall-filters to limit recursive service to only IP blocks of paying customers.

While we’re on the subject, another current best practice in the industry is to apply a similar methodology to requests for records for which a given DNS Server is not authoritative for.  Some resolvers may respond to these types of requests by providing a root-referral, and in the worst cases a resolver may actually perform a recursive query on behalf of the original source.  An authoritative resolver should respond to any non-existent domain requests with either the REFUSED message or other similar type of message, rather than providing a root referral or performing a recursive query.  In fact, BCP 140 (Preventing Use of Recursive Nameservers in Reflector Attacks, RFC 5358) looked at this problem and concluded that sending REFUSED was the best general guidance that can be given.  While BCP 140 applies guidance to recursive servers, returning REFUSED to queries which are not within the namespace served by authoritative servers is entirely consistent with BCP 140.  You can generally find out if your nameservers allows for recursion or if it responds with a root-referral, by using a command such as the following:

If you see a response which looks like the large root-referral response above, or some other type of response other than a REFUSED or SERVFAIL, you should take steps to harden your resolver.  One can also look for an “RA” entry in the “Flags” section of the DNS response which should give you some indication as to whether the resolver allows for recursion.

In conclusion, there are several such steps which allow administrators to prevent from being used as an unwitting pawn in an attack against third-parties.  Firewall filters are effective, but are reactive in nature.  Therefore, it is recommended to follow some of the steps below in order to effectively harden your DNS infrastructure against reflection attacks.

SYNOPSIS – Steps to prevent a DNS infrastructure from being used for reflection/amplification type attacks:

  1. Disable querying for root on Authoritative resolvers, return REFUSED
  2. Filter queries to Recursives from only paying customers, via ACLs
  3. Apply BCP 140 or similar rules to cause any non-existent domain queries to respond with a REFUSED.

An excellent whitepaper entitled “Anatomy of Recent DNS Reflector Attacks from the Victim and Reflector Point of View” by Ken Silva, Frank Scalzo and Piet Barber covers this topic in more detail.

Reflections on the Past :: ConneXions – The Interoperability Report

Way back in 1987, before there was the the “Internet Protocol Journal” and other notable publications which cover various aspects of Internet Technologies, there was “ConneXions – The Interoperability Report“.   At the time, aside from reading RFCs or Internet-Drafts for more information on various protocols, this publication was the defacto resource for informative analysis of various protocols and their operation.  A quick glance at the articles and you’ll see long-time industry heavy-hitters such as Doug Comer, Jon Postel, and Vint Cerf listed as the authors.  This is an invaluable resource for those of you who want to understand the history and evolution of various Internet protocols commonly in use today.

Preventing DNS Fragmentation and Large DNS Packet Attacks

Often times, attackers will attempt to perform very rudimentary attacks against DNS resolvers in an attempt to cause a Denial of Service. It is not uncommon to see attackers crafting a DoS attack composed mostly of UDP packets destined to port 53 with invalid payloads containing the ‘more-fragments’ bit set. In some cases, the packets may contain the ‘non-more-fragments’ bit set with packets of specific lengths, typically larger than the average size of a normal DNS packet.

Many flow analysis tools and IDP products have the ability to look for IP fragmentation misuse based on parameters that the operator may set; these tools are invaluable as an early warning system to alert the network administrator that their infrastructure is under attack.

Insofar as being able to mitigate these types of attacks, a few simple approaches can be utilized by a network administrator in order to filter this type of traffic using simple ACLs or firewall filters on routers or other types of equipment capable of filtering at Layers 3 and 4. Normally, is is not typical to see DNS queries which are fragmented, therefore the following Juniper firewall-filter should effectively filter the fragmented packets:

For packets containing the ‘non-more-fragments’ bit set, or which all packets within the attack flows share a common packet size (typically this will be large, on the order of 540 bytes or larger), a network administrator can easily filter those on the router as well. Normally we should not expect to see queries of this large size, so the following could be effectively used to filter these types of attacks as well.  In this example we are filtering UDP or TCP packets destined to port 53, with a size of either 540 bytes or 1480:

NOTE: It is more than likely a network administrator would need to adjust the above packet sizes after analysis of the packet size used in the attack vector using whatever flow reporting or network visibility tools are in use, since it is unlikely an attacker would use the exact same packet sizes listed in the example above.

Book Review :: Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)


Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)
by Victor Oppelman, Oliver Friedrichs, and Brett Watson
Paperback: 448 pages
Publisher:  McGraw-Hill Osborne Media
ISBN-13: 978-0072259551

4starsGood coverage of darknets, honeynets, and triggered blackholes

First I must admit that I know and have worked with several of the authors of this book. I was given an autographed copy of the book late last year, however seeing as the book was published in 2005 I didn’t think there would be much along the lines of useable information seeing as many of the security threats and vulnerabilities have evolved quite a bit since then. However, as I started reading the book I quickly realized much of the information was still relevant today as it was several years ago. The chapters on ISP Security Practices and Securing the Domain Name System had very good coverage of many of the techniques used throughout Service Provider networks to secure their network and DNS infrastructure.

I particularly enjoyed reading the sections on using egress packet filters to restrict data leaks from within an organization – a particular problem today with the prevalance of Internet Worms and other Malware which often attempt to communicate back to their centralized Command & Control (C&C) hosts. The chapter on ‘Sinkholes and Backscatter’ has very good coverage on a wide variety of topics such as using Darknets and Honeynets to monitor malicious traffic and other nasties emanating throughout your network, as well as using techniques such as Triggered Blackhole Routing to propagate filters quickly and dynamically to drop DDoS and other malevolent traffic.

I would have to disagree with Dr. Anton Chuvakin that the chapters on Digital Forensics were disappointing. Personally, I learned quite a bit from these chapters and came away from reading them with a whole arsenal of new tools to use with which I can perform my own digital forensics on compromised systems. The coverage of Foremost, memdump, and some of the advanced digital forensic tools was top notch.

All in all, I would say this is still a good book for anyone involved in Network Security. Much of the information covered is still relevant in today’s networks. If the authors attempt to release a second edition I would suggest coverage of adapting Triggered Blackhole techniques to be used in more modern DDoS Mitigation scenarios. Additionally, discussion of new techniques used for Malware C&C and coverage of Fast-flux and Double-flux techniques used by the attackers to create more robust and reliable networks would be welcomed.

Book Review :: OSPF and IS-IS: Choosing an IGP for Large-Scale Networks


OSPF and IS-IS: Choosing an IGP for Large-Scale Networks
by Jeff Doyle
Paperback: 480 pages
Publisher: Addison-Wesley Professional
ISBN-13: 978-0321168795

5starsA welcome addition to any networking library

If you consider yourself a student of routing protocols and enjoy coverage of graph theory from the perspective of its application to link-state routing protocols, this text will certainly be a welcome addition to your library. This book not only provides information regarding ‘how’ link-state routing protocols work, it also provides information regarding ‘why’ the link-state routing protocols behave as they do, and why the protocol designers made certain choices in the development of these protocols. While it might seem a daunting task especially to the novice reader to learn about two routing protocols side-by-side, it is this treatment which makes this text so worthwhile. Being able to compare these two protocols and identify their similarities and differences simultaneously will ultimately help the network designer pick the right protocol for the job in a given network environment.

This book goes beyond IGP fundamentals by giving practical advice to the network designer which can assist in the planning and implementation of a scalable IGP deployment. For example, in the chapter on Area Design, the author states that “a useful guideline when designing a network is that network control traffic should never exceed 5 percent of the available bandwidth of any link in the network, and in normal circumstances should not exceed 1 percent”. The author then presents various formulas which can be used to determine the amount of bandwidth used by the protocol control traffic based on the number and type of LSAs which are expected to be present in a given network. Arguably one of the best chapters in the book is the chapter on Scaling. This chapter has some of the best coverage of the various modifications which router vendors make to their link-state protocol implementations in order to make routers perform calculations more rapidly, enhance flooding of Link-State updates, and other changes designed to make the protocols scale to support very large networks.

I am a stickler for accuracy, especially when it comes to technical textbooks. I pride myself on my ability to spot technical and grammatical errors in texts such as these, however I must say as I read this book I was very impressed that I found very little errors beyond just the simple grammatical and typographical. Jeff Doyle is an experienced writer, and it should come as no surprise that the technical content in this book is extremely well-vetted, accurate, and error-free. Ultimately, if you are a network operator, designer or architect and are interested in broadening your understand of link-state protocols coupled with the ability to more fully understand the technical distinctions between OSPF and IS-IS, this book is without a doubt one of the best options on the market today.

Book Review :: Designing and Developing Scalable IP Networks

Scaleable Networks

Designing and Developing Scalable IP Networks
by Guy Davies
Hardcover: 302 pages
Publisher: Wiley
ISBN-13: 978-0470867396

3starsDecent information with a hefty price tag…

The title of this book “Designing and Developing Scalable IP Networks” would lead one to believe that reading this book would give the reader special insight into certain architectural approaches that would enable the network designer to build very large and expansive networks. And while the book certainly did provide some useful information, I found it lacking somewhat in details. The author does not delve into the minutiae of the various protocols, such as message types, protocol interaction, etc. Instead, the author assumes the reader already has a solid understanding of the basic principles of IP networking and the protocols associated with IP routing and switching. The author states early on that the book is meant to “examine the architectural and design principles that can be applied to designing and building scalable IP and MPLS networks”, however after a thorough reading I did not find that I was substantially more educated in the subject matter. And herein lies the crux – this book, which is priced in at a whopping $130 – is far more expensive than other texts of a similar nature, some of which cover far more expansive material and cost considerably less. Furthermore, the book is too light on details to be sufficiently useful to someone who is new to the industry and looking to gain a better understanding of what is required to build large-scale networks, and is unlikely to provide the experienced network architect with useable knowledge beyond that which he or she may already possess.

That being said, there is decent treatment of MPLS and Generalized MPLS, MPLS VPNs, QoS, and IPv6. And there certainly are a few good nuggets of information to be found throughout the book. For example, there is very good information on route-reflection, such as the pro’s and con’s of using the same cluster-id on a pair of route-reflectors running in a pair. It also examines practical deployment information for such mechanisms as graceful-restart, citing the fact that enabling BGP graceful-restart without enabling a similar mechanism in the IGP is likely to reduce the benefit of enabling such a mechanism in the first place. And while this is one of the few texts that I have seen on the market that broaches the subject of graceful-restart, I welcome the author to include more information on this subject in subsequent editions.

All in all I would say that this is a good desk side reference if one wants a text which covers the main protocols and mechanisms in use in large Service Provider networks, but if you are looking for a text which will enable you to build large-scale networks you might be somewhat disappointed in the treatment, especially considering the hefty price tag of this item.

Danny McPherson talks with Verizon Business about Arbor’s 2007 Worldwide Infrastructure Security Report

Danny McPherson, Chief Security Officer at Arbor Networks, talks with Verizon Business’ Stefan Fouant about the complex set of challenges facing the service provider community.  What are the most pressing security issues facing providers today, and how do they plan to address them? Listen to this podcast to learn more.