Publicly Available Security Tools

Arthur Donkers

This month, I will look at a number of publicly available security tools (under the Open Source or GPL license). You can use these tools when you want to check the security of your network; any other use is at your own risk.

The Internet contains a lot of free security tools that can assist you in assessing the security of your network. In addition to these free tools, a lot of commercial tools are available, but I will focus solely on Open Source tools.

Available Tools

I will take a look at the following tools:

nmap (http://www.insecure.org/nmap) - This is a very versatile port scanner that allows you to scan one or more machines for available services. Newer versions of nmap are capable of determining the type of remote machine as well.

Nessus (http://www.nessus.org) - This is a complete auditing tool that tests for a lot of vulnerabilities. The list of vulnerabilities is updated very regularly.

SATAN (various sites) - This is also an audit tool. The SATAN tool has also spawned another tool, called SAINT (http://www.wwdsi.com) with more tests.

All of these tools are for the UNIX platform; there are also freely available NT tools, but those are not included here.

Building the Tools

In all cases, it is very easy to build these tools on a UNIX platform (provided you have a C compiler, preferably a GNU C compiler). You should simply follow the instructions in the accompanying documentation. In most cases, you will have to run a configuration program to determine your hardware and system settings. According to these settings, the program will build one or more makefiles. After configuring the tools, you can build them by using make. Finally, after using make, you can install this software.

Whenever you are using software downloaded from the Internet, you should always be very careful when installing it, especially if you have to install it as root. You should check the software and install scripts for hidden features that may cause problems or unwanted side effects. Only recently, a number of alerts were published on a version of TCPwrappers that was infected with a Trojan horse. So be careful.

Using nmap

As stated before, nmap is a port scanner. It will try to establish a list of active services on a machine. A potential attacker will then (ab)use one or more of these services to gain unauthorized access to that system. Scanning for these services can be done in a number of different ways.

UDP Services

First of all, you can scan for UDP-based services. UDP is a connectionless protocol, so it is very difficult to remotely scan for UDP services. If a UDP service is not active, the target machine may reply with an ICMP unreachable message, indicating that there is no service listening on that port. Whenever you do not receive an unreachable message, it might mean that a UDP service is active on that port. Sometimes a systems manager has configured the system to never return an ICMP unreachable message (i.e., silently drop unacceptable traffic).

So, when you are connected to the same LAN as your target machine, scanning for UDP ports might yield unreliable results. However, when you try to scan for UDP ports over the Internet, the results may be even more unreliable, as intermediate systems (especially firewalls) will probably silently drop ICMP traffic.

TCP Services

The TCP protocol uses a three-way handshake to establish a session. After this session is established, data can be exchanged. To scan for TCP services, you should try to establish a session with each of the ports you are scanning. When you are able to complete the three-way handshake, a service is active on that port. This is the so-called regular scanning.

Most systems on the Internet, however, are connected via a firewall and/or router. This firewall or router will block most session requests from the Internet in order to prevent various attacks and related problems. Session requests are only accepted from a predefined set of IP addresses. "Luckily" for us, there are other ways of scanning a target besides conforming to the three-way handshake protocol. You can start with a ACK packet and observe the way the target systems responds (stealth scanning). You can also use the FIN option of a packet and observe the response (FIN scanning). Depending on the implementation of TCP/IP on the target, a system will react differently if a service is active on a port.

When performing a scan, nmap will by default try to ping a target machine. If it cannot ping the machine, it will not continue the scan. You can, however, disable this ping behavior so that nmap will scan a machine even when it does not react to ping. By enabling the verbose option (once, or even better, twice), you can watch nmap doing the scan and see the intermediate results. After completing the scan, nmap can write the results to a "resultsfile". This file may be used by another program or read by a user. You can save this "resultsfile" in a format easily read by a human, or easily parsed by a program.

Finally, nmap is capable, more often than not, to determine the kind of hardware and software of the target machine. It does this by sending probes to the machine and carefully examine the responses. A probe is a network packet with a certain combination of flags. Apparently different systems react differently to these probes.

Using Nessus

Nessus is a complete, graphical, auditing tool. The current WIP (work in progress) version contains tests for more than 180 vulnerabilities. These vulnerabilities are written as separate modules that are loaded when starting Nessus.

Nessus uses a client-server architecture. The actual probes and tests are executed by a daemon that runs in the background (which you connect with a client program). Using this client program, you can configure the tests and view the report that is generated after completing the test. Clients are available for a number of platforms and you can run the client on a different machine from the scan daemon.

As mentioned previously, the tests that Nessus will perform are stored in separate modules. Each of these modules fits into the Nessus framework. Since you have the source available, you have enough sample code available to write your own modules. So, if you have found a new exploit or security leak, you can wait for someone to write a module, or you can write your own.

Currently Nessus comes equipped with 180 different tests. Among these are tests for vulnerabilities in Web servers, NFS, NIS, Sendmail, telnet, and other well-known services. It also contains modules for performing different denial of service attacks. Altogether, Nessus contains at least the same set of tests that the commercial versions of these tools support. The advantage of Nessus lies in its expandability - you can write your own modules.

Although testing for vulnerabilities is important, the way the program reports these vulnerabilities is important as well. In my opinion, this is where a lot of work needs to be done on Nessus. The reporting possibilities are very terse. Nessus generates a tree-based list of the vulnerabilities it has detected. And, as network and system managers probably know from their own experience, upper management needs a report with pictures, pie charts, and other goodies to make it more acceptable.

Using SATAN and SAINT

SATAN is a familiar player in this field. It was one of the first publicly available security tools. It has an open structure and can be extended with new tests. This is what SAINT has done. It has taken the structure of SATAN, polished it, and added a number of tests. Although you can download the source for SAINT and build it on your own system, it does not use the GPL licensing structure - it has its own. Please read these licensing rules carefully before using SAINT.

SAINT, and therefore SATAN, also uses a client-server structure. The user interface is build around a Web-based structure. When you start the program, it automatically starts Netscape or Mosaic. Via this Web interface, you can configure which tests should be executed. You can start the tests from this Web interface, and the results are also presented via the Web interface. As a result of this structure, the Web interface needs to run on the same machine as the scan program.

The set of tests performed by SAINT is far bigger than the set of SATAN's tests. Furthermore, new tests have been added, such as the Netbus and Back Orifice tests.

Conclusion

Tools such as these and other publicly available (or Open Source) software, can be used very well in security-related audits. Open Source software frequently has the same testing options as commercial products, but also provide you with the ability to extend them because you have the source.

About the Author

Arthur Donkers graduated from the Delft University of Technology with a degree in Electrical Engineering and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands. His primary field of interest is in datacommunications, especially the security aspects involved. He now is the founder and owner of Le Reseau, a company specializing in security-related issues for UNIX, OpenVMS and Windows NT, and the application of Linux in corporate environments.