Uses for Port Scanners

Once you have permission to scan, you need to consider what your goal is in scanning your network.

Network Inventory

Not sure exactly how many machines you have running? Want to know the IP addresses of all your servers? Ports scanners offer a quick way to scan a range of addresses and find all the live machines on that segment. You can even use the Nlog tool (discussed later in this chapter) to log this into a database and create useful reports.

Network/Server Optimization

A port scanner will show you all the services currently running on a machine. If it is a server machine, it is likely that there are many programs running, but you may not be aware that some of these services are running. They may not be needed for the primary function of the machine. Remember, the more services that are running, the more insecure it is. And all these programs can slow down the performance of a heavily loaded server. Things like extraneous Web servers, FTP servers, or DNS servers can take processor cycles away from the main function of the box. Port scanning your servers and then going through and optimizing them can give you an immediate increase in speed and response times.

Finding Spyware, Trojan Horses, and Network Worms

Regular Web surfers will often pick up little programs from Web sites that try to track their behavior or send custom pop-up ads to their computer. These programs are known as spyware because they often try to track the user's activities and may report this data back to a central server. These programs are usually benign, but enough of them can dramatically slow down a user's performance. Also, they are often not well written and can interfere and crash other programs. They also can present opportunities for hackers looking for weak spots.

Another class of network-aware software that you definitely don't want on your network is the Trojan horse. These programs are specifically designed for those intent on breaking into networks. Just like the Trojan horse of Greek lore, these programs allow hackers and crackers a back door into your network, usually advertising their presence via an open network port. Trojan horses can be notoriously hard to track down even if you are using anti-virus software. They don't always set off anti-virus scanners, and sometimes the only thing that shows they are there is an open network port. Once inside a computer, most Trojan horses try to communicate outwards to let their creator or sender know they've infected a machine on these ports. Table 4.2 lists the most prevalent Trojan horses and their port numbers. Many of the port numbers are easily recognizable from the clever arrangements of numbers (for example, NetBus is 54,321, and Back Orifice is 31,337, which stands for "elite" in the numbers used for letters in hacker code). Trojan horses tend to run on high number ports with unusual, unrecognizable port numbers, although some really wily Trojans try to run on low-level reserved ports to masquerade as a conventional service.

Table 4.2. Major Trojan Horse Ports

Port Number	IP Protocol	Trojan Horses Known to Use These Ports
12456 and 54321	TCP	NetBus
23274 and 27573	TCP	Sub7
31335	TCP	Trin00
31337	TCP	Back Orifice
31785–31791	TCP	Hack 'a'Tack
33270	TCP	Trinity
54321	UDP	Back Orifice 2000
60000	TCP	Deep Throat
65000	TCP	Stacheldraht

Network Worms are a particularly nasty type of virus. They are often network-aware and open up ports on the host computer. Network Worms use the network to spread and as such sometimes show up on network scans. A port scan can be a valuable backup to anti-virus protection against these threats.

Looking for Unauthorized or Illicit Services

Regulating what employees run on their computers is a tough task. While you can limit their access to floppy and CD-ROM drives using domain security polices, they can still download software easily from the Web. Also, employees like to run instant messaging services such as ICQ or AOL Instant Messenger to communicate with friends, relatives, and other people outside your network. If you allow these services, you should be aware of the security risks that they present to your enterprise. In addition to the employee productivity and bandwidth they eat up, instant messaging networks are often used to spread viruses. They also are known for having bugs that allow users to access files on the local machine. Even if you don't allow them officially, they can be hard to track down. A regular port scan will turn up many of these services by showing the open ports they use.

There are even more noxious applications that your users may try to run, such as peer-to-peer file transfer software. This software allows users to network with thousands of other users worldwide to share files such as music, movies, and software programs. These programs can consume your bandwidth because of the size of the files transferred (often hundreds of megabytes). This can also potentially expose your company to legal liability for copyright violations. The large media companies as well as software concerns are pursuing illegal file sharing more aggressively these days, and companies present a much bigger target than individuals. Also, this use can open up the inside of your network to outsiders. These programs can make part of users' hard drive accessible by other users of the software, often without explicitly notifying them. And there are many hacks and exploits for these programs that allow malicious users to do far more. The bottom line is that you don't want employees using peer-to-peer software on your enterprise network. And with a good port scanner like the one discussed next, you can identify any users of such software and shut them down.

