The importance of firewalls is well known and well documented. Linux uses a kernel-based filtering mechanism known as ipchains for creating firewall rules on Linux 2.2.x systems. Creating a good firewall rule set is important, and everyone running Linux should have configured ipchains to handle network traffic on their machines.

While this is a good first step to improving system security, it is not the only step. Another necessity in keeping your system secure is regular maintenance on the system—by this I mean checking logs and ensuring that your firewall rules work as expected. In both cases, auditing your system should be a regular occurrence, especially for a system administrator. While a home user casually running Linux as a dial-up user can get away with performing no audits and having few or no ipchain rules, any Linux user with a dedicated connection (cable, ADSL, etc.) should invest some time and effort into securing their system. After all, it is your system, and unless you care nothing about any of the data on it, you need to take steps to secure it. Ask yourself these questions: Do I want people looking at my financial records? Do I want people looking at my e-mail? Do I want people snooping into what I download from the Internet or what I write on my word processor? If the answer to any of these questions is no, then you need to seriously consider becoming aware of your system and especially your system security.

One very good tool to help you perform auditing on your system is nmap. This tool is a port scanner and thus can be used to snoop on others as well as yourself. The purpose of this Daily Drill Down is not to use a tool like nmap on your neighbor’s computer to look for holes in his system (unless he asks you to, of course), but to use nmap on your own system or network to evaluate its security and help you tighten security.

A problem many people have—especially those new to Linux—is that they don’t understand that many daemons run on a typical Linux system. What’s even worse: They may understand that there are a number of daemons running but may not know what each does or how to turn it off—or hide it from the outside world—if necessary. This is where nmap comes in handy. It allows you to find the open ports on your system, and with that information, you can write the appropriate firewall rules to make those ports unavailable to the outside world.

Running nmap on a regular basis also helps you determine changes in the status of listening services on your system. It helps you find out whether an unauthorized program is running on the computer, which may be something you inadvertently forgot to turn off or protect or which could be the result of someone having broken into your system and setting up their own daemon to allow himself access.

Installing nmap
You can find nmap from, ironically enough,, where you can download a pair of generic RPMs or the source tarball. The nmap utility comes with two tools: nmap, the text-mode console client, and nmapFE (also known as xnmap), which is a GUI front end to nmap. For this Daily Drill Down, I’ll assume that you will be downloading the source tarball and building nmap from scratch. Download the latest stable version of nmap, which is currently 2.53, and save the nmap-2.53.tgz file into the /usr/local/src directory. Then, execute the following commands to unpack, compile, and install nmap:
cd /usr/local/src
tar xvzf nmap-2.53.tgz
cd nmap-2.53
make install

You can build nmap as a user if you like. To install it, however, you must be logged in as root, which means that you must either use su to change to root or use sudo to execute the make install command as root. Once this is complete, you’ll have nmap installed and ready to run.

Using nmap
The first time you run nmap, you should do so as root. There are a number of tests it can run as root but not as a regular user. This is because nmap needs access to privileged TCP ports (those below 1024, which can be bound to only as root) to run the full suite of tests. When you first run nmap, keep in mind the purpose of the machine you’ll be scanning. If it’s a Web server, all that really needs to be accessible is port 80 for Web connections and possibly port 443 if you want to allow SSL-based HTTP connections. If it’s a DNS server, port 53 should be available. If you notice other open ports that should not be open, you’ll have to configure the host to restrict those ports. Realistically, if you’re looking at a machine that should only be a Web server, there should be no reason to have open the SMB ports for file and print sharing with Windows computers. You may want to have FTP access available, but if it isn’t a mail server, you shouldn’t have the POP3, SMTP, or IMAP ports open.

For the first-time run of nmap, execute the following command:
nmap -O -sX

This command performs various checks against host The first, specified by -O, activates the remote host identification via TCP/IP fingerprinting. Basically, nmap uses a variety of techniques to detect subtleties in the network stack of the operating system that’s running the computer you’re scanning. It then takes this information and compares it to a database of known fingerprints and tries to make a best guess as to what operating system the remote computer is running. The second command, -sx, tells nmap to run what is called an Xmas Tree scan, which is a little more advanced than a simple SYN scan. It turns on additional flags on the packets it sends to the remote host, including the FIN, URG, and PUSH flags. The Xmas Tree scan is perhaps one of the most comprehensive scans that nmap performs. Although nmap can also perform a variety of other scans, such as a Stealth FIN scan (-sF), a Null scan (-sN), a ping scan (-sP), a UDP scan (-sU), and a few others. For more information on the various scan types you can use, view the nmap man page by issuing this command:
man nmap

Now that you have run the nmap scan, you will have output similar to this:
Starting nmap V. 2.53 by ( )
Interesting ports on (
(The 1509 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
111/tcp open sunrpc
113/tcp open auth
139/tcp open netbios-ssn
631/tcp open unknown
897/tcp open unknown
1024/tcp open kdm
1026/tcp open nterm
3306/tcp open mysql
6000/tcp open X11

TCP Sequence Prediction: Class=random positive increments
 Difficulty=2089903 (Good luck!)
Remote operating system guess: Linux 2.2.12

Nmap run completed — 1 IP address (1 host up) scanned in 7

There is quite a bit of information on this screen—some of it a little unsettling. This is a personal Linux machine that’s used for personal work. Because a lot of remote work is done on it, having the FTP and SSH ports open is normal. The SMTP port should be accessible only by the localhost, so we should restrict access to port 25 from the outside world, as well as the netbios ports, mysql, kdm, and X11. All of those ports should be available only to the localhost, because no one outside of your system has any reason to be connecting to your X server or to your MySQL server.

Unfortunately, this scan was performed on the localhost, and therefore it isn’t entirely accurate. The firewall saw the scan coming from the localhost and allowed everything to be seen, so it was a little self-defeating. Ideally, you should alter your firewall rules when doing your scan so that the host performing the scan is not a “trusted” host but has the same restrictions as any other machine beyond your firewall.

Of course, another problem with this scan is that a number of services are listed; you may not know to which programs they belong and thus won’t know how to turn them off. This is where another handy program comes into play. For instance, you may not know what the auth service is (associated with ident) or the sunrpc service (associated with NFS). Of course, nmap couldn’t tell us which services belonged to ports 631 and 897 either. If it doesn’t know, how can you be expected to know?

The solution is to use netstat on the host you scanned. Obviously this technique won’t work on a Windows machine, but if the host you scanned was a Linux machine, the netstat utility will be available to you. Execute the following command:
netstat -l -p –protocol=inet

By default, netstat will list all listening ports, including UNIX domain sockets, in which we aren’t interested. All we want to see are the TCP/UDP ports used by the TCP/IP protocol. The output of the netstat command may look something like the following table:

Proto Recv-Q Send-Q Local address Foreign address State PID/ program name
tcp 0 0 localhost localdo: 16001 LISTEN 26295/esd
tcp 0 0 *:6000 *:* LISTEN 28174/X
tcp 0 0 *.1026 *:* LISTEN 1083/kd,
tcp 0 0 somehost. so:netbios-ssn *:* LISTEN 959/smbd
tcp 0 0 *:mysql *:* LISTEN 904/mysqld
tcp 0 0 *:ftp *:* LISTEN 820/proftpd
tcp 0 0 *:7102 *:* LISTEN 772/fontfs
tcp 0 0 *:smtp *:* LISTEN 762/tcpserver
tcp 0 0 *:897 *:* LISTEN 718/rpc.statd
tcp 0 0 *:1024 *:* LISTEN 694/rpc.mountd
tcp 0 0 *:631 *:* LISTEN 567/cupsd
tcp 0 0 *:ssh *:* LISTEN 548/sshd
tcp 0 0 *:auth *:* LISTEN 510/identd
tcp 0 0 *:sunrpc *:* LISTEN 437/portmap
udp 0 0 localhost. localdom:1248 *:* LISTEN 6465/smbd
udp 0 0 *:798 *:*
udp 0 0 *:799 *:*
udp 0 0 *:800 *:*
udp 0 0 netbios-dgm *:* LISTEN 969/nmbd
udp 0 0 netbios-ns *:* LISTEN 969/nmbd
udp 0 0 *:xdmcp *:* LISTEN 1083/kdm
udp 0 0 netbios-dgm *:* LISTEN 969/nmbd
udp 0 0 netbios-ns *:* LISTEN 969/nmbd
udp 0 0 *:netbios-dgm *:* LISTEN 969/nmbd
udp 0 0 *:netbios-ns *:* LISTEN 969/nmbd
udp 0 0 *:895 *:* LISTEN 718/rpc.statd
udp 0 0 *:1026 *:*
udp 0 0 *:1024 *:* LISTEN 694/rpc.mountd
udp 0 0 *:2049 *:*
udp 0 0 *:841 *:* LISTEN 664/rpc.rquotad
udp 0 0 *:631 *:* LISTEN 567/cupsd
udp 0 0 *:sunrpc *:* LISTEN 437/portmap
Output of netstat -l -p –protocol=inet

There are quite a few daemons running. The ones we are most interested in are the servers in the LISTEN state, which are at the beginning of the list. You can see which program and Process ID (PID) are associated with each listening port. Combine this information with the output of nmap, and you’ll have an idea as to what needs to be eliminated or tightened. From this list, you can also see that port 897, which was listed as unknown by nmap, was opened by the rpc.mountd process, which is used for NFS file sharing. The other unidentified port was 631, which is owned by the CUPS daemon (CUPS is the Common UNIX Printing System, a replacement for other printer daemons such as lpd or LPRng). That port is open to handle printing requests.

With the information you now have, you can make a few determinations. You need to double-check that the ports nmap found open are available only to other systems in the local network and not those out on the Internet. The only ports you want to make available on a machine with this particular configuration would be the FTP and SSH ports. Of course at the same time, you want to ensure that you’re using a secure FTP server—or at least a reliable one. If you insist on using wu-ftpd, make sure that you’re using the latest release version, but I’d personally suggest using ProFTPD if you want to have your personal machine open for FTP access. There should also be no need for anonymous FTP access on a machine of this type, so I would remove any options for anonymous FTP access.

The GUI front end: xnmap
Of course, you can also use the GUI front end by typing xnmap on the command line. This will provide you with a very nice interface to select the host (or hosts) you want to scan, as well as a simple way to select check boxes for various scans you’d like to perform. With the GUI, you can execute all of the various scan options against the remote (or local) system. One nice feature is that it will also show you the equivalent nmap command-line options, depending on what options you select, so that you can perform the same scans in the future on a system without X installed or run the scans you like as a monthly cron job.

Logs with xnmap
Using xnmap, you can also create logs of your scans. On the File menu, you can select to save or open a log file. This way, you can save your logs after each scan and keep them for future reference (not a bad idea). You can also do this on the command line by using redirection, as shown here:
nmap -O -sX >> /var/log/nmap.log

This command will write all of the output from nmap to file /var/log/nmap.log. You can also use what nmap calls a machine-parsable log format. This basically puts each scan onto three lines in the defined log file, where the first and third lines are comments regarding that particular scan, and the second line is uncommented and contains the output of nmap on one long line with information separated by the forward slash (/) character. This output is handy for using external programs to generate reports based on the log. If you wish to use the machine-parsable log as well as a human-readable log, you can use the following command on the command line:
nmap -O -sX -m /var/log/nmap-parse.log >> /var/log/nmap.log

You’ll find using xnmap to be quite easy and comfortable. It’s certainly much nicer to use than learning and typing out the various nmap commands on the command line. And it offers you a central location where you can scan multiple hosts at once with a variety of scan types.

The nmap utility is a very handy tool that can and should be used as a regular part of your security auditing. With its wide range of options and advanced scanning capabilities, it should be added to every system administrator’s arsenal. While years ago programs such as SATAN were considered the ideal tool to use, nmap is clearly one of the easiest and most powerful tools of its kind now available. And nmap can do just as much as SATAN or SAINT or any other port scanner you may find. It’s fast, it works well, and it’s free. Just the kind of tool everyone should have installed and use with some regularity.

Performing port scans is but one part of a healthy and regular security audit. While there are many other tools available to help secure your system, nmap is perhaps one of the first tools you should be using on any new installation. In this Daily Drill Down, I’ve shown you how nmap will quickly help you detect problems and insecure configurations, thus saving you future headaches.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.