DNS Security Management E-Book

Michael Dooley

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Serie: IEEE Press Series on Network Management
• Sprache: Englisch

Seitenzahl: 492

Veröffentlichungsjahr: 2017

Beschreibung

An advanced Domain Name System (DNS) security resource that explores the operation of DNS, its vulnerabilities, basic security approaches, and mitigation strategies DNS Security Management offers an overall role-based security approach and discusses the various threats to the Domain Name Systems (DNS). This vital resource is filled with proven strategies for detecting and mitigating these all too frequent threats. The authors--noted experts on the topic--offer an introduction to the role of DNS and explore the operation of DNS. They cover a myriad of DNS vulnerabilities and include preventative strategies that can be implemented. Comprehensive in scope, the text shows how to secure DNS resolution with the Domain Name System Security Extensions (DNSSEC). In addition, the text includes discussions on security applications facility by DNS, such as anti-spam, SPF, DANE and related CERT/SSHFP records. This important resource: * Presents security approaches for the various types of DNS deployments by role (e.g., recursive vs. authoritative) * Discusses DNS resolvers including host access protections, DHCP configurations and DNS recursive server IPs * Examines DNS data collection, data analytics, and detection strategies With cyber attacks ever on the rise worldwide, DNS Security Management offers network engineers a much-needed resource that provides a clear understanding of the threats to networks in order to mitigate the risks and assess the strategies to defend against threats.

Leseprobe

IEEE Press

445 Hoes Lane

Piscataway, NJ 08854

IEEE Press Editorial Board

Tariq Samad, Editor in Chief

Giancarlo Fortino

Xiaoou Li

Ray Perez

Dmitry Goldgof

Andreas Molisch

Linda Shafer

Don Heirman

Saeid Nahavandi

Mohammad Shahidehpour

Ekram Hossain

Jeffrey Nanzer

Zidong Wang

Copyright © 2017 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone], or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permission.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data is available.

ISBN: 978-1-119-32827-8

CONTENTS

Preface

Acknowledgments

1 Introduction

Why Attack DNS?

DNS Basic Operation

Security Context and Overview

What's Next

2 Introduction to the Domain Name System (DNS)

DNS Overview – Domains and Resolution

Name Resolution

Zones and Domains

Resolver Configuration

Summary

Notes

3 DNS Protocol and Messages

DNS Message Format

The DNS Resolution Process Revisited

Summary

Notes

4 DNS Vulnerabilities

Introduction

DNS Data Security

DNS Information Trust Model

DNS Infrastructure Risks and Attacks

Broader Attacks that Leverage DNS

Summary

5 DNS Trust Sectors

Introduction

Cybersecurity Framework Items

DNS Trust Sectors

External DNS Trust Sector

Extranet DNS Trust Sector

Recursive DNS Trust Sector

Internal Authoritative DNS Servers

Additional DNS Deployment Variants

Other Deployment Considerations

Putting It All Together

Notes

6 Security Foundation

Introduction

Hardware/Asset Related Framework Items

DNS Server Hardware Controls

Summary

7 Service Denial Attacks

Introduction

Detecting Service Denial Attacks

Denial of Service Protection

Summary

8 Cache Poisoning Defenses

Introduction

Attack Forms

Cache Poisoning Detection

Cache Poisoning Defense Mechanisms

Notes

9 Securing Authoritative DNS Data

Introduction

Attack Forms

Attack Detection

Defense Mechanisms

Summary

10 Attacker Exploitation of DNS

Introduction

Detecting Nefarious use of DNS

Mitigation of Illicit DNS Use

11 Malware and Apts

Introduction

Malware Proliferation Techniques

Malware Use of DNS

Detecting Malware

Mitigating Malware Using DNS

Summary

12 DNS Security Strategy

Major DNS Threats and Mitigation Approaches

Common Controls

DNS Role-Specific Defenses

Broader Security Strategy

13 DNS Applications to Improve Network Security

Safer Web Browsing

Email Security

Securing Automated Information Exchanges

Storing Security-Related Information

Summary

Notes

14 DNS Security Evolution

Appendix A: Cybersecurity Framework Core DNS Example

Appendix B: DNS Resource Record Types

Bibliography

Index

ELUA

List of Table

1

Table 1.1

Table 1.2

3

Table 3.1

Table 3.2

Table 3.3

Table 3.4

Table 3.5

Table 3.6

Table 3.7

4

Table 4.1

Table 4.2

Table 4.3

Table 4.4

Table 4.5

Table 4.6

Table 4.7

Table 4.8

Table 4.9

Table 4.10

Table 4.11

5

Table 5.1

Table 5.2

Table 5.3

6

Table 6.1

12

Table 12.1

Appendix B

Table B.1

List of Illustrations

1

Figure 1.1

Basic DNS Resolution Flow

Figure 1.2

DNS Query Flow and Data Sources

Figure 1.3

Risk Likelihood-Impact Plot

2

Figure 2.1

Domain Tree Mapping to a Fully Qualified Domain Name

Figure 2.2

Recursive and Iterative Queries in Name Resolution

Figure 2.3

Zones as Delegated Domains

Figure 2.4

Microsoft Windows Configuration of IP Address DNS Servers to Query

3

Figure 3.1

DNS Labels

Figure 3.2

Name Compression with Pointers

Figure 3.3

DNS Message Fields

Figure 3.4

DNS Message Header

Figure 3.5

Question Section Format

Figure 3.6

Answer Section Format

Figure 3.7

DNS Update Message Format

Figure 3.8

EDNS0 Format

Figure 3.9

Recursive and Iterative Queries in Name Resolution

Figure 3.10

Resolver-Issued DNS Query Packet Example

Figure 3.11

Recursive Server Query to an Internet Root Server

Figure 3.12

Example Root Server Referral Response

Figure 3.13

Recursive Server Iterative Query to a .com Name Server

Figure 3.14

TLD Server Referral

Figure 3.15

Recursive Query to an example.com Name Server

Figure 3.16

Authoritative Answer

Figure 3.17

Query Answer Example

4

Figure 4.1

Basic DNS Data Stores and Update Sources

Figure 4.2

Denial of Service Attack

Figure 4.3

Distributed Denial of Service Attack

Figure 4.4

Bogus Domain Query

Figure 4.5

PRSD Attack

Figure 4.6

DNS Cache Poisoning

Figure 4.7

Valid and Falsified Response; Which is Correct?

Figure 4.8

Resolver Infiltration for Man in the Middle Attack

Figure 4.9

Reflector Style Attack

Figure 4.10

DNS Tunneling

5

Figure 5.1

Basic DNS Trust Sectors

Figure 5.2

External Trust Sector Deployment

Figure 5.3

Extranet Trust Sector

Figure 5.4

Addition of Caching Servers for External Resolution

Figure 5.5

Internal DNS Servers for Internal Clients

Figure 5.6

Internal Namespace Delegation

Figure 5.7

Three-Tiered Internal Server Structure

Figure 5.8

Anycast Routing Table Example

Figure 5.9

Logical Routing Perspective from Router 1 Showing Hop Counts

Figure 5.10

IPAM Worldwide DNS Server Deployments

6

Figure 6.1

Risk Likelihood-Impact Plot

7

Figure 7.1

Denial of Service Attack

Figure 7.2

Distributed Denial of Service Attack

Figure 7.3

Bogus Domain Query

Figure 7.4

PRSD Attack

Figure 7.5

Reflector Style Attack

8

Figure 8.1

Legitimate versus Poisoned Response

Figure 8.2

Digital Signature Creation and Verification Process

9

Figure 9.1

DNSSEC Chain of Trust Traversal

Figure 9.2

Basic DNSSEC Implementation Steps

Figure 9.3

Prepublish Rollover

Figure 9.4

Dual-Signature KSK Rollover

Figure 9.5

Algorithm Rollover

11

Figure 11.1

Fast-Flux Network

Figure 11.2

Double-Flux Network

Figure 11.3

DNS Firewall Example

13

Figure 13.1

TLS Handshake

Figure 13.2

Certificate Verification Using DANE

Figure 13.3

Simple SMTP Transaction Example

Figure 13.4

Email Relay

Figure 13.5

DMARC Email Policies

14

Figure 14.1

DNS Security Maturity Model

Guide

Cover

Table of Contents

Preface

Pages

xiii

xiv

xv

xvii

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

22

23

24

25

26

27

28

29

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

291

292

293

294

295

296

297

299

300

301

PREFACE

As the Internet transformed from a scientific and educational network experiment into a global commercial communications network over the last four decades, its widespread adoption by organizations and individuals fueled its explosive growth, which continues unabated to this day. Providing the ability to communicate, update bank accounts, access critical information remotely, and much more, the Internet serves as the prime vehicle for anytime, anyway, anywhere communications. As such it also became an extremely attractive target for criminals seeking to disrupt an organization's web presence or email, infiltrate an enterprise's internal network, and steal valuable data, including personal, corporate, or government classified information, among other things.

Organizations have responded by implementing various security measures including intrusion protection mechanisms such as firewalls, authentication and encryption technologies, proactive security scanning, attack detection monitors, and security education to name a few. With defensive implementations deployed, attackers seek targets that are less well defended or that provide a generally free-flowing communications pathway like hypertext transfer protocol (HTTP), simple mail transfer protocol (SMTP), or domain name services (DNS).

While attacks on web traffic and email have been fairly well publicized, though they continue to evolve over time, attacks on DNS represent an emerging threat to organizations. Unlike HTTP, SNMP, and other application layer protocols, DNS is an “application helper” protocol that exists to facilitate application ease-of-use. DNS is not an end user application, but without DNS end user applications would largely be useless.

DNS essentially serves as the Internet directory to convert user-entered web or email addresses that humans use into Internet Protocol (IP) addresses computers use. And with each web page to which one navigates DNS provides analogous lookup functions for additional content all of which is “linked” from the destination web page, including images, scripts, styles, videos, ads, and so on. DNS also provides lookup functions for numerous other applications such as machine-to-machine communications, the Internet of Things (IoT), voice over IP, and so on. DNS is truly indispensable to the effective operation of the Internet and of your IP network.

The objective of this book is to help you understand how DNS works, its vulnerabilities, threats and attack vectors, and how to incorporate detection, defensive, and mitigation techniques to secure your DNS. By securing your DNS, you can better secure your network at large. We've attempted to bring together the topics of DNS and security assuming only basic knowledge of both. In the first chapter, we set the stage with a brief introduction to DNS and the National Institute of Standards and Technologies (NIST) Cybersecurity Framework (1), which is a de facto security implementation standard not only for the US government, but for organizations worldwide. This framework defines a common lexicon to facilitate documentation and communication of security requirements and level of implementation. In addition, the framework enables an organization to identify risks and to prioritize the mitigation of risks with respect to business priorities and available resources.

Chapters 2 and 3 provide an introduction to DNS, with Chapter 2 covering the organization of DNS data across the Internet and Chapter 3 discussing the DNS protocol which serves as a foundation for understanding certain attack methods. Chapter 4 introduces these attack methods at a summary level. The purpose of this chapter is to cover the breadth of attack types, which we've segmented into those that attack DNS itself and those that use DNS as an attack enabler to target other computing and network systems.

Chapters 5 through 11 serve as the heart of the book, drilling into each of the vulnerabilities introduced in Chapter 4 and providing detailed discussions of each attack form, detection techniques, defensive measures, and mitigation methods. We apply the relevant cybersecurity framework principles throughout these chapters to normalize the discussion within a security context. As we discuss various protection and mitigation strategies, we've also included basic configuration syntax to implement these strategies for three popular open source DNS implementations: Internet Systems Consortium (ISC), PowerDNS, and Knot DNS. Note that there are dozens of DNS server implementations and we chose these based on their free availability and relatively rich features sets, but we invite you to evaluate other implementations that may suit your particular requirements.

Chapter 12 brings things together in discussing an overall DNS security strategy. And once you've secured your DNS, you can then use DNS as a means to enhance the security of your overall network and applications. In Chapter 13, we discuss methods for using DNS to secure critical applications including web browsing, email, and others. Chapter 14 provides a brief though bold prediction of our view of the evolution of DNS security techniques and technologies. We've also included a pair of appendices, the first mapping the NIST framework core to DNS-specific outcomes and the second providing a list of currently defined DNS resource records, which summarily illustrate the diversity of data type lookups that DNS offers.

These network or cyber security technologies must continue to evolve to protect against a growing volume and diversity of attacks. As new defensive measures are implemented, criminals deftly seek new and innovative methods to attack targets to suit their nefarious purposes. Attack strategies have grown increasingly sophisticated as have defense mechanisms in response. As this arms race spirals onward, don't lose sight of protecting your DNS. We hope this book helps you understand the threats against your DNS and the mechanisms you can implement to defend and protect against them.

MICHAEL DOOLEY

TIMOTHY ROONEY

ACKNOWLEDGMENTS

We would both like to thank Thomas Plevyak, Veli Sahin, and Mary Hatcher, our editors at IEEE Press for their ongoing support and encouragement. We'd also like to thank Scott Rose, Paul Mockapetris, Paul Vixie, Greg Rabil, and Stu Jacobs for their time spent reviewing proposals and drafts of this book and for providing extremely valuable feedback. Their feedback has vastly improved the quality and usefulness of this book.

Michael: I would like to thank my family, my wife Suzanne, my son Michael, and my daughter Kelly, for all their love and support and allowing me to be distracted at home while I was working on this book. And I can't forget my lovable dog Bailey and crazy Ollie as well. I would also like to thank the following individuals who are my friends and co-workers. I have had the pleasure to work with some of the best and brightest people in the world, and I am truly blessed. In no particular order: Karen Pell, Steve Thompson, Greg Rabil, John Ramkawsky, Alex Drescher, and Bob Lieber. I would also like to acknowledge the original Quadritek leadership team that I had the privilege to work with as we helped to define and create the IP Address Management market back in the early years, specifically including Joe D'Andrea, Arun Kapur, and Keith Larson.

Timothy: I would first like to thank my family especially my wife LeeAnn, and my daughters Maeve and Tess as well as Uncle Jimmy for their love and support during the development of this book. I would also like to thank the following individuals with whom I have had the pleasure to work and from whom I have learned tremendously about networking technologies among other things: Greg Rabil, John Ramkawsky, Andy D'Ambrosio, Alex Drescher, Steve Thompson, David Cross, Marco Mecarelli, Brian Hart, Frank Jennings, and those I have worked with at BT, Diamond IP, INS, and Lucent. From my formative time in the field of networking at Bell Laboratories, I thank John Marciszewski, Anthony Longhitano, Sampath Ramaswami, Maryclaire Brescia, Krishna Murti, Gaston Arredondo, Robert Schoenweisner, Tom Walker, Charlene Paull, Frank DeAngelis, Ray Pennotti, and particularly my mentor, Thomas Chu. I also wish to acknowledge others who have otherwise inspired me to press on to complete this and affiliated works, including Peter Tsai, Elle Carpenter, Howard Falick, Holly Weller, Steve Wheeler, Ken Schumaker, Martin Wellsted, Craig Hamilton, and my esteemed co-author, Michael Dooley.

1INTRODUCTION

WHY ATTACK DNS?

The Domain Name System (DNS) is fundamental to the proper operation of virtually all Internet Protocol (IP) network applications, from web browsing to email, multimedia applications, and more. Every time you type a web address, send an email or access an IP application, you use DNS. DNS provides the lookup service to translate the website name you entered, for example, to its corresponding IP address that your computer needs to communicate via the Internet.

This lookup service is more commonly referred to as a name resolution process, whereby a worldwide web “www” address is resolved to its IP address. And a given web page may require several DNS lookups. If you view the source of a random web page, for example, count the number of link, hypertext reference (href), and source (src) tags that contain a unique domain name. Each of these stimulate your browser to perform a DNS lookup to fetch the referenced image, file or script, and perhaps pre-fetch links. And each time you click a link to navigate to a new page, the process repeats with successive DNS lookups required to fully render the destination page.

Email too relies on DNS for email delivery, enabling you to send email using the familiar user@destination syntax, where DNS identifies the destination's IP address for transmission of the email. And DNS goes well beyond web or email address resolution. Virtually every application on your computer, tablet, smartphone, security cameras, thermostats, and other “things” that access the Internet require DNS for proper operation. Without DNS, navigating and accessing Internet applications would be all but impossible.

Network Disruption

An outage or an attack that renders the DNS service unavailable or which manipulates the integrity of the data contained within DNS can effectively bring a network down from an end user perspective. Even if network connectivity exists, unless you already know the IP address of the site to which you'd like to connect and enter it into the browser address field, you'll be unable to connect, and you won't see any linked images or content.

Such an event of the unavailability of DNS will likely spur a flurry of old fashioned phone calls to your support desk or call center to politely report the problem. IP network administrators generally desire to minimize such calls to the support center, polite or otherwise, given that it forces those supporting the network to drop what they're doing and resolve the issue with the added pressure of visibility across the wider IT or Operations organization.

DNS as a Backdoor

Just as DNS is the first step in allowing users to connect to websites, it is likewise usable by bad actors to connect to internal targets within your enterprise and external command and control centers for updates and directives to perform nefarious tasks. Given the necessity of DNS, DNS traffic is generally permitted to flow freely through networks, exposing networks to attacks that leverage this freedom of communications for lookups or for tunneling of data out of the organization.

Thus, attacking DNS could not only effectively bring down a network from users' perspectives, leveraging DNS could enable attackers to communicate to malware-infected devices within the network to initiate internal attacks, to exfiltrate sensitive information, or to perform other malicious activity. Malware-infected devices may be enlisted to serve as remote robots or bots under the control of an attacker. A collection of such bots is referred to as a botnet. A botnet enables an attacker to enlist an army of devices potentially installed around the world to perform software programmable actions.

By its very nature, the global Internet DNS system serves as a distributed data repository containing domain names (e.g., for websites) and corresponding IP address information. The distributed nature of DNS applies not only to the global geographic distribution of DNS servers, but to the distribution of administration of the information published within respective domains of this repository. DNS has proven extremely effective and scalable in practice and most people take DNS for granted given this and its historical reliability. However, its essential function and decentralized architecture serve to attract attackers seeking to exploit the architecture and rich data store for sinister activities.

While DNS is the first step in IP communications, many enterprise security strategies trivialize or startlingly even ignore its role in communications and therefore its susceptibility to attacks on this vital network service or on the network itself. Most security strategies and solutions focus on filtering “in-band” communication flow in order to detect and mitigate cyber attacks. However, as we shall see, filtering DNS traffic can support a broader network security plan in providing additional information for use in identifying and troubleshooting attack incidents. This book is intended to provide details regarding the criticality of DNS, its vulnerabilities, and strategies you can implement to better secure your DNS infrastructure, which will in turn better secure your overall network.

DNS BASIC OPERATION

Figure 1.1 illustrates the basic flow of a DNS query. Upon entry of the desired destination by name, www.example.com in this case, software called a resolver is invoked by the application, for example, web browser. This resolver software is typically included with the device operating system. If a connection had recently been made to this website, its IP address may already be stored in the resolver cache. The resolver cache helps improve resolution performance by temporarily keeping track of recently resolved name-to-IP address mappings. In such a case, the resolver may return the IP address immediately to the application to establish a connection without having to query a DNS server.

Figure 1.1. Basic DNS Resolution Flow

If no relevant information exists in the resolver cache the device will query its recursive DNS server. The role of the recursive server is to locate the answer to the device's query. The recursive server is itself a resolver of the DNS query; we refer to the resolver on the originating device as a stub resolver as it initiates a query to its recursive server, and it relies solely on the recursive server to locate and return the answer. The stub resolver is configured with DNS server IP addresses to query as part of the IP network initialization process. For example, when a device boots up, it typically requests an IP address from a dynamic host configuration protocol (DHCP) server. The DHCP server can be configured to not only provide an IP address but the IP addresses of recursive DNS servers to which DNS queries should be directed. Use of DHCP in this manner facilitates mobility and efficiency as addresses can be shared and can be assigned based on the relevant point of connection to the IP network.

As we mentioned, the recursive DNS server's role is to resolve the query on behalf of the stub resolver. It performs this role using its own cache of previously resolved queries or by querying DNS servers on the Internet. The process of querying Internet DNS servers seeks to first locate a DNS server that is authoritative for the domain for which the query relates (example.com in this case) and then to query an authoritative server itself to obtain an answer that can be passed back to the client, thereby completing the resolution process. The location of the authoritative server is determined by querying Internet DNS servers that are responsible for the layers of the domain tree “above” or “to the right” of the domain in question. We'll discuss this process in more detail in Chapter 2. The recursive server caches the resolution information in order to respond more quickly to a similar query without having to re-seek the answer on the Internet.

To access your website, people need to know your web address, or technically your uniform resource locator or URL. And you need to publish this web address in DNS in the form of a resource record so browsers can locate your DNS servers and resolve your www address to your web server's IP address. Multiple, at least two, authoritative DNS servers must be deployed to provide services continuity in the event of a server outage. Generally, an administrator configures a master server that then replicates or transfers its domain information to one or more slave servers. We will discuss more details on this process and server roles in Chapter 2.

Basic DNS Data Sources and Flows

Figure 1.2 illustrates a subset of the various data stores for DNS data and corresponding data sources. The authoritative DNS servers must be configured to answer queries for domain name-to-IP address mappings for this domain for which they are authoritative. Depending on your DNS server vendor implementation, DNS configuration information may be supplied by editing text files, using a vendor graphical user interface (GUI) or deploying files from an IP address management (IPAM) system as shown in Figure 1.2. Each server generally relies on a configuration file and authoritative servers store DNS resolution information in zone files or a database. Some implementations utilize dynamic journal files to temporarily store DNS information updates prior to committing to zone files in an effort to improve performance. All vendor implementations feature the ability to update DNS resolution information on a given “master” server which will then replicate this information to other authoritative servers to provide redundancy of this information.

Figure 1.2. DNS Query Flow and Data Sources

Figure 1.2 also illustrates various DNS message types that are used to query for and configure DNS information. The recursive and iterative query types enable the resolution of DNS data, while dynamic updates and zone transfers enable the dynamic updating and replication of resolution information, respectively. DNS configuration information includes the parameters of operation for the DNS server daemon as well as published resolution data within zone files. We'll describe these in more detail in Chapters 2 and 3, but for now, you may observe that there are several independent data sources that may configure your DNS information as you permit.

DNS Trust Model

The DNS trust model refers to how DNS information flows among these components of the DNS system. In general, information received by other components in the system is trusted though various forms of validation and authentication can improve trustworthiness as we shall discuss later.

From the client resolver perspective, the client trusts its resolver cache and the recursive server to provide answers to DNS queries. Should either trusted data source be corrupted, the resolver could inadvertently redirect the user application to an inappropriate destination. For example, a user, thinking he or she is connecting to his or her bank, may inadvertently be connected to an imposter site in an attempt by an attacker to collect authentication credentials or financial information.

The recursive server trusts its cache and the various DNS servers it queries, whether internally on the enterprise network or externally on the Internet. It relies not only on accurate responses from authoritative DNS servers but on other domain servers which provide referrals to locate DNS servers authoritative for the domain in question. Referral answers are generally provided by the Internet root servers as well as top level domain (“TLD,” e.g., .com, .edu, .net, etc.) servers as shown in Figure 1.1. Referrals may also be provided by other servers operated internally, externally, or by DNS hosting providers to walk down the hierarchical domain tree to locate the authoritative DNS servers. Corruption of recursive server DNS information, whether referral or resolution data, could have broader impacts affecting many clients given the caching of seemingly accurate resolution data. Each user attempting to connect to a website whose resolution information has been poisoned may be provided such falsified information from the recursive server cache.

Authoritative DNS servers are so called given that they are purportedly operated by or on behalf of the operator of a given DNS domain who is responsible for the information published on these servers. Resolvers attempting to resolve hostnames within the domain of the authoritative server trust the server to respond with accurate information, where accurate means as published by the domain administrator. Information published within authoritative DNS servers originates from a variety of sources as shown in Figure 1.2, including manually edited text files, inter-server transfers and updates, and/or use of IPAM solutions. Inter-server transfers refer to master–slave replication, while updates may originate from other DNS servers, DHCP servers, other systems, or even end user devices if permitted by administrators. Corruption of authoritative server configuration information impacts all Internet users attempting to connect with resources within the corresponding domain.

DNS Administrator Scope

As a DNS administrator, you'll generally need to be concerned first with your internal users or customers attempting to resolve domain names within your internal infrastructure and those on the Internet. For access to your internal systems, you'll need to configure authoritative DNS servers with the domain name to IP address mappings for those systems for which internal users need access. We'll refer to this naming and address mappings for internal infrastructure as your internal namespace.

To enable your users to access Internet websites, you'll need to manage recursive servers which your users can query to locate external authoritative servers from which to seek query answers.

You will also need to provide external Internet and extranet users with name to address mappings for your Internet reachable systems such as websites and email servers. Note that this external namespace will likely be a subset of your internal namespace, though ideally totally independent. We'll discuss approaches to serving these constituencies beginning with respective DNS server deployment approaches in Chapter 5.

SECURITY CONTEXT AND OVERVIEW

The practice of network security essentially boils down to the management of risks against a network. Risks may consist not only of malicious attacks but also include natural or man-made disasters, poor architecture design, unintended side effects of legitimate actions, and user error. Development of a security plan requires enumeration of risks, identification of vulnerabilities which may be exploited to affect the risk, characterization of the likelihood of each risk, determination of the impact the risk presents to the organization and defining controls to constrain the risk impact for each. Application of controls seeks to mitigate the risk to eliminate, or more likely yield a lower level of residual risk that is more tolerable to the organization.

We will apply the National Institute of Standards and Technologies (NIST) Cybersecurity Framework (1) as the context within which we discuss security approaches and strategies. The cybersecurity framework has emerged as a de facto standard worldwide. While no security framework can be “one size fits all,” it provides a taxonomy and methodology for organizations to characterize their current and desired (planned) cybersecurity status, to prioritize initiatives to enable improvement of their current status toward their desired state and to communicate among stakeholders about cybersecurity risk. The framework provides guidance for organizations to perform risk assessments and to plan to manage risk in light of each individual organization's vulnerabilities, threats, and risk tolerance.

The framework relies on existing security standards including COBIT 5 (2), ISA 62443 (3), ISO/IEC 27000 (4), NIST SP 800-53 Rev4 (5) among others. It references specific sections of these supporting standards within each of the major framework activities. As such, the framework essentially provides a common overlay among these various standards to define a language for expressing and managing cybersecurity risk.

Cybersecurity Framework Overview

NIST's cybersecurity framework seeks to facilitate communications within and external to an organization when conveying security goals, maturity status, improvement plans, and risks. The framework is comprised of three major components:

The framework core defines security activities and desired outcomes for the lifecycle of an organization's management of cybersecurity risk. The core includes detailed references to existing standards to enable common cross-standard categorization of activities. The core defines these activities across five functions.

Identify – deals with what systems, assets, data, and capabilities require protection

Protect – implement safeguards to limit the impact of a security event

Detect – identification of incidents

Respond – deals with security event management, containing incident impacts

Recover – resilience and restoration capabilities

Each function has a set of defined categories and subcategories which we will explore later in this chapter.

The

framework profile

defines the mechanism for assessing and communicating the current level of security implementation as well as the desired or planned level of implementation. The profile applies business constraints and priorities, as well as risk tolerance to the framework core functions to characterize a particular implementation scenario.

The framework implementation tiers define four gradations of maturity level of security implementations, ranging from informal and reactive to proactive, agile and communicative.

Tier 1 – Partial – Informal, ad hoc, reactive risk management practices with limited organizational level risk awareness and little to no external participation with other entities.

Tier 2 – Risk Informed – Management approved with widely established organization-wide risk awareness but with informal and limited organization-wide risk management practices and informal external participation.

Tier 3 – Repeatable – Risk management practices are formally approved as policy with defined processes and procedures which are regularly updated based on changes in business requirements as well as the threat and technology landscape. Personnel are trained and the organization collaborates with external partners in response to events.

Tier 4 – Adaptive – Organization-wide approach to managing cybersecurity risk where practices are adapted to the changing cybersecurity landscape in a timely manner. The organization manages risk and shares information with partners.

The implementation tiers enable an organization to apply the rigor of a selected maturity level to their target profile definition to align risk management practices to the particular organization's security practices, threat environment, regulatory requirements, business objectives, and organizational constraints.

Framework Implementation

Implementation of the cybersecurity framework entails interaction and feedback among three major organizational tiers.

Executive level – with a focus on organizational and business risk, the executive level sets out business priorities, risk tolerance, and security budget to those in the business/process level.

Business/Process level – in consideration of business priorities, risk tolerance, and budget, this level focuses on critical infrastructure risk management, defining a cybersecurity framework target profile for the organization based on these inputs and the current profile, allocating budget accordingly to closing gaps between these profiles. This level feeds back to the Executive level any changes in current and future risk based on security threats and technologies and provides implementation directives to the Implementation and Operations level.

Implementation/Operations level – responsible for framework profile implementation and risk management tactics. Feedback to the business/process level includes implementation progress, issues, and changes in assets, vulnerabilities, and threats.

The cybersecurity framework document leverages this three-tier organizational structure and identifies the following basic steps in defining a cybersecurity plan:

The first step starts at the Executive level to identify your business and organizational priorities and objectives and risk tolerance in order to scope out in priority order the set of assets and systems within the network to focus on.

Within the selected scope, the second step entails the organization enumerating affected systems and assets, regulatory and legal requirements, risk tolerance, and corresponding threats and vulnerabilities associated with the scoped systems and assets.

This step consists of defining the current status of cybersecurity implementation. Using the framework core, you can identify your level of compliance and discipline in implementing each function category and subcategory. The resulting analysis becomes your Current Profile defining a snapshot of your organization's alignment with the framework.

A risk assessment should then be conducted to enumerate risks in terms of asset vulnerabilities, potential threats and respective likelihood, and the potential network and business impact of each threat.

The fifth step entails defining the desired cybersecurity activities and outcomes by defining the Target Profile. Using the framework core along with business-specific categories and subcategories, desired outcomes can be enumerated.

Comparing the Target Profile with the Current Profile, one may define the gaps which need to be addressed to evolve from the current status to the desired state. Based on the cost to implement gap closure for each category and subcategory in light of its corresponding security priority, the business can determine whether to invest in closing that gap based on the corresponding value to the business. This helps prioritize which gaps will be addressed initially, which can be addressed later, and at what cost for each from a capital, expense, and resource perspective.

The final step consists of formally defining and implementing an action plan to address the prioritized gaps. As implementation ensues within the Implementation/Operations level, and snapshots of current or in-progress status may be communicated by updating the Current Profile.

The Current and Target profiles enable communication within or outside an organization of its current and planned cybersecurity implementation state, respectively. The broad use of this common framework facilitates communication among these entities and stakeholders using well-defined terms.

Scoping DNS Once your executive team identifies and prioritizes DNS as within the scope of priority for applying security controls, your business team needs to define the corresponding set of affected DNS components. Table 1.1 illustrates an example scoping of basic business priorities that affect DNS to corresponding affected DNS components which could be considered for application of security controls.

TABLE 1.1 DNS Scope Examples

Broad DNS Scope

Affected DNS Components

Accurately resolving the organization's published namespace on the Internet

Authoritative DNS servers and/or your external DNS hosting provider configured to resolve your namespace

Accurately resolving the organization's namespace for internal users

Device stub resolvers

Recursive DNS servers configured to resolve DNS queries from internal device resolvers

Authoritative DNS servers configured to resolve your namespace for internal resolvers

Accurately resolving Internet domain names for legitimate internal user access to the Internet

Device stub resolvers

Recursive DNS servers configured to resolve DNS queries from internal device resolvers

Current Profile Once the organization defines the scope as including one or all of these broad areas, a Current Profile should be developed regarding the current security level of the associated DNS components. Consider each of the categories and subcategories as it applies to your current DNS management and security policies and procedures. As with the cybersecurity framework itself, you may have additional processes or desired outcomes for consideration in your implementation.

Risk Assessment The next major step in the process comprises the risk assessment for affected DNS components. This step entails enumeration of each possible threat event. A threat event is an event that upon occurrence could impact the network and business detrimentally. Threat events may include events beyond security-related threats such as natural or man-made disasters so you may wish to consider all possible threats to secure your network and DNS in particular.

For each identified threat, consider the likelihood of the threat event occurring as well as the impact on your network and business should the threat event occur. The likelihood of a given threat event may be estimated by considering known vulnerabilities that may be exploited by an attacker to instigate the threat event. It's useful to plot each threat on a graph where the x-axis relates the relative impact of the threat while the y-axis reflects its relative likelihood. The relative impact could be estimated in terms of resource unavailability or downtime, end user or customer dissatisfaction, and/or lost revenue. Plotting risks in this manner can help you prioritize for which risks more urgent remediation is required.

As you may conclude from Figure 1.3, Risk #4 (R4) has a relatively high likelihood and high impact. This risk should likely be mitigated with the highest priority. Risk #2 of slightly lower impact and less likelihood should be next. Even though Risk #1 has a higher likelihood than Risk #2, its impact is substantially less. By applying controls, the goal is to shift each unmitigated risk down and to the left to render a lower overall residual risk to the organization.

Figure 1.3. Risk Likelihood-Impact Plot

To add some structure to the process of assessing risk on a per system level, NIST published Federal Information Processing Standards (FIPS) Publication 199 (6). This publication defines standards for categorizing information and information systems based on the potential impact on the organization should certain threat events occur for use in assessing risk to an organization. Categorization is performed based on three security objectives for information and information systems.

Confidentiality – the protection of information from unauthorized disclosure

Integrity – protection against unauthorized modification or destruction of information

Availability – protection against disruption of access to or use of information or system

FIPS Publication 199 defines three levels of impact on an organization for each of these objectives as follows:

Low impact – expected to have a limited effect on the organization's operations, assets, or individuals; for example, loss of confidentiality, integrity, or availability could degrade an organization's capability though with noticeably reduced effectiveness. It could also result in minor damage to some or all of the organization's assets, minor financial loss and/or minor harm to individuals.

Moderate impact – expected to have serious adverse impact on the organization's operations, assets, or individuals; for example, loss of confidentiality, integrity, or availability could cause significant degradation of an organization's capability though with substantially reduced effectiveness. It could also result in significant damage to the organization's assets, significant financial loss, and/or significant but not life-threatening harm to individuals.

High impact – expected to have severe or catastrophic impact on the organization's operations, assets, or individuals; for example, loss of confidentiality, integrity, or availability could cause severe degradation of an organization's capability including the inability to perform one or more of its primary functions. It could also result in major damage to the organization's assets, major financial loss, and/or severe or catastrophic and life-threatening harm to individuals.

Categorization of each of the three objectives as low, moderate, or high is performed on various types of information at rest (e.g., within a file on a server) or in motion (e.g., within an IP packet traversing your network) through a network and on information systems themselves (e.g., servers, laptops, etc.). Examples of information types might be published DNS zone information or DNS query transaction information. The security categorization (SC) for the types and systems within your organization is represented as a tuple as illustrated in the following example:

For DNS, generally the highest requirement for most organizations is integrity, protecting DNS data from unauthorized changes. After all, users are relying on DNS data to enable them to connect to an intended destination. High availability likewise is paramount so that the resolution process and data is available. Confidentiality is typically lower in relative priority since DNS data generally is public information. However, many organizations publish a set of DNS information for resolution only for all or certain internal users and prohibit access for external users. In this scenario, for this type of information, confidentiality might be considered moderate if not high.

Target Profile and Security Planning Your risk assessment will provide valuable input when prioritizing security initiatives in your security plan. We've included a sample of a DNS-specific framework core in Appendix A as a starting point. You can use our example framework core or create your own. Creating a target profile using the framework core allows you to define the desired outcomes for each of the defined categories along with those you may choose to add in. The differences between your target profile and your current profile define your to-do list of tasks, implementations, and process improvements necessary to transition from your current security implementation state to your desired target state.

To mitigate a given risk, a control or set of controls may be implemented to minimize the likelihood and/or impact of a given risk. Your risk assessment results will enable you to prioritize resources and efforts to apply controls in order to mitigate higher impact and higher likelihood threat events. A control is an implementation of technology, processes, and/or people resources that is intended to reduce such risks. Generally, a residual risk remains, which if excessive, may behoove you to apply additional controls.

In general, the application of multiple controls yields a defense in depth security approach that provides multiple lines of defense for a given threat event. Should an attacker penetrate one control, another is provided to hamper the further progress of the attack. When considering a given host, for example, a DNS server, a defense in depth approach entails securing each of the layers defined in Table 1.2.

TABLE 1.2 Defense in Depth Layers

Data at rest

Data residing on the host, e.g., a file on a hard drive, thumb drive, or database

Configuration files, zone files, resource records, cached data

Data in transit

Data sent or received by the host

DNS queries and responses, DNS updates, zone transfers, configuration updates

Application

Reputability of each application running on the host

ISC BIND, Unbound, NSD, PowerDNS, Knot DNS, etc., i.e., your deployed DNS server application(s)

Host hardware and operating system

Reputability of the hardware manufacturer, software (e.g., BIOS) manufacturer, kernel and operating system hardening tactics

DNS server hardware, kernel, and operating system

Internal network

Internal firewalls, host firewalls, malware presence within internal infrastructure

Permissible ports and protocols for DNS, DNS ACLs, and port ACLs

Network perimeter

Boundary between trusted and untrusted environments

Permissible ports and protocols for DNS traffic traversal

External network

Internet-based vulnerabilities

Inbound purported DNS traffic; external DNS hosting providers; domain registrar(s)

Physical security

Building/datacenter/computer access, access control, property removal policies

DNS server physical security

Operations

Adherence to security policies by people, processes, and technologies; policy verification and enforcement

DNS configuration and transaction audits; training, holistic security awareness

Several aspects of this defense in depth strategy are common across several elements of your network, for example, all servers require strong credentials and all remote administrator access must be encrypted. Such common controls provide consistent protection and should apply to your DNS servers as well.

DNS-specific controls such as those example attributes outlined above provide added protection. The NIST framework core implicitly recommends a defense in depth strategy. NIST has also published a DNS-specific guide for secure DNS deployment (7). This useful guide describes DNS-specific controls with a particular focus on securing the integrity of DNS data. This guide provides thorough procedures for securing a BIND DNS server, including configuration and management of DNS security extensions (DNSSEC). We'll refer to this guide as well throughout this book where appropriate.

Your security plan should define specific control implementations designed to mitigate specific threat events. Because each planned implementation will require organizational resources with respect to personnel involvement and perhaps capital and/or expense, you will generally need to prioritize and/or implement the plan in stages over time as resources permit. Application of the NIST cybersecurity framework provides structure and common language for efficiently conveying security status and goals. It also facilitates prioritization of security gaps to enable staging of the implementation of DNS and network security controls.

WHAT'S NEXT

Chapters 2 and 3 provide an overview of how DNS works with details regarding the DNS protocol, respectively. Chapter 4 introduces major security-related threats to and vulnerabilities of the DNS system. Chapters 5–11 delve more deeply into each vulnerability and defines detection and mitigation strategies accordingly. Chapter 12 discusses an overall security management architecture in terms of monitoring and maintaining your security approach and in defining response policies to security incidents. Chapter 13 discusses particular uses of DNS within broader security initiatives such as anti-spam and certificate validation.

2INTRODUCTION TO THE DOMAIN NAME SYSTEM (DNS)

DNS OVERVIEW – DOMAINS AND RESOLUTION

As we introduced in Chapter 1, DNS is a foundational element of IP communications. DNS provides the means for improved usability of IP applications, such as insulating end users from typing IP addresses directly into applications like web browsers and enabling web servers to serve web pages compromised of diverse linked content. To communicate over an IP network, an IP device needs to send IP packets to the intended destination; and each IP packet header requires both source and destination IP addresses. DNS provides the translation from a user-entered named destination, for example, web site www address, to its IP address such that the sending device may populate the destination IP address with the address corresponding to the entered domain name.

DNS is not only useful for Internet users but also for network administrators. By publishing name-to-IP address mappings in DNS, the administrator gains the freedom to change IP addresses as needed for network maintenance, service provider changes, or general renumbering without affecting how end users connect. I can map my www address to 192.0.2.55 today and change it to 198.51.100.23 tomorrow without affecting how users reach my website. Of course, I'd need to keep both addresses active for some time given the caching of the former mapping in various recursive servers that had queried for my address before I made the change.

This level of indirection is also useful when configuring Internet “things” such as home appliances, smart cars, surveillance cameras, etc. that can connect to the Internet independently of user-initiated commands. Such connections may be initiated first by a DNS lookup of its configured web address, to which it connects to communicate a status update, alert, or other information. The thing's home website IP address may be changed as needed by changing its DNS entry in a manner similar to that just described.

As a network service, DNS has evolved from this simple domain name-to-IP address lookup utility to enabling very sophisticated “lookup” applications supporting voice, data, multimedia, and even security applications as we shall discuss in Chapter 13. DNS has proven extremely scalable and reliable for such lookup functions. We'll discuss how this lookup process works after first introducing how this information is organized.

Domain Hierarchy

The global domain name system is effectively a distributed hierarchical database. Each “dot” in a domain name indicates a boundary between tiers in the hierarchy, with each name in between dots denoted as a label. The top of the hierarchy, the “.” or root domain provides references to top-level domains, such as .com, .net, .us, .uk, which in turn reference respective subdomains. Each of these top-level domains or TLDs is a child domain of the root domain. Each TLD has several children domains as well, such as ipamworldwide.com with the ipamworldwide domain beneath the com domain. And these children may have child domains and so on.

As we read between the dots from right to left, we can identify a unique path to the entity we are seeking. The text left of the leftmost dot is generally1 the host name, which is located within the domain indicated by the rest of the domain name. A fully qualified domain name (FQDN) refers to this unique full [absolute] path name to the node or host within the global DNS data hierarchy. Figure 2.1 illustrates a FQDN mapping to the tree-like structure of the DNS database. Note that the trailing dot after .com. explicitly denotes the root domain within the domain name, rendering it fully qualified. Keep in mind that without this explicit FQDN trailing dot notation, a given domain name may be ambiguously interpreted as either fully qualified or relative to the “current” domain. This is certainly a legal and easier shorthand notation, but just be aware of the potential ambiguity.

Figure 2.1. Domain Tree Mapping to a Fully Qualified Domain Name

NAME RESOLUTION

To illustrate how domain information is organized and how a DNS server leverages this hierarchical data structure, let's take a look at an example name resolution. Let's assume you'd like to connect to a website, www.example.com. You'd enter this as your intended destination in my browser. The application (browser in this case) utilizes the sockets2 application programming interface (API) to communicate with a portion of code within the TCP/IP stack called a resolver. The resolver's job in this instance is to translate the destination domain name you entered into an IP address that may be used to initiate IP communications. If the resolver is equipped with a cache and the answer resides in cache, the resolver responds to the application with the cached data and the process ends.

If not cached, the resolver issues a query for this domain name to the local recursive DNS server, requesting the server provide an answer. The IP address of this local DNS server is configured either manually or via DHCP using the domain server's option (option 6 in DHCP and option 23 in DHCPv6). This DNS server will then attempt to answer the query by looking in the following areas in the specified order and as illustrated in Figure 2.2. We recommend you specify at least two local DNS server addresses to provide resilient resolution services in the event of a single DNS server failure.

Figure 2.2. Recursive and Iterative Queries in Name Resolution

We refer to this DNS server to which the resolver issues its query as a recursive server

3DNS PROTOCOL AND MESSAGES

Attackers may leverage the DNS protocol itself to launch attacks or attempt to infiltrate DNS data in motion. To help us understand such techniques, this chapter provides an overview of DNS protocol operations and message formats.

DNS MESSAGE FORMAT

Encoding of Domain Names

In Chapter 2, we discussed the organization of DNS information into a domain hierarchy as well as the basics of how a client or resolver performs resolution by issuing a recursive query to a DNS server which in turn iterates the query in accordance with the domain hierarchy to obtain the answer to the query. Next we'll dig deeper into the DNS query and general message format, but we'll first introduce the representation of domain names within DNS messages. Domain names are formatted as a series of labels. Labels consist of a one byte length field followed by that number of bytes/ASCII characters representing the label itself. This sequence of labels is terminated by a length field of zero indicating the root “.” domain. For example, the series of labels for www.ipamworldwide.com would look like the following in ASCII format. Length bytes are highlighted in darker shading in Figure 3.1.

Figure 3.1. DNS Labels

Starting at the upper left, the value “3” of the first length byte indicates that the following three bytes comprise first label, “www.” The fifth or next byte after this is our next length byte, which has a value of “13” (0xD1), which is the length of “ipamworldwide.” After this label, the following byte of value “3” is the length of “com.” Finally, the zero-value byte indicates the root “.” domain, fully qualifying the domain name. Note that the darker shaded bytes in the figure are encoded as length bytes to differentiate them from host or domain name characters containing numbers. The first byte in a name will almost always2 be a length byte followed by that number of bytes representing the first label, immediately followed by another length byte to eliminate ambiguity.

Name Compression

A given DNS message may contain multiple domain names, and many of these may have repetitive information, for example, the ipamworldwide.com. suffix. The DNS specification enables message compression in order to reduce repetitive information and thereby reduce the size of the DNS message. This works by using pointers