Proactively Protecting VPN with Nessus
Edward L. Haletky
A growing number of users telecommute from a remote locations into a corporate
network using some form of a Virtual Private Network (VPN). Although a VPN connection
can secure the client's direct connection with the corporate network, the company
typically has very little control over the security environment in which the
client operates. The airtight security of the VPN is of little benefit if the
remote host is itself insecure. A variety of security options are available
for telecommuters, ranging from hardware routers and firewalls (Linksys, NetGear),
to software firewalls (iptables, blackice, sygate home network, etc.), to managed
firewalls (Sygate, Symantec). In some cases, the remote user might have only
a single computer with little or no security.
This article describes a system I created that allows a network official to
assess the security of the remote network through which a VPN connection is
initiated. I put together this tool using Linux, Apache, the security assessment
tool Nessus, a job scheduler, and a bit of scripting. This tool works well on
my network, but if you plan to implement something like this, you need to think
through how it fits within your corporate security framework. In other words,
please consult your IT department before implementing this tool.
Scanning Tool
Sys Admin has covered the vulnerability scanning tool Nessus in several
previous issues. I will not provide a full tutorial on Nessus in this article.
(For more information on Nessus, see "Using Freeware Vulnerability Scanners"
in the April 2001 Sys Admin, http://www.sysadminmag.com or visit
the Nessus Web site: http://www.nessus.org.) Nessus operates as a daemon
process that:
- Accepts a request for a security assessment.
- Performs a scan on the target address referenced in the request.
- Outputs a report that highlights any vulnerabilities associated with the
target address.
I built this remote scanning system around Nessus, however, I faced several
complications. For security reasons, I wanted to make this scanning tool available
only to VPN users. This requirement creates something of a paradox, since the
whole purpose of the scan is to identify problems with the external (Internet-facing)
network, which is invisible to resources accessed through the VPN connection.
The solution is shown in Figure 1. The remote user
resides behind some firewall of unknown quality. (Actually, the object of the
exercise is to determine the quality of the remote user's firewall.) An example
of this situation is a telecommuting user behind a home office-style firewall
device attached to the Internet through a cable modem. Another example is a
remote user connecting to the corporate network through a firewall-protected
Internet connection in a hotel room. In some cases, of course, the remote user
might not have any firewall at all, in which case the scan will apply directly
to the user's own Internet-facing address.
The remote user initiates a VPN connection to the corporate network. The VPN
creates a virtual network device that operates through the physical connection
but uses a separate (typically non-routable) IP address associated with the
internal corporate network.
Once the remote user is validated for the VPN, the user accesses a Web page
used for initiating a network scan. The Web page is accessible only to the internal
corporate network, however, the Web page uses an HTML inline frame <iframe>
to reference the actual Nessus server, which resides outside the corporate firewall.
The scan is therefore initiated from the VPN connection, however, since the
Nessus server has an external address, the referral forces the remote host to
access the Nessus server through the external network, and the Nessus server
is therefore able to scan the remote user's physical connection to the Internet.
Note that the system depicted in Figure 1 only
works if the remote client is configured to route internal traffic through the
VPN and external traffic through the external network. I will not go into all
the possible ways to achieve this configuration. On my network, I configure
the external network as the default route and specify the VPN route for the
corporate address range. An alternative approach is to make the VPN route the
default and then specify the external network for the address of the Nessus
server. The most important requirement for this type of tool is "ease of use".
The tool must be easy to use and documented sufficiently for the average non-technical
employee to understand and use it. (Part of the plan was for non-technical remote
users to initiate their own scans if they moved to a new location or made a
change to their network.) Another requirement was for someone, or a group of
people, to be designated to review the results of the security scan and make
recommendations.
How It Works
The system depicted in Figure 1 consists of several
components that do not require much explanation. You must configure a firewall,
establish a VPN connection, set up a Web server, and set up the Nessus server.
I refer you to worthy treatments of these topics elsewhere in the literature.
The essential elements of this system are the interaction of the Web server
on the internal network with the Nessus server on the external (Internet-facing)
network and the interaction of the Nessus server itself with its own Web interface.
As the preceding section describes, the trick is that the remote user thinks
he is initiating the scan through the VPN connection and all authentication
takes place through the VPN, but the scan actually occurs on the open Internet
and targets the user's physical Internet connection.
The key to the system is that the internal Web server, through which the user
initiates the scan, references the Nessus server through an inline frame <iframe>
element. The Syntax may vary depending on your configuration, but in this case,
the Nessus server is referenced as follows in from the internal Web page:
<iframe height=250 scrolling=no frameborder=0 \
src=http://scannerAddr/~doscan/doscan.html></iframe>
The <iframe> element embeds a Web page within a sub-window. When a user
accesses the sub-window, the user's browser is instructed to open a connection
to the URL referenced in the <iframe> statement. In this case, since the
reference is to an external Web address, that connection passes through the physical
network and the Nessus server obtains the IP address of the remote user's firewall
or NAT device.
The URL referenced in the <iframe> statement is to the Nessus server's
own Web interface. The Nessus server's Web interface form obtains the user's
external IP address, username, and email address. Control then passes to a CGI
shell script, which writes a job submittal script to run the scanner. The new
script contains a command to scan the IP address and another command to mail
the results to the appropriate experts. Then, the CGI script calls a queue submittal
command of the job scheduler. The job scheduler runs one scan at a time in order
of submittal.
The entire process is depicted in Figure 2. Note
that a second Web interface provides a simple queue status form (see the "Status"
arrow to the right of the "Allow Referrer" diamond in Figure
2). The queue status form runs the queue status command available to the
job scheduler and displays the results.
After the scan, the scan results are mailed to a security consultant. The
security consultant interprets the results, responding with suggestions or a
pat on the back to the user who requested the scan. If problems appear, the
user performs a follow-up scan. Interpretation of the scan results is almost
an art form, which is why results are not just mailed to the user without explanation.
We tried mailing the results directly to users without any comments, but that
approach lead to confusion. As an aside, on the job submittal, a message states
"Your security scan results will be mailed to you after review. Bad news will
get a faster response than good news." This allows us to concentrate on the
truly important security issues.
Use of the security scanner is recommended any time a firewall change is made
(no matter how insignificant), when new security hardware or software or new
Internet-related programs are installed, and at least once a quarter to stay
on top of the latest attacks. The Nessus scanner is updated daily with the tools
to test for the latest vulnerabilities. If a major vulnerability is reported,
then a request to test all firewalls is made to the community.
Could the scan request be automated? Yes, however, there are problems with
that as well. Since the Internet facing IP address can change without warning,
it is probably best that the VPN machine make the submittal in an orderly and
timed fashion -- using cron.
Configuration
The first component to configure is the Nessus server and client. The current
implementation uses v1.2.6. When a new version is made available, the tool is
upgraded and tested. A test report is created using a known set of Internet-facing
machines. By getting a baseline report with the earlier version, doing our upgrade,
and then testing with the newest version of Nessus, we should see at least the
same results.
You can download Nessus from http://www.nessus.org and install it using
the nessus-installer.sh script. Everything goes into /usr/local. To begin, add
the users who are authorized to run the software into Nessus, then start the
Nessus server and then the Nessus client to test whether Nessus will work. I
use the graphical client for these first tests, because there are often issues
with the latest configuration that require review of all the options and scan
scripts available. Additionally, I generally disable the Nmap program that could
be installed with the operating system (or separately) by either renaming the
program or removing it entirely.
Why do we disable Nmap when it is such a useful and powerful security tool?
Nmap, however useful, is the first thing Nessus will run if it's available,
even if it is disabled in the program options, as some scripts will request
it be run. This could cause an intrusion detection system (IDS) to come into
play. Once an IDS traps a port scan, it will do its magic and Nessus will report
the port as closed, causing actual vulnerability tests to assume the service
tested is unavailable. This is a false assumption, as the IDS say they are not
available if you are performing a port scan, yet they are available if you access
the actual service. So in this case, the port scan clouds the issue. Nessus
should try to detect vulnerabilities by running its >1000 security attacks
simulations without the benefit of the pre-scan. These results are closer to
reality.
After disabling Nmap and disabling those Nessus scripts that will cause machines
to crash (dangerous DoS attacks), Nessus can be configured. We then build the
system from the bottom outward testing each component as it is added to verify
the Nessus scans are still produced. Each scan should be identical to the last.
We test in the following order:
1. Nessus Graphical Client. (Run /usr/local/bin/nessus without any
arguments.)
2. Nessus batch mode client with HTML output. (Run /usr/local/bin/nessus
with appropriate arguments to specify the proper server, port, username, password,
and html setting.)
3. Expect/Tcl script wrapper around Nessus batch mode client. (Nessus has
changed to allow the password to be on the command line. This is no longer needed,
except to provide timeout capability, yet we still use Tcl to verify the IP
address to make sure a reserved IP address is not scanned.)
4. Job scheduler script created by the cgi-script. We do this outside the
job scheduler first. (The scanning cgi-script produces this script on the fly,
so we must test its effectiveness. This script should call the scanning Expect/Tcl
script then call the script to email the results.)
5. Job scheduler script run through the job scheduler. (We submit the job
scheduler script through the job scheduler. This is often using the qsub command.)
6. Running via the cgi-script. (Submit the form and make sure everything works.)
7. Verify that the referral-allow script works. (We test this by accessing
the Web form through the corporate network and outside. We should be allowed
in if coming from the corporate network and denied access or asked for a username
and password from outside.)
During the initial creation of this tool, there was only one major programming
issue to overcome. That was at Step 5 above. The Expect script would not execute
properly through the job scheduler using the Expect RPM that ships with Red
Hat version 7.1 and higher. The following error will occur with when the Expect
spawn command is issued:
executing commands from command file /usr/local/bin/doscan
Tcl_RegisterChannel: duplicate channel names
Development of this tool started around the time that Red Hat v7.0 became available
and, because it was first implemented on Red Hat v7.0, we were able to use the
RPMs from that version for Expect and its TCL dependencies. These older packages
were installed into the /var/www/7.0 directory and referenced from there in any
script that required them, namely the single Expect script.
We tested the tool using Generic NQS and OpenPBS job scheduling tools. Both
exhibited the same Expect issues. Any job scheduler could be used as long as
there is a simple job submittal command. Currently, the scanning system uses
the following software (this is also the software installation order):
1. Red Hat v8.0
2. Apache v2.0
3. modperl v1.99
4. Expect and Tcl RPMs from v7.0 installed into /var/www/7.0 (v5.31 and 8.3,
respectively)
5. Nessus v1.2.6 installed into /usr/local
6. Generic NQS (http://www.gnqs.org) installed into /usr/local and
compiled using all the defaults
7. Scripts to start and stop Nessus and Generic NQS at boot time
8. Block access to Nessus server ports from outside the bastion host
Using this proactive tool has enhanced the security partnership between virtual
office (VO) employees and security by raising the awareness of security issues
to the VO community and their managers. Even so, the security scans still require
review by a knowledgeable professional. We should discuss briefly how to read
these scans to provide good diagnostics. Additionally, all common problems and
their identified solutions are then documented clearly and concisely for the
rest of the community to implement at need.
Quantity of Data Received
In some cases, a scan will return incomplete or non-existent data. Does this
imply that the scan failed? Or was the firewall so good that it blocked everything?
This could mean both. In these cases, a re-scan is requested but only after
the Nessus server has been restarted. If the results are the same a second time
and a test scan to a known host with open ports works, then it's a good guess
that the firewall in use has no open ports and drops all incoming packets unrelated
to an established outgoing connection (D-Link DI-713P demonstrates this behavior).
Informational Reports
Informational tests from the scanner are designed to query data from the tested
host to determine which IP services are running, their creators, and version
information. For example, if you use the PPTP VPN, you may get a report similar
to the following:
Warning found on port unknown (1723/tcp)
Firmware Revision:3224
Host name:
Vendor string:Microsoft Windows NT
Informational requests do one of two things. First, they tell a wily hacker that
there is something on the port and what that something is; and second, they give
version information that can be further used to try known vulnerabilities against
your system. When looking at this data, it's important to determine what information
could be harmful to report and what does not matter. This is a judgment call,
but personally I dislike reporting anything about my hosts. Specifically,
I believe reporting anything about the security measures in place puts you at
risk for further attack. In the case of the PPTP information request output, I
would change the firewall to not ever report that information. No one needs
to know whether I am using IPSec, PPTP, or some other VPN. As for DNS, HTTP, ftp,
telnet, and SMTP servers, some are reconfigured to not give out any other
information and others require investigation to determine whether these services
need to be available externally. In most cases, they are not needed externally
for corporate use. When such things are needed for corporate or personal use,
the partnership comes into full swing and the VO and security employees work together
to deny this information to hackers or move the services to bastion hosts. No
personal service is allowed to run on corporate computers.
Security Warnings
Security warnings should not exist in the scan output and should be fixed
as soon as possible, unless you can prove that the attack will fail. In some
cases, the warning is directed toward a known problem with a service running
on a specific operating system and the warning appeared because it was running
on another. For example, SMTP warnings will occur when running a form of sendmail
on a VMS operating system. These warnings occur because the expected response
from the SMTP server was not received. Since VMS does not really run
sendmail in this case, we must prove that the vulnerability does not exist by
running more exhaustive tests and then documenting the false positive.
Vulnerabilities
Vulnerabilities must be fixed. Any vulnerability that appears cannot
be ignored, and must be fixed. In rare cases a vulnerability is not a
vulnerability but ignorable, like SMTP vulnerabilities on VMS. But, these should
never be approved without research and a written report with a detailed explanation
as to why this is not a vulnerability.
Conclusion
In the future, this tool will include methods for automating the scan process
by not requiring human intervention. To do this, tools will be added to take
advantage of the cron-like daemons available to most modern operating systems
to force a scan at regular intervals (e.g., whenever Internet software is installed
or when firewalls change). This can be a daunting task for the mixed bag of
operating systems that may be scanned at any time.
By forming a partnership between the remote user and security employees, raising
awareness, and providing a proactive testing tool for VPN endpoints, we have
helped to create a careful and concerned community of virtual office employees.
This continual testing of firewalls provides the virtual office community a
means to lobby for even better tools and gives them a voice in requirements
for any security feature to be implemented. Virtual office employees and telecommuters
are no longer lambs left unprotected from the wily coyote.
Edward L. Haletky graduated from Purdue University in 1988 with a degree
in Aeronautical and Astronautical Engineering. Since then, he has worked programming
graphics and other lower-level libraries on various UNIX platforms. He currently
works for Hewlett-Packard in the High Performance Technical Computing team and
as a security consultant for the virtual office community.
