dns_bind esample pa raport

8/4/2019 DNS_BIND Esample Pa Raport

http://slidepdf.com/reader/full/dnsbind-esample-pa-raport 1/23

Student number: xxxxxxxx

Practical UNIX Security Full Time Course Work 1

The role and function of Bind/DNSwithin a distributed network

- From an administration and security perspective

STUDENT NUMBER: xxxxxxxx

Module Code: SY4S04

Module Title: Practical UNIX Security Lecturer: Dr. Andrew Blyth

Submission Date: 28th April 2008



Student number: 07238959

I. Abstract Computers that communicate on the Internet use IP addresses (Internet Protocol

addresses) to find the correct system to talk to. An IP address is a 32 bit numerical

address that looks like this: 64.233.183.991. Many network system administrators

probably read IP addresses as easy as the computers do, but for the average user it is alot easier to remember and to use addresses like www.google.com. We therefore need

a technology that maps the easy-to-remember-human addresses with the IP addresses

used by the computers. DNS do just that. Through out this report we will focus on the

UNIX implementation of DNS – the Berkeley Internet Name Domain (BIND), it’s

role and functions in a distributed network, it’s security issues from an administrators

point of view – and we will discuss possible solutions and compare it with other

systems.

II. Table of content

I. ABSTRACT 2

II. TABLEOFCONTENT 2

III. INTRODUCTION 3

IV. ANALYSIS 4

A. AFUNCTIONINGSERVICE… 4

B. POISONINGTHEDNSCACHE… 5

C. DNSSPOOFINGATTACKS 8

D. AVOIDINGCACHEPOISONINGANDDNSSPOOFING 10I. SPLITDNS 10

II. DNSSECURITYEXTENSION 11

III. SECURINGZONETRANSFERS 14

E. S AFEGUARDINGYOURINFORMATION 15

I. LOGGINGTHEDATATRANSFERS 15

II. SECURINGTHEINFORMATION 18

V. SUMMARYANDCONCLUSIONS 20

VI. REFERENCES 22

A. BOOKS 22B. WEBSITES 22

1 J. D. Wegner and Robert Rockell, (2000), Chapter 1, IP Addressing and Subnetting,

including IPv6 , Syngress Media




IV. AnalysisIn order for BIND / DNS to function as it should, there are several points we need to

consider:

We need to ensure that the information our name servers give out – arecorrect. We need to ensure that the information our name servers retrieve from other

name servers – are correct. We need to ensure that the service in it self – is resistant to attempts on

gaining unauthorised information or access. We need to ensure that we can transfer data – both name-to-IP mappings and

zone transfers, in a safe and secure manner. We need to ensure that we can log any data transfer performed to and from our

name servers.

a. A functioning service…Various implementations of name servers may do tasks in different ways, but one

could divide their tasks in to two major components:

Handle request from applications to map domain names to IP addresses Handle request from other name servers to map domain names to IP addresses

When a request comes in, the name server does one of three things depending on

implementation and configuration:

If the IP address for the requested domain is already known (in the DNSCache) – it replies with the address in question. If the IP address for the requested domain is not known, it will forward therequest to a name server with authority in a higher hierarchy level ( see figure 1) .

If the requested domain name is invalid or does not exist, it will reply with anerror.

Figure 1: Example of a forward lookup query (T.D)




There are several tools one can use to perform a query. In Linux, the most used ones

are host:

Screen shot 1

And dig

Screen shot 2

Looking at Figure 1, there is five name servers involved in this query, and we need to

believe that they do what they are supposed to. Nevertheless, the fact is that there is

ways to make any of the five servers spread false information.

b. Poisoning the DNS cache…One of the ways – is by poisoning the DNS cache. A name server will save the

information it obtains temporarily – in case other clients on the network asks for the

same domain name.




Figure 2: Example of a DNS cache poisoning (T.D)

In Figure 2, an attacker has control over the domain hacker.domain – where he has set

up a name server. By using tools such as host, dig or nslookup he could then find the

