Overview of Class (Nine and) Ten

by Torleif Mohling
CU Boulder, dept of Computer Science

0 Contents

1 DNS - The Domain Name System

    IMPORTANT
We covered the Domain Name System for all of class nine (14 March) with a guest lecture from the famous Evi Nemeth! Copies of her slides will be made available in class. Class Ten, (21 March) also covered the setup of a DNS stealth server. See: ./dns.HTML/index for those slides. The following is last year's DNS notes that also go over the general structure and concepts of the Domain Name System.

The Domain Name System is a distributed system; no single DNS server stores all of the nameservice information. Instead the internet is divided up into separate domains which are also called zones of authority . Each domain has a primary nameserver that is considered to be authoritative for that domain.

The main purpose of DNS is to resolve symbolic hostnames into IP addresses. The reason this is necessary is that humans generally prefer and remember the symbolic hostnames while application programs need IP addresses to actually contact those hosts.

     
The domain name space is a hierarchical tree structure very similar to the un*x filesystem structure. The root domain of this hierarchy is called the root and is designated by a . (a single dot). The next level of domains are refered to as top level domains and they are probably familiar to you: com , edu , org etc.

                      "."  (The Root)
                       |
           -+----------+----------+-
            |          |          |
          .com       .edu       .org 
                       |
             -+--------+--------+-
              |                 |
          .berkeley          .colorado 
            |                   |
           -+-             -+---+---+-
            |               |       |
           www             www     .cs
                                     |
                                -+---+-----+-
                                 |         |
                                www       bfs

A fully qualified domain name (FQDN) simply specifies each node in the hierachy that is necessary to reach a particular host, e.g. bfs.cs.colorado.edu. Also note that each part of the symbolic hostname is specified from most to least specific ; and that hosts are leaf nodes.

It is also important to remember that this domain-tree is in no way a map of network topology; it is only a representation of the name-space defined by DNS. It is this hierarchical name-space that allows DNS to function as a distributed system.

     
Delegation is involved in the concept of authoritative zones . The top level domain edu for example delegates authority to each sub-domain in the edu namespace. The University of Colorado for example, is delegated authority over the colorado.edu domain, or zone. The Computer Science department in turn is delegated authority over the cs.colorado.edu sub-domain of colorado.edu, creating a new cs.colorado.edu zone.

     
There are two main type of DNS servers. Each domain has a primary master server and one or more secondary "slave" master servers. The secondary servers exist to provide redundancy in case the primary server is unavailable and also to provide loadbalancing so that all DNS queries are not sent to the primary server. Both primary and secondary servers are considered to be authoritative for their zone. Additionally, sites often have a secondary server located off-site. This involves negotiating with the DNS administrator at a remote site to have her set up their nameserver accordingly. It is possible for a single nameserver to be a primary server for one zone or group of zones, while at the same time function as a secondary server for any number of other zones.

Other hosts in a given domain may run caching only nameservers. These servers are not authoritative, but cache the results of any queries made so that identical queries don't generate new network traffic.

When a primary nameserver starts up it loads necessary information from datafiles call zone files . When secondary servers startup they perform a wholesale zone transfer to get the latest data from the primary server. The startup information includes two important things. The first is the symbolic hostnames and IP addresses for a handful of nameservers which are called root servers and are authoritative for the root zone. The reason this information is important is that the root servers have the names and IP addresses of nameservers for all of the top-level domains like .edu and .com. Using this information, a local nameserver can iteritively discover the name and IP address of an authoritative nameserver for any domain in the internet! The second important thing is the actual names and addresses of machines for which the nameserver is a primary master.

The most commonly encountered implementation of DNS is called BIND (The Berkeley Internet Name Daemon, pronounced like kind ). The actual server process for Bind is called named (pronounced "name-dee"). I will be showing examples of Bind Version 8. You encounter many Bind Version 4 implementations out on the internet. The configuration scheme between the two versions changed quite substantially.

The main config file for the server is usually /etc/named.conf although you may sometimes find it as /var/named/named.conf. The location of the other datafiles used by the server is determined by an entry in the main config file, but it is usually /var/named. We will look at some examples below.

     
Recursive queries are made by stub resolvers (i.e. when you use nameservice on an arbitrary host, you are making use of the stub resolver) because they rely on receiving an answer back from the queried nameserver. When the nameserver itself (recursively!) sends the query on to get an answer, the nameserver sends iterative queries. Many times, the queried nameserver will simply return a referal to yet another nameserver which may know the answer. A nameserver may not return a referal as an answer to a recursive query.

     
Caching is the concept of saving the answers to queries that have been made in order that if a subsequent query is needed, the locally-cached answer can be returned with generating additional network traffic getting the same answer again.

Time-to-live is an important related concept that causes answers to purged out of local caches- each answer returned by a nameserver has a time-to-live associated with it; when this TTL expires, the cached data should be discarded. Large TTL's cause answers to stay in the cache longer - which can be good, but it also causes any changes made to the information to take a lot longer to propogate.

     
Now let's look at an example. Suppose you are on a machine in the CSEL lab, like chicchan.cs.colorado.edu which has no nameserver running on it (i.e. a stub resolver) and you are trying to reach the website www.berkeley.edu to research possible grad programs. For your web-browser client to contact that host you need to get its IP address. Please assume that there are no cached records on any relevant nameservers.

Now, as a stub resolver, you need to make a recursive query to a local nameserver as determined from the /etc/resolv.conf file; in this case nago.cs.colorado.edu. The nameserver on nago doesn't have any information about www.berkeley.edu so it forwards the query (this time as an iterative query) to the nameserver for the root zone. The root zone nameserver doesn't have any information about berkeley.edu, but it does know about an authoritative server for the .edu zone, and it returns this information in the form of a referal. The nago nameserver then sends the original query to the name server for the .edu zone and the story is repeated except this time we are returned the name and address of a nameserver for berkeley.edu itself and nago's query to that server returns the desired result: the IP address for the webserver www.berkeley.edu!

     
So far we have been looking at DNS in terms of transforming symbolic hostnames into actual IP addresses. What if you wanted to do the opposite process of mapping an IP address to a symbolic hostname? This is called a reverse lookup. The process involved is exactly like what we have been looking at so far, except that it makes use of an entirely separate namespace (except for sharing the same root node) to facilitate the lookups. The top level domain for this namespace is arpa and the next level is in-addr.

Recall the namespace tree described above. Each node in that tree, particularly the leaf nodes, has specific information associated with it, like e.g. the leaf node bfs.cs.colorado.edu. has an IP address associated with it: 128.138.202.9. Also note again that the most specific part of the fully-qualified hostname is given first (the left-most as it is read on a screen or piece of paper) while the least specific portion is given last. The top-level domain is the least specific portion (e.g. .edu ).

For in-addr.arpa lookups the same DNS namespace is extended to include the top-level in-addr.arpa domain, with a hierarchy of IP addresses descending from it. In the same fashion as before, the most specific part of the IP address (from the point of view of the host !) is the leaf node:

                               "."  (The Root)
                                |
              -+----------------+----------+-
               |                |          |
             .arpa            .edu       .org 
               |                |
           .in-addr            -+--------+-
               |                         |
             .128                        |
               |                         |
             .138                    .colorado 
               |                         |
       -+------+------+-            -+---+---+-
        |      |      |              |       |
      .129   .202   .242            www     .cs
        |      |      |                       |
       .25    .9    .195                 -+---+-----+-
                                          |         |
                                         bfs       www

It is vital to make a distinction here: when you are dealing with IP addresses from the point of view of netmasks and actual binary representation in the kernel, the concept of most-significant-bits is different from the DNS concept of least or most specific. For DNS we are also dealing with the (base-10 specified) octets of a written IP address: 128.138.202.9 The difference for the DNS namespace though is that the leaf nodes are most-specfic so the representation for bfs's IP address in the in-addr.arpa namespace would be: 9.202.138.128.in-addr.arpa. - woah!

The reason the namespace was organised like this is 1) so that the existing code for DNS could simply include a new record-type by just extending the namespace. And 2) imagine trying to map an arbitrary IP address to a symbolic hostname in any other fashion (in terms of how to look up that information in a globally distributed database)!

     
All information in the DNS is stored as resource records . The format of a resource record is as follows:

    NAME  TTL  CLASS  TYPE  DATA
The NAME is sort of optional, it is the name of the domain object which the given record references. If the NAME is not specified it defaults to the previously named domain. The special name . (a dot) refers to the root domain. The special name @ refers to the current (local) domain.

