|< Day Day Up >|
Vulnerability Scanners to the Rescue
As you can see, modern computer networks have multiple potential areas of insecurity. How do you protect all these avenues of attack? You might start to feel like a single guard trying to protect a giant castle with multiple windows, doors, and other ways to get in. You can't be everywhere at once. You could spend all day, every day, just checking for these security holes manually. Even if you tried to automate it with scripts, it would seem to take dozens of programs. Well, fortunately for you and your sanity, there are packages out there called vulnerability scanners that will automatically check all these areas and more.
Nessus is a truly amazing program. It is a great example of how well open source projects can work. It is robust, well documented, well maintained, and top of its class. Nessus has consistently been rated in the top of all vulnerability scanners, commercial or noncommercial. This is amazing when you consider its counterparts cost thousands of dollars and are created by large companies. It continues to impress and improve, and most importantly, to protect thousands of companies' networks. There are some design features that make Nessus unique and superior to other vulnerability scanners.
Depth of Tests
Nessus currently offers over 2,000 individual vulnerability tests that cover practically every area of potential weakness in systems. Very few scanners out there can compete with this level of testing, and new tests are being added daily by a worldwide network of developers. The speed of release of new tests for emerging vulnerabilities is usually measured in days if not hours. Its plug-in based architecture allows new tests to be added easily. Here is a list of all the categories of tests that Nessus runs.
You can turn off whole categories of tests if they don't apply or if you are worried they could be dangerous to your systems, or you can deactivate individual tests if you have a concern about a specific one. For example, you may prefer to disable the untested category, which contains tests that haven't been fully tested yet (caveat emptor). See Appendix E for a complete list of all the security checks. Keep in mind, though, that this list is only complete as of the date listed and will be changing constantly as new plug-ins are added.
Nessus uses a client-server architecture to run its security checks. The server runs the tests and the client configures and controls the sessions. The fact that the client and server can e separated offers some unique advantages. This means that you can have your scanning server outside your network, yet access it from inside your network via the client. This also allows other operating systems to be supported via different clients. There are currently UNIX and Windows clients available, with projects to create additional ones ongoing. There is also now a Web client interface available, which makes Nessus truly platform independent (at least on the client end).
Because Nessus is open source and the plug-ins are written by a diverse group of individuals in the security community, you don't have to worry about any conflicts of interest that may arise with commercial companies. For example, if the provider of a commercial vulnerability scanner has a large contract with a major OS provider, they may be less critical and slower to release tests for their products. An open source project like Nessus has no financial motivation not to develop and release tests right away. And because of its extendability, you can always write your own rather than wait for the official one.
Built-in Scripting Language
To supplement the plug-in architecture, Nessus has its own scripting language called Nessus Attack Scripting Language (NASL). This easy-to-learn utility language allows you to quickly and easily write your own custom security plug-ins without having to know C or all of the internal workings of the main program. (There is an example of writing a custom plug-in with NASL later in this chapter.)
Integration with Other Tools
Nessus can be used by itself or with several other open source security tools. Some of these are discussed in this chapter, and all of them are best-of-breed tools. You can use Nmap, the best port scanner in the world, for the port scanning part of the job, rather than the built-in one. The Nessus port scanner is faster and a little more efficient with memory, but Nmap allows for a lot more options and settings as you learned in Chapter 4. Almost all of the Nmap settings are configurable from within the Nessus client. Nessus also works with Nikto and Whisker, tools that run more complex tests on Web servers; CGI programs; and Hydra, a tool for running brute-force password attacks against common services. The functionality of these tools is written right into Nessus, so you can make configuration changes from a single interface.
Nessus can be set up so that it doesn't automatically run all of the vulnerability tests on every host. Based on the results of a port's scan or other input such as past vulnerability tests, Nessus will run only tests appropriate to that machine. So if the server is not running a Web server, it won't run Web server-related tests. Nessus is also smart in that it doesn't automatically assume that Web servers will run on port 80, but rather checks all the possible ports for signs of a Web server. Nessus will even find multiple instances of services running on different ports. This is especially important if you are inadvertently running a Web server or other public service on an unusual port.
Nessus can save all scan results in a database called the Knowledge Base. This allows it to use the results of past scans to intelligently figure out what tests to run. You can use this to avoid doing a port scan every time you run Nessus, because it will remember what ports it found open last time on each host and test only those. It can also remember what hosts it saw last time and test only new hosts. I don't recommend you do this every time, because you may miss new ports that open up on machines or new vulnerabilities that show up on previously scanned boxes. However, it can allow you to run scans more often with less bandwidth and processor power as long as you do a complete scan on a regular basis.
Multiple Report Formats
Nessus has some of the best reporting capabilities in the open source field. Although it's not perfect, it can output your scan data in just about any format. Basic HTML and HTML with pie charts and graphs are two of the more popular formats. These reports include summary data and are suitable for posting to an internal Web site with little or no editing. Other report formats supported include XML, LaTeX, and good old plain text. The Windows client offers additional report formats. There are additional tools available, discussed in the coming chapters, that allow you to do further manipulation of the data.
Robust Support Network
Nessus has an extensive support network for getting help, both on basic installation and use as well as more complex programming and customization. There are no fewer than five Nessus mailing lists, each dedicated to a different area. Subscribers to the lists will notice that Renaud himself frequently answers many of the questions. Try getting this kind of support from a commercial company! There is an archive of all the past posts so you can check to see if your question has ever been answered. The following are the main Nessus mailing lists.
To subscribe to any of the above lists, send an e-mail to email@example.com with the following text in the body of the e-mail:
Replace listname with the name of the list you want to subscribe to. To unsubscribe, do the same but write Unsubscribe listname in the body.
Nessus has quite a bit of documentation on its Web site, including detailed instructions on installation, basic operation, and tutorials on how to write your own security checks in NASL. To my knowledge, no one has yet attempted to completely cover all the features and settings on the Nessus client in a single document. This section tries to do just that.
Nessus provides you with a quick and easy way to test your network and systems for almost every kind of vulnerability, so let's install it.
Installing Nessus for Linux Systems
There are two prerequisites you must have before installing Nessus, and two others that are nice to have installed beforehand to take full advantage of the add-on capabilities.
There are three ways to install Nessus on UNIX systems, ranging from very simple to slightly more complicated. This is one case where I recommend the more extensive install process in order to have more control over your installation.
The easiest way to install Nessus is to run the auto-installer script remotely. You can do this by typing:
lynx –source http://install.nessus.org | sh
This initiates the installation script and loads the program on your computer. However, I don't really recommend doing this as it could open your computer up to an attack if that URL was ever compromised. Follow these steps for a safer way to do it.
Setting Up Nessus
The first thing you need do to get Nessus ready to run is create a certificate that Nessus will use for SSL communications.
Now you are finally ready to run Nessus.
You are now ready to start using Nessus.
Nessus Login Page
The first thing you will see is the login page for Nessus (see Figure 5.1). Because of the client-server architecture, you must first log in to a Nessus server before you can begin using Nessus. If you will be running the client and server on the same machine, the correct login parameters are:
Figure 5.1. Nessus Login Screen
You can also run the client on a separate machine from the server. In this case, just replace localhost with the IP address or host name of your Nessus server. This gives you the ability to log in from home and access the Nessus servers at work so you can start scans late at night. Or you may have your Nessus server in a data center where it has access to lots of bandwidth and need to access it from your desk inside your firewall. This flexibility is a big advantage of Nessus over some of the competitive scanners and increases its scalability for larger organizations. You can also perform other local functions on the client without logging into a Nessus server. You can bring up scans run previously to view and manipulate them. You can configure the scan options, but you can't access the plug-ins or preferences section without being logged into a server (because these are saved on the server side).
Nessus Plugins Tab
Once you are logged in, you can access the other tab sections. The Plugins tab is where you can selectively enable or disable certain groups of plug-ins as well as individual plug-ins (see Figure 5.2). Each category is listed, and when you click on a category the individual plug-ins in that category appear in the lower section. By deselecting the box to the right of an item, you can disable that category or plug-in.
Figure 5.2. Nessus Plugins Tab
Plug-ins that may cause a problem with a service or can crash servers are highlighted with a triangular exclamation symbol (see Figure 5.2). Nessus also has buttons that make it easy to quickly enable all plug-ins, enable all but dangerous plug-ins, disable all plug-ins, or load a custom plug-in. You can use the Filter button to sort the plug-ins by Name, Description, Summary, Author, ID number, or Category. I recommend that you generally run Nessus with dangerous plug-ins disabled, unless you have prepared for a true denial of service test and are willing to risk crashing some of your servers.
Nessus Preferences Tab
Most of the server-side Nessus options are configured on the Preferences tab (see Figure 5.3). The following sections and subsections cover these options.
Figure 5.3. Nessus Preferences Tab
You use these Nmap settings to customize the configuration of how the port scan part of the test runs. Many of these correlate directly to the Nmap settings discussed in Chapter 4, so refer there for details on what each option means.
You can also enter a location for an Nmap results file so that Nessus will use that data rather than run a new scan.
Ping the remote host
This selection lets you ping the machines on the target network to determine first if they are alive, or just scan all the IPs in the target range. By default, Nessus tries ICMP and TCP pings on both the Web and secure socket layers ports. If a host is online, it should respond to one of these polls. This is the setting I recommend using most of the time, because you don't want to waste time and bandwidth running the tests against dead addresses. However, if you are scanning from outside a firewall, you may want to run Nessus without pinging the hosts so you don't risk missing anything. You can also configure the number of tries it makes before considering a nonresponding host dead. The default of 10 is probably too high for most high-speed networks. Unless you are scanning from a dial-up connection, turn the retries rate down to 3 to speed up the scan process, especially on large target networks. You can also set whether dead hosts should appear in the report. Usually you don't want these to be included because they will skew your overall scan statistics, reporting that there are more hosts scanned on your network than there really are. However, this can be useful when you want to know each IP that was contacted.
This section is where you set up login accounts if you want Nessus to test some services at a deeper level. The standard Nessus scan tests the network as if it had no additional knowledge about it other than just the IP addresses. However, if you specify an account and password for a certain service, Nessus will run additional tests on it. For example, if you enter a Windows domain login (SMB account), it will further test your Windows domain security as a logged-on user. By default, it tests only for an anonymous FTP server using the account of "anonymous" and the standard password of an e-mail address. You can have it test FTP, HTTP, IMAP, NNTP, POP2, POP3, and SNMP services with valid logins.
There is a special section for testing HTTP login forms. You can give it the specific URL and form fields to be filled in. By default, it will test an index directory for blank user and password fields.
Brute-force login (Hydra)
This section lets you take advantage of the add-on program Hydra, which tests the integrity of your system's passwords. You give it a file of logins and passwords and it will attempt to go through the whole list on each service you designate. I don't recommend you use this option unless you are prepared to deal with the aftermath of a brute-force attack, which may leave many users locked out of their accounts as the scanner maxes out the number of login attempts they are allowed. A better way to test your password strength would be to run your password file through a password cracker offline. However, it might be useful to test a single service that isn't used much, such as FTP or Telnet. With Hydra, you can attempt brute force on the following services: Cisco IOS standard and enable passwords, FTP, HTTP, ICQ, IMAP, LDAP, NNTP, PCNFS, POP3, Rexec, SMB (Windows Domain), SOCKS 5, Telnet, and VNC.
SMB use host SID to enumerate local users
This section gives a range of User ID (UID) numbers to try to get additional information about the user names in the domain. The default uses UIDs 1,000–1,020, which always encompasses at least the administrator and guest users accounts on Windows networks. Nessus will try administrator and guest with passwords as blank and the same as the login.
This section has to do with testing SSL services. You can specify certificates to check and get reports on the level of encryption your Web servers will accept. This can locate servers that are still accepting older 40-bit encryption, which is now considered insecure for highly sensitive data.
This setting lets you adjust how deeply into a Web site the scanner will read looking for any flaws or security holes. You can also change the default start directory.
Misc. Information on the News Server
If there is a Network News (NNTP) server located on any of the IPs in the target range, Nessus checks the settings and restrictions set on postings. This ensures that your news servers aren't susceptible to spamming or other misuse.
Test HTTP dangerous methods
The Integrist test checks to see if any Web servers on the network will allow dangerous commands such as PUT and DELETE. This is disabled by default because the test could delete your home page if your server responds to these commands.
Ftp writable directories
This checks for FTP servers that allow write access to anonymous users (which is not a good idea at all). The default setting checks the permissions listed by the file system and responds if one shows as being writable. You can also have it ignore what the file system says and try to write a file anyway to test that there are no writable directories. Again, like the Integrist test above, be careful with this option because you could end up overwriting files on your FTP server.
These settings are used for additional testing of a mail system. Nessus does this by attempting to send bogus e-mail messages to see how the system responds. Nessus.org is used as the default domain the test mail would be coming from, though this is configurable here. Many mail servers won't respond if the mail server name isn't real. You may want to change this address if you are an outside consultant and want your client to know where the dummy e-mails are coming from. However, don't use your own domain if you are scanning from within a company; this will confuse your mail server to see e-mail coming from itself and may produce unreliable test results.
These options are for use with the add-on Whisker program, which tests the integrity of your Web servers. Refer to the Whisker documentation program for explanations of these settings. These options are disabled by default.
SMB use domain SID to enumerate users
This Windows domain test tries to identify users based on their Security ID (SID). In typical Windows domains, SID 1,000 is the administrator, and several other standard designations are used for system accounts such as guest. Nessus polls this range of SIDs to try to extrapolate user names.
HTTP NIDS evasion
This section lets you use various techniques to avoid detection by a network intrusion detection system (NIDS) by crafting and mal-forming special URLs for attacks on Web servers. You need the Whisker add-on program to take advantage of these. The various tests try to send strange URLs to your Web servers to see if they will allow a user to do things that they aren't supposed to be able to do using CGI scripts. For a complete description of these tests, see the Whisker documentation or the article at www.wiretrip.net/rfp/libwhisker/README.
These methods are disabled by default because they tend to create a lot of network traffic and may generate many false positives. However, if you do run a NIDS on your network and want to see if it's really working, you can run these tests to see if it picks up your scans.
This section is similar to the HTTP NIDS evasion section, except that Nessus does strange things to the actual TCP packets to avoid pattern-matching NIDS rather than just the URL requests. Most modern NIDS will catch these tricks, but if you have an older system or one that hasn't been patched in a while, it is worth trying these to see if your NIDS catches them. Once again, this will cause your reports to contain data that may be suspect, so it's not recommended for normal vulnerabilities testing.
Scan Options Tab
Unlike the individual tests on the Preferences tab, this tab contains settings that affect the overall scan (see Figure 5.4).
Figure 5.4. Nessus Scan Options Tab
This controls which ports are scanned during the port scan phase of the test. The default is 1–15,000, which should catch most normal services. However, you should open it up to scan all 65,535 TCP and UDP ports if you want to search for Trojan horses and other services operating on unusual high ports. You should do a full port scan of the machines on your network on regular basis, either monthly or quarterly depending on the network size.
Consider unscanned ports as closed
This option causes Nessus to declare unscanned ports as closed. If you didn't set your port range wide enough in the last option, you may miss something, but it makes your scan run faster and puts less traffic on the network.
Number of hosts to test at the same time
This sets the number of hosts that Nessus tests concurrently. On a large network, you may be tempted to crank this setting way up and run all of them at once. However, at some point this becomes counterproductive and your scan will actually take longer or may not finish at all if it gets bogged down on one particular host. In fact, on average servers (under 2Ghz) machines, I recommend changing this to 10 hosts from the default setting of 30. This seems to be the optimal setting for most scans. However, if you have a super-server and have a very large network, you can try turning it up as high as you can get away with.
Number of checks to perform at the same time
Nessus has the ability to multitask not only how many hosts it scans at once but also the tests. The default setting of 10 seems to work well; however, you can do more or fewer depending on your how much horsepower your Nessus server has.
Path to the CGIs
This is the default location where Nessus will look for CGI scripts on the remote system to test them. If you have an unusual configuration on a machine, you should change this to the correct path so that Nessus will test your CGIs.
Do a reverse lookup on the IP before testing it
This setting attempts to do a reverse DNS lookup and determine every IP's hostname before testing them. This will considerably slow down your scan and is disabled by default.
Optimize the test
Nessus, by default, attempts to be smart about the tests it runs and won't run tests that don't apply to a particular host. You can disable this here so Nessus will run every test on every host regardless of what the port scan finds.
This setting is always on by default. It means Nessus won't perform any unsafe checks that may crash or otherwise harm a server. It will depend on banners or other information to determine if a host has a particular vulnerability. I recommended to always keep this on, even though it will result in more false positives.
Designate hosts by their MAC address
Enable this option if you want Nessus to show hosts in the report by their MAC address rather than IP address, which is the default. If you have a good database of MAC addresses on your network and you have a hard time correlating IP addresses to specific hosts because of DHCP, this may create a more useful report for you.
This feature allows Nessus to run scans without being connected to the client. This is usually done to run scans at unusual times without human intervention. It can be set up to e-mail the scan report to a specific address when it is done.
This feature starts a new scan on a regular basis. You can use this to set up an automatic scan of your network on a scheduled basis. Set the "Delay between two scans" timing in seconds (86,400 for a daily scan, 604,800 for weekly scans, and approximately 2,592,000 for monthly scans). There are better ways to do this, such as using the Nessus Command Center (NCC) tool described in Chapter 8. However, if you don't want to set up the Web server and database required by NCC, this feature is a quick and easy way to do a regular scan.
This has several global settings for the port scanner portion of the test.
Target Selection Tab
This tab is where you set your targets to scan (see Figure 5.5). The following list describes the ways you can designate scan targets.
Figure 5.5. Nessus Target Selection Tab
There are several options you can set on this tab.
Click here to read your targets from a file. This must be a standard text file with addresses formatted as in the above example.
Perform a DNS zone transfer
This attempts to pull a zone file for the domain represented by the target IPs. This doesn't work on private (nonroutable) IP addresses.
Save this session
Keeps a record of the targets and settings so they can be restored at a future date. By default, this is turned on.
Save empty sessions
This saves sessions even when they contain no data, for example, an IP range with no live hosts in it.
This lists all your previously run sessions and allows you to reload them by clicking on the listing.
This tab shows all the users you have set up to use the Nessus server and any rules associated with those users (for example, only able to log on from a specific IP address). These are set up when you create the user with the nessus-adduser script, but you can also edit or add rules for any users from this tab at any time.
KB (Knowledge Base) Tab
This tab contains the configuration and controls for the Nessus Knowledge Base (see Figure 5.6). This is one of the most useful features Nessus offers. It is disabled by default, so you need to select the Enable KB saving check box to turn it on. The Knowledge Base keeps track of all the scans you have done. Then when you want to run that scan again, Nessus uses that data to be intelligent about which hosts it scans and what tests are run on those hosts. Each setting is described below.
Figure 5.6. Nessus Knowledge Base Tab
Test all hosts
This is the default setting. Knowledge Base data will be saved but each host will be tested in full.
Test only hosts that have been tested in the past
This setting has Nessus test only hosts that it has tested in the past in the target range. This means it will not scan for any new hosts. This reduces network traffic a little, but Nessus won't test any machines on your network that have been added since your last scan.
Test only hosts that have never been tested in the past
This is the opposite of that last setting; it looks only for new hosts on the target network. This is useful for doing a quick check for new machines on your network without scanning your existing machines.
Reuse the knowledge bases about the hosts for the test
This eliminates running certain tests based on what it found and the options you set.
Max age of a saved KB (in secs)
This setting prevents the server from using a scan Knowledge Base that is older than the entry. The default setting is 86,400 seconds, which is one day. You can set this up to 60 days, which is 5,184,000 seconds. Setting it for any longer is not useful, as you will be relying on data that is too old.
The Knowledge Base features can make your scanning quicker and easier. However, you should use the features selectively and always run a full scan on a regular basis (monthly is recommended).
Nessus Scan in Process Options
Once your scan is underway, Nessus displays a screen showing the status of your scan. You can see each host being tested and how far along in the process it is. It also shows you the plug-in that is running at the moment. Most of these fly by very quickly, but sometimes it will get stuck on a particular plug-in. You can stop the testing on that host only by clicking on the Stop button on the right side (see Figure 5.7). You can also click the Stop the whole test button at the bottom to stop all the testing and just report the results thus far.
Figure 5.7. Nessus Scan in Progress Screen
NessusWX is a Windows client for Nessus. It represents the client end only of the program. Unfortunately, Nessus doesn't yet offer an all-Windows solutions for vulnerability testing. Tenable Network Security makes a commercial Windows Nessus port called NeWT, but if you can't afford that you will have to use a UNIX-based Nessus server for your NessusWX client to attach to.
NessusWX is far more than just a clone of the UNIX client. Besides giving you access to your Nessus server from your Windows machine, NessusWX adds some features that are missing from the UNIX client. It also implements some of the other settings in a more logical and easier to use manner. If fact, some consider NessusWX a superior way to use Nessus. Just keep in mind that you will still need to have a UNIX Nessus server to connect to in order to run your scans. Also, because NessusWX is a separate programming effort, its features will sometimes be a little behind those of the native UNIX platform. Here are a few nice extras you get with NessusWX.
You can also get packages with the source code if you care to monkey around with it and see if you can improve on it. But if you are not intending on doing that, there is no real reason to get the sources. Simply click on the file and the install program will guide you through the process.
Using the NessusWX Windows Client
The NessusWX interface looks different from the native UNIX client (see Figure 5.8). You won't see the same tabs described earlier, but all the configuration options discussed are available in this version. The NessusWX client makes it clearer which settings are client controlled and which are server controlled. The server-controlled settings are the ones found in the nessus.rc text file and constitute global settings, whereas the client-side settings are mostly related to specific scans. You can see the contents of the nessus.rc file and edit it by choosing Server Preferences from the Communication menu.
Figure 5.8. The NessusWX Interface
Another nice thing about the Windows client is that you can interactively create scan configurations (called sessions) and then connect to a Nessus server. This means you can do your configuration offline without connecting to the server. However, to start a scan or view and configure the server-side preferences you need to be connected and log in. To do this, on the Communications tab click on Connect. You can also use the Quick Connect option and set a default server to always log in to. It will also remember your password and login so that you don't have to enter it each time, which is nice (though certainly less secure!).
Creating a Session Profile
The first thing you want to do is create a session profile. This is a target or collection of targets that you want to scan.
To get, create, and view NessusWX reports, right click on any scan profile and select Results. Several options on this screen allow you to control the output of the reports. You can choose whether the report is sorted by host or by vulnerability. You can select to leave false positives out of the report and to include the scan configuration so you can remember what settings were used to obtain these results. You can also have it show only reports on open ports, and low, medium, or high severity alerts by deselecting the check boxes for each one. This gives you more flexibility on how the report will look. This is important if you are presenting these reports to nontechnical management, auditors, customers, or other outsiders.
Report options in NessusWX include .nsr, which is the older native Nessus format, .nbe, html, plain text, and .pdf format. All of the results are stored in a database, so you can easily retrieve old scans. You can also compare results from one scan to another by using the diff option. The basic HTML report has some nice additions from the UNIX HTML reports. It adds the profile name, so you know what was scanned. It also timestamps it and gives other statistics, such as how long the scan took. In addition, the scan can be ordered by IP address, as mentioned earlier, which greatly assists in finding a particular host, as anyone who has tried to sort through the randomly ordered UNIX scan report can attest to. Unfortunately, it doesn't have the embedded HTML links that the UNIX reports do, which would greatly improve the ease of navigation through the report. (Hopefully someone is working on merging the best of the UNIX and Windows reports.) Or you scan it all into a database and create your own reports using NCC, which is described in Chapter 8.
Sample Nessus Scanning Configurations
With so many settings to choose from, it can be rather bewildering to know what to do for your first scan. It does take time to learn the intricacies of all the options, but here are a few sample configurations that should produce good results for the most common network configurations.
Sample Configuration 1: External scan of multiple IP addresses; no firewall
This is the simplest possible configuration and requires the fewest changes in the default Nessus configuration.
Sample Configuration 2: External scan of a network with a single external IP address on the firewall
This is a little more complex and requires some stealth to get scan packets past the firewall.
Sample Configuration 3: External scan of a network with multiple public IP addresses on the firewall and DMZ
Sample Configuration 4: Multiple external IP addresses with a Network Intrusion Detection System
Sample Configuration 5: Internal scan behind the firewall
With this kind of scan you are much less concerned about stealth (since you are already inside the firewall) and more concerned about the kind of data you generate.
|< Day Day Up >|