12.4 Managing Services Securely | Practical Unix & Internet Security, 3rd Edition

Once you have deployed a Unix server on a network, it is important that you manage it securely. You should periodically monitor your server and the network for potential problems or abuse. Most network topologies provide three locations for monitoring:

You can monitor on the hosts themselves , either by monitoring the packets as they enter or leave the system, or by monitoring servers that are running on the system.
You can monitor the local area network. If you have an Ethernet hub on your network, you can monitor by attaching another computer to the hub that is running a network monitor or packet sniffer. If you have a switched network, you will need to create a mirror port or monitor point . ^[40]

^[40] Typically, mirror or monitor ports can be created on managed switches, but cannot be created on low-cost switches.
You can monitor information entering or leaving your network at the point where your network connects to other networks.

Most monitoring involves one or at most two of these systems; the most secure networks combine all three.

You may also wish to employ other methods , such as network scanning, to detect vulnerabilities before attackers do so.

12.4.1 Monitoring Your Host with netstat

You can use the netstat command to list all of the active and pending TCP/IP connections between your machine and every other machine on the Internet. This command is very important if you suspect that somebody is breaking into your computer or using your computer to break into another one. netstat lets you see which machines your machine is talking to over the network. The command's output includes the host and port number of each end of the connection, as well as the number of bytes in the receive and transmit queues. If a port has a name assigned in the /etc/services file, netstat will print it instead of the port number.

Normally, the netstat command displays Unix domain sockets in addition to IP sockets. You can restrict the display to IP sockets only by using the -f inet (or -A inet in some versions) option.

Sample output from the netstat command looks like this:

 %  netstat -f inet  Active Internet connections Proto Recv-Q Send-Q  Local Address          Foreign Address        (state) tcp4       0      0  R2-INTERNAL.imap       KITCHEN.1922           ESTABLISHED tcp4       0  31400  r2.http                z06.nvidia.com.27578   ESTABLISHED tcp4       0      0  r2.http                66.28.250.172.2020     TIME_WAIT tcp4       0     20  r2.ssh                 h00045a28e754.ne.3301  ESTABLISHED tcp4       0      0  r2.http                goob03.goo.ne.jp.35251 TIME_WAIT tcp4       0      0  r2.1658                ftp2.sunet.se.8648     ESTABLISHED tcp4       0      0  R2-INTERNAL.imap       G3.1472                FIN_WAIT_2 tcp4       0      0  r2.http                66.28.250.172.1574     TIME_WAIT tcp4       0      0  r2.1657                ftp2.sunet.se.ftp      ESTABLISHED tcp4       0      0  r2.1656                rpmfind.speakeas.59355 TIME_WAIT tcp4       0      0  r2.1655                rpmfind.speakeas.ftp   TIME_WAIT tcp4       0      0  r2.http                host-137-16-220-.1600  TIME_WAIT tcp4       0      0  r2.http                z06.nvidia.com.25805   FIN_WAIT_2 tcp4       0      0  r2.http                z06.nvidia.com.25803   FIN_WAIT_2 tcp4       0      0  r2.http                z06.nvidia.com.25802   FIN_WAIT_2 tcp4       0      0  r2.1654                K1.VINEYARD.NET.domain TIME_WAIT tcp4       0      0  R2-INTERNAL.imap       G3.1471                TIME_WAIT tcp4       0      0  r2.ssh                 h00045a28e754.ne.3300  ESTABLISHED tcp4       0      0  localhost.imap         localhost.1544         ESTABLISHED tcp4       0      0  localhost.1544         localhost.imap         ESTABLISHED tcp4       0      0  r2.imaps               h00045a28e754.ne.3285  ESTABLISHED tcp4       0      0  R2-INTERNAL.ssh        KITCHEN.1190           ESTABLISHED tcp4       0      0  R2-INTERNAL.netbios-ss KITCHEN.1031           ESTABLISHED %

The netstat program displays only abridged hostnames, but you can use the -n flag to display the IP address of the foreign machine, and then look up the IP address using another tool such as host . This is probably a good idea anyway, as IP addresses are harder to hide and the hostname lookup itself may alert an attacker that you are monitoring them.

The first line indicates an IMAP connection with the computer called KITCHEN . This connection originated on port 1922 of the remote machine. The second line indicates an in-process HTTP connection with the host z06.nvidia.com . The third line is an HTTP download that has entered the TIME_WAIT state. ^[41] The subsequent lines are various TCP connections to and from other machines. These lines all begin with the letters "tcp4", indicating that they are TCP servers running on top of IPv4.

^[41] RFC 793 defines the TCP states, in case you're interested. TIME_WAIT means that the local process is "waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request."

With the -a option, netstat will also print a list of all of the TCP and UDP sockets to which programs are listening. Using the -a option will provide you with a list of all the ports that programs and users outside your computer can use to enter the system via the network.

 %  netstat -f inet -a  Active Internet connections Proto Recv-Q Send-Q  Local Address          Foreign Address        (state) ... Previous netstat printout ... tcp4       0      0  *.amidxtape            *.*                    LISTEN tcp4       0      0  *.amandaidx            *.*                    LISTEN tcp4       0      0  *.smtps                *.*                    LISTEN tcp4       0      0  *.pop3s                *.*                    LISTEN tcp4       0      0  *.imaps                *.*                    LISTEN tcp4       0      0  *.imap                 *.*                    LISTEN tcp4       0      0  *.pop3                 *.*                    LISTEN tcp4       0      0  *.time                 *.*                    LISTEN tcp4       0      0  *.ftp                  *.*                    LISTEN tcp4       0      0  *.3306                 *.*                    LISTEN tcp4       0      0  *.smtp                 *.*                    LISTEN tcp4       0      0  *.gdomap               *.*                    LISTEN tcp4       0      0  R2-INTERNAL.netbios-ss *.*                    LISTEN tcp4       0      0  r2.netbios-ssn         *.*                    LISTEN tcp4       0      0  *.ssh                  *.*                    LISTEN tcp4       0      0  *.printer              *.*                    LISTEN tcp4       0      0  *.1022                 *.*                    LISTEN tcp4       0      0  *.nfsd                 *.*                    LISTEN tcp4       0      0  *.1023                 *.*                    LISTEN tcp4       0      0  *.sunrpc               *.*                    LISTEN tcp4       0      0  localhost.domain       *.*                    LISTEN tcp4       0      0  BLAST.domain           *.*                    LISTEN tcp4       0      0  R2-INTERNAL.domain     *.*                    LISTEN tcp4       0      0  r2.domain              *.*                    LISTEN udp4       0      0  localhost.4122         *.*                     udp4       0      0  R2-INTERNAL.netbios-dg *.*                     udp4       0      0  R2-INTERNAL.netbios-ns *.*                     udp4       0      0  r2.netbios-dgm         *.*                     udp4       0      0  r2.netbios-ns          *.*                     udp4       0      0  localhost.ntp          *.*                     udp4       0      0  BLAST.ntp              *.*                     udp4       0      0  R2-INTERNAL.ntp        *.*                     udp4       0      0  r2.ntp                 *.*                     udp4       0      0  localhost.domain       *.*                     udp4       0      0  BLAST.domain           *.*                     udp4       0      0  R2-INTERNAL.domain     *.*                     udp4       0      0  r2.domain              *.*                     %

The lines in the middle of the listing that end with "LISTEN" indicate TCP servers that are running and listening for incoming communications. Clearly, this computer is running a lot of services. Some of the ports on which this computer is listening have no matching name in the /etc/services file, and are therefore listed only by their numbers (i.e., 1022, 1023). This should be a cause for further investigation. Unfortunately, netstat will not give you the name of the program that is listening on the socket.

To determine which process is listening on port 1022 and port 1023, we can use the lsof ^[42] command:

^[42] lsof stands for "list open files" ”on Unix systems, network connections, like nearly everything else, can be treated as a kind of file. It's available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/. If it's distributed with your operating system, make sure that nonprivileged users can't use it to see files and devices owned by other users; if they can, rebuild it from the source code.

 r2#  lsof -i:1022  COMMAND   PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME rpc.statd 107 root    4u  IPv4 0xd5faa700      0t0  TCP *:1022 (LISTEN) r2#  lsof -i:1023  COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME mountd   98 root    3u  IPv4 0xd5e2b500      0t0  UDP *:1023 mountd   98 root    4u  IPv4 0xd5faab40      0t0  TCP *:1023 (LISTEN) r2#

The rpc.statd program has a history of security vulnerabilities (See http://www.cert.org/advisories/CA-2000-17.html). The mountd program is part of the NFS system; it also has a history of security vulnerabilities (see http://www.cert.org/advisories/CA-1998-12.html. Fortunately, all known vulnerabilities in both of these programs have been fixed. ^[43] Perhaps even more importantly, the r2 computer is protected with a host-based firewall that blocks all connections to port 1022 and 1023 that originate on the Internet.

^[43] Of course, we don't know about the unknown problems!

We can verify that r2's firewall is in proper operation by probing the system with the nmap ^[44] command from an outside host:

^[44] nmap is a powerful port scanner that is distributed with many Unix operating systems, or available from http://www. insecure .org/nmap.

 king1#  nmap r2.simson.net  Starting nmap V. 2.54BETA34 ( www.insecure.org/nmap/ ) Interesting ports on r2.nitroba.com (64.7.15.234): (The 1545 ports scanned but not shown below are in state: filtered) Port       State       Service 22/tcp     open        ssh                      25/tcp     open        smtp                     53/tcp     open        domain                   80/tcp     open        http                     110/tcp    open        pop-3                    389/tcp    open        ldap                     443/tcp    open        https                    465/tcp    open        smtps                    554/tcp    closed      rtsp                     993/tcp    open        imaps                    995/tcp    open        pop3s                    Nmap run completed -- 1 IP address (1 host up) scanned in 161 seconds king1#

Alternatively, we can attempt to connect to these ports from a remote site using the telnet command:

 %  telnet r2.simson.net 1022  Trying 64.7.15.234... telnet: connect to address 64.7.15.234: Operation timed out telnet: Unable to connect to remote host %

So it seems that the firewall is properly working. This is always a good thing to verify.

12.4.1.1 Limitation of netstat and lsof

There are many ways for a program to be listening for commands over the Internet without having the socket on which it is listening appear in the output of the netstat or lsof commands. Attackers have used all of these techniques to create programs that wait for an external trigger and, upon receipt of the trigger, carry out some predetermined action. These programs are typically called zombies . ^[45] They can be used for many nefarious purposes, such as carrying out remote denial-of-service attacks, erasing the files on the computer on which they are running, or even carrying out physical attacks (through the use of control equipment that may be connected to the computer).

^[45] Not to be confused with defunct processes, which are listed by the ps command as type "Z" (zombie). Defunct processes are usually the result of sloppy programming or unusual system events, but don't usually represent a security concern in and of themselves.

Here are a few of the ways that a zombie might be triggered:

The zombie might join an Internet Relay Chat room. If a special password is typed in the room, that might be a signal to the zombie to attack a remote machine.
The zombie might periodically probe a web page or make a specific DNS request, and carry out an attack depending upon the response that it receives.
The zombie might listen to the raw Ethernet device in promiscuous mode and initiate an attack when a command is sent to another computer that is on the same local area network. To further confuse matters, the zombie might initiate its attack using packets that have forged source addresses so that they appear to come from the other computer, when in fact they do not.
The zombie might run inside the system's kernel and be activated if an otherwise legitimate IP packet is received that has a particular IP or TCP option set. The trigger might be a sequence of values in the time-to-live field.
Instead of listening to the network, the zombie might instead probe the computer's log files. The zombie might be activated if a particular URL is fetched from the web server, or if a particular firewall rule is exercised.

Any of the above triggers might be set up so that they work only if they are exercised at a particular time.

To complicate matters even further, your system's kernel or utilities might be patched so that the process or TCP sockets associated with the zombie do not appear in program listings.

12.4.2 Monitoring Your Network with tcpdump

You can use the tcpdump command to watch packets as they move over your network. This command is included as a standard part of most Unix systems. The tcpdump command attaches to an interface and reads all the packets, optionally displaying them in your terminal window or writing them into a file. You can also specify a filter ”either simple or complex ”using the tcpdump filter language. ( Solaris systems come with a program called snoop that performs much the same function; you can also download a copy of tcpdump to run with Solaris systems.)

The tcpdump command has this syntax:

 tcpdump [ -adeflnNOpqRStvxX ] [ -c   count   ] [ -F   file   ]                [ -i   interface   ] [ -m   module   ] [ -r   file   ]                [ -s   snaplen   ] [ -T   type   ] [ -w   file   ]                [ -E   algo:secret   ] [   expression   ]

Special options that you may care about include:

-i interface: Specifies the interface that tcpdump should listen to. The ifconfig -a command can be used to list all the interfaces on a system:

 #  ifconfig -a  eth0      Link encap:Ethernet  HWaddr 00:50:DA:21:EE:0E           inet addr:10.15.9.3 Bcast:10.15.9.255  Mask:255.255.255.0           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:4516220 errors:6 dropped:0 overruns:1 frame:8           TX packets:1061622 errors:0 dropped:0 overruns:0 carrier:779           collisions:30650 txqueuelen:100           RX bytes:745434919 (710.9 Mb)  TX bytes:624301746 (595.3 Mb)           Interrupt:11 Base address:0xc000 lo        Link encap:Local Loopback           inet addr:127.0.0.1  Mask:255.0.0.0           UP LOOPBACK RUNNING  MTU:16436  Metric:1           RX packets:233421 errors:0 dropped:0 overruns:0 frame:0           TX packets:233421 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:0           RX bytes:52307549 (49.8 Mb)  TX bytes:52307549 (49.8 Mb)

-c count: Specifies the number of packets that should be recorded. By default, tcpdump runs until you type Ctrl-C.
-F file: Specifies a file that contains the filter to use
-s snaplen: Specifies the number of bytes of each packet that tcpdump should record. Normally, tcpdump records only the first 68 bytes of each packet. This is useful for traffic analysis, but is not useful if you are interested in viewing the contents of the packets. Specify -s 4096 to be sure that you are getting complete packets.
-w file: Specifies that tcpdump should write its packets to a file, rather than displaying them on the terminal.
-r file: Specifies that tcpdump should read packets from a file, rather than from the interface. This can be useful when analyzing dump files that have been previously created.
-n: Specifies that tcpdump should not convert IP addresses to hostnames. Normally, tcpdump performs a reverse name lookup on each IP address that it sees. Unfortunately, this can slow your system dramatically. It can also tell an attacker that you are monitoring the network. ^[46]

^[46] An attacker can send packets to a nonexistent host with a source IP address that is not used for any other purpose. If a reverse DNS query is performed for that IP address, the attacker knows that somebody is sniffing the traffic on the network.
-v , -vv , -vvv , -vvvv: Prints increasingly verbose amounts of information.

The tcpdump command is a great tool for learning what is going over your network. It can also be a great tool for violating people's privacy because people often send information over a network that is confidential, but without using encryption to ensure that it stays confidential. Remember that tcpdump captures packets moving over the network, whether or not they are originating or destined for your host. (Also remember that others on the network may also have access to tcpdump !)

Be aware that some local, state, and national laws may apply to the monitoring of network traffic. Wiretapping, email privacy laws, and even espionage statutes might come into play. Thus, if you intend to monitor network traffic, you should obtain the advice of competent legal counsel before doing so. Also note that your users may view excessive monitoring or storage of logs to be a serious invasion of privacy. Monitoring should be kept to a minimum, and you should ensure that your users understand that you are doing it ”finding out by accident will do little to build trust and cooperation with your user population.

For example, to display the next 16 packets moving over a network, you might use this command:

 r2#  tcpdump -i dc0 -c 16  tcpdump: listening on dc0 18:20:32.992381 r2.ssh > sdsl-64-7-15-235.dsl.bos.megapath.net.3055: P 1386964717: 1386964761(44) ack 819912634 win 58400 (DF) [tos 0x10]  18:20:32.993592 arp who-has r2 tell sdsl-64-7-15-235.dsl.bos.megapath.net 18:20:32.993630 arp reply r2 is-at 0:3:6d:14:f1:c7 18:20:32.994151 sdsl-64-7-15-235.dsl.bos.megapath.net.3055 > r2.ssh: . ack 44 win  63588 (DF) 18:20:33.012035 r2.1561 > 209.67.252.198.domain:  17877 PTR? 204.130.200.216.in-addr. arpa. (46) 18:20:33.127273 ipc3798c16.dial.wxs.nl.netview-aix-7 > r2.http: . ack 3791268234 win  8576 (DF) 18:20:33.127448 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 7505:8041(536) ack  0 win 57352 (DF) 18:20:33.127494 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 8041:8577(536) ack  0 win 57352 (DF) 18:20:33.294095 ipc3798c16.dial.wxs.nl.netview-aix-7 > r2.http: . ack 1073 win 8576  (DF) 18:20:33.294257 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 8577:9113(536) ack  0 win 57352 (DF) 18:20:33.294298 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 9113:9649(536) ack  0 win 57352 (DF) 18:20:33.490989 ipc3798c16.dial.wxs.nl.netview-aix-7 > r2.http: . ack 2145 win 8576  (DF) 18:20:33.491092 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 9649:10185(536) ack  0 win 57352 (DF) 18:20:33.491125 r2.http > ipc3798c16.dial.wxs.nl.netview-aix-7: . 10185:10721(536) ack 0 win 57352 (DF) 18:20:33.637745 hoh.centurytel.net.36672 > sdsl-64-7-15-236.dsl.bos.megapath.net. domain:  51006 [1au] AAAA? www.yoga.com. OPT  UDPsize=4096 (41) (DF) 18:20:33.638473 hoh.centurytel.net.36672 > sdsl-64-7-15-236.dsl.bos.megapath.net. domain:  40001 [1au] A6 ? www.yoga.com. OPT  UDPsize=4096 (41) (DF) r2#

Apparently, there are several hosts on this network. Two of them are running web servers. If you wish to see only packets that are requesting web pages, you could run tcpdump with a filter:

 r2#  tcpdump -i dc0 -c 10 dst port 80  tcpdump: listening on dc0 18:25:25.888628 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: P  4030704166:4030704548(382) ack 3582479098 win 65535 <nop,nop,timestamp 13952175  419395> 18:25:25.952951 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: .  ack 2897 win 64252 <nop,nop,timestamp 13952175 419495> 18:25:25.977404 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: .  ack 5793 win 64252 <nop,nop,timestamp 13952176 419495> 18:25:26.158506 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: .  ack 6475 win 65535 <nop,nop,timestamp 13952176 419495> 18:25:28.679752 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: P  382:765(383) ack 6475 win 65535 <nop,nop,timestamp 13952181 419495> 18:25:28.743668 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: .  ack 9371 win 64252 <nop,nop,timestamp 13952181 419523> 18:25:28.767757 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: .  ack 12267 win 64252 <nop,nop,timestamp 13952181 419523> 18:25:28.785001 205.128.215.120.43693 > sdsl-64-7-15-236.dsl.bos.megapath.net.http: .  ack 14411 win 65004 <nop,nop,timestamp 13952181 419523> 18:25:40.627919 200-158-162-37.dsl.telesp.net.br.4711 > sdsl-64-7-15-236.dsl.bos. megapath.net.http: F 1600587054:1600587054(0) ack 3610767708 win 64499 (DF) 18:25:40.800037 200-158-162-37.dsl.telesp.net.br.4711 > sdsl-64-7-15-236.dsl.bos. megapath.net.http: . ack 2 win 64499 (DF)

If you want to see what the remote users are actually sending, you can save the packets into a file (remembering to tell tcpdump to record the entire packet) and then use the strings command:

 r2#  tcpdump -i dc0 -c 16 -s 4096 -w packets.dmp dst port 80  tcpdump: listening on dc0 r2#  strings packets.dmp  (F9@ (G9@ A=q) (H9@ (I9@GET /roots/menu/default.asp HTTP/1.1 Accept: */* Referer: http://www.yoga.com/ Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: www.yoga.com Connection: Keep-Alive Cookie: ASPSESSIONIDGGGQGCJU=DKDBOMMABEJIHPAGBANHCHKA (J9@ (K9@ (L9@ Q#RP Q#RP " -z GET /home.asp HTTP/1.1 Accept: */* Referer: http://www.yoga.com/ Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: www.yoga.com Connection: Keep-Alive Cookie: ASPSESSIONIDGGGQGCJU=DKDBOMMABEJIHPAGBANHCHKA (M9@ NN      P " 79 r2#

Significantly more sophisticated analysis can be performed using snort , an open source intrusion detection system, or using a commercial network forensics analysis tool, which will monitor all of the traffic that passes over the network, reassemble the TCP/IP streams, and then analyze the data. Systems like these not only monitor packets, but also analyze them and compare them to rules designed to detect intrusion attempts. For example, here's some of the output of snort :

 Aug 20 14:07:33 tala snort[24038]: [1:615:3] SCAN SOCKS Proxy attempt  [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 128.171.143.7:2436  -> 10.13.6.226:1080 Aug 20 14:12:55 tala snort[24038]: [1:1734:4] FTP USER overflow attempt  [Classification: Attempted Administrator Privilege Gain] [Priority: 1]: {TCP} 62.64. 166.237:3158 -> 10.13.6.226:21 Aug 20 14:23:19 tala snort[24038]: [1:884:6] WEB-CGI formmail access [Classification:   sid] [Priority: 2]: {TCP} 162.83.207.174:2129 -> 10.13.6.226:80 Aug 20 14:44:46 tala snort[24038]: [1:654:5] SMTP RCPT TO overflow [Classification:  Attempted Administrator Privilege Gain] [Priority: 1]: {TCP} 128.248.155.51:44743 ->  10.13.6.226:25 Aug 20 15:07:48 tala snort[24038]: [1:937:6] WEB-FRONTPAGE _vti_rpc access  [Classification:  sid] [Priority: 2]: {TCP} 202.155.89.77:2566 -> 10.13.6.226:80

This log shows several intrusion attempts on the host 10.13.6.226, including a scan for an open SOCKS proxy (which can be abused by spammers), an attempt to overflow the FTP server's buffer with a long USER command, an attempt to access the formmail CGI script (which has been abused by spammers), an attempt to overflow the SMTP server's buffer with a long RCPT TO command, and an attempt to access one of the private directories used by web sites managed with Microsoft FrontPage.

12.4.3 Network Scanning

In recent years , a growing number of programs have been distributed that you can use to scan your network for known problems. Unfortunately, attackers can also use these tools to scan your network for vulnerabilities. Thus, you would be wise to get one or more of these tools and try them yourself, before your opponents do.

There are several kinds of network scanners available today:

Commercial network scanners: These programs, typified by the Internet Security Scanner (ISS), systematically probe all of the ports of every host on your network. When a TCP connection is accepted, the scanner examines the resulting banner and looks in its database to see if the banner corresponds to a version with known security vulnerabilities. The advantage of these systems is their large database of vulnerabilities. The disadvantage of these systems is that they are frequently licensed to scan a limited set of IP addresses, and those licenses can be quite expensive.
Freeware security scanners: These programs are similar to commercial scanners, except that they are usually open source tools that are freely available. An early example of such a program was SATAN; a popular and up-to-date one is Nessus. The advantage of these systems is their cost. The disadvantage is that their databases are can be limited when compared to the commercial offerings, though Nessus in particular has a very extensive database.

Security Scanners

Before 1990, people didn't like to talk about security vulnerabilities. It was difficult to find published papers describing vulnerabilities: how they came to be, how they were found, and how to fix them. To find out about problems one had to get a "friend of a friend" introduction to one of the closed mailing lists, or else get a copy of a closely guarded technical report detailing problems. The result was that most system administrators didn't know how to secure their systems, and researchers couldn't perform organized studies of vulnerabilities.

That changed when Dan Farmer wrote the COPS scanner under the direction of Gene Spafford at Purdue, then released it on the Usenet. Suddenly, there was a widely available system that scanned for vulnerabilities that were known to several experts and also gave recommendations on how to patch them. (It was an explicit design principle of the project to provide information about how to fix the problems rather than exploit them.)

COPS has been downloaded, modified, used, extended, emulated, and studied by hundreds of thousands of people in the intervening years. It succeeded in many ways beyond the authors' expectations. However, there are at least two sets of thoughts that we pose from this experience that are interesting to contemplate:

As recently as early 2002, Spafford is still getting requests for help with configuring COPS and interpreting the output! The software is 12 years old. What does it say about sysadmins that they still expect this software to work? What does it say about the coding and design used that parts of COPS still do work? What does it say about coding practices that many versions of Unix and Linux are still shipped with vulnerabilities that COPS identifies?
Had Farmer and Spafford taken out software patents on the scanner and some of its subsystems, the patents would still be in force and the authors might be very wealthy. However, would the overall state of security on the Internet be better today as a result? Would there be fewer security tools developed and in use? Maybe people would be less tolerant of flaws in deployed systems if scanning tools were less available? (Contrast this with what patents on public-key cryptography did to security.) Does this imply anything about software patents?

As with most other aspects of Internet technology, it is amazing to see how much has changed in only 10 or 15 years. And to think what the next decade will bring.

Freeware port scanners: These programs typically scan for open ports and services, but they do not include a database of known vulnerabilities. One example of these programs is nmap , the network mapper, which can perform a large number of different kinds of scans and is also remarkably good at identifying the operating system of a remote machine based on the way it responds to scanning. A typical output from nmap was shown earlier, in Section 12.4.1.