Monday, April 25, 2011

Nessus scan




local vulnerabilities. Nessus looks at specific well-known security vulnerabilities, but
also does generic checks, such as looking for file permissions or sensible configura-
tion files.
The login and password information are part of the policy. This means that if you
want to connect to servers that have different passwords, you have to create a new
policy for each of them. In the Windows client, the credentials are accessible after
clicking on Edit Settings, as shown in Figure 3-2.
Network Scan
You can run a scan from inside your network to get as much information as you can
on potential vulnerabilities or weaknesses. Or you can scan your network from the
outside to understand how an attacker sees it. You want to do a thorough analysis of
all servers at the interface between your local network and the Internet, usually your
DMZ zone: mail server, HTTP server with web applications, and VPN server.
You can start a scan simply by inputting the IP address or hostname of the targets.
Nessus proposes four types of scan:
Nonintrusive scan
This is best suited to scan targets in a production network. A scan of one target
on a 100 MB network from a Windows XP client takes about 25 minutes.
Intrusive scan
This enables all plug-ins, including dangerous checks that can harm the target.
This scan takes about 30 minutes for one target.
Predefined policy
Use a predefined or customized policy defined earlier. Check the section “Policy
Configuration” later in this chapter for more details.
New policy
Define a new policy to use for the scan. Check the later section “Policy Configu-
ration” for more details.
If your goal is to test a remote server, do not forget to turn off any anti-
virus, firewall, or other security software running on the Nessus server.
This software may drop some of the traffic generated by Nessus.
Nessus first does a port scan to identify the services running and the target operating
system (see Chapter 2). It uses a combination of features to determine what the tar-
get is running. Here is what it tries to discover:
• What services are running? For example, SSH and NTP are more common on a
Unix machine, NetBios and MS-RPC are more on common on Windows.
• How the target reacts to malformed ICMP packets.
• SNMP information.
• Information gathered from an NTP service.
To get more information about operating system fingerprints, check out Chapter 2
and examples related to p0f (see Section 4.4).
The port-scanning phase is very important. It is used by Nessus to know what plug-
ins are relevant (Apache or ISS plug-ins for a web server, Linux or Windows vulnera-
bilities, etc.), and what service is running on what port. Nessus can detect services on
nonstandard ports.
If you scan a large network, it is more efficient to place one Nessus
server per network segment.
There could be false detection if the target is behind a Port Address Translator, since
each port could correspond to a different operating system. A firewall between the
Nessus server and the target could drop the malformed ICMP traffic. This would
then lead in false positives in vulnerabilities found by Nessus. If you know the details
of the machine you are scanning, it is possible to tell Nessus what operating system
or services are running on the host in a policy (see the section “Policy Configura-
tion” later in this chapter).
If you run a web server with virtual hosts—that is you have different web domains
with the same IP address—you need to indicate the list of virtual hosts to Nessus.
Where you enter the IP address of the target, add the hostnames between brackets:
192.168.1.1[domain.com domain.net domain.org]. You can save it in the address book
to avoid typing a long list all the time.
If you happen to scan a network printer, the printer may print garbage
characters indefinitely. It often happens with network printers using
CUPS. You should exclude the IP address of all your network printers.
Scan Results
At the end of a scan, Nessus generates a report that provides a list of all open ports
and the potential risks associated. If you use any encryption (SSH, HTTPS, IMAPS,
SMTPS), Nessus analyzes the algorithms allowed and warns you if any weak encryption mechanism are allowed (see Figure 3-3).
If you run a web server with virtual hosts—that is you have different web domains
with the same IP address—you need to indicate the list of virtual hosts to Nessus.
Where you enter the IP address of the target, add the hostnames between brackets:
192.168.1.1[domain.com domain.net domain.org]. You can save it in the address book
to avoid typing a long list all the time.
If you happen to scan a network printer, the printer may print garbage
characters indefinitely. It often happens with network printers using
CUPS. You should exclude the IP address of all your network printers.
Scan Results
At the end of a scan, Nessus generates a report that provides a list of all open ports
and the potential risks associated. If you use any encryption (SSH, HTTPS, IMAPS,
SMTPS), Nessus analyzes the algorithms allowed and warns you if any weak encryp-
tion mechanism are allowed (see Figure 3-3).
You may see a list of more specific issues (such as a list of vulnerable software ver-
sions that you run) or known vulnerable CGI scripts.
All these results should be double-checked; there are often a lot of false positives:
• A firewall or other security device may have detected the ongoing scan. My firewall can detect the scan after a few seconds and blocks all traffic generated by
Nessus. The report shows a lot of open ports that do not exist on the target
because it misinterpreted the dropped packets (see Chapter 2). Nessus may also
display that it was able to crash the target when the traffic was actually dropped
by the firewall.
• Some vulnerability checks are too superficial. Sometimes, a plug-in looks for the
version in the banner only. This may not be enough to know whether the service is actually vulnerable. It is possible that the server has been patched without changing the software version, or that the vulnerable options are not
enabled. See “Plug-in Code Example” later in this chapter to understand how to
verify what a plug-in is actually doing.
• If a service or server is incorrectly identified, checks that do not apply to the
actual version may give wrong results.
The scan results highlight potential issues that should then be checked one by one.
This is a good base to start tightening up the security of the servers running on a network. But like all the tools described in this book, some manual work is necessary to
analyze the results, and other security checks with other tools should be performed.
All reports are automatically saved. They can be reviewed later. You can also com-
pare two reports to see whether you actually did increase the security of the target
between the last scan, or whether the target was modified since the last scan.
Policy Configuration
Instead of running a full scan, it is possible to customize the areas that should be
checked. By reducing the number of checks that are done and by tuning the default
settings, you both reduce the duration of the scan and improve its accuracy.
The settings are associated with a policy. This means that each target that requires
special settings (different passwords for example) requires its own policy. You can not clone a policy; this makes Nessus hard to use accurately on a large networks.
To modify the default settings, create a new policy and click on Edit Settings. Under
the General tab, you can select how thorough the test will be. For a full scan, unselect
Safe Check and select “Thorough tests.” For more verbose output (but also more false
positives), select Paranoid for report paranoia and “verbose Report” for verbosity.
The Credentials tab contains settings used for local vulnerability checks. See “Local
Vulnerabilities” earlier in this section for more information.
The tabs for Others and Web contain login and password information for different
services, as shown in Figure 3-4. This information is needed to perform all the tests.
If you have subscribed to the Direct Plugin Feed, you can add your compliance policy files under the Compliance tab. These files describe your company policies for
different OSs. Nessus can check whether the targets comply with them.
You can select the list of plug-ins to enable by clicking Edit Plugins. By default, all
plug-ins shown are enabled. However, it you selected “Safe checks” in the settings,
the plug-ins considered dangerous (denial of service, exploitation of a vulnerability,
etc.) are not run.