12.4 Managing Services Securely
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.
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. 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.
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 lsofcommand:
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.
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.
We can verify that r2's
firewall is in proper operation
by probing the system with the nmap command from an outside host:
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. 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).
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.
- -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.
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.
|