DNS Security DNS Security Defending the Domain Name System

DNS Security DNS Security Defending the Domain Name System Allan Liska Geoffrey Stowe Timothy Gallo, Technical Editor AMSTERDAM • BOSTON • HEIDELBERG • LONDON NEW YORK • OXFORD • PARIS • SAN DIEGO SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Syngress is an imprint of Elsevier https://telegram.me/informationsec Syngress is an imprint of Elsevier 50 Hampshire Street, 5th Floor, Cambridge, MA 02139, USA Copyright © 2016 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein. British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the Library of Congress ISBN: 978-0-12-803306-7 For Information on all Syngress publications visit our website at http://www.elsevier.com Publisher: Todd Green Acquisition Editor: Chris Katsaropoulos Editorial Project Manager: Anna Valutkevich Production Project Manager: Punithavathy Govindaradjane Designer: Matthew Limbert Typeset by MPS Limited, Chennai, India https://telegram.me/informationsec Dedication To Kris and Bruce, as always thank you for your support during the research and writing process, love you both! Allan Liska To Katie and Murphy. Geoffrey Stowe https://telegram.me/informationsec About the Authors Allan Liska is a Consulting Systems Engineer at FireEye Inc. and an “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 professional. 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 to Apache 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 degree in computer science. xi https://telegram.me/informationsec 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 topic and the absolutely fantastic writing 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, and Sean Murphy for your early 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 so much more. 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 and son Murphy made everything possible. xiii https://telegram.me/informationsec CHAPTER Understanding DNS 1 INFORMATION IN THIS CHAPTER • DNS History • The Root • Recursive and Authoritative Services • Zone Files • Resource Records INTRODUCTION Prior to discussing ways to secure DNS infrastructure, it is important to understand 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, not so 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 administrator 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 administrator 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 to properly 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 DNS Security. DOI: http://dx.doi.org/10.1016/B978-0-12-803306-7.00001-2 1 © 2016 Elsevier Inc. All rights reserved. https://telegram.me/informationsec 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 other and branches spread in every direction, that often feels like it is held together by force of will more than anything else. If DNS is a tree, it is more like the Banyan Tree, in Lahaina, Maui. The Banyan was 8 ft tall when it was first planted in 1873 now it is more than 60 ft 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- plete flow of a DNS query from workstation to response is outlined in Fig. 1.1. DNS is not only important to the functionality of the Internet, but also important to the functionality of almost any reasonably sized organization.

Load more