name servers for a site and add records of these name servers in his own DNS zone.

Of course, these records will have mappings to IP addresses of the attackers own

choice. The following steps will now poison your DNS cache:

The attacker tricks you into querying his name server for www.hacker.domain –

for instance by sending you an email with a link.

Screen shot 3

You click on the link, and your DNS will issue a query to ns.hacker.domain. ns.hacker.domain will respond, and in addition to the records for

www.hacker.domain, the records of bank.com will be in that response.




Screen shot 4

Screen shot 5

Your DNS will cache this information for later use, and hand the information

to you upon request. So you type in www.bank.com to make a largetransaction, and you end up in www.hacker.domain. Of course you are required to type in username and password, and suddenly

the attacker controls your bank account.

Daniel J. Bernstein pointed out this problem early8, along with the solution to the

problem: Don’t allow name servers to cache information other than the ones queried

about.

8Daniel J. Bernstein: Notes on the Domain Name System. Retrieved 16 March, 2008 from:

http://cr.yp.to/djbdns/notes.html#poison




This solution was adopted by BIND in version 4.9.6, but according to Computer

Emergency Readiness Team, best practice then was to upgrade to version 8.1.1 if

there was no need for the shared object client subroutine library9. As we can see in the

screen shot below (Screen shot 6), the Additional Section in this request does not contain

any pointers to www.bank.com even though present in the zone file

Screen shot 6

c. DNS spoofing attacks

The effect on the decision to drop all other information than the ones queried aboutwas that attackers needed another way of distributing false records through name

servers. The solution was to spoof (impersonate) legitimate responses to queries

issued.

An ordinary DNS query is sent by way of the UDP protocol to port 53 on the nameserver. One of the efforts to stop attackers from being able to spoof DNS responses is

to use random source port numbers. Since the source port field in an UDP packet is 16 bits10, one should think that the efficiency of this method is higher than it actually is.

Also, the DNS packet itself contains a 16-bits transaction ID field to authenticateanswers to a query (see Figure 3).

9 CERT. (1997, August 13) CERT® Advisory CA-1997-22 BIND - the Berkeley Internet Name

Daemon. Retrieved 18 March, 2008 from: http://www.cert.org/advisories/CA-1997-22.html 10

Wikipedia contributors. (2008, March 18). User Datagram Protocol. Retrieved 18 March

2008, from: http://en.wikipedia.org/wiki/User_Datagram_Protocol




Figure 3: The structure of a DNS packet 11

Unfortunately, the UDP source port is determined when the daemon starts – thus can

be fairly easy picked up by anyone with a packet sniffer 12

. In addition to this, the

transaction ID was discovered not to be random but sequential, making it possible for

attackers to guess the next ID number 13

.

Figure 4: Example of DNS spoofing (T.D)

11Eric Pace Birkholz, (2003), Chapter 8, Special OPS Host and Network Security for

Microsoft, UNIX and Oracle , Syngress Publishing, p399-400 12

Wikipedia contributors. (2008, March 15). Packet sniffer. Retrieved 18 March 2008, from:

http://en.wikipedia.org/wiki/Packet_sniffer 13

SecureWorks.com (2007, August 13). DNS Cache Poisoning – The Next Generation.Retrieved 18 March, 2008 from: http://www.secureworks.com/research/articles/dns-cache-

poisoning




In the situation shown in figure 4, the following takes place:

The attacker starts by sending the target a mail with a link to

www.example.com

The target queries the local name server for the IP mapping

The local name server sends a DNS request to ns.example.com

The attacker now floods the local name server with response to the query,guessing the source UDP port and Transaction ID.

If one of the responses from the attacker has the correct source port (which can be picked up by a network analyser), the correct Transaction ID (which is guessable) and

reaches the local name server before the legitimate response from ns.example.com,the local name servers cache is now corrupted.

d. Avoiding cache poisoning and DNS spoofing

i. Split DNSWith BIND version 9, the transaction ID is made random and not sequential. One can

also use a technique called split DNS14-15.

Screen shot 7

Screen shot 8

14 Split DNS means that one uses two separate servers containing a BIND DNS each that

serves different purposes: one for serving internal computers with remote DNS records, and

the other for serving external computers with public DNS records about the internal network. 15Brian Hatch and James Lee, (2003), chapter 7, Hacking Linux Exposed, second edition,

McGraw Hill, p289




ii. DNS Security ExtensionSince all DNS servers are vulnerable to spoofing in one way or another, it’s suggested

to use DNSSEC16

. DNSSEC is depending on the fact that both sites (requesting server

and authoritative zone source) involved in data transfer must support DNSSEC. Theauthoritative name server signs its zone data and becomes SEP - Secure Entry Point .

The receiving name server must then be configured to support a security service and

thus be called security aware17.

Figure 5: DNSSEC uses private / public keys (T.D)

The authoritative name server signs its zone file with a private key, and the receiving

server must than have access to the public key of that zone to authenticate the zone

information it receives. This method of digitally signing documents for authenticity

has been done since Whitfield Diffie split the crypto keys in May 197518. However it

would be impossible for every name server on the Internet to send every other nameserver on the Internet its public key, so we need to make sure that the receivers can

obtain this public key in a secure manner. There is two ways of handling this problem19:

Publish the key using DNSKEY RR in the zone fileObtain the key through email, telephone or some other acceptable process

The method using DNSKEY RR in the zone file creates a chicken-and-egg situation:

In order to get the key for validating responses in a secure manner, we need the key

we are asking for to securely validate the response containing the key that we need to

16 IETF.org, (2005, March), The DNS security introduction and requirements , Retrieved 25

March from: http://www.ietf.org/rfc/rfc4033.txt 17

Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND , Apress, p283-284 18

Steven Levy, (2001), Public Key, Crypto - How the Code Rebels Beat the Government - Saving Privacy in the Digital Age 19

Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND , Apress, p285




validate the response... Therefore, DNSSEC uses the second method20. The second

method is often referred to as creating an “island of security.” The signing of the zone

is not validated by a secured parent and stands alone in “a sea of unsecured domains”,

hence an “island of security.”21

To create an island of security in BIND, one must first create a key-pair:

Screen shot 9

We also need, as stated in RFC3757, SEP keys. SEP is short for Secure Entry Point,

and these keys should only be used to verify your zone-signing keys.22 There is no

support for this in BIND 8, so it’s wise to upgrade to BIND 9.

Screen shot 10

Here (Screen shot 12), we are using the KSK option to generate key-signing-keys. One

should differ between the two because if one has separate zone and key-signing keys,

it’s easier to re-sign zone after update without involving parent zone administrators.23

The files are stored in the same folder they are generated in, and they are named key

(public) and private (private)

Screen shot 11

20Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND , Apress, p285

21RIPE NCC, (2004, December), DNSSEC HOWTO A Tutorial in disguise, Retrieved 27

March, from: https://www.ripe.net/projects/disi//dnssec_howto/dnssec_howto-v1.6.html 22

IETF.org, (2004, April), Domain Name System KEY (DNSKEY) Resource Record (RR)

Secure Entry Point (SEP) Flag , Retrieved 25 March from: http://www.ietf.org/rfc/rfc3757.txt 23Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and BIND 5

th edition , O´Reilly, section

11.4.9




After the signing-keys are generated, we need to sign our zone (not much use

otherwise...). This is done in two steps:

Add DNSKEY records to the zone file:

Screen shot 12

Sign the zone file with the dnssec-signzone command:

Screen shot 13

The zone is now signed; the dnssec-signzone checks the SEP field in the DNSKEY

records, to find out which key to use.24

The result is another zone file named

secured.domain.zone.signed and one needs to remember to re-sign the zone every

time the zone is updated.

Screen shot 14

24Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and BIND 5


11.4.10.2




Screen shot 15

Running dig should also produce RRSIG records and such

Screen shot 16

The discussion around the use of DNSSEC has been long and is ongoing. The

“resistance” claims the process is too lengthy and weak, and there is also

vulnerabilities to DNSSEC in it self. (Ref: CVE-2007-0494 ) The “likers” says if everyone implemented DNSSEC, every zone could validate their “childs”. The

toplevel domain .se has implemented DNSSEC and claims it works fine.25

iii. Securing zone transfersWhen there is more than one name server for a zone (and there should be) it isrequired that these servers have the same information stored about their zone. To

accomplish this, they perform zone transfers. Earlier versions of DNS supported onlyfull zone transfer (AXFR), which means that the whole zone file in all its glory is

25.SE, .SE-DNSSEC, Retrieved 31 March, from: http://www.iis.se/domains/sednssec




copied between the servers. In BIND 9, incremental zone transfers (IXFR) are on by

default. The incremental zone transfer only copies the actual changes in the zone, so

its much more efficient.26

Any zone transfer is a liability, so one needs to secure these transfers of zone

information. This can be done partly through network design and partly by transactionsignatures TSIG.

27The message digest is computed over the entire DNS message, so

altering a single bit would result in a message digest mismatch. The time of signing is

also included in a TSIG record, to prevent so called replay attack , where an attacker intercepts the transaction and replays it later.28

Screen shot 17

Creating shared key for master and slave in secured.domain (Scree n shot 20) is done with

the same command used to create the zone signing keys: dnssec-keygen. Its common

to name the key after the two servers in question, and after transferring the key to both

servers one can restrict zone transfers to those signed with the correct key:

Screen shot 18

e. Safeguarding your informationi. Logging the data transfers

Logging means recording sequential data, often chronological29, and this is done to

monitor and discover network bottlenecks, unusual patterns and such, to predict a

possible attack. BIND supports logging to syslog , which has been the de factostandard for forwarding log messages in an IP network until recently.

30Logging can



10.4 27

TSIG is a method of authenticating DNS messages, including zone transfers, using shared

secrets and one-way hash functions. Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and

BIND 5 th

edition , O´Reilly, section 11.1 28

Wikipedia contributors. (2008, March 25) Replay Attack, Retrieved 1 April, from:

http://en.wikipedia.org/wiki/Replay_attack 29

Wikipedia contributors. (2008, March 28) Data logging. Retrieved 2 April, from:

http://en.wikipedia.org/wiki/Data_logging 30Wikipedia contributors. (2005, March 25) Syslog. Retrieved 2 April, from:

http://en.wikipedia.org/wiki/Syslog




be divided into channels and categories, where categories tells us what is going to be

logged, and channels where to log it. The channels and categories in BIND 9 arediscussed in the table below31:

Table 1

Channels also allow you to filter the messages by severity:

Screen shot 19

It´s important to know that syslog is not only used by BIND, and with noconfigurations at all, default messages will pile up in /var/log/messages:



7.5.2 - 7.5.3




Screen shot 20

Screen shot 21

Screen shot 22

As we can see, the applications that use syslog can be “chatty”, so for the sake of better overview and easier troubleshooting, it’s suggested dividing the messages by

category:

Screen shot 23

The messages are now logically divided, and when needed, it is much easier to makesome sense of what is going on:

Screen shot 24

There is also a security issue with syslog in that it uses UDP for transport and is

therefore easily spoofed and altered with. Be aware also that log files can be deleted

or tampered with in several ways. IETF (Internet Engineering Task Force) has put




down a work group to look at these issues32, and other logging tools, such as syslog-

ng and metalog to mention two of them. Either way, you need to centralise and

automate the process of watching log files. There are many different tools out there to

accomplish this; you will have to evaluate them to fit your needs.

ii. Securing the informationIn my opinion there is two sides of securing information. The first is to make surenobody can break into your server and grab information directly. The second is to

make sure your server gives up as little information as possible to the outside world. It

goes without saying that the servers need to be secured both physically and by

maintaining good password practises and good security related routines. BIND should

run in a so-called jailed environment33

.

To make sure your server does not give out unnecessary information to potential

