Vulnerability Scanning: What It Won’t Fix

 

Vulnerability scanningSecurity Issues That Won’t Be Fixed By Vulnerability Scanning

While vulnerability testing is a valuable tool in your security arsenal, you should not think of it as a silver bullet. There are still situations and areas that a vulnerability testing program won’t help you with. You have to develop additional systems and procedures to lessen your exposure in these areas. The following include security issues that won’t be found by vulnerability testing.

Logic errors are security holes that involve faulty programming logic inside a program. these are generally undiscovered or unpatched bugs where the program does not perform as it was supposed to. An example would be a web login page that does not authenticate properly or one that allows users to get more privileges than they should have. Well-known logic errors in major programs might be included in the Nessus vulnerability tests, but most of them are too obscure to be noticed except by a dedicated hacker.

Vulnerability testers rely on published reports of vulnerabilities. Usually, once a vulnerability is announced, an add-on or plug-on for the system is written. With open source programs, this may only take a few days. However, during that time there may be a window of vulnerability because your scanner won’t be finding that security hole if it exists. Of course, you could quickly write your own tests using NASL while you wait for the official one to come out.


Vulnerability testing programs typically only address published commercial and open source programs. If you have a program that was developed for internal use only, a vulnerability tester probably won’t test anything on it. If it uses standard protocols or subprograms such as HTTP, FTP, or SQL, then some of the tests may apply. There are additional programs specially designed to test code for its security that you should run on these applications. The good news is that with an open source vulnerability tester like Nessus, you can write tests custom designed for your in-house application.

All the testing in the world won’t help you if you have poor or nonexistent security policies for your employees. Hackers denied technical means to gain access to your network can revert to social engineering – in other words, trying to talk someone into giving them access. This can be surprisingly easy, because the hacker takes advantage of the basic human nature of people generally wanting to help others, especially people perceived as fellow employees. There is only one way to combat this kind of hacking, and it does not involve any technical systems. Having good security policies, educating employees about them, and enforcing them will lessen your exposure to these kinds of attacks.


Vulnerability testing only shows you potential security holes in your system; it won’t tell if those holes have been exploited or alert you if an attack is taking place. Programs like Nessus are purely preventative in nature, and they are effective only if you take action to fix problems when they are found. Vulnerability scanners won’t fix them for you, although Nessus is very helpful in giving you detailed information on how to fix any issues found.

External Links:

Vulnerability scanner on Wikipedia

Vulnerability Scanning Tips

vulnerability scanning tipsBefore you start vulnerability scanning, you should take into consideration some issues. Port scanning is a fairly innocuous activity, althouh it is annoying when you see the activity showing up in your logs. Vulnerability testing, however, can be quite a bit more disruptive, crashing servers, taking down Internet connections, or even deleting data. Many of the Nessus tests, for example, are specifically designed to cause a denial-of-service attack. Even with the safe checks option turned on, the tests can cause problems with some systems. With this in mind, here are some guidelines.

Scan Only with Permission

You should never scan a network that is not under your direct control or if you do not have explicit permission from the owner. Some of the activity initiated by Nessus could be legally considered hacking (especially with the DoS checks turned on). Unless you want to take the chance of being criminally and civilly charged, or having a complaint lodged against you by your ISP, you should always scan with permission. Non-company outsiders such as consultants should make sure to obtain written permission with all the legal disclaimers necessary. Internal personnel should make sure they have authority to scan all the machines in the range they are scanning. Coordinate with other departmental personnel as necessary, such as firewall administrators and security staff.


Modern vulnerability scanners are easy to install and use, but they are generally installed with generic settings. Using such settings may not be a good idea if you have legacy hardware. Approaching legacy hardware with a scan calls for caution, as a scan may cause problems with the legacy machine’s approaches to port management and binding. In such cases, port scanning can cause connection hang-ups and even system crashes. As a result, if your network includes such hardware, you want to be aware of the potential issues of running an untested scan and plan accordingly. Segmenting your risk by testing only a few servers at a time may be the way to go.

You should always make sure your backups are current anyway, but it is doubly important when vulnerability scanning, just in case the scan causes a problem with a server. Doing a Nessus scan right after you run backups will ensure that you can restore the most current version. But also make sure you aren’t running your scan during a backup. Not only could you cause a corruption of your backup data, but both processes will slow to a crawl.

Scheduling Your Scans

Along the lines of the last comment, make sure you coordinate your scan to get the results you want with minimal impact on other employees. Scanning the mail server at 8:00 AM when everyone is getting their e-mail will probably not make you very popular with the staff. Schedule scans on always-up servers for off-hours, and be sure to avoid overlapping with other system administration and general activity levels. If you are scanning internal machines, you will probably want to do it during the day unless you can arrange for everyone to leave their machines on at the end of the day. The best time to do it during business hours is generally around the lunch hour, as a minimal number of people will be using the network.

Schedule your scans as often as you feel is necessary, but don’t automatically assume that nightly scans are going to make your network more secure. If you cannot interpret and respond to scan reports on a daily basis, then don’t do the scan; all it will do is put additional traffic on your network. Base your frequency on the capability of your staff to deal with the results. You should do it at least once a month, but if you have a particularly busy network, you may want to do it weekly. Similarly, if you have a very small external network, you may feel comfortable with quarterly scans. Daily scans are probably excessive unless you have dedicated staff to handle the remediation work. If you have that much need for up-to-the minute protection, then use an intrusion detection system to supplement your vulnerability testing.

If you want a true of your external vulnerability (for the Internet), you should make sure your Nessus server is located outside your firewall. This can be on a home Internet connection, at a data center that is outside your company network, or at another company (perhaps you can negotiate a trade to use another company’s facilities for scanning and let them user yours for the same). Remember, because of the Nessus client-server architecture, you can still control your scans from inside your firewall. Just make sure you enable the SSL support so communications between your client and the server are encrypted.

If you are scanning your internal network, your internal network, your server will have to be located inside your firewall. Loading Nessus on a laptop can facilitate doing scans from both inside and outside your network without requiring multiple machines.

External Links:

Vulnerability Scanning Do’s And Don’ts at www.darkreading.com

Nessus Configuration: Part One

Nessus Configuration

Advanced settings in the Nessus web GUI.

Nessus Configuration: Proxy and Advanced Settings

The first thing you will see when you access Nessus is the login page. You must first enter the login name and password you created when you set up Nessus. Since Nessus uses a web-based front end, you can access the Nessus server from any computer on the local network that has a web browser, making Nessus configuration much easier. This increases the scalability of Nessus for larger organizations. You can configure scan options and make other changes, all from the web interface.

Once you are logged in, there are several settings you can change. If you click on your username (in this example, “nessusadmin”) on the right side of the page, there is a drop-down menu with several options; select “Settings”. On the left sidebar, there is an option called “Proxy”. If you did not set up a proxy during the setup process and need to do so now (for example, if your organization requires that all web traffic be directed through a corporate proxy), you can input the settings here.

Proxy Setting Options

Option Description
Host The host or IP of the proxy
Port The port of the proxy
Username Optional: if a username is required for proxy usage
Password Optional: If a password is required for proxy usage
User-Agent Optional: If the proxy you are using filters specific HTTP user agents, a custom user-agent string can be supplied
Custom Update Host Optional: This can be used to force Nessus to update plugins from a specific host. For example, if plugins must be updated from a site residing in the U.S., you can specify “plugins-us.nessus.org”

Different Nessus configuration options can be set by clicking on the “Advanced” link in the Settings menu. Each option can be configured by editing the corresponding field and clicking the “Save” button at the bottom of the screen. In addition, the option can be removed completely by clicking on the “X” button.


By default, the Nessus GUI operates on port 8834. To change this port, edit the xmlrpc_listen_port to the desired port. The Nessus server will process the change within a few minutes.

If additional preferences are required, click on the “New Setting” button, input the name and the value, and press “Save”. Once a preference has been updated and saved, Nessus will process the changes within a couple of minutes.

Nessus Configuration

Adding a new user in Nessus.

Nessus Configuration: Adding/Editing Users

During the initial setup, one administrative user is created. Using the credentials specified during the setup, you can log into the Nessus GUI. Once authenticated, click on the “Users” heading at the top. To create a new user, click “New User” on the upper right. This will open a dialog box asking for required details. Input the username and password, verify the password, and determine if the user should have administrator privileges. If a user account needs to be modified, double-click on the user.

You cannot rename a user. If you want to change the name of a user, delete the user and create a new user with the appropriate login name. To remove a user, select the check box next to the account on the list, select “Options” on the upper right, and then click “Delete User” and confirm.

A non-admin user cannot upload plugins to Nessus, cannot restart it remotely, and cannot override the max_hosts/max_checks setting in the configuration section. If the user is intended to be used by SecurityCenter, it must be an admin user. SecurityCenter maintains its own user list and sets permissions for its users.

In the next article, we will cover more Nessus configuration options.

External Links:

Nessus home page on www.tenable.com

Nessus on Wikipedia

Nessus Vulnerability Scanner: An Introduction

Nessus

Introducing the Nessus Vulnerability Scanner

Modern computer networks have multiple potential areas of insecurity. How do you protect all these avenues of attack? You might feel that protecting your network is an impossible situation. You could spend all day, every day, just checking for these security holes manually. Even if you tried to automate it with scripts, would would seem to take dozens of programs. Fortunately, there are packages out there called vulnerability scanners that will automatically check all these areas and more.

Nessus is an excellent program. It is a great example of how well open source projects can work, although the project has been since been changed to a proprietary (closed source) license. [The Nessus 3 engine is still free of charge, though Tenable Network Security, the company founded by Nessus creator Renaud Deraison, charges $100/month per scanner for the ability to perform configuration audits for PCI, CIS, FDCC and other configuration standards, technical support, SCADA vulnerability audits, the latest network checks and patch audits, the ability to audit anti-virus configurations and the ability for Nessus to perform sensitive data searches to look for credit card, social security number and many other types of corporate data.] It is robust, well documented, well maintained, and the premiere vulnerability scanner. Nessus has consistently rated at the top of all vulnerability scanners, commercial or noncommercial. This is amazing when you consider its competitors 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.


Even as Nessus 3 and subsequent versions went closed source, the Nessus 2 engine and a minority of the plugins are still GPL, leading to forked open source projects based on Nessus. Tenable Network Security has still maintained the Nessus 2 engine and has updated it several times since the release of Nessus 3. The current stable version of Nessus is 5.2.1 (released May 7, 2013).

Nessus currently offers over 2000 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.

You can turn off whole categories of tests if they do not apply or if you are worried they could be dangerous to your systems, or you can deactivate individual tests if you have it 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.

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 be 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 Window clients available, with projects to create additional ones ongoing. These is also now a web client interface available, which makes Nessus truly platform independent (at least on the client end).

In the next article, we will continue our discussion of Nessus and its features.

External Links:

Nessus home page on www.tenable.com

Nessus on Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy