Security auditing is a critical aspect of network administration. Knowing where your servers are vulnerable can aid you in saving your data. Unfortunately, many port-scanning tools don’t do the job completely. Nessus, on the other hand, is really an attack application.
In this Daily Drill Down, I will show you how to install, configure, and use Nessus so you too can enjoy hardened server security, as well as better job security.
In “Security auditing with nmap,” we looked at a program called nmap, an advanced port scanner used to help identify areas in your system that might be insecure. Using nmap, you can determine which services are listening to which ports, and based on that information, you can further lock down your system and make available only those ports necessary. It also helps you decide what you should be blocking via your firewall if some of those ports are necessary to an internal network.
While nmap is an excellent piece of software and should be used by every system administrator at least once, it does have a few limitations. For instance, it can tell you which ports are open, it can make a best guess as to what that port is used for, and it gives you an idea of what you need to secure. However, it cannot tell you whether the SMTP server it knows is listening to port 25 is vulnerable to well-known attacks and exploits. That information is vital as well, and unless you pay strict attention to mailing lists such as BugTraq or to security releases by the distribution you have chosen, you may be using a vulnerable piece of software and not even realize it.
Recognizing the importance of subscribing to vendor-supplied mailing lists regarding security announcements should be common sense, and upgrading packages your vendor deems essential for security reasons is a given. However, you may have chosen an inappropriate software package to begin with—one that, perhaps, has a history of security problems and shouldn’t be trusted as much as other, more viable packages. For instance, just last week, a friend of mine who works at an ISP reported to me how all of the servers co-located at the ISP had gotten hammered one evening by a number of crackers. The one server the hackers managed to break in to was running a stock Red Hat 6.2 system with no updates and using wu-ftpd as the FTP server. Using brute force and some well-known exploits, they managed to get root access to the system via the FTP server and covered their tracks by scrubbing the log files. They managed to deface the Web sites hosted on the system and use the compromised system for more malicious activity.
This experience obviously drove home a hard point for the owner of that server. Red Hat 6.2 has had a number of updates for security, and if those updates had been applied, his experience may have been quite different. However, his choice of using wu-ftpd also concerned me. Wu-ftpd has had a long and messy history in terms of security, and ProFTPD is a much better choice in my opinion.
My point here is simple. Education and awareness will prevent such things from happening to you. And taking other steps, such as security auditing, is essential to protecting your system and helping you to identify weaknesses in your system—before others do it for you.
A number of programs like nmap exist, but my favorite has to be Nessus. Nessus does far more than nmap does by performing actual attacks on the server. It scans the ports to see what is available, and based on the resulting open ports, it tries to collect as much information as possible—and the results can be surprising.
Nessus operates on a client/server basis. The server, nessusd, does the actual scanning and attacking, whereas the client collects the results of the scan. The server is available only for POSIX systems such as Linux and some UNIX variants, while there are clients available for Linux/UNIX, Java, and Windows. The server is not optional, however, and is required to run any tests. This means that you must have at the very least a Linux or UNIX machine to run the server on, while you can run the client on any other machine.
With this sort of setup, a system administrator can closely monitor Nessus. Nessus uses key-based authentication, and users must authenticate themselves with the server prior to performing any tests. This means that you can restrict access to certain people, which is a good idea because Nessus is a powerful tool and some of its tests can render your system inoperable temporarily. Users can also be restricted to performing tests on specific hosts. If you like, you can restrict all users to testing their own machines and no others. This kind of sophistication makes Nessus a little more trying to use but also benefits the administrator setting it up. You don’t want overeager users using Nessus against hosts on the Internet that they really shouldn’t be using it against. Again, tools like Nessus and nmap exist to help you evaluate your own security and should not be used against other systems without that system owner’s express permission.
You can download Nessus from the Nessus home page. Here you can find the source tarball or precompiled RPM packages, as well as the Java and Windows clients. For the purpose of this Daily Drill Down, we will download the source packages nessus-core-1.0.6.tar.gz, nessus-libraries-1.0.6.tar.gz, nessus-plugins-1.0.6.tar.gz, and libnasl-1.0.6.tar.gz and save them to our /usr/local/src directory. Prior to building Nessus, you must have nmap installed because Nessus does use nmap to do some of the port scanning. If you have nmap installed already, or after you install nmap, you can build and install Nessus using these commands:
tar xvzf nessus-libraries.1.0.6.tar.gz
tar xvzf nessus-core-1.0.6.tar.gz
tar xvzf nessus-plugins-1.0.6.tar.gz
tar xvzf libnasl-1.0.6.tar.gz
Once this process is complete, you must check your /etc/ld.so.conf file and make sure that /usr/local/lib is in the path. Once this has been verified—or you’ve added the path if it wasn’t there previously—run the following command to set up the Nessus libraries:
At this point, Nessus is installed into your /usr/local directory tree. You are now ready to configure the Nessus server and set up your first user.
To configure nessusd, the Nessus server, you must edit the file /usr/local/etc/nessusd.conf. This file is pretty straightforward and well documented. Most of the defaults should be adequate; however, you may wish to change the e-mail address for the administrator to your own e-mail address instead of the default root@localhost.
I also suggest changing the logfile to a dedicated logfile in your /var/log directory tree; for example:
logfile = /var/log/nessusd.messages
Beyond that, you really shouldn’t have to configure anything because the defaults work quite well. The next step is to add a user permitted to use Nessus. To do this, you must run the program nessus-adduser, which is located in your /usr/local/sbin directory. Execute the program like this:
You will be prompted for the user’s login name and then the authentication type. If you’re using the Windows or Java clients, you’ll want to select plain text, but if you’re using the Linux or another POSIX client, you’ll want to use the cipher method of authentication.
Next, you can tell nessusd to allow the user to connect only from a specific IP address or network. This means that the user you define will be able to run Nessus only from a particular machine or range of machines if you wish. The default is to allow them to connect to the nessusd server from anywhere, but it might be ideal to restrict this, especially in a larger environment. For instance, if the internal network has an IP address range of 192.168.1.100 to 192.168.1.200, you might want to allow the user to connect only from the 192.168.1.0 IP network by using:
This will allow the user to connect to nessusd from any machine in the 192.168.1.0 network, which will prevent the user from trying to connect to nessusd from home, for example.
If you select the cipher method of authentication, you must supply a one-time password for the user. This means that the first time the user connects to nessusd, he or she will need to supply the password. Subsequent connections will not require a password—the cipher key will be used instead.
Finally, you can enter the rules by which this user will be bound when using Nessus. These rules specify which machines the user can run Nessus against. By default, the user is permitted to use Nessus against any machine. Let’s use the previous example. We have allowed the user to connect from any machine on the internal LAN. Now we also want to restrict the user to scan only machines on the internal LAN. The last thing we want is for our user to go crazy and start scanning the entire Internet. The rules specified here are matched from top to bottom, which means that you should specify the default rule last. We want our user to scan only the 192.168.1.0 network, so we specify our rules like this:
Now the user can connect to Nessus only from a LAN machine and can use Nessus only against a LAN machine. For more information on the rules, you can look at the nessus-adduser man page.
Now that we have added the users that we want to use Nessus, let’s take a look at how we actually use it. The first step is to start the nessusd server, which we can do by running:
This will launch the nessusd server in the background. We can now start up our Nessus client and connect to the server. To do this, start the Nessus client by running
from an xterm window. A new window should appear on your desktop showing the Nessus splash screen and a message that Nessus is generating your new private key. Once this is done, Nessus will ask you for your passphrase for the newly generated key. Enter a good password here to protect your private key.
Once you have entered your password, you will be in the Nessus Setup screen. The very first step here is to log in to the nessusd server. Make sure the host to connect to is correct and verify your user name. The rest should be fine. Next, click the Login button. You will be asked for your one-time password to the server. Once you enter that, you will be shown the plug-in screen, where you can select which plug-ins to use to scan other hosts.
You may want to click the Enable All But Dangerous Plug-Ins button. This will allow you to do a comprehensive test against the remote machine without causing any serious damage. For a fully thorough test, you should click the Enable All button. Be warned, however, that some of those plug-ins can do temporary damage and may require you to reboot the machine you scanned to get things back in order. It’s a dangerous option, but it provides the most thorough scan possible.
Other options are available that you can tweak prior to performing your scan. On the Prefs tab, you can select which type of scans you wish to use and specify some nmap options as well. On the Scan Options tab, you can select the port range to scan, the maximum number of threads, and the path to the remote server’s /cgi-bin directory if it is running a Web server. This will allow Nessus to test the CGI scripts running on the remote Web site as well.
Once you have configured the test options, proceed to the Target Selection tab, where you can define a list of machines to scan. You can enter as many as you like here, using IP addresses or domain names. The list of targets is one long string separated by commas, like this:
The above string tells Nessus to scan the hosts located at IP addresses 192.168.1.105, 192.168.1.178, and 192.168.1.101. You can also tell Nessus to perform a DNS zone transfer on the hosts. This will make Nessus perform an AXFR request (zone transfer) on the DNS server to obtain a list of all the hosts on the system, and Nessus will then proceed to test each host. Finally, click Start The Scan, and Nessus will do its work.
While Nessus is scanning and attacking the specified systems, it will display a progress report for you. The report indicates what Nessus is doing and how much of the testing remains.
Once Nessus has finished scanning, it will present you with a detailed report of everything it found. It will show you open ports and will comment on any security holes or notes it found based on remote server information and other factors. You need this information to assess the strength of your machine. Pay close attention to the results that Nessus returns—they are quite valuable. However, they should also be taken with a grain of salt. If Nessus doesn’t know something for sure, it will indicate that it might be a false alarm. In order for you to know whether this is a false alarm, you need to be familiar with the software you use and whether it is vulnerable to what Nessus thinks it is. For instance, when you’re running a qmail mail server, Nessus identifies a number of vulnerabilities because qmail does not tell it that a specific action has failed. For example, say Nessus tries to send an e-mail to the server with a local file as the destination. Qmail doesn’t indicate to Nessus that the user doesn’t exist; it simply accepts the message. However, if you were to look at your qmail log files, you would see that qmail does not deliver the message but discards it as invalid. This is why I suggest looking at the Nessus results with a grain of salt.
Another good idea is to analyze the log files of the various servers and programs on your system. This will identify the logging strengths of your programs and whether you need to increase the verbosity of the logging. Remember, Nessus is an attacker who is trying to infiltrate your machine. You want as much warning and record of its activity as possible.
You can also save the report that Nessus generates. You can save it in a number of different formats, and these reports are good to keep handy. This way, you can refer to previous Nessus reports after making configuration and/or program changes on your machine and compare them to more recent tests.
While nmap makes a wonderful port scanner, Nessus takes security auditing to another level. As we’ve pointed out in this Daily Drill Down, for a system administrator, Nessus can be both a blessing and a curse because it does glean quite a bit of information from your system. However, proceeding from the prospective that you are running Nessus on your own system before a potential cracker does should provide some comfort. Using the tools that make a cracker’s life easier can also make your own life easier. By running repeated scans against your own machine and following the recommendations Nessus makes, you can considerably tighten your own system security so that an unauthorized user of Nessus attempting to use it against you will not find out more information than you are willing to provide.
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.