Proactively Protecting VPN with Nessus

Edward L. Haletky

A 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 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

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

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.