Vulnerability Testing Against a Predominately UNIX-based Network (DRAFT)
Jeffrey S. Marker, CISSP
Network vulnerability testing seems to be a self-describing term. When we perform this type of testing, we are interested in where and how hosts may be attacked via the network. We are concerned about potential vulnerabilities, not with exploiting these vulnerabilities. Exploiting vulnerabilities to demonstrate their danger is the providance of penetration testing, where the goal is to demonstrate how a networked host can be compromised.
We are limiting our discussion to ``predominately UNIX'' networks because we wish to address TCP/IP testing. We do not want to discuss NetBIOS or other non-TCP/IP protocols. The general methodology described herein should be applicable to non-TCP/IP protocols, although the tools may be different.
Network vulnerability testing is valuable for a number of reasons. The initial tests will help the systems, network, and security administrators develop a picture of what is present on the network. Subsequent tests can help map changes to the network. Regular testing can help discourage the running of unauthorized services. Vulnerability testing also helps demonstrate the effectiveness of current security measures, and the reports from the tests can be used to help evaluate, and make a case for, enhanced security measures. And, finally, there is always the remote chance that one might detect compromised hosts on the tested network1
Vulnerability testing should not be performed to
2 Preparing for the testing
To perform the vulnerability testing, we need to have at least one network connection. This can be either ``internal'' - inside the security perimeter - or ``external.'' Ideally, we would be able to have both an internal and an external connection, so we can compare the views of an external and internal threat.
External network connection
Simply put, the purpose of the external network connection is to allow us to see what an ``outsider'' will see during an attack. This connection should be outside of whatever perimeter security is in place for the network to be tested. Also, all automatic trust relationships between the testing platform and the hosts to be tested should be severed for the duration of the testing. This means that SSH keys, .rhosts, /etc/hosts, .netrc files and the like need to be checked to make certain that they are not allowing the testing platform access that other hosts or users can not be expected to have. Failure to sever these trust relationships may ultimately result in false-positive reports, which will make it appear that the network being tested is less secure than it actually is.
Because remote network vulnerability testing can be rather network intensive, it is best if the external network connection has a lot of bandwidth. This can be accomplished via the sundry commercial broadband solutions2, by locating the testing platform at the site of a business partner, or by locating the testing platform at a remote site.
Internal network connection
The internal network connection is used for the internal testing. This allows us to see what ``insiders'' see, and to be able to make some value judgements regarding the effectiveness of the perimeter security. This connection should be inside the security perimeter of the network we are testing. Unlike the external testing, we do not need to sever our trust relationships, because it can be assumed that trust exists with other hosts - and other users - on the network.
The tools we will use to perform our testing are all UNIX based. Consequently, the testing platform will need to be able to run a version of UNIX as its operating system.
nmap is primarily a port scanner, rather than a vulnerability tester per se. We will use this tool in both the external and internal testing to determin which TCP and UDP services are listening on the tested hosts. We will also make use of nmap's operating system detection feature to make guesses at what operating systems are being run on the tested network. Finally, we will use some of nmap's scanning variations in the external testing to map out the perimeter security.
nmap can be obtained from http://www.insecure.org/nmap/.
SATAN is the grand old man of network vulnerability testers, being released in 1995. Because of its age, it is often called obsolete. However, SATAN uses it's own method for probing services, which gives us another view of the network. Additionally, it was written with modularity in mind, so enhancing SATAN with localized tests is well-documented3 and relatively straight-forward.
SATAN can be obtained from http://www.porcupine.org/satan/.
SARA is a third-generation decendant of SATAN, with all of the advancements one might expect to find. It has hooks for using nmap for service scanning, an up-to-date vulnerability database, and a well-developed report writing feature.
SARA can be obtained from http://www-arc.com/sara/.
NessusNessus is another modern vulnerability scanner. Unlike the SATAN family, it uses it's own console for configuration and reporting4, and is client-server based. Also, Nessus makes it easy to select precisely which tests to run, whereas the SATAN family selects its tests based upon a ``scanning level.''
Nessus can be obtained from http://www.nessus.org/.
Whisker tests http servers for vulnerabilities. It will, therefore, only be used if hosts on the network are found to be running http servers.5
Whisker can be obtained from http://sourceforge.net/projects/whisker/.
Make a directory for the results of the tests. For the examples herein, we'll call that example.com_vuln_test. Under that directory, we will make external and internal, so as to be able to better organize the different tests.
When we perform the tests, there are two items we need to protect: ourselves and the data the testing generates. We need to protect ourselves from ``real world'' ramifications, such as letters of reprimand, demotion, firing, and/or legal action. We need to protect both the confidentiality and the integrity of the data.
We protect ourselves by obtaining approval to perform the testing before we begin. In some organizations, this includes obtaining permission to possess the above mentioned tools6. Regardless of the organization, however, pre-approval from the network owner must be obtained. This means getting approval from management, not the network administrators. We want to get the approval from as far up the food chain as is possible.
We protect the data via file permissions, encryption, and labeling. Our file permissions should be as restrictive as is possible, allowing only the owner access7. We should also encrypt the data while it is stored8. Additionally, if the final report is to be transferred electronicly, it should be done so in an encrypted form9. Finally, the report should be properly labeled10. This helps prevent accidental disclosure via honest mistake, as well as encouraging the authorized recipients to be more protective of the document.
One important rule is to not launch denial of service attacks against production networks during ``normal'' production hours11.
3.1 External testing
If perimeter security is in force on the network to be tested, it is possible that we are able to know what security policies are being enforced on the perimeter. This ``insider'' knowledge will modify the nmap portion of the test, as we can avoid a comprehensive port scan, and, instead, scan only those services which are allowed to pass through the perimeter.
Open service detection with nmap
We begin the testing with nmap, because that will give us a picture of open services. First, we will will probe all TCP ports, via
% nmap -sT -p 1-65535 -P0 -n -oA tcp_services -v \
This will take quite some time to run, especially if the perimeter security utilizes rule that drop, rather than reject, unwanted packets. When it finishes, however, we will have three files called tcp_services.gnmap, tcp_services.nmap, and tcp_services.xml in the example.com_vuln_test/external directory.
Next, we will probe all UDP ports, via
% nmap -sU -p 1-65535 -P0 -n -oA udp_services -v \
As is the case with the TCP probe, this test will take quite a while to run. When is is finished, we will have files called udp_services.gnmap, udp_services.nmap, and udp_services.xml in the example.com_vuln_test/external directory.
Statistics, Research, and Test Creation
The next step is to create a frequency list of open services. This can be accomplished by using the Perl-script service_freq.pl (Figure 2) in the following fashion12:
% service_freq.pl tcp_services.xml | sort -rn +1
This will provide a list of TCP services, sorted in reverse numerical order by the number of times they appear on the network. A sample of such a list can be found in figure 1 on page . Running
% service_freq.pl udp_services.xml | sort -rn +1
will produce a similar list of UDP services.
We examine the frequency lists for services we know should be running - such as tcp-2213 and tcp-8014 in the sample15 - and for services we know should not be running - such as tcp-666716 in the sample. In the process, we will probably find services that are listed neither in /etc/services or in the tcp_services.nmap or udp_services.nmap files. These should be researched17, as should any named services that are unfamiliar or unexpected.
The vulnerability testing programs we are using will likely have tests for most, if not all, of the services nmap shows us. It is important to remember, however, that information security is a moving target. The tools we use can only find vulnerabilities for which they have tests, and vulnerabilites, as well as their corresponding exploits, are ever changing. Thus, it is possible, if not likely, that some services nmap tells us are running will not have tests included in the standard package. Consequently, we may need to search the Internet for tests, or we may have to write our own18.
Once we have tests to check for vulnerabilities on all of the services reported running, we're ready to begin the vulnerability testing proper.
3.2 Being trickyIf we are not privy to the perimeter security rules, we can make use of nmap's built-in tricks to test whether the perimeter security is a smoke-screen.
3.3 Internal testing
4.1 False positivesMany of the tools only check banners - they don't actually test the vulnerability. Because many network daemons allow the administrator to use arbitrary headers, it may be necessary to verify the results of such tools by hand, either exhaustively or by examining a random sample.
4.2 False negativesThe tools we use are only as knowledgeable as their vulnerability databases are up-to-date. Fortunately, most of these tools allow direct review of all of the responses to their tests, without the filter of the front-end.
4.3 Comparison between external and internal tests
4.4 Danger signs