Intrusion detection systems are one way to maintain network integrity. However, a commercial IDS -- properly called NIDS, for Network IDS -- can be costly to install and maintain. Even open-source systems such as Snort may require an investment of time in order to set up the necessary rule sets and databases. Either way, a NIDS usually assumes that you have several reasonably powerful machines lying around for use as detection hosts. These machines sit on a vulnerable segment of the network, collecting and comparing network traffic to known attack signatures. As networks get faster, this becomes more difficult—older machines are simply incapable of running at Gigabit Ethernet speeds, much less capturing and analyzing all the traffic that passes through a GE link. Newer, more capable hardware, of course, is usually being put to more profitable uses.

If you can't afford a NIDS, basic network mapping techniques are still beneficial. Start by regarding your network not as something you maintain, but as something you want to break into. Begin collecting intelligence about the machines on your network, using the same tools available to the intruder. I’ll ignore the complex subject of local host security for the moment and focus on eliminating network vulnerabilities, for several reasons. First, local host security -- i.e., preventing security breaches by authorized local users -- involves questions of policy that can't be addressed through technology, such as how to explain to your boss that just because he's the boss doesn't mean he needs the root password to your transaction server jotted down on a Post-It stuck to his monitor. Secondly, for this exercise, we'll want to assume that a determined local user can become root at will—therefore, any unauthorized access to the system via the network is unacceptable. Never forget, of course, that most security breaches occur from the inside. Don’t focus exclusively on securing the network.

Establishing a Baseline Using nmap
The best tool for network scanning, also known as port scanning, is the open-source Nmap. Because of the sensitive nature of this tool -- improper use can shut down entire networks -- I recommend against downloading a binary distribution of this tool unless absolutely necessary. The source code is very clean, and if you've never compiled anything before, it's a good utility to start with. However, relatively trustworthy Linux binaries are available at the host site. To find binaries for other operating systems, stick to well-known sites such as Sunfreeware.com.

Nmap performs all sorts of network scans, from simple ping scans to see what hosts on a network are "alive" to more advanced scans by protocol and packet type. It's even possible to distribute scans across multiple hosts to hide your true identity. Nmap is clearly designed to enable rapid pinpointing of hosts vulnerable to attack, and that's exactly its strength -- and the source of much criticism in the security community. In my opinion, the mere existence of such a tool has done much to level the playing field and increase awareness of security among vendors, which is never a bad thing. By the same token, SANS contends that there are legitimate groups devoted to mapping the entire Internet—so there are undoubtedly more nefarious ones as well, probably using the same tools.

Reading Nmap Output
Nmap scans a list of target machines and outputs a list of the interesting ports on each. A network "port" is simply an abstraction that describes a communication channel. "Open" ports are associated with running processes. Such processes are said to be "listening" on the network. Thus, a listening process does something with the data it receives over its port. This makes open ports dangerous. For instance, a web server process, under normal circumstances, accepts properly formatted HTTP requests and sends back the corresponding web pages. However, if the web server process accepts improperly formatted requests, or responds unpredictably to properly formatted ones, sensitive information might be divulged.

Network traffic directed to closed ports also generates responses, informing the requesting machine that the ports are "closed." This is normally accomplished via an ICMP "port-unreachable" message. ICMP is a network protocol (similar to the more familiar TCP and UDP) used to determine the state of a network connection. When you "ping" another machine on the network, you’re actually sending an ICMP message. Although it’s often simpler and more effective to direct denial-of-service attacks at listening TCP or UDP ports, certain ICMP requests can overwhelm a target machine, or force the machine to divulge information about itself. These types of attacks may seem like mere annoyances, but may lay the foundation for actual intrusions. For instance, the ICMP "timestamp" request can be used to help predict TCP sequence numbers, which aids in IP spoofing. When scanning your own network for vulnerabilities, don’t assume that having all ports closed makes your machine invulnerable -- read up on how the networking on your particular machine operates, or you may be surprised.

Here’s a scan of a single hypothetical machine.

  $ /usr/local/bin/nmap -sT 10.0.0.1

        Starting nmap V. 2.54BETA29 ( www.insecure.org/nmap/ )
        Interesting ports on fake.host.name.com (10.0.0.1):
        (The 1545 ports scanned but not shown below are in 
         state: closed)
        Port            State           Service
        22/tcp          open       ssh                     
        80/tcp          open            http                    
        443/tcp         open            https

        Nmap run completed -- 1 IP address (1 host up) scanned 
             in 2 seconds

  $ /usr/local/bin/ssh -v 10.0.0.1

        < output snipped for clarity >
        debug1: match: OpenSSH_3.1p1 pat OpenSSH*

$ /usr/local/bin/nmap -sT 10.0.0.2

Starting nmap V. 2.54BETA29 ( www.insecure.org/nmap/ )
Interesting ports on hypothetical.host.com (10.0.0.2):
(The 1525 ports scanned but not shown below are 
                in state: closed)
Port    State      Service
7/tcp           open            echo                    
9/tcp           open            discard                 
13/tcp          open            daytime                 
19/tcp          open            chargen                 
21/tcp          open            ftp                     
22/tcp          open            ssh                     
23/tcp          open            telnet                  
37/tcp          open            time                    
80/tcp          open            http                    
111/tcp         open            sunrpc                  
512/tcp         open            exec                    
513/tcp         open            login                   
514/tcp         open            shell                   
515/tcp         open            printer                 
540/tcp         open            uucp                    
1501/tcp        open            sas-3                   
4045/tcp        open            lockd                   
6000/tcp        open            X11                     
7100/tcp        open            font-service            
32777/tcp       open            sometimes-rpc17         
32778/tcp       open            sometimes-rpc19         
32779/tcp       open            sometimes-rpc21         
32780/tcp       open            sometimes-rpc23         

Nmap run completed -- 1 IP address (1 host up) 
        scanned in 1 second

  $ /usr/local/bin/nmap -O 10.0.0.2

        Starting nmap V. 2.54BETA29 ( www.insecure.org/nmap/ )
        TCP/IP fingerprinting (for OS scan) requires root 
                privileges which you do not appear to possess. 
                Sorry, dude.

        QUITTING!

  # ./nmap -O 10.0.0.2

        < output snipped for brevity >

        Remote operating system guess: Sun Solaris 8 early 
                access beta through actual release
        Uptime 38.959 days (since Mon Mar 1319:39:06 2002)

        Nmap run completed -- 1 IP address (1 host up) 
                scanned in 9 seconds

Nmap has provided us the probable operating system and a large list of potentially vulnerable ports on this host. Compromising it is probably merely a matter of additional research.

Massive Attack
Nmap offers many more capabilities than those listed above. The "-sT" switch I used to scan the above two hosts uses the simplest form of scan, a TCP connect scan. This scan is easily detectable, and is likely to betray itself in the target system's logs. Also, a TCP scan only scans TCP ports, ignoring the equally vulnerable UDP ports. UDP is the connectionless protocol used in applications such as streaming video, while TCP is the connection-oriented protocol used for interactive tasks such as HTTP and telnet sessions. Many hall-of-fame security holes rely on the UDP protocol.
Now that we know what nmap can do, we can use it to establish a baseline of all our hosts:

  nmap -iL list -sS -sU -sR -O -oA results -v -v

  results.gnmap           machine-readable results
        results.nmap            human-readable results
        results.xml                     XML-formatted results for 
                                                  use by other applications

The duplicated "-v" switches at the end simply increase the verbosity of nmap’s output slightly. The type of scan desirable for your network may vary. The nmap manual page describes all these options in much more detail. In any case, the resultant list gives us two imperatives. First, we need to secure any ports we don’t absolutely need running by shutting down their associated processes. Secondly, we need to be able to compare these results to a more current scan on a regular basis.

Securing Hosts
Managing applications, closing ports, and setting up host-based IP filtering is a topic for another article, but a few words are in order. Networking gurus tend to assume that you want your host to be visible on the network, or that allowing any and all traffic to reach the host is a good thing. Exactly the opposite is true, as most system administrators know; thus, the prevalence of firewalls. However, the "protected" areas behind firewalls are frequently left unrestricted. This is folly: most security breaches are inside jobs, and a firewall is no substitute for good host-based security. On a properly secured host, ALL network traffic should be accounted for, incoming and outgoing.

Most host-based network filtering packages have the capability to block traffic bi-directionally. An excellent tutorial on restricting IP traffic in this manner is the How-To document for the IP Filter package. IP Filter is a free firewall package included with the FreeBSD and NetBSD operating systems, but is compatible with many others. Incoming and outgoing traffic should both originate from trusted users. For incoming traffic, this is almost never possible—if you run a Web server, it’s usually available to the entire world. Filtering outgoing traffic ensures that an intruder cannot use the machine to launch additional attacks, nor local personnel use the machine for purposes other than originally intended. It should go without saying that for this to work, the filtering program must be immune to interference. This can usually be accomplished by running the filter as a different user than any listening process, and by limiting root access to trusted personnel.

Comparing Periodic Nmap Scans
Comprehensive nmap scans of any size can be time-consuming. I’ve personally had a scan of 25 machines take over 5 hours to run. Unfortunately, a faster machine is not the answer—this delay is imposed by the need for various types of scans to timeout. UDP scans progress slower than TCP scans, in general. However, as UDP ports have historically been the source of major security woes, I can’t recommend skipping them.

Once you have a baseline scan, peruse nmap’s Related Projects page. Two tools are of interest here. For a network of medium to large size, the nlog CGI scripts are useful. These generate a searchable database of your nmap scan results—essential for a network of any size. Search terms include port, protocol, IP address, and more. Secondly, the ndiff Perl scripts can be used to generate a list of changes between two machine-readable nmap output files. Ndiff is analogous to a Tripwire program for your network.

Store a baseline scan of your network somewhere inaccessible to the average user—perhaps even on read-only media—and compare it to a regularly scheduled scan using the cron facility. This works on the assumption that an intruder will want to do something with your machine once he/she’s gained access: open up an IRC client, start an FTP server, or begin attacking other machines. Evidence of such activity should emerge in an nmap scan.

Since some programs, especially those that use the RPC facility, tend to use high-numbered UDP ports and to change them when the application is restarted, you’ll also want to compare your baseline to a list of known applications and ports to differentiate false alarms from real ones. The netstat tool included with nearly all UNIX systems is useful for this. Here’s sample output from the 10.0.0.1 machine we scanned earlier (some extraneous columns of data have been removed for formatting purposes):

Since netstat’s output shows the same three open ports, we’re assured of the accuracy of our nmap scan. Netstat will also show you any open network connections. For instance, here’s evidence of an established Secure Shell connection (again, some extraneous columns of data have been removed for formatting purposes):

Netstat’s output should be checked during your first scan, to ensure that your baseline isn’t already corrupted. Nmap, along with a few extra tools to parse its output, can be used to as a simple yet effective network integrity checker. While not as proactive as a full-fledged intrusion detection system—nmap scans can only alert you after something unwonted has occurred—this model serves a different purpose in any case. A NIDS detects attempted intrusions as they occur, in real time, but often generating multiple false alarms. However, a NIDS is only as good as its database of attack signatures. If an intrusion does occur despite the best efforts of the NIDS, monitoring of individual hosts is the next line of defense. Periodic nmap scans, like Tripwire and other file integrity checkers, are a key component of any well-rounded security infrastructure.

Simple, Yet Effective
Nmap, along with a few extra tools to parse its output, can be used to as a simple yet effective network integrity checker. While not as proactive as a full-fledged intrusion detection system—nmap scans can only alert you after something unwonted has occurred—this model serves a different purpose in any case. A NIDS detects attempted intrusions as they occur, in real time, but often generating multiple false alarms. However, a NIDS is only as good as its database of attack signatures. If an intrusion does occur despite the best efforts of the NIDS, monitoring of individual hosts is the next line of defense. Periodic nmap scans, like Tripwire and other file integrity checkers, are a key component of any well-rounded security infrastructure.