attackers, you need to know what information is given to anyone who asks. The use of

simple tools such as whois can often provide attackers with useful information, but as

we can see in screen shot 25, not all organisations give away information for free.

Screen shot 25

Other techniques involves asking the name server it self. host can be used to get some

answers, and with the –c switch, one can query the chaos class:

Screen shot 26

32IETF.org, (March 13, 2008), Security Issues in Network Event Logging (syslog), Retrieved

April 22, 2008 from: http://www.ietf.org/html.charters/syslog-charter.html 33

This means that BIND runs in a folder of itʼs own, with no possibilities of reading or writing

outside this folder. In practical terms, if the application runs in /var/bind and accesses a filecalled /etc/bind/named.conf, the actual path would be /var/bind/etc/bind/named.conf. Ronald

G. F. Aitchison, (2006), chapter 10, Pro DNS and BIND , Apress, p251




One can put in an option in named.conf to make it say something else:

Screen shot 27

Several administrators make things easy for themselves by using descriptions and

such. The information they provide for themselves also goes out to potential attackers

Screen shot 28

Screen shot 29

But then again, not all organisations are that informative…

Screen shot 30

Screen shot 31

Dig is also a nice tool for diagnostics, and therefore a good tool for hackers to gather

information




Screen shot 32

V. Summary and conclusions

It is easier for most humans to read and remember addresses based on names than on

numbers, so in my opinion the need for a technology to convert, or map name based

addresses to number based addresses is non-negotiable. The question is how to make

this a reliable and trustworthy technology for people outside the small circle of

“computer geeks”. So-called experts is arguing in public forums34, meanwhile most people surfs the net in ignorance.

Mr. Dan Bernstein says that his focus for the djbdns will be nym-based 35

approach

(implementing a fingerprint of a computers public key in the actual DNS name) and

Mr. Paul Vixie´s BIND has support for DNSSEC. The nym-based approach requires

long host names, and even though Mr. Bernstein claims that users happily will use

bookmarks to handle long host names, I don’t think it will stop attackers from leading

users in a wrong direction. The DNSSEC requires every zone to be associated with a

public key, and then signs messages with corresponding private key. In order to

validate the public keys of a zone, the parent zone signs the keys, all the way to the

root name servers. The root zone’s public key should be widely known and distributed

among all the DNSSEC supporting name servers36. This of course, requires that

everyone acknowledges DNSSEC to be the right way to go, and implements it all the

way, and that is not something likely to happen in very near future.

34CircleID.com, (2004, October 11), Thoughts about “Protecting Against BIND”, Retrieved 6

April, from: http://www.circleid.com/posts/thoughts_about_protection_against_bind/ 35

Dan J. Bernstein, DNS forgery , Retrieved 6 April, from:

http://cr.yp.to/djbdns/forgery.html 36Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and BIND 5


11.4.5




Keeping ones systems updated and well patched, signing up for newsletters

concerning the tools and systems one uses, keeping track of information one handles

and shares – and watching over ones logs seems to be the only real alternative at the

moment. Of course when or if the experts agrees on one technology, whether its

DNSSEC or the nym-based approach, or any ground-shaking new approach, we can

all start building secure DNS services. Until then, better play it safe, and upgrade toBIND version 9.4.2

37.

37ISC.org, Newest release - http://www.isc.org/index.pl?/sw/bind/index.php




VI. References

All screen shots are taken from my own test systems. I have constructed all figures

but figure 3, with Microsoft Visio. Figure 3 is collected from the book Special OPSHost and Network Security for Microsoft, UNIX and Oracle by Eric Pace Birkholz

a. Books

J. D. Wegner and Robert Rockell, (2000), Chapter 1, IP Addressing and Subnetting, including

IPv6 , Syngress Media

Paul Albitz and Cricket Liu, (2006), Chapter 2, DNS and BIND, 5 th

Edition , OʼReilly, section

2.4

Eric Pace Birkholz, (2003), Chapter 8, Special OPS Host and Network Security for Microsoft,

UNIX and Oracle , Syngress Publishing, p399-400

Brian Hatch and James Lee, (2003), chapter 7, Hacking Linux Exposed, second edition,

McGraw Hill, p291

Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND, Apress, p283-284

Steven Levy, (2001), Public Key, Crypto - How the Code Rebels Beat the Government -

Saving Privacy in the Digital Age

b. Websites

Wikipedia contributors. (2008, March 10). Domain Name System. Retrieved 11 March 2008,

from: http://en.wikipedia.org/wiki/Domain_name_system

Jupitermedia Corporation. (2007, December 27). Berkeley Internet Name Domain. Retrieved

11 March 2008, from: http://webopedia.com/TERM/B/Berkeley_Internet_Name_Domain.htm

WSWS.ORG. (1999, March 3). Hackers shut down East Timor Internet addresses. Retrieved

12 March 2008, from: http://www.wsws.org/articles/1999/mar1999/hack-m03.shtml

ICANN.ORG. (2007, March 1). Root server attack on 6 February 2007. Retrieved 12 March

2008, from: http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf

DNS Spoofing is the art of making a DNS entry to point to another IP than it ʼs supposed to

point to. (2002, January 23). DNS spoofing techniques. Retrieved 12 March 2008, from:

http://www.securesphere.net/download/papers/dnsspoof.htm

Daniel J. Bernstein: Notes on the Domain Name System. Retrieved 16 March, 2008 from:

http://cr.yp.to/djbdns/notes.html#poison

CERT. (1997, August 13) CERT® Advisory CA-1997-22 BIND - the Berkeley Internet Name

Daemon. Retrieved 18 March, 2008 from: http://www.cert.org/advisories/CA-1997-22.html



Wikipedia contributors. (2008, March 18). User Datagram Protocol. Retrieved 18 March 2008,

from: http://en.wikipedia.org/wiki/User_Datagram_Protocol

Wikipedia contributors. (2008, March 15). Packet sniffer. Retrieved 18 March 2008, from:

http://en.wikipedia.org/wiki/Packet_sniffer

SecureWorks.com (2007, August 13). DNS Cache Poisoning – The Next Generation.

Retrieved 18 March, 2008 from: http://www.secureworks.com/research/articles/dns-cache-poisoning

IETF.org, (2005, March), The DNS security introduction and requirements , Retrieved 25

March from: http://www.ietf.org/rfc/rfc4033.txt

RIPE NCC, (2004, December), DNSSEC HOWTO A Tutorial in disguise, Retrieved 27 March,

from: https://www.ripe.net/projects/disi//dnssec_howto/dnssec_howto-v1.6.html

IETF.org, (2004, April), Domain Name System KEY (DNSKEY) Resource Record (RR)

Secure Entry Point (SEP) Flag, Retrieved 25 March from: http://www.ietf.org/rfc/rfc3757.txt

SE, .SE-DNSSEC, Retrieved 31 March, from: http://www.iis.se/domains/sednssec

Wikipedia contributors. (2008, March 25) Replay Attack, Retrieved 1 April, from:

http://en.wikipedia.org/wiki/Replay_attack

Wikipedia contributors. (2008, March 28) Data logging. Retrieved 2 April, from:

http://en.wikipedia.org/wiki/Data_logging

Wikipedia contributors. (2005, March 25) Syslog. Retrieved 2 April, from:

http://en.wikipedia.org/wiki/Syslog

IETF.org, (March 13, 2008), Security Issues in Network Event Logging (syslog), Retrieved

April 22, 2008 from: http://www.ietf.org/html.charters/syslog-charter.html

CircleID.com, (2004, October 11), Thoughts about “Protecting Against BIND”, Retrieved 6

April, from: http://www.circleid.com/posts/thoughts_about_protection_against_bind/

Dan J. Bernstein, DNS forgery , Retrieved 6 April, from:

http://cr.yp.to/djbdns/forgery.html

ISC.org, Newest release - http://www.isc.org/index.pl?/sw/bind/index.php

dns_bind esample pa raport

Documents