DNS Security. Defending the Domain Name System

226 Pages·2016·5.8 MB·English

by  Allan Liska

DNS Security
DNS Security
Defending the Domain
Name System
Allan Liska
Geoffrey Stowe
Timothy Gallo, Technical Editor
AMSTERDAM(cid:129)BOSTON(cid:129)HEIDELBERG(cid:129)LONDON
NEWYORK(cid:129)OXFORD(cid:129)PARIS(cid:129)SANDIEGO
SANFRANCISCO(cid:129)SINGAPORE(cid:129)SYDNEY(cid:129)TOKYO
SyngressisanimprintofElsevier
SyngressisanimprintofElsevier
50HampshireStreet,5thFloor,Cambridge,MA02139,USA
Copyright©2016ElsevierInc.Allrightsreserved.
Nopartofthispublicationmaybereproducedortransmittedinanyformorbyanymeans,
electronicormechanical,includingphotocopying,recording,oranyinformationstorageand
retrievalsystem,withoutpermissioninwritingfromthepublisher.Detailsonhowtoseek
permission,furtherinformationaboutthePublisher’spermissionspoliciesandourarrangements
withorganizationssuchastheCopyrightClearanceCenterandtheCopyrightLicensingAgency,
canbefoundatourwebsite:www.elsevier.com/permissions.
Thisbookandtheindividualcontributionscontainedinitareprotectedundercopyright
bythePublisher(otherthanasmaybenotedherein).
Notices
Knowledgeandbestpracticeinthisfieldareconstantlychanging.Asnewresearchandexperience
broadenourunderstanding,changesinresearchmethods,professionalpractices,ormedicaltreatment
maybecomenecessary.
Practitionersandresearchersmustalwaysrelyontheirownexperienceandknowledgeinevaluating
andusinganyinformation,methods,compounds,orexperimentsdescribedherein.Inusingsuch
informationormethodstheyshouldbemindfuloftheirownsafetyandthesafetyofothers,including
partiesforwhomtheyhaveaprofessionalresponsibility.
Tothefullestextentofthelaw,neitherthePublishernortheauthors,contributors,oreditors,
assumeanyliabilityforanyinjuryand/ordamagetopersonsorpropertyasamatterofproducts
liability,negligenceorotherwise,orfromanyuseoroperationofanymethods,products,instructions,
orideascontainedinthematerialherein.
BritishLibraryCataloguing-in-PublicationData
AcataloguerecordforthisbookisavailablefromtheBritishLibrary
LibraryofCongressCataloging-in-PublicationData
AcatalogrecordforthisbookisavailablefromtheLibraryofCongress
ISBN:978-0-12-803306-7
ForInformationonallSyngresspublications
visitourwebsiteathttp://www.elsevier.com
Publisher:ToddGreen
AcquisitionEditor:ChrisKatsaropoulos
EditorialProjectManager:AnnaValutkevich
ProductionProjectManager:PunithavathyGovindaradjane
Designer:MatthewLimbert
TypesetbyMPSLimited,Chennai,India
Dedication
To Kris and Bruce, as always thank you for your support during the research
andwritingprocess,loveyouboth!
AllanLiska
ToKatieandMurphy.
GeoffreyStowe
About the Authors
Allan Liska isaConsultingSystemsEngineer atFireEye Inc. andan“accidental”
security expert. While Allan has always been good at breaking things, he got his
start professionally working as a customer service representative at GEnie Online
Services (a long defunct early competitor to AOL), where he would spend his off
hours figuring out how users had gain unauthorized access to the system, booting
them off, and letting the developers know what needed to be patched.
Unknowingly, this was leading him down the path of becoming a security profes-
sional. Since then he has work at companies like UUNET, Symantec, and
iSIGHT Partners helping companies better secure their networks. He has also
worked at Boeing trying to break into those company networks.
In addition to his time spent on both sides of the security divide Allan has
written extensively on security including The Practice of Network Security and
Building an Intelligence-Led Security Program. He was also a contributing author
toApache Administrator’s Handbook.
Geoffrey Stowe lives in San Francisco and is an Engineering Lead at Palantir
Technologies. His network security work has included vulnerability research,
reverse engineering, incident response, and anomaly detection. There was a time
when he could translate byte code to assembly without looking at a manual.
Geoff started Palantir’s commercial business in 2010 and built its first platforms
for distributed, large-scale data analysis. He graduated from Dartmouth College
with a degreeincomputer science.
xi
Acknowledgments
Allan Liska would like to acknowledge the following people: First and foremost,
I have to acknowledge the great work that my coauthor, Geoff Stowe, and our
technical editor, Tim Gallo, did to make this book a reality. The idea for this
book came to me several years ago and I struggled to bring it into focus. Tim and
Geoff were great for bouncing ideas off, calling me out when I missed things
and, in general, making this book much better. The book would not have been
finished without the two of you. Geoff, I especially appreciate your enthusiasm
for the topicand the absolutely fantasticwriting you did.
I also need to thank Anna Valutkevich, our project manager at Elsevier.
I appreciate you pushing to make this project work, especially as I fell behind.
I also appreciate you working with Geoff to bring him onboard and get him up to
speed quickly.
Of course, this book also would not have been done without the great support
from colleagues from a wide range of companies, who all contributed their
thoughts and answered my questions throughout. I want to give special shout out
to the analyst teams at iSIGHT Partners and FireEye, JJ Guy and the team at
Carbon Black, Arnie Bjorklund and the team at SecurityZones, Sean Blenkhorn
and the team at eSentire, andSeanMurphy for yourearly thoughts on the book.
Finally, I want to thank all of the people who volunteer their time to keep the
DNS infrastructure together and protected from everyone who wants to tear it
down. People who help write RFCs, contribute to working groups, create tools
that others can freely use, and somuchmore.Thank you for your contributions!
Geoffrey Stowe would like to add his appreciation for Allan Liska pioneering the
book and giving me the chance to write about a fascinating topic. Allan, Tim, and
Anna are true professionals, and working with them was a wonderful experience.
I would also like to thank Drew Dennison, Miles Seiver, and Dane Stuckey from
Palantir for providing ideas and feedback. And of course, the support from my
wife Katie andson Murphy madeeverything possible.
xiii
CHAPTER
1
Understanding DNS
INFORMATION IN THIS CHAPTER
(cid:129) DNSHistory
(cid:129) TheRoot
(cid:129) RecursiveandAuthoritativeServices
(cid:129) ZoneFiles
(cid:129) ResourceRecords
INTRODUCTION
Prior to discussing ways to secure DNS infrastructure, it is important to under-
stand what DNS is, and what needs to be secured. DNS has traditionally been an
afterthought at many organizations. Often times initialization and maintenance of
an organization’s DNS infrastructure falls to the people responsible for the setting
up and patching webservers, or configuring and managing the network devices.
They are frequently untrained on the intricacies of DNS and are reliant upon
information they can glean from various web sources some of which are great
and others well, notso much.
From a security perspective, this can be extremely problematic. How can
someone be expected to effectively secure a solution they do not understand?
Simply put they cannot, without sound understanding of the principles, an admin-
istrator cannot be expected to comprehend the nuances associated with securing
the system, let alone keeping up with and realizing the risks posed by the volume
of vulnerabilities published on this topic alone annually. Given the large number
of DNS vulnerabilities published every year and the number of ways an adminis-
trator can expose a DNS infrastructure to attack, it is imperative that those who
manage DNS installations understand the principles behind DNS, in order to be
able toproperly secure those installations.
The best place to start is by defining DNS. The acronym DNS stands for
Domain Name System, although some use DNS to refer to Domain Name
Servers. DNS is a redundant, hierarchical, distributed database that is used to pass
information about domain names. The acronym disagreement demonstrates the
difficulty anyone would have in documenting DNS. If people cannot even agree
DNSSecurity.DOI:http://dx.doi.org/10.1016/B978-0-12-803306-7.00001-2 1
©2016ElsevierInc.Allrightsreserved.
2 CHAPTER 1 Understanding DNS
on what the acronym stands for how can they agree on anything else? As you
progress through this book, you will note that DNS administrators rarely agree
on anything.
The metaphor most often used to describe DNS is a tree. DNS has a root, and
the various Top Level Domains (TLDs) are similar to branches that shoot off the
root. Each branch has smaller branches, which are Second Level Domains, and
the leaves are Fully Qualified Domain Names (FQDNs), sometimes referred to as
hostnames. Do not get the idea that this tree is a peaceful Palm Tree or a strong
Oak. This is a monstrosity of a tree, planted in cement with roots ensnarling each
otherandbranchesspreadineverydirection,thatoftenfeelslikeitisheldtogether
by force of will more than anything else. If DNS is a tree, it is more like the
BanyanTree,inLahaina,Maui.TheBanyanwas8fttallwhenitwasfirstplanted
in 1873 now it is more than 60ft tall and it has spread over 2/3 of an acre. Much
like DNS, the Banyan Tree has grown so large by dropping new roots from its
branches, those roots go on to become new trunks in the Banyan Tree. The com-
pleteflowofaDNSqueryfromworkstationtoresponseisoutlinedinFig.1.1.
DNS is not only important to the functionality of the Internet, but also impor-
tant to the functionality of almost any reasonably sized organization. A poorly
configured DNS server can impact an entire organization and a poorly secured
DNS server or Domain provides an attacker an easy opening into an organiza-
tion’s network. Even if an organization is properly protected, DNS can still be
used asan attackvectoragainst anorganization.
This chapter covers the basics of DNS—it is designed as a very high level
overview of the DNS process and does not get overly bogged down in details.
Starting with the beginnings of the DNS it then moves onto the root system,
details the different types of DNS servers, and reviews how DNS servers speak to
each other, andwhattype of informationis communicatedbetween servers.
DNS HISTORY
When most people think of Internet luminaries Bill Gates, Steve Jobs, Marc
Andreessen, and Mark Zuckerberg come to mind. Certainly these people have
madegreatcontributionstotheprogressionoftheInternet(oritsdownfall,depend-
ingonwhoyouask),butthereareawholegroupofpeoplewhoseimpacthasbeen
muchmoreprofound.Thesecontributionsdidnotnecessarilyresultinmultimillion
dollar Initial Public Offerings (IPOs), but without them the Internet would not be
whatitistoday.
THE HOSTS.TXT FILE
TheInternetis sometimescomparedtoan organism. Like anyorganismit evolves
overtimeandalsolikeanorganismitleavestracesofitsformerexistencebehind.
DNS History 3
FIGURE1.1
AstylizedversionofthetrafficflowofaDNSquery.
In this case remnant of the precursor to DNS, the hosts.txt file, is still found on
manysystems.
To understand why DNS became necessary, take a look at the file /etc/hosts
on UNIX systems or %systemroot%\system32\drivers\etc\hosts.txt in Microsoft
Windows or the hosts.txt file on Android devices. The format of all these files is
the same:
IPAddress ComputerName Comment
These files are used to map IP Addresses to hostnames, in other words they
serve the same function that DNS does. These files were the precursor to DNS.
4 CHAPTER 1 Understanding DNS
Prior to the introduction of DNS, the host file was used as the primary method
of sharing data about hostnames.
Two events helped bring about the birthof the host file. In December of 1973,
and outlined in conjunction with RFC 592, an “official” host naming convention
was established. Numbers, letters, and dashes were the only characters allowed in
hostnames, parentheses were allowed aspart of network names.
Once the list of hostnames (all 81 of them!) had been gathered, the next step
came with RFC 606 and RFC 608. These RFCs outline the creation of a new
centralized file, called HOSTS.TXT, which could be downloaded via FTP so that
alladministratorsconnectedtotheARPANETwouldhavethesamedataregarding
hostnames.
It is interesting to note that while this idea makes a lot of sense in retrospect,
the author of RFC 606, L. Peter Deutsch, felt compelled to add the following
disclaimer:
I realize that there is a time-honored pitfall associated with suggestions such
as the present one: it represents a specific solution to a specific problem, and
as such may not be compatible with or form a reasonable basis for more gen-
eral solutions to more general problems. However, (1) this particular problem
has been irking me and others I have spoken to for well over a year, and it is
really absurd that it should have gone unsolved this Long; (2) no one seems
particularlyinterestedinsolvinganymoregeneralproblem.
The first hosts.txt file went online March 25, 1974 and was announced by
RFC 627. Prior the release of the first hosts.txt file, another DNS institution was
introduced. RFC 623 and RFC 625 discussed placing the hosts.txt file on an addi-
tional server. If the primary server, OFFICE-1, was unavailable, a host could
retrieve the file from the secondary server. Again, this is very similar to the way
DNSworkstoday.
MAIL PROBLEMS
ARPANET continued in this manner for more than a decade. As more organiza-
tions connected to this Internet, it became obvious that there were some issues
with this system, particularly when it came to most commonly used application:
Computer Mail.
The problem with computer mail was that too many people were using the
system, so it became difficult for postmasters to manage mail messages. The for-
mat of mail addresses was based on the addresses in the host file. So, if someone
wanted to send a message to Allan Liska at Example Corp, the format would be
something along the lines of liska@example or aliska@example. This is fine, as
long as there is only one computer to which users at the originating organization
are connected. But ARPANET was growing in popularity, and computer users
were not isolated to one department or even to one campus. There were
ARPANET users spread outacrossorganizations andin multiple locations.