Nmap: A Versatile Port Scanner and OS Identification Tool

Nmap is arguably the best port scanner out there, bar none. It is primarily written by a guy called "Fyodor" (a pseudonym). His software is used in many other programs and has been ported to just about every major operating system. It is a prerequisite for the Nessus vulnerability scanner described in Chapter 5. There are also several add-ons available, including the Nlog program discussed later in this chapter. Suffice it to say, Nmap should be in every security administrator's toolkit. The following are some of the main advantages of Nmap.

• It has lots of options. Simple port scanners are available with tools like Sam Spade (see Chapter 2). However, Nmap has a huge number of options, which gives you almost unlimited variations on how you can scan your network. You can turn down the frequency of probe packets if you are nervous about slowing down your network or turn them up if you have bandwidth to spare. Stealth options are one thing that Nmap has in spades. While some criticize these features as being needed only by hackers, there are legitimate uses. For example, if you want to check to see how sensitive your intrusion detection system is, Nmap lets you do that by running scans at various stealth levels. Nmap also goes beyond mere port scanning and does OS identification, which comes in handy when trying to figure out which IP is on which machine. This section discusses most of the major options, but there are so many they can't all be covered here.

• It's lightweight, yet powerful. The code for Nmap is pretty small and it will run on even the oldest machines (I routinely run it on a Pentium 133 with 16 MB of RAM, and I'm sure it would run on something older). In fact, it even runs on some PDAs now. It packs a lot of punch in a small bundle and it has no problem scanning very large networks.

• It's easy to use. Even though there are numerous different ways to run it, the basic default SYN scan does everything you want for most applications. There are both command line modes and graphical interfaces for both UNIX and Windows to satisfy both the geeks and the GUI-needy. It is also very well documented and supported by a large body of developers and online resources.

Installling Nmap on Linux

If you are running Mandrake, RedHat, or SUSE, you can get the files from the CD-ROM that accompanies this book, or download the binary RPM. To download the files from the Web, type this at the command line:

rpm -vhU http://download.insecure.org/nmap/dist/

  nmap-3.50-1.i386.rpm

rpm -vhU http://download.insecure.org/nmap/dist/

  nmap-frontend-3.50-1.i386.rpm

You will need two packages: the actual Nmap program with the command line interface and the graphical front end for X-Windows. The preceding commands will download the RPMs and run them. You may want to update the command to reflect the file for the latest version (see the Web site for the exact file name). Once you have run both RPMs, you should be ready to go.

If that doesn't seem to work or if you have a different distribution, you will have to compile it manually from the source code (see the sidebar on compiling). This is a little more complicated but not too difficult. It is good to learn how to do this as you will be doing it with other security tools in this book. You will be seeing these commands often, in this format or one very similar to it.

Compiling from Source Code: A Quick Tutorial Many major UNIX programs are written in C or C++ for both speed and portability. This makes it easy for programmers to distribute one version of the source code and allow users to compile it for their particular operating system. Most UNIX systems come with a C compiler built in. The open source C compiler used by Linux is called Gcc (for Gnu C Compiler). When you want to build a binary program from some source code, you invoke Gcc (assuming the program is written in C code). From the directory where you untarred the program source code, type: ./configure program_name This runs a program that checks your system configuration with what the program will need and sets what are called compile-time parameters. You can often specify certain settings, such as to leave out parts of programs or to add optional elements by using the configure program. When configure runs, it creates a configuration file called makefile that Gcc, in conjunction with the make program, will tell the compiler how and in what order to build the code. Run the make command to compile the program: make program_name This takes the source code and creates a binary file compatible with your configuration. Depending on the program and the speed of your computer, this may take some time. Finally, run the following command: make install This command installs the binary so you can run it on your computer. This process may differ slightly from program to program. Some programs do not use a configure script and have a makefile all ready to go. Others may have slightly different syntax for the make commands. In most open source programs, there should be a file called INSTALL in the main directory. This is a text file that should contain detailed instructions for installing the program and any compile-time options you may want to set. Sometimes this information is contained in a file called README.

Here is the entire process using Nmap as an example.

Installing Nmap for Windows

Nmap for Windows is maintained by Jens Vogt. He has ported it to the Windows OS and has done an admirable job of keeping up with the UNIX releases, although it is a version behind as off this writing (version 3.0) and is considered to be in beta format (what open source project isn't?). It isn't quite as fast as the UNIX version but it has the same major features.

Scanning Networks with Nmap

When Nmap starts up, the graphical client presents a pretty straightforward interface (see Figure 4.2). There is a spot at the top to put your IP address or IP address range and you can click on Scan to start a scan.

Figure 4.2. Screen Shot of NMapWin

[View full size image]

Table 4.3 shows the different formats IP addresses can be entered in. They can also be pulled from a file by selecting the Input item under File on the main menu and selecting a text file with data in proper Nmap format (see Figure 4.2).

Table 4.3. IP Address Formats

Format	Example
Single IP address	192.168.0.1
IP addresses separated by commas	192.168.0.1,192.168.0.2
IP ranges separated by dashes	192.168.0.1-255
Using standard slash notation	192.168.0.1/24 (a class C network of 256 addresses)

Flamey the Tech Newbie Lesson: Understanding Netmasks and Slash Notation You will often see IP networks referred to with either a netmask or a slash and a number at the end of it. Both of these are ways of defining the size of the network. To understand them, you need to understand a little of how an IP address is structured. A standard IPv4 address is made up of 32 bits. It is usually represented in four sections, with four octets of 8 bits each. Each octet is usually converted from a set of 8 binary bits to a decimal number when written to make it easy to read. So when you see 192.168.1.1, the computer sees it as: 11000000 10101000 00000001 00000001 A netmask is usually a set of four numbers that tells you where the local network ends and the wide area network begins. It usually looks something like this: 255.255.255.0. A quick way to figure out the size of a network represented by a netmask is to subtract each octet from 256 and multiply those numbers together. For example, the netmask of 255.255.255.248 describes an 8 IP network because (256 – 255) * (256 – 255) * (256 – 255) * (256 – 248) = 8. A netmask of 255.255.255.0 describes a 256 IP network because (256 – 255) * (256 – 255) * (256 – 255) * (256 – 0) = 256. And finally, a netmask of 255.255.0.0 describes a network of 65,536 IP addresses because (256 – 255) * (256 – 255) * (256 – 0) * (256 – 0) = 65536. Slash notation is a little tougher to grasp but it uses the same concept. The number after the slash tells how many bits describe the wide area network. Subtract that number from 32 and that is number of bits that describe the local network. For example, the notation 192.168.0.0/24 describes a network starting at 192.168.0.0 that is 256 IP addresses big. (This is the same size as the one above with a netmask of 255.255.255.0.) The 32 bits in an IP address minus the 24 bits for the network prefix leaves 8 bits turned on (equal to 1) for the local network size. An 8-bit binary number of 11111111 converted into decimal is 256. If binary math gives you the fits, then just use this little cheat sheet to help you remember. Slash Notation Network Size /24 256 IP addresses /25 128 IP addresses /26 64 IP addresses /27 32 IP addresses /28 16 IP addresses /29 8 IP addresses /30 4 IP addresses /31 2 IP addresses /32 1 IP address

Nmap Command Line Operation

You can run Nmap from the command line either in UNIX or Windows. The general format is:

nmap parameters ip-range

with any additional settings replacing parameters. Throughout the rest of this chapter, any settings or options for the GUIs will have the equivalent command line settings in parentheses with the name of the option, for example, SYN (–sS) and Bounce Scan (–n FTP_HOST).

Nmap Scan Types

There are many different kinds of scans you can run with Nmap. Table 4.4 lists some of the ones you'll probably use most often. The command line parameters are also given if you want to use that interface.

Table 4.4. Nmap Scan Types and Command Line Parameters

Scan Types (Command Line Parameters)	Descriptions
SYN (-sS)	This is the default scan and is good for most purposes. It is quieter than a TCP Connect scan, that is, it won't show up on most simple logs. It works by sending a single TCP SYN packet to each possible port. If it gets a SYN ACK packet back, then Nmap knows there is a service running there. If it doesn't get a response, it assumes the port is closed. The SYN scan does not complete the TCP handshake by sending an ACK back to the machine; as far as the scanee is concerned, it never sees a valid connection. However, the remote system will hold this "half socket" open until it times out from not receiving a response. Some servers and IDS programs are smart enough to catch this now, but the SYN scan will be invisible to most machines.
TCP Connect (–sT)	This works much like the SYN scan, except it completes the full TCP handshake and makes a full connection. This scan is not only noisy but also puts more load on the machines being scanned and the network. However, if stealth or bandwidth is not an issue, a Connect scan is sometimes more accurate than the SYN scan. Also, if you don't have administrator or root privileges on the Nmap machine, you won't be able to run anything other than a Connect scan because the specially crafted packets for other scans require low-level OS access.
Ping Sweep (–sP)	This does a simple ping of all the addresses to see which ones are answering to ICMP. If you don't really care about what services are running and you just want to know which IP addresses are up, this is a lot faster than a full port scan. However, some machines may be configured not to respond to a ping (for example, machines running the new XP firewall) but still have services running on them, so a ping sweep is not as accurate as a full port scan.
UDP Scan (–sU)	This scan checks to see if there are any UDP ports listening. Since UDP does not respond with a positive acknowledgement like TCP and only responds to an incoming UDP packet when the port is closed, this type of scan can sometimes show false positives. However, it can also reveal Trojan horses running on high UDP ports and hidden RPC services. It may be quite slow, since some machines intentionally slow down responses to this kind of traffic to avoid being overwhelmed. Machines running Windows OS, however, do not implement this slowdown feature, so you should be able to use UDP to scan Windows hosts normally.
FIN Scan (–sF)	This is a stealthy scan, like the SYN scan, but sends a TCP FIN packet instead. Most but not all computers will send a RST packet back if they get this input, so the FIN scan can show false positives and negatives, but it may get under the radar of some IDS programs and other countermeasures.
NULL Scan (–sN)	Another very stealthy scan that sets all the TCP header flags to off or null. This is not normally a valid packet and some hosts will not know what to do with this. Windows operating systems are in this group, and scanning them with NULL scans will produce unreliable results. However, for non-Windows servers protected by a firewall, this can be a way to get through.
XMAS Scan (–sX)	Similar to the NULL scan except all the flags in the TCP header are set to on (hence the name—it lights up like a Christmas tree). Windows machines won't respond to this due to the way their TCP stack is implemented.
Bounce Scan (–n FTP_HOST)	This tricky scan uses a loophole in the FTP protocol to "bounce" the scan packets off an FTP server and onto an internal network that would normally not be accessible. If you have the IP address of an FTP server that is attached to the local LAN, you may be able to breach the firewall and scan internal machines. It's a good idea to test to see if your network is vulnerable to this exploit. Most current FTP servers have fixed this security hole. Note: You must input a valid FTP server that would have access to the network in addition to the IP addresses to be scanned.
RPC Scan (–sR)	This special type of scan looks for machines answering to RPC (Remote Procedure Call) services. RPC, which allows remote commands to be run on the machine under certain conditions, can be a dangerous service. Since RPC services can run on many different ports, it is hard to tell from a normal scan which ones might be running RPC. This scan will probe the ports found open on a machine with commands to show the program name and version if RPC is running. It's not a bad idea to run one of these scans every so often just to find out if and where you have these services running.
Windows Scan (–sW)	This scan relies on an anomaly in the responses to ACK packets in some operating systems to reveal ports that are supposed to be filtered. Operating systems that are known to be vulnerable to this kind of scan include some versions of AIX, Amiga, BeOS, BSDI, Cray, DG/UX, Digital UNIX, FreeBSD, HP/UX, IRIX, MacOS, NetBSD, OpenBSD, OpenStep, OpenVMS, OS/2, QNX, Rhapsody, SunOS 4.X, Tru64 UNIX, Ultrix, VAX, and VxWorks.
Idle Scan (–sI zombie_host: probe_port)	This type of scan is a new feature for Nmap version 3.0. It is a super-stealthy method whereby the scan packets are bounced off an external host. You don't need to have control over the other host but it does have to be up and meet certain requirements. You must input the IP address of your "zombie" host and what port number to use. While this scan is very hard to track back to the original scanner, it is probably not very useful to most administrators scanning their own networks. It is one of the more controversial options in Nmap since it really only has a use for malicious attacks.

Nmap Discovery Options

You can also adjust the way Nmap does its network discovery and determines which hosts are alive. Table 4.5 lists several different choices.

Table 4.5. Nmap Discovery Options

Options	Descriptions
TCP + ICMP (–PB)	This is the default setting. Nmap normally uses both ICMP and TCP packets to determine a host's status. This is the most reliable and accurate way since it usually gets a response from one of the two methods if something is there. However, it's also the noisiest way and is likely to end up being logged by some device on the scanned network.
TCP Ping (–PT)	This uses only the TCP method to find hosts. Many firewalls and some routers will drop ICMP packets and may also log them. If you are trying to be stealthy, this is your best option. However, with some of the more exotic scan types (FIN, XMAS, NULL) you may end up missing hosts.
ICMP Ping (–PE)	This uses only ICMP packets for network discovery. This is not a good choice if you are scanning from outside the network firewall because most of your packets will probably be dropped. However, inside a network it is fairly reliable, although you may miss your firewall and some network devices that don't respond to ICMP.
Don't Ping (–P0)	If you set with this option, Nmap will not attempt to learn which hosts are up first and will instead send its packets to every IP in the specified range, even if there isn't a machine behind them. This is wasteful both in terms of bandwidth and time, especially when scanning large ranges. However, this may be the only way to scan a well-protected network that doesn't respond to ICMP.

Nmap Timing Options

Nmap offers you the capability of speeding up or slowing down the frequency at which it sends out its scan packets. If you are worried about too much network traffic (or trying to be stealthy), you can crank the level down. Just keep in mind that the longer you spread them out, the longer your scan will take. This can increase scan times exponentially on large networks. On the other hand, if you are in a hurry and don't mind some extra network traffic, you can turn it up. You can see the different levels and packet frequencies in Table 4.6. You can also set a custom frequency on the Windows version or using the command line options.

Table 4.6. Nmap Frequency Settings

Frequency Level	Command Line Parameter	Packet Frequency	Comments
Paranoid	-F 0	Once every 5 minutes	Don't use this option on scans of more than a few hosts or your scan will never finish.
Sneaky	-F 1	Once every 15 seconds
Polite	-F 2	Once every 4 seconds
Normal	-F 3	As fast as the OS can handle	Default setting
Aggressive	-F 4	Same as Normal but the packet timeout is shortened to 5 minutes per host and 1.25 seconds per probe packet
Insane	-F 5	.75 second timeout per host and .3 seconds per probe packet	This method won't work well unless you are on a very fast network and using a very fast Nmap server. Even then, you may still lose data.

Other Nmap Options

Table 4.7 lists a number of other miscellaneous options for Nmap that control things like DNS resolution, OS identification, and other features that don't fit into one of the other categories.

Table 4.7. Miscellaneous Nmap Options

Options	Descriptions
Don't Resolve (–n)	Normally, Nmap tries to resolve DNS names for any IP it scans. This can cause the scan to take a lot longer, so if you are not worried about knowing the host names you can turn this off. Keep in mind, however, that host names are useful to know, especially when scanning on a DHCP network where IP addresses can change.
Fast Scan (–F)	This option only tries to scan ports in the Nmap common ports files. By default, these are commonly known server ports under 1,024. You can edit this file and add ports to the list. It can make for a much faster scan but it won't find Trojan horses or services running on higher ports.
Port Range (–p port_range)	By default, Nmap scans all 65,535 possible TCP ports. However, if you just want it to scan a certain range, you can set this by using this switch and replacing port_range with the range you want to look for. You could use this to scan for just a single type of server, such as port 80 for Web servers, or you might just want to scan the upper ranges to look for odd services and potential Trojan horses.
Use Decoy (–D decoy_address1,decoy_address2...)	This option makes it look like the host(s) you enter are decoys scanning the machine as well. The scanned machine will see traffic from several sources and it will be hard to tell which one is the real scanning host. This is another extreme stealth option and not necessary for most legitimate uses. It also puts a lot more traffic on the network and can submit your decoy hosts to being blocked from accessing the scanned machine. This could bring you ire from the people whose hosts you are using as decoys.
Fragmentation (–f)	This option fragments the scan packets as they go out. This is a stealth feature that can be used to avoid having your scan detected. They will be assembled on the other end by the machine receiving them, but the fragmented packets might fool intrusion detection systems and firewalls, which often look to match a specific pattern signature.
Get Identd Info (–I)	The Identd service runs on some machines and provides additional information on that host when queried. It can provide data beyond what the port scan provides, such as operating system type. However, it usually only runs on UNIX systems. Nmap will also automatically do an OS identification using TCP fingerprints as well, so this feature is less useful than it used to be. If you don't have UNIX systems on your network, it is not worth running with this option.
Resolve All (–R)	This option tries to resolve every address in the range, even when they are not answering. This can be useful, for example, in an ISP network, where a whole range of host entries may be assigned to potential IP addresses for a dial-up pool, but only a certain number may be used at a given time.
OS Identification (–O)	This option is set by default. As mentioned earlier, every TCP stack is slightly different. By comparing the exact "fingerprint" of the replies to a database of known TCP fingerprints, Nmap can usually identify the OS it is talking to with a fair amount of accuracy. It can even narrow it down to version ranges. Occasionally, something will come up that it doesn't know, and then it prints out the TCP response at the bottom of the report. If you find one of these unidentified signatures, you can help build the OS fingerprint database when you get an unidentified TCP signature. If you know what it is for sure, cut and paste it into an e-mail to the Nmap development group. They will add it to the database so when someone else scans that type of machine, it will be properly identified. You can find all the TCP fingerprints Nmap knows in the file nmap-os-fingerprints in the Data directory of the Nmap installation.
Send on Device (–e interface_name)	This forces the scan packets to go out a specific interface. This is really needed only on a machine with multiple network cards or if Nmap doesn't recognize your network interface automatically.

There are more options for fine-tuning your scans available using the command line interface. Read the Nmap man pages for more details.

Running Nmap as a Service

By default, Nmap is run as a service in the Windows version. This means that it is running in the background all the time and can be called by other programs or run by a script or cron job. In Windows, the Nmap service is manageable and configurable under the Services Tool. To do this, from the Control Panel menu select Administrative Tools, and then Services. You will see Nmap listed as a service; you can click on it and configure its properties.

This option is useful if you want to have Nmap run scans on a regular basis. You can set Nmap to scan your network once a week or once a month and report the results to you. Or you might just have it scan your servers to see if anything substantive has changed. If you are not going to be using this feature, I suggest you disable the service in Windows to conserve resources and for better security. You can do this by clicking on the Nmap service in the service viewer and changing the Start-up Type to Manual rather than Automatic. This change will take place the next time you reboot the machine. You can also manually stop the service by clicking on the Stop button.

Flamey the Tech Tip: Friendly Nmap Scanning As mentioned earlier, Nmap can cause problems on networks if used incorrectly or indiscriminately. Here are a few tips to keep your Nmap scanning safe. Select where you scan from carefully. Scanning from inside a network will generate a lot more information than scanning outside the firewall. Doing both and comparing the results is often useful, but it is less vital if a server shows an open port inside your network than if it shows one open from outside the firewall. You may want to run your scans early in the morning or late at night. That way, you minimize the chances of slowing down vital servers or user machines. If you are worried about overwhelming your network, put an older 10Mbps network card in your scanning machine or connect it via a 10Mps hub. That way the maximum traffic it can put on the wire is 10Mbps, which is unlikely to overwhelm a 100Mbps network.

Output from Nmap

Nmap produces a report that shows each IP address found, the ports that were discovered listening on that IP, and the well-known name of the service (if it has one). It also shows whether that port was open, filtered, or closed. However, just because Nmap gets an answer back on port 80 and prints "http," this does not mean that a Web server is running on that box, although it's a good bet. You can always verify any suspicious open ports by telneting to that IP address on the port number specified and seeing what response you get. If there is a Web server running there, you can usually get it to respond by entering the command GET / HTTP. This should return the default index home page as raw HTML (not as a pretty Web page), but you will be able to verify that a server is running there. You can do similar things with other services such as FTP or SMTP. In the UNIX version, Nmap also color codes the ports found according to what they are (see Table 4.8)

Table 4.8. Nmap Output Color Coding

Colors	Descriptions
Red	This port number is assigned to a service that offers some form of direct logon to the machine, such as Telnet or FTP. These services are often the most attractive to hackers.
Blue	This port number represents mail service such as SMTP or POP. These services are also often the subject of hackers' attacks.
Bold black	These are services that can provide some information about the machine or operating system such as finger, echo, and so on.
Plain black	Any other services or ports identified.

As you can see from Figure 4.3, this output lets you scan a report and quickly determine whether there are any services or ports you should be concerned with. This doesn't mean you should ignore any unusual numbers that aren't highlighted or bolded (in UNIX versions). Trojan horses and chat software often show up as unknown services, but you can look up a mystery port in the list of common ports in Appendix C or cross-reference it against a list of known bad ports to quickly determine if the open port is anything to be concerned about. If you can't find it anywhere, you have to wonder what strange service is running on that machine that doesn't use a well-known port number.

Figure 4.3. Nmap Output

[View full size image]

You can save Nmap logs as a number of formats, including plain text or machine-readable, and import them into another program. However, if these options aren't enough for you, Nlog, the next tool discussed, can help you make sense of your Nmap output. Running it on very large networks may be a lifesaver, because poring over hundreds of pages of Nmap output looking for bad guys can quickly drive you blind, crazy, or both.

Nlog: A Tool for Sorting and Organizing Nmap Output

The Nlog program helps you organize and analyze your Nmap output. It presents them in a customizable Web interface using CGI scripts. Nlog makes it easy to sort your Nmap data in a single searchable database. On larger networks, this kind of capability is vital to making Nmap useful. Austinite H. D. Moore put together these programs and made them available, along with other interesting projects, at his Web site www.secureaustin.com.

Nlog is also extensible; you can add other scripts to provide more information and run additional tests on the open ports it finds. The author provides several of these add-ons and instructions on how to create your own. Nlog requires Perl and works on log files generated by Nmap 2.0 and higher.

Installing Nlog

Follow these steps to install and prepare Nlog.

Using Nlog

This section describes how to use Nlog.

Nlog Add-ons

As mentioned earlier, Nlog is easily extensible and you can write add-ons to do other tests or functions on any protocols or ports found. In fact, there are several included with the program. If there is an add-on available, there will be a hypertext line next to the port and you can click on it to run the subprogram. Table 4.9 lists the built-in extensions.

Table 4.9. Nlog Built-in Extensions

Extensions	Descriptions
Nlog-rpc.pl	This add-on takes any RPC services that are found and attempts to find out if there are any current RPC attachments and exports for that service.
Nlog-smb.pl	For any nodes running NetBIOS (which most Windows machines will be), this script tries to retrieve shares, user lists, and any other domain information it can get. It uses the user name and login specified in the nlog-config.ph file.
Nlog-dns.pl	This script runs a standard nslookup command on the IP address. (See Chapter 2 for more information on nslookup.)
Nlog-finger.pl	This runs a query against any finger service found running to see what information is sent.

Creating Your Own Nlog Extensions

If you examine these add-on scripts, you will see that they are just basic Perl programs. If you are experienced with Perl, you can write your own extensions to execute just about any function against your scanned hosts. For example, you can retrieve and display the HTTP header for any Web servers found so you can more easily identify it. You don't need to go overboard with this, because programs like Nessus (discussed in Chapter 5) can do much more comprehensive testing, but if you just need a banner or some small bit of information, then using Nlog is a good solution.

Nlog comes with a sample custom add-on called nlog-bind.pl. This script is designed to poll a DNS server and tell you what version of BIND (the Berkley Internet Naming Daemon DNS service) it is running. However, this script is not finished; it is provided as an exercise to create your own add-ons. The sample script is in /nlog*/extras/bind/. The following procedure guides you through finishing the script. You can use that format to create any custom script of your own.

Now when your Nmap scans find port 53 open (which is generally a DNS server), you can click on the link that Nlog creates and find out what version of BIND it is running. You can write additional scripts to extend Nlog by following the logic in this example.

Interesting Uses for Nlog and Nmap

So now you can port scan with Nmap and sort and analyze the results with Nlog. So what do you do with these new toys? Well, there are some interesting applications for port scanners. Here are some real examples for you to try on your network (or someone else's, with their permission, of course!). You may be surprised at what you find.

Scan for the Least Common Services

If you have a service or port number that is only showing up on one or two machines, chances are that it is not something that is standard for your network. It could be a Trojan horse or a banned service (for example, Kazaa, ICQ, or MSN). It could also be a misconfigured machine running an FTP server or other type of public server. You can set Nlog to show the number of occurrences of each and sort them by the least often occurring. This will generate a list for you to check out. You probably won't want to include your companies' servers in this scan as they will have lots of one of kind services running. However, it wouldn't hurt to scan these servers separately either to fine-tune or eliminate extraneous services.

Hunt for Illicit/Unknown Web Servers

Chances are that if you run one or more Web servers for your company, you will see the HTTP service showing up a few times on your network. However, it is also likely that you will see it on machines where you don't expect it. Some manufacturers of desktop computers are now loading small Web servers by default on their systems for use by their technical support personnel. Unfortunately, these Web servers are often barebones programs with security holes in them. You will also find Web servers running on printers, routers, firewalls, and even switches and other dedicated hardware. You may need these servers to configure the hardware, but if you aren't using these servers, you should shut them off. These mini-servers are often configured with no password protection by default and can offer a hacker a foothold onto that machine. They can also offer access to the files on the machines if an intruder knows how to manipulate them. Scan for these hidden Web servers, and either turn them off or properly protect them. You should also search for ports other than 80 that are commonly used for HTTP. Table 4.10 has a short list of port numbers for Web service.

Table 4.10. Common Alternate Web Server Ports

Common Port Number	Protocol
81	Alternate Web
88	Web
443	Https, Secure Web
8,000–8,002	Web
8,080	Web
8,888	Web

Scan for Servers Running on Desktops

Going a step further with the last exercise, restrict the IP range to only those that are nonserver machines and set a port range from 1 to 1,024. This will find desktop machines running services that are normally done by servers, such as mail, Web, and FTP. Unless there is a good reason for this (for example, PCAnywhere), your desktop machines should not be running these types of services.

Hunt for Trojan Horses

To hunt for Trojan horses on your network, run a scan of your network and translate it into the Nlog database format. Open the Nlog search page, select the ports, and set the range from 30,000 to 65,400. This is the favored range for Trojan horses because it is out of the range of normal services and so they usually will go unnoticed—that is, unless you are port scanning your network. However, just because there are some services running on high-level ports doesn't always mean you have Trojan horses, but it is worth paying attention to services running on these high port numbers. Once you've narrowed it down to the machine and port numbers, you can rule them out by checking the services running on those machines or by telneting to those port numbers and seeing if you get a service banner.

Check Your External Network Exposure

Put your Nmap box outside your network, either on a dial-up or home broadband connection, and try scanning your company's public IP addresses. By doing this you will see what services are accessible from the Internet (and thereby to any port scanner–wielding person). This is the most vulnerable part of your network, and you should take extra care to secure any services that are public-facing by using a vulnerability scanner, such as the one described in the next chapter. It will also show if your firewall is properly filtering ports that it is forwarding to internal LAN addresses.

So you've seen all the cool things you can do with a port scanner like Nmap. These programs are useful for finding out what you have running and where your exposures might be. But how do you know if those exposed points might be vulnerable? Or if services that are supposed to be open are safe and secure? That goes beyond the function of a port scanner and into the realm of a vulnerability scanner, which is discussed next.