Tài liệu IP Behavior VI Domain Name System (DNS) pdf

Trang 1

IP Behavior VI Domain Name System (DNS)

Hello again I am Judy Novak If you are taking the IP Behavior series in successive webcasts, my name and voice may be familiar to you by now since I am the author of a couple of previous

webcasts I still work for Jacob and Sundstrom in the Computer Security and Incident Response Team at the Army Research Lab as a Shadow analyst Stephen Northcutt has graciously requested that I author this webcast on the Domain Name System or DNS I’d personally like to thank my excellent technical editors Bill Ralph of Naval Surface Warfare Center and Hal Pomeranz of Deer Run Associates

What’s the big deal with DNS? Isn’t it basically used to translate a hostname to an IP number and that’s it? Well sure, that is a big and important part of DNS, but it is much more Having examined traffic for over two years on a military network, we see much interest in our DNS servers from less-than-upstanding citizens

Our DNS servers are probably the most common targets of reconnaissance efforts Your DNS server

is a cherished prize for a hacker to compromise, so they are going to see how vulnerable it is by pounding on it for weaknesses Some of the reasons that the DNS server is targeted are, first, this is a good reconnaissance method of learning about all the DNS information in preparation for launching

an attack Second, if an intruder can inject spurious DNS information in the local server, this can be used as an attack on other hosts Finally, UDP port 53, the port commonly associated with DNS

Trang 2

Objectives

• Explain DNS theory including:

– Client and server interaction– Server to server interaction– Primary and secondary servers– Transport protocol used (TCP/UDP)– WINS

• Intelligence gathering tools

• DNS - the dark side

The objectives of this webcast are to teach the underlying theory of DNS so the student can interpret tcpdump output of DNS transactions and examine DNS events occurring on the network with some insight about what is transpiring

Specifically, we will examine how a DNS query is answered DNS is different than a normal client server application in this aspect Typically, in client server applications such as telnet or ftp, the client requests a connection to a desired server and the interaction is pretty much between those two hosts For DNS, however, when a client issues a DNS query, a DNS server will accept the query, perhaps interact with one or more additional DNS servers, and when it receives the response to the query, it will return it to the client

We will look at the role of primary and secondary name servers and discuss the interaction between them Also, unlike other services, DNS can switch between UDP and TCP protocols depending on the kind of DNS activity We will briefly cover the way in which Windows hosts do hostname resolution

We will also talk about some ways that others may use your DNS server to gather information about the DNS server itself and hosts that the DNS server knows about Finally, we will look at examples of how DNS was used for malicious purposes

Trang 3

Step 2: Request a connection to

the resolved IP number.

The slide “Going places” supposes that you want to go to the SANS website, www.sans.org to see what the latest offerings and postings of interest might be You bring up your Netscape browser and enter the URL http://www.sans.org Seconds later, if you are not on a slow or congested network, you will see the www.sans.org web page

Remember that TCP/IP datagrams use IP numbers for all source and destination addresses TCP/IP does not use hostnames However, we humans tend to remember hostnames far better than we

remember IP numbers so we speak in hostnames It’s obvious that we need some kind of translation mechanism between the way we reference hosts hostnames and the way TCP/IP must reference hosts IP numbers

So, how did this translation from www.sans.org to an IP address mysteriously occur behind the scenes? Before you could even send out a request to www.sans.org, your host had to know an IP number Your host needs this IP number to package into the datagram when it sends the connection request to

www.sans.org out on the network We’ll examine this Step 1 process from the above slide in the next several slides

Trang 4

Continuing with the process of resolution from hostname www.sans.org to IP number, look at slide

“Client resolver” Here, we see the host on which we have our Netscape browser, host.my.com

attempt resolution of www.sans.org

Assuming that your host is not a name server, it is mostly passive throughout the resolution process It simply fires off the request for the translation, and resumes the process of connecting to the

www.sans.org web page after it receives a reply of the IP address The workhorse behind the

resolution process is the DNS server which is queried, in this case, dns.my.com Generally, a default name server is chosen at the time the operating system is installed on a given client machine (on Unix machines the information is stored in the file /etc/resolv.conf) This default DNS server is typically managed locally and is located somewhere on your organization’s intranet dns.my.com is this site’s DNS server

On the client host, the TCP/IP applications such as telnet, ftp, Netscape or Internet Explorer call

“resolver” library routines to obtain DNS resolution When you requested www.sans.org, application software issued a call to resolve the hostname to an IP address In this case, a gethostbyname call is sent from host.my.com to the DNS server This requests that the hostname www.sans.org be translated

to an IP address The DNS server receives this request, processes it, and returns it to host.my.com

Trang 5

DNS server resolution (part I)

dns.my.com

IP for www.sans.org

h.root-servers.net Ask host server1.sans.org

Resuming our resolution journey on slide “DNS server resolution (part I)”, we see dns.my.com take

over the actual duties of finding the answer of the IP of www.sans.org dns.my.com begins its search with a root server to find the resolution

In order to resolve external names, many times, your local name server must contact a root name server Root name servers maintain a mapping between domain names (sans.org) and the authoritative name servers for those domains When the local name server, dns.my.com, asks a root name server for the IP address of www.sans.org, it gets back a referral to the name servers for sans.org

You might ask how dns.my.com knows the names and IP numbers of the root servers to contact Obviously, the local name server must be pre-configured with a list of known root name servers This information is maintained by the InterNIC and may be downloaded from

ftp://ftp.rs.internic.net/domain/named.ca

Trang 6

DNS server resolution (part II)

dns.my.com

IP for www.sans.org

IP is 167.216.233.33

server1.sans.org

Continuing our resolution journey on slide “DNS server resolution (part II)”,

The root server lets dns.my.com know where to continue its search The root server has returned a referral to the name server server1.sans.org as an authoritative name server for www.sans.org dns.my.com then queries server1.sans.org and receives an authoritative answer, the IP number of 167.216.133.33

Trang 7

in-addr

If you look at the next slide “Requisite picture of DNS structure”, we need to interject a little theory

about the nature of DNS

DNS is a globally distributed system which depends on the cooperative interaction of many DNS servers to store records about “domains” and communicate with each other A domain is a subset of DNS records associated with a logical grouping For instance, sans.org, is the domain that logically contains all hosts that SANS might use

The distributed system has been set up as a hierarchy of special servers known as root servers at the top

of the domain tree These servers simply point to other DNS servers that may have dominion of DNS records being sought You are probably familiar with the top-level domains, those falling directly under the root servers as edu, org, com, net, mil, gov to name the domestic domains There are additional top-level domains for foreign countries, such as jp for Japan

Trang 8

tcpdump output of resolution

Moving to slide “tcpdump output of resolution”, we can see what was happening on the network

First we see host.my.com issue the request to resolve www.sans.org to dns.my.com While tcpdump prints the word “udp” for some UDP protocols, there is no such blatant clue in tcpdump DNS output Regardless of this omission, the above transactions used UDP UDP was selected for the method of transmission of the majority of DNS traffic since the queries and responses are often short and the application itself can withstand lost or missing data When anticipated data is not received, a new query is reissued

Next, dns.my.com attempts a connection to h.root-servers.net on port domain which is port 53 Note that both source and destination ports are 53 We see h.root-servers.net respond back to dns.my.com on source and destination ports 53 as well We’ll discuss the numbers and notations found at the end of each tcpdump record in the next slide h.root-servers.net doesn’t have the answer to the query,

however it has a reference of another DNS server that may have the answer or may have a reference of who may have the answer Querying name servers for the IP of www.sans.org is a repeated process that may yield a reference of another DNS server that may have the answer until finally a name server

is contacted that has the answer of the IP number

Since h.root-servers referred dns.my.com to another DNS server, we next see dns.my.com query this server, server1.sans.org, for the IP for www.sans.org server1.sans.org happens to “own” the DNS record for www.sans.org and is able to return to dns.my.com the IP number associated with

www.sans.org

Trang 9

What is that strange tcpdump notation?

dns.my.com.domain > h.root-servers.net.domain: 12420 (30) (DF)

h.root-servers.net.domain > dns.my.com.domain: 12420- 0/3/3 (153) (DF)

authority records

sans.org nameserver = server1.sans.org

sans.org nameserver = ns.BSDI.COM

sans.org nameserver = ns.DELOS.COM

additional records

server1.sans.org internet address = 167.216.133.33

ns.BSDI.COM internet address = 205.230.225.16

ns.DELOS.COM internet address = 192.65.171.1

Let’s look at slide “What is that strange tcpdump notation?” The first line of tcpdump output is the

query from dns.my.com to the root server The first field that we haven’t seen before in conventional tcpdump output is the number 12420 following the colon after domain This is the DNS identification number It is a unique identifying number that a DNS server or client uses to match a query and response dns.my.com issues the request to the root server with the number 12420 and when it receives

a response, it is able to pair it to the request Remember, dns.my.com is probably doing a lot of other queries while it is doing ours so it has to be able to match multiple queries with responses The length

of the UDP payload (not including the IP or UDP headers) is 30 bytes And, we have the don’t

fragment flag set so this datagram won’t be fragmented

The response to query 12420 follows There is a dash after the 12420 signifying that recursion was not available dns.my.com did not tell the root server that it wanted a response that referenced where the next DNS server might be - it did not want the root server to pursue finding the response itself Root servers are very busy machines and cannot process queries in a recursive fashion as dns.my.com is doing They are only expected to give whatever knowledge they have about a good reference in pursuit

of the answer

In the response from the root server, we see some strange output in the format of 0/3/3 This says that there were 0 answer records - this means no IP was found, but 3 authoritative records were found and 3

Trang 10

tcpdump output of resolution (2)

Moving to slide “tcpdump response output”, we examine the remainder of the tcpdump output from

the resolution process dns.my.com has been informed that there are several authoritative servers and it selects the first one, server1.sans.org for resolution It issues a new query 12421 and asks for recursion, noted by the plus sign Essentially, dns.my.com has tasked server1.sans.org to find the IP address In this case server1.sans.org is an authoritative name server for www.sans.org so it can answer the query itself However, if it were not the authoritative name server, it would have to find the IP number by recursively issuing queries to other name servers until an IP number was found

server1.sans.org responds to the query The asterisk means that this is an authoritative response This means that the record for www.sans.org is in the DNS database that server1.sans.org maintains One answer is returned - the answer in this case is the IP number of www.sans.org, 167.216.133.33 We don’t see the IP in the tcpdump output, but that is what is in the payload of the UDP datagram The 3 authority records and 3 additional records that we saw on the previous slide are returned here too

Finally, once dns.my.com has the IP address, it delivers it to host.my.com, the original querier

Trang 11

Caching – been there, done that

dns.my.com

What is IP of www.sans.org?

167.216.133.33

www.sans.org = 167.216.213.33

cached responses

Turning to slide “Caching - been there, done that”, we illustrate what happens to received responses

DNS servers cache or save responses that they receive This makes the resolution process more efficient if the same DNS queries don’t have to be repeated over and over again This also potentially will cut down on hits that other DNS servers take in helping you respond to queries Chances are good that the same hostname to IP resolution that was requested once may be requested again soon

How long do cached records stay around on the DNS server? Well, it depends; each cached record may have a different life span It turns out that each response of a DNS resource record has a time to live value This time to live value is set by the responding DNS server and cached by the receiving name server for the TTL time value DNS servers that may update records often, may have lower time

to live values than relatively static servers

Trang 12

nslookup

• Tool that uses “resolver” software

• Allows you to make DNS queries and see responses

dns.my.com host.my.com

nslookup www.sans.org

167.216.133.33

Next we look at a very helpful tool for using DNS in slide “nslookup” Suppose you wanted to see the

responses host.my.com received from the resolutions it asked for nslookup acts much as a DNS client would, but displays the information so that you can see In fact, that is how we got the authoritative name server hostnames and IP numbers for the sans.org domain This is a very helpful interactive tool that can be used on a Unix or Windows NT host

There are many more questions that can be asked of a DNS server than hostname We examine some

of these in the next several slides Using nslookup, we can formulate queries and see the kinds of responses we get There is a debug setting that allows you to see more of the data in the DNS message that is sent and returned than just the query and response values We’ll examine this too

Finally, you can use another DNS server to do resolution for you Instead of using your default DNS server, you can direct your queries to another DNS server and see the responses

Trang 13

Sample nslookup output

Let’s look at slide “Sample nslookup output” to get an idea of the capabilities of the nslookup tool

We see host.my.com issue the nslookup command We enter into the nslookup interactive process and receive notification of the default DNS server being used to resolve our queries and its associated IP number

At the greater than prompt we enter www.sans.org to find its IP number Again we get confirmation of the DNS server and IP number being used to resolve the query We see the answer below that of 167.216.133.33

Next, we put nslookup in debug mode and reissue the query for www.sans.org Debug mode give you much more information about the query process

(continued on the next slide)

Trang 14

Sample nslookup debug output

Got answer:

HEADER:

opcode = QUERY, id = 15135, rcode = NOERROR

header flags: response, want recursion, recursion avail.

questions = 1, answers = 1, authority records = 3, additional = 3

Moving to slide “Sample nslookup debug output”, we see output from the debug option

The debug output tells us that an answer was returned to our query The query was issued with a DNS identification number of 15135, and the response was error free A recursive query was issued, and recursion was available on the response We asked one question (the IP number of www.sans.org) and

we received one answer - the IP number We got 3 authority records and three additional records delivered in the response The answer delivered was the IP number 167.216.133.33 and it has a time to live value of 14373 This is in seconds - computed in a more human readable format; this is just under four hours This means this record will be cached in dns.my.com for this amount of time After that

my DNS server will expire the cached record and have to reissue the query

This TTL value of 14373 represents the amount of time remaining before the resource record gets flushed from the cache of dns.my.com It may not reflect the original TTL value returned with the query In this instance, the original TTL value was 14400 from a query executed 23 seconds ago

Next, all the authoritative DNS servers are listed for the sans.org domain Any of the listed three DNS servers has the database records for hosts in the sans.org domain

(continued on the next slide)

Trang 15

Sample nslookup debug output(2)

Finally, we see the actual query parameter - www.sans.org and the answer in the form of the IP

number Why do you think we received the message Non-authoritative answer? This means that we didn’t receive the answer from any of the authoritative hosts listed in the previous slide How could that be? Remember this is the second time we queried for host www.sans.org in the nslookup process The first time we did, we didn’t have the debug option turned on We turned the option on and then issued the query for www.sans.org again

So the first response was cached When we asked the same question a few minutes later, the answer was obtained from cache and not from the authoritative server Retrieving the answer from cache, even though it was previously from authoritative source, is not considered an authoritative answer

Trang 16

Reverse lookups

Root servers arpa

We discuss resolving IP numbers to hostnames in the slide “Reverse lookups” Occasionally, you’ll

be given an IP number and want to see if it resolves to a hostname This is known as a gethostbyaddr call made by the client resolver

As we examined earlier in this webcast, DNS is a distributed hierarchy of responsibility and ownership begins at the root servers and continues down in the DNS tree We saw top level domain nodes such as org, mil, edu and so forth A special domain has been reserved for resolution of IP numbers to hostnames At the top level domain, this is the arpa suffix A second level domain follows known as in-addr Beneath this, the tree expands outward for the legal first octets in the IP number For instance,

in the case of the IP for sans.www.org, the first octet is 167 Beneath this will follow a subtree with the next node of 216, the second octet of the www.sans.org IP number Following this logic, the 233 and

33 nodes for the final two octets fall below We examine just this one subtree in this example, but this spans all the possible IP numbers just as the other top level domains begin the expansion of all the hostnames

Resolutions of IP to hostname are known as reverse lookups When we attempt a reverse lookup for 167.216.233.33, the application software reformats this as a query to 33.233.216.167.in-addr.arpa We reverse the order of the octets to conform to the hostname notation For name www.sans.org, we formulated the name by starting at the bottom of the DNS tree with node www, we moved up to node sans and topped out at node org Similarly, with the IP number, we must move from the most specific

to the most general

Trang 17

Primary - Secondary name servers

• Primary server is the one that maintains zone maps

• Zone maps are the set of domain names for which DNS is the

authoritative nameserver

• Zone maps resident on primary server upon start-up

• Secondary server gets its zone maps from the primary server

zone maps

zone maps downloaded

Turning to slide “Primary - Secondary name servers”, we look at two different kinds of DNS servers

Each domain has to have a primary server, one upon which database records of names and IP addresses are maintained Then, for redundancy sake, one or more secondary servers are often created in case the primary server ever goes down If there were no redundancy built in, if the only DNS server for a particular domain were to go down, no queries could be answered for hosts in that domain Unless entries were cached at other DNS sites, all resolution of hosts in the domain whose DNS server was down could not be accomplished Secondary servers can share the load of responding to queries with the primary name server

DNS information is maintained on the primary server in flat text files The secondary name servers periodically contact the primary name server to see if any updates have been made for a particular domain If so, the secondary server downloads all information for that domain even if only one record has been modified

Trang 18

Zone transfers

Primary Server

Evil Host Legitimate Secondary Server

We’ll now examine how changes are propagated from the primary to the secondary name server on

slide “Zone transfers” When the secondary server restarts or when it periodically queries the primary

server and finds updated records, a zone transfer is performed between the primary and secondary servers

This is simply a transfer of the zone maps or DNS records from the primary server to the secondary server Unlike most DNS transactions, this is done using TCP since there is a lot of data and reliable delivery is important The zone transfer seems like an innocuous process Between the same domain primary and secondary servers, it usually is However, what if a hacker could do a zone transfer of your domain data? This would give him or her all the IP numbers and hosts in your domain This is very valuable data that should not be readily available to anyone

Obviously, we’d like to try to prevent this kind of misuse There are a couple of ways that this can be done In versions of BIND 4.9.3 and later, there is a configuration parameter that allows the DNS administrator to specify IP numbers or subnets that are authorized to do zone transfers

If your version of BIND doesn’t support this feature, another option is to block inbound traffic to TCP port 53 This will prevent transfers, but may block other legitimate data as well However, if this is your only option, it is preferable to prevent the zone transfer even at the expense of blocking other legitimate data, as we will see on the next slide

Trang 19

Truncated bit set

Let’s turn to slide “UDP/TCP” to discuss some issues associated with the transport protocol for DNS

traffic Earlier, we mentioned that typically DNS traffic is sent using UDP because answers are often succinct and a best delivery effort can be tolerated since unreceived responses to DNS queries can be reissued Since there is a lot of data for zone transfers, they are an exception to the UDP protocol and are done using TCP

The maximum allowable size for a UDP DNS response is 512 bytes Of the 512 bytes, a minimum of

20 must be reserved for the IP header, and 8 more most be reserved for the UDP header This leaves

484 bytes for the DNS messages itself

What happens if the data contained in the DNS datagram response exceeds 484 bytes? The first thing that happens is that the response is returned with the truncated bit turned on This bit is found in the flags field of the DNS message In the above output, look at the second line of tcpdump output The response is from dns.verbose.com to dns.my.com After the DNS identification number, 18033, you see a vertical line or Unix pipe symbol This is the notation that tcpdump uses to alert you that the DNS record has been truncated The response of 7 resource records had 494 bytes of data, exceeding the 484 limit for the 512 bytes of IP datagram

Trang 20

UDP/TCP ports used in DNS

All BIND Versions

udp >1023 53 Client queries

udp 53 >1023 Replies to above client queries

We examine “UDP/TCP ports used in DNS” on the next slide Studying this will help you understand

how DNS communicates This is a table of protocols and DNS source and destination ports used for different circumstances

As we’ve already witnessed, traffic between two DNS servers, whether UDP or TCP, uses port 53 for both the destination ports Versions of BIND 8 can have different source ports than UDP 53, usually

an ephemeral port above 1023 But they can also be configured to use UDP source port 53 to mimic the behavior of previous versions of BIND 4.x.x

Client to DNS queries, as we saw between host.my.com and dns.my.com, resemble the behavior of typical client and server ports The client selects an ephemeral port greater than 1023 and connects to server port 53 The server responds with source port 53 to the ephemeral destination port This same pattern is observed regardless if the protocol is UDP or TCP

Trang 21

As we discover in the slide “WINS”, Windows hosts manage hostname resolution a bit differently than

Unix ones Windows Internet Name Service (WINS) supplies a method to map hostnames to IP numbers for Windows based systems Windows uses a different naming convention for hostnames, the NetBIOS name

When a Windows host boots up, it dynamically registers its NetBIOS name and IP number in the Windows Internet Name Server This differs from DNS entries which are static In other words, if a host registered in a DNS server has its hostname or IP address changed, this will not be automatically updated in the DNS server Another difference is that WINS is used to resolve NetBIOS names to IP numbers typically on an intranet On the other hand, DNS is used to resolve fully qualified domain names (hostnames with domain names, hostx.my.com) to IP addresses on the Internet

The slide illustrates the resolution process for hostnames to IP numbers done by a Windows host In this case, we search for the IP number for hostx and our domain is my.com First, the WINS will be queried for hostx if our Windows host, winhost, has enabled the WINS resolution option If hostx is found in WINS, the resolution is complete If hostx is not found in WINS and our querying Windows host, winhost, has DNS resolution enabled, the DNS server will be queried for hostx.my.com Note that we append the domain name, in this case, my.com to the hostname to get the fully qualified domain name which the DNS server uses as the hostname

Trang 22

How do they know what my DNS

sans.org nameserver = DELOS.COM

sans.org nameserver = server1.sans.org

sans.org nameserver = NS.BSDI.COM

Authoritative answers can be found from:

DELOS.COM internet address = 192.65.171.1

server1.sans.org internet address = 167.216.133.33

NS.BSDI.COM internet address = 205.230.225.16

Turning to slide “How do they know what my DNS server is?”, we begin looking at how

reconnaissance is done using the DNS server as an informative source I often wondered with the number of scans and probes directed to our sites DNS servers, how the world knew about our DNS servers Actually, it is rather trivial to find this out

We return to the nslookup command and enter the command set type=ns We have just set the option

to return an answer of a name server(s) to subsequent queries issued We’ve already seen how we got name server records for www.sans.org when we turned on the debug option But, if you don’t want all the depth of detail provided by the debug option, set the name server option

We bump up one node on the DNS tree and query for sans.org to see the name servers for this domain

We then see all the name servers for sans.org - both hostnames and IP addresses So, this appears to be

a pretty good place to start the reconnaissance effort for a site After discovering the name servers, one might scan those name servers for potential security deficiencies or to see what kind of Internet services or daemons are being run on the DNS server

Trang 23

Start of Authority (SOA)

refresh = 7200 (2H) retry = 3600 (1H) expire = 1728000 (2w6d) minimum ttl = 7200 (2H)

Current serial numberSlave checks for updatesSlave gives up contacting primarySlave expires records

Other DNS servers cache length

The “Start of Authority (SOA)” record seen in the next slide is a required DNS resource record for

any DNS server to indicate the zone for which it has authoritative records In this case, we see that server1.sans.org is authoritative for records for the zone sans.org There are other entries associated with the SOA record that you see in the slide when we query nslookup for the SOA for sans.org

The origin is the domain and the mail addr is t he e-mail address of a contact for the domain

The serial number is a number that changes each time updates are made to the zone’s records Many administrators will use a YYYYMMDDNN configuration, but this is not required Slave servers know that changes have been made in the primary server when the primary server’s serial number has changed

The refresh field informs the secondary servers how frequently to look for updates – in this case 2 hours This field as well as other time fields are expressed in seconds The retry parameter tells the secondary servers to give up contacting the primary server if there is a failure to communicate after a given time period – one hour in this case The expire value tells the slave to stop giving out responses

if it has not been able to an update from the primary in a given time frame – the above value is 2 weeks

Tiêu đề	Domain Name System (DNS)
Tác giả	Judy Novak, Stephen Northcutt
Người hướng dẫn	Bill Ralph of Naval Surface Warfare Center, Hal Pomeranz of Deer Run Associates
Trường học	Army Research Lab
Chuyên ngành	Network Security
Thể loại	webcast
Năm xuất bản	2001
Thành phố	Not specified

Định dạng
Số trang	47
Dung lượng	1,56 MB