The TTL is the time-to-live in seconds for the (cached) resource record. This field is also sort of optional. If it is not specified, a global TTL value is used.

The CLASS is almost always just IN (for "internet"). I'd be really surprised if you ever encounter any other class!

The TYPE is one of the following Resource Record types:

     
Check out the file /etc/named.conf on bfs.cs.colorado.edu as well as associated datafiles in /var/named for an example configuration of a secondary (slave) server.

     
Don't forget about the advanced usage of nslookup that was demonstrated in class. For example, first let's look up the SOA record for the cs.colorado.edu zone:

    suod % nslookup
    Default Server:  suod.cs.colorado.edu
    Address:  128.138.192.205

> set type=SOA > cs.colorado.edu Server: suod.cs.colorado.edu Address: 128.138.192.205

cs.colorado.edu origin = cs.colorado.edu mail addr = hostmaster.cs.colorado.edu serial = 2000030500 refresh = 7200 (2 hours) retry = 1800 (30 mins) expire = 604800 (7 days) minimum ttl = 7200 (2 hours) cs.colorado.edu nameserver = cs.colorado.edu cs.colorado.edu nameserver = moet.cs.colorado.edu cs.colorado.edu nameserver = piper.cs.colorado.edu cs.colorado.edu nameserver = anchor.cs.colorado.edu ...

And now we'll lookup the nameservers for berkeley.edu:
     
    > set type=NS
    > berkeley.edu
    Server:  suod.cs.colorado.edu
    Address:  128.138.192.205

Non-authoritative answer: berkeley.edu nameserver = VANGOGH.CS.berkeley.edu berkeley.edu nameserver = NS2.berkeley.edu berkeley.edu nameserver = NS1.berkeley.edu berkeley.edu nameserver = CGL.UCSF.EDU

Authoritative answers can be found from: VANGOGH.CS.berkeley.edu internet address = 128.32.33.5 NS2.berkeley.edu internet address = 128.32.136.12 NS2.berkeley.edu internet address = 128.32.206.12 NS1.berkeley.edu internet address = 128.32.206.9 NS1.berkeley.edu internet address = 128.32.136.9 CGL.UCSF.EDU internet address = 128.218.14.2 CGL.UCSF.EDU internet address = 128.218.27.20 >

     
There are a few other descriptions of DNS available. Check out:

2 Other Topics from Class Ten

3 Nmap and other considerations

The program nmap is perhaps the most widely used and well known tool in the category known as portscanners. Portscanner programs bombard a target system with packets to probe the status of TCP and UDP ports. The tools were often developed by hackers themselves to facilitate the locating of vulnerable targets. If only because hackers employ these sorts of tools, you should too! Ignorance is not a method of security.

The nmap program is available in the OpenBSD ports collection. So, let's install it. I think it resides in the /usr/ports/security directory.

    ramblo:tor {45} cd /usr/ports/security
    ramblo:security {46} ls
    ADMsmb       bounix       gnupg        nessus       portscanner  stel
    ADMsnmp      cfs          john         nfsshell     rsaref       strobe
    CVS          cops         libident     pgp          smurflog     swatch
    Makefile     crack        logsurfer    pgp5         socks5
    SSLeay       fragrouter   nbaudit      pgplib       ssh
(By the way, ramblo is a locked-down OpenBSD box on the DRAG net. There is a T-shirt available with a 'blowfish' geared out like Guerrilla soldier... ;) Uh oh! Nmap doesn't appear to be present in the 'security' directory. Sigh, what is world coming to? I'm certain it is in the ports tree, though, so a nice way to verify is to use the find command:

    ramblo:ports {48} find . -maxdepth 2 -name \*nmap\* -print
    ./net/nmap
Wahoo! It's in the net subdir. BTW: -maxdepth tells find to only descend into two levels of subdirectory-depth (including the starting directory) and also, you can use traditional shell regex characters like the asterisk, but you have to escape 'em with back-slashes.

Now do the usual:

    ramblo:ports {49} cd net/nmap
    ramblo:nmap {50} sudo make
    ...
    ramblo:nmap {51} sudo make install
    ...
Before continuing, I should point out that using portscanners arbitrarily on internet targets is not recommended. Most administrators will take serious offense and even possible legal action (if you crash a machine by accident, for example). If you need to portscan through any public networks it is advisable to first ask your ISP for permission.

Okay. Here is a basic scan of my home gateway system, coatlicue. The scan uses as a Stealth Syn scan (the -sS argument - read the manpage). The -v is for verbosity. The -O argument is cool, it performs a heuristic scan to try and determine the target machine's Operating System, Version of OS and Hardware type. Finally, the target may be a host, a list of space-seperated hosts, or a subnet, or... The default scan checks all ports less than 1024, and then checks any additional ports that are listed in the /etc/services file.

    ramblo:net {52} sudo nmap -sS -O -v coatlicue.colorado.edu

Starting nmap V. 2.3BETA6 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Host coatlicue.Colorado.EDU (198.11.19.5) appears to be up ... good. Initiating SYN half-open stealth scan against coatlicue.Colorado.EDU (198.11.19.5) Adding TCP port 114 (state Open). Adding TCP port 25 (state Open). Adding TCP port 443 (state Open). Adding TCP port 22 (state Open). Adding TCP port 80 (state Open). The SYN scan took 9 seconds to scan 1489 ports. For OSScan assuming that port 22 is open and port 39417 is closed and neither are firewalled Interesting ports on coatlicue.Colorado.EDU (198.11.19.5): Port State Protocol Service 22 open tcp ssh 25 open tcp smtp 80 open tcp http 111 filtered tcp sunrpc 114 open tcp audionews 443 open tcp https 2049 filtered tcp nfs 6000 filtered tcp X11

TCP Sequence Prediction: Class=random positive increments Difficulty=47220 (Worthy challenge)

Sequence numbers: 700E82F1 700EF54B 70104594 70104CBB 70119C89 7013AFB0 Remote operating system guess: OpenBSD Post 2.4 (November 1998) - 2.5

Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds ramblo:net {53}

Not bad, twelve seconds to determine quite a bit of information, including the fact that it is an OpenBSD box.

However! Check out the /var/log/ipflog logfile on my gateway machine:

    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,291 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,549 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,150 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,684 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,2 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,1404 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,1539 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,547 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,1668 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,305 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,372 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,963 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,161 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,502 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,868 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,22321 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,588 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,1482 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,320 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,69 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,852 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,1522 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,801 PR tcp len 20 40 -S 
    le0 @0:21 b 128.138.192.86,44437 -> 198.11.19.5,2016 PR tcp len 20 40 -S 
    ...
The log continues for quite a while! (422 different probes were logged.) It is dead obvious that my system has just been portscanned. I re-tried the same scan using the NULL scan instead of the Stealth Syn scan. This time only 39 probes were logged, but the scan produced much less useful information and the OS could not be determined. Nice, it gives me concrete proof as to OpenBSD's security.

There are actual programs available called scan-detectors that run on your gateway (or whatever) and "listen" for port-scan attempts to be made on your system, and then raise some kind of alarm. One such detector is available in the 'BSD ports tree: /usr/ports/security/swatch and others can be found on the 'net as well.

Another topic, related to scan detection is called intrusion detection and it is a large and inexact science. Tools available to perform intrusion detection include ISS and swatch in conjunction with mtree or tripwire. There are two main aspects (in my mind) to this sort of detection. One aspect is to look at network traffic in real time, looking for signatures that match the profile of known attacks. This type of signature refers to specific sequences of packets and header values inside those packets. The other aspect is related (directly) to the use of mtree or tripwire and involves monitoring the integrity of each system. A common scenario following a hacker break-in is to find rootkit files hidden in your filesystem, for example. These rootkit files consist of trojan binaries for commands like ps and ls and netstat. The trojaned binaries mask out specific files and processes from being reported by the respective programs. Regular use of mtree should quickly discover any system that has been expoited.

More comprehensive tools that make use of portscanners are available as well. The traditional favorite has been satan (System Administrator's Tool for Analysing Networks) but it is fairly out of date at this point. You can still find it for download on the 'net and it is worth looking at. A more modern tool is called nessus. Nessus is available for download and it is also integrated into the 'BSD ports tree.

Nessus has a number of features that make it quite useful. It is very configurable; you can adapt it to local conditions or needs by writing new modules for it. It has a fancy GUI front-end, but also the capacity to be used from the command-line. What I like most about nessus is that it has an extensive database of known vulnerabilities and suggestions about how to fix them!

There are many sites on the web devoted to security, both for administrators as well as for hackers. Here are a few of them: