Vulnerability Assessments

After you have configured your system and believe it is ready for prime time, you need to test it. There are two main categories of tests that should be performed.

The first is a measurement of the target profile your machine presents. This means probing your server for each and every port it presents to the world. In the examples here, we use the nmap tool available from www.insecure.org.

The second group of tests involves verifying your server for published vulnerabilities in the services it offers. A number of tools are available to perform this task. In this chapter, we concentrate on the Nessus tool (www.nessus.org).

Both of these tools are present on your SLES distribution media. You should verify that the versions you have installed are up to date. Scanning for vulnerabilities with an outdated tool will leave you with a false sense of security. Verify with the websites shown here that you have the latest software versions and vulnerability signatures.

Both series of tests should be run with your firewall up as well as with your firewall down. While it is comforting to think that the local firewall software will never fail, it never hurts to be cautious. Only by fully testing listener applications will you have a sense of your exposure. If anything, always lean to the side of the paranoid when testing systems.

TESTING VERSUS HACKING!

The tools presented here are excellent professional-grade applications. They can be used to probe your network for weaknesses and vulnerabilities.

Most companies have an explicit policy against running such tools on their production network. Even if such a policy is not written down, any type of vulnerability scanning is considered an attack.

To use these tools, you must receive written permission to conduct your tests. It is also critical that the person giving you permission to run the scans is a recognized agent of the company with the authority to grant such permissions. Also, ensure that strict timelines associated with the scanning event are adhered to.

nmap

The nmap tool is a network mapping tool. Designed to scan full networks, nmap can return a list of all the ports available on individual machines. It can also be used to probe a single machine for network-accessible ports. Though it can be used in stealth mode, the testing presented here does not have to traverse firewalls, and we are not concerned about having this scan activity logged. The nmap options used in this section are shown in Table 12.1.

Table 12.1. nmap Command-Line Switches

OPTION	MEANING
-sS	Specifies SYN scan. This option establishes half of the standard handshake used by TCP/IP for establishing a connection. It is a little stealthier and does not produce as many log entries.
-sT	Turns on TCP connect() scan. This option creates a full connection to the report port. Each connection shows up in the appropriate application log if it is reachable.
-sV	Turns on version detection. This option triggers additional probes that will be used to get version information on the individual applications hosting open ports.
-P0	Turns off the pinging of hosts for the scan. Because ICMP is often filtered by firewalls, it is not a valid measure for establishing whether a host is present at the specified IP address.
-O	Turns on operating system fingerprinting. Because of the various idiosyncrasies of the various TCP/IP stacks, it is often possible to guess the version of the operating system on the target.
-v	Turns on Verbose mode.
-oN <logfile>	Logs the nmap output to logfile in text format.
-oX <logfile>	Produces an XML logfile.
-p <port ranges>	Specifies a comma-separated list of ports to be scanned. Hyphens can be used to identify a range of ports (for example, Oracle Listeners: 1521-1526).
-F	Specifies Fast mode. This option only scans ports that nmap knows about.

The following two examples represent nmap scans of the same server. In the first instance, the firewall is down, and you can see a number of services accepting connections:

 Athena:~ # nmap -O -n -sT 192.168.1.243 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-03-01 08:31 EST Interesting ports on 192.168.1.243: (The 1654 ports scanned but not shown below are in state: closed) PORT     STATE SERVICE 22/tcp   open  ssh 111/tcp  open  rpcbind 427/tcp  open  svrloc 5801/tcp open  vnc-http-1 5901/tcp open  vnc-1 Device type: general purpose Running: Linux 2.4.X|2.5.X OS details: Linux Kernel 2.4.0 - 2.5.20, Linux Kernel 2.4.18 - 2.5.70 (X86) Nmap run completed -- 1 IP address (1 host up) scanned in 5.644 seconds Athena:~ # 

In this second instance, we have brought up the firewall. As you can see, all but the ssh port have been removed from access as expected. Port 113 is accessible but left closed because it is used by some mail services for authentication:

 Athena:~ # nmap -O -n -sT 192.168.1.243 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-03-01 08:40 EST Interesting ports on 192.168.1.243: (The 1657 ports scanned but not shown below are in state: filtered) PORT    STATE  SERVICE 22/tcp  open   ssh 113/tcp closed auth Device type: general purpose Running: Linux 2.4.X|2.5.X|2.6.X OS details: Linux Kernel 2.4.18 - 2.5.70 (X86), Linux 2.4.20 Uptime 0.003 days (since Tue Mar  1 08:37:54 2005) Nmap run completed -- 1 IP address (1 host up) scanned in 77.250 seconds Athena:~ # 

What is missing from the second example are ports 5801 and 5901. Referring back to the no-firewall example, you can see that these ports have been enabled to allow remote VNC connections to the server. If this service is not required, the appropriate applications should be disabled. If, however, you want to allow for VNC connections to the server, you could open the ports on the firewall. A more secure option would be to tunnel VNC over ssh as discussed in Chapter 8, "Network Services." Such tunneling would require the listeners on the local machine for local connections only.

In both examples, nmap was able to guess that the operating system was a Linux variant. With the reduced number of ports available in the second example, nmap took a lot longer to forge a guess of the remote operating system.

This section shows that it is possible to probe a significant amount of information from a system using nmap. By testing the server with the firewall down, you can inventory the ports offered by the server and ensure that the firewall is tuned appropriately. Keep in mind that the nmap tool is also available to others.

Nessus

The Nessus tool is an open source vulnerability scanner that is composed of both server and client components. This permits a single client workstation to perform testing using several different servers. All the actual communications to the target machine are driven from the server.

The Nessus tool can be used to probe a target machine for services exposed to the network. For each of the ports it finds, it performs a number of tests. Each test is designed to attempt to discover the purpose of the open port and what protocols are supported. The tests also allow for the detection of the application version hosting the port.

Scan results are cross-referenced against a list of known application version vulnerabilities. When this is done, Nessus reports its findings in a number of different formats.

When you are installing SLES, it is possible to include Nessus as one of the components. Before you can use it, however, you must perform a couple of setup steps.

Because the purpose of the Nessus tool is to report back on machine vulnerabilities, the information passed between the server and the client is considered sensitive and should be protected from interception. For this purpose, Nessus encrypts client/server communications. The nessus-mkcert command is used to generate the appropriate certificates. When it is invoked, you are asked the following questions:

• CA certificate lifetime in days

• Server certificate lifetime in days

• Your country (two-letter code)

• Your state or province name

• Your location (for example, city or town)

• Your organization

Nessus then creates the appropriate files in /var/lib/nessus/CA. After this is done, you are ready to grant end-user access to the application.

The following shows nessus-mkcert in action:

               Creation of the Nessus SSL Certificate This script will now ask you the relevant information to create the SSL certificate of Nessus. Note that this information will *NOT* be sent to anybody (everything stays local), but anyone with the ability to connect to your Nessus daemon will be able to retrieve this information. CA certificate life time in days [1460]: Server certificate life time in days [365]: Your country (two letter code) [FR]: CA Your state or province name [none]: Ontario Your location (e.g. town) [Paris]: Peterborough Your organization [Nessus Users United]: UniversalExport.ca ---------------------------------------------------------------------               Creation of the Nessus SSL Certificate --------------------------------------------------------------------- Congratulations. Your server certificate was properly created. /usr/local/etc/nessus/nessusd.conf updated The following files were created : . Certification authority :    Certificate = /usr/local/com/nessus/CA/cacert.pem    Private key = /usr/local/var/nessus/CA/cakey.pem . Nessus Server :     Certificate = /usr/local/com/nessus/CA/servercert.pem     Private key = /usr/local/var/nessus/CA/serverkey.pem Press [ENTER] to exit 

Before Nessus can be used, individual accounts called "logins" must be created within it. Using these accounts, users will be able to probe machines for vulnerabilities. Because of the nature of these probes, some being potentially fatal to some services, great care should be exercised when selecting targets and granting access to Nessus.

To grant access to Nessus, you use nessus-adduser. When it is executed, you are prompted for

• Login

• Authentication (password/certificate)

• password

• User rules

The login prompt requests the username to be used to establish new client sessions. Authentication can be done by password or certificate. You have to select the appropriate choice for your environment. When you are selecting a login password, ensure that it is sufficiently complex. The user rules section can restrict individuals to specific IP ranges. In most cases, the few individuals allowed to run these scans are granted access to the whole of Nessus.

The following is a transcript of a nessus-adduser session. In this example, the user Carol is given the rights to use the Nessus tool to scan all the machines in her branch office (subnet 10.0.17.0/25, which is the short form of 10.0.17.0 netmask 255.255.255.0). Scanning of any other subnets is explicitly denied for this user.

 Athena:~ # nessus-adduser Using /var/tmp as a temporary file holder Add a new nessusd user ---------------------- Login : carol Authentication (pass/cert) [pass] : pass Login password : Login password (again) : User rules ---------- nessusd has a rules system which allows you to restrict the hosts that carol has the right to test. For instance, you may want him to be able to scan his own host only. Please see the nessus-adduser(8) man page for the rules syntax Enter the rules for this user, and hit ctrl-D once you are done : (the user can have an empty rules set) accept 10.0.17.0/25 default deny  ^D Login             : carol Password          : *********** DN                : Rules             : accept 10.0.17.0/25 default deny Is that ok ? (y/n) [y] y user added. Athena:~ # 

Before the server side of Nessus is invoked, you should perform one important step. Vulnerabilities are being discovered on a regular basis. A list of known weaknesses from the original install CDs will most certainly be out of date by the time you install Nessus. Therefore, before you start Nessus as well as on a regular interval, it is important to update the list of known vulnerabilities. This ensures the validity of the scan results. Nessus uses plug-ins for scanning. These plug-ins are brought up to date using the nessus-update-plugins command. At the time of writing, there were more than 7,200 Nessus plug-ins.

After you run the update command, you can start the Nessus server daemon by issuing the following command:

 Athena:~ # nessusd -D Loading the plugins... 1224 (out of 7297) 

After the server has loaded all the plug-ins, the system prompt will return. The client can now be invoked, as follows:

 Athena:~ # nessus & 

On startup, the client requires credentials for authenticating against the Nessus scanner on the server side. In addition, if firewalls are in place, allowances for port 1241 will have to be made for client/server communications. The default login screen is shown in Figure 12.1.

Figure 12.1. The Nessus Client login screen.

The Nessus client interface is composed of a number of tabs. Each tab represents a family of options allowing you to customize your scans. The major tabs are

• Plugins This tab allows you to define the series of tests that will be performed on the selected target.

• Credentials This tab allows you to define valid application accounts (SMB and ssh) to be used to probe for known vulnerabilities available to authenticated users.

• Scan Options On this tab, you can select the number of hosts and tests to run simultaneously. This tab also allows you to select which options are used for port discovery on the target.

• Target You can simply specify a name or address for the target system on this tab. The software also supports defining multiple targets and retrieving a target list from a disk file.

• User User-customized rules can be included using this selection.

• Prefs. This tab permits fine-tuning of the various aspects of the port scanning options. This is also the place where the SNMP community string used for scanning can be changed from public to a more appropriate value. Using this tab, you can also define accounts to be used for insecure services such as FTP, POP, and HTTP.

Upon successful login, you are presented with the Plugins tab as well as a warning message (see Figure 12.2). A number of known exploits are Denial of Service exploits (DoS) that cause services to fail. To properly measure the exposure of a system, you must test for the vulnerability using the same approach as the attack. If the system is vulnerable, the service will fail, causing an outage. By default, Nessus disables these tests.

Figure 12.2. The Nessus Plugins tab and warning message.

A more detailed version of the Plugins tab is shown in Figure 12.3. In the upper portion of the tab is a list of the different families of tests. If you want to reduce network load and unnecessary alarm, it is best to customize the plug-in selection to match the host type. When you are testing a SUSE server, looking for operating-systemspecific vulnerabilities, such as those for Solaris or Windows, is wasteful.

Figure 12.3. The Nessus SUSE Local Security Checks options.

The lower portion of the Plugins tab shows the tests available for a SUSE server. Notice that these are local security checks. This means that if given the proper credentials, Nessus can create a valid ssh client session to your server and test for the SUSE vulnerabilities listed.

Selecting the appropriate options for scanning requires a certain amount of fine-tuning. Once you have chosen the appropriate values, you can proceed to the Target tab. After choosing the appropriate target, you can select the Start the Scan button at the bottom of the window.

For the purpose of this section, we have started a number of extra services on the server Athena. We have also selected to run the tests without the local server-side firewall. If the services are present and unprotected, it is best to know whether any vulnerabilities exist.

Nessus will proceed to scan the target for open ports, and for each, it will run a number of tests. A typical report is shown in Figure 12.4. When the report window opens, you are presented with a number of blank panes. Selecting the appropriate subnet in the upper-left pane presents a list of valid scanned hosts in the lower-left pane. Selecting the appropriate host populates the report portion of the window.

Figure 12.4. A Nessus report for Athena.

Figure 12.4 presents the information gleaned from finding an open Telnet service on the server. Throughout this book, we have discussed using ssh over Telnet. In this example, the security warning option in the Severity pane rehashes the perils of using Telnet. The Security Note portion of the Severity pane presents information that a hacker could collect if Telnet were accessible. From the Telnet banner alone, a hacker can determine not only the flavor of the operating system, but also which version of the kernel it is running.

To reduce this exposure and that of traffic intercept, we have suggested many times replacing Telnet with ssh. If you then view the Nessus results for ssh, you find the information presented in Figure 12.5. Though ssh is a more secure protocol, certain incarnations of the protocols have been found to have weaknesses over time. Currently, ssh versions earlier than version 2 are not considered totally safe. In this case, Nessus has revealed that simply turning on ssh might leave a false sense of security. Nessus also offers the appropriate configuration changes required to secure the solution.

Figure 12.5. A Nessus report for the ssh service on Athena.

This discussion illustrates how Nessus can be used to probe for vulnerabilities on your servers. Selecting the appropriate scanning options allows for efficient, customized scanning for your infrastructure. It is important to remember that a number of scanning options are known to crash services. Great care should be exercised to restrict the use of such selections.

In most cases, a valid corporate IT policy will prohibit the unscheduled use of scanning tools such as Nessus on the live network. It is not difficult to imagine the chaos that would result from having the uncontrolled use of vulnerability scanners crashing production environments. The next section describes how such scans can be tracked. Whenever possible, a preproduction environment should exist where these tests can be performed on staging servers. This ensures that the soon-to-be-rolled-out changes are secure. If not, the tests will generate downtime in the development section, not in production.