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 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.
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.
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!
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)!
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:
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
>
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
...
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.
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!