Managing secure remote access is a tough job. Because remote systems may directly connect to the Internet rather than through the corporate firewall, they pose an increased risk to your network environment. Virus and spyware protection, and a general VPN network policy isn’t enough to keep these systems—and the network they connect to—safe. Here are five best practices for providing secure remote access.

1. Software controls policy

Create a policy that defines the exact security software controls that must exist on systems with remote access.

For example, you may need to spell out that antivirus, anti-spyware and desktop firewalls must be installed and configured in a specific manner with the latest signatures, along with which vendors are acceptable. The best practice is to distribute the policy along with the connection setup or similar instructions for end users. Often a zerotolerance policy is best for endpoint security. End users should meet a set of guidelines before connecting to the network. No AV, antispyware and desktop firewall? No remote access allowed. The policy should also spell out what ports and services may be exposed on the system.

2. Endpoint security management

Choose a vendor that offers comprehensive endpoint security management and policy enforcement as part of their VPN or remote access solution. It is best to mandate that all remote users use the enterprise sponsored VPN client. That’s the only way you are going to get true policy compliance and assurance of endpoint security posture. Your chosen remote access solution should be able to refuse connections for endpoint systems that do not meet the policy compliance checks. Ideally, the solution should tell end users which items are out of compliance so they can remediate the situation prior to attempting to reconnect. This cuts down on help desk calls.

3. Enforce corporate policy compliance

Inform end users that corporate security policy extends to their remote desktop when connected to the enterprise network. For example, no file sharing and other disallowed use while connected to the corporate network.

4. Reporting features

Reporting on end user compliance is critical. Most of the solutions mentioned above offer reporting capabilities to keep admins updated on the status of the connecting endpoints. Depending on the number of users you have to manage, it may be wise to set up alarms that e-mail admins when a machine that is significantly out of compliance tries to connect. In some cases administrative intervention may be warranted — especially when other access methods to the network may exist.

5. Periodically review policy and reports

Every couple of months, review policies and reports to identify trends and patterns in access violations. This is important to ensure that the policy and technical controls are addressing your remote access security needs. If you find trends in access violations, add or modify policies accordingly.

6. Pen testing your VPN

A Virtual Private Network (VPN) is like a large sign, saying “Sensitive Data Here.” Hackers know that when they’ve found a VPN, they’ve hit the jackpot, because it means somebody is trying to secure something confidential.

Therefore, like any other gateway, your VPN needs to go through a thorough penetration test to check for vulnerabilities. It’s easy to overlook VPNs when pen testing your network, as it’s often assumed that they’re the most secure part of it. But, they’re not and they’re a magnet for hackers.

Pen testing a VPN is straightforward, and there are some common tools for the job. It’s not much different from the rest of your pen testing routine and should be part of it. There are two types of VPNs: IPSec and SSL. Which VPN you are running will determine how you conduct the pen test. Regardless, there are three basic steps to pen testing your VPN:

1. Scout the terrain and plan the attack.
2. Exploit known vulnerabilities—then close or patch them.
3. Test for default user accounts—then shut them down.

To scout the terrain, run a simple port scan. This will reveal whether you are running an IPSec or SSL VPN. Even though you already know that, a port scan is a good defensive exercise that mirrors the steps of a potential intruder. Scan the network perimeter where the VPN may be located. The only caveat is to watch for bounced packets if the VPN is part of a combo with a firewall. If the scan shows that port 500 is open, the VPN is IPSec. Port 500 is the standard port for the Internet Key Exchange (IKE) protocol used for the key exchange required in IPSec. If the scan shows port 443 to be open, the standard port for SSL, then the VPN is obviously SSL. An SSL VPN uses the same port as any other SSL communication.

The exploit phase of the test must go in one of two directions. Testing an IPSec VPN is very different from testing an SSL VPN. The IPSec VPN is network-based, while the SSL VPN is Web-based. In fact, the SSL VPN is essentially a Web application and should be tested as such.

For IPSec VPNs, NTA Monitor has a tool called IKE-scan, which can fingerprint many VPN vendors and models. With that information, a hacker can search the Web for details of attacks against specific vendors.

Exploits have been found and posted for Cisco, Nortel, Check Point and Watchguard devices. The tool can’t fingerprint every VPN model, but it can reveal the type of authentication used in the VPN – useful information for a prowling cracker.

Other tools, like IKEProbe and IKECrack, take advantage of weaknesses in the pre-shared key (PSK) authentication used in IPSec VPNs. The hashes captured by these tools can then be run through ordinary password crackers, such as Cain and Abel, to steal passwords for malicious access to the VPN and, of course, the corporate network. For SSL VPNs, the same tools for scanning a Web application can be used. Tools can check for Web threats like cross-site scripting (XSS), SQL injection, buffer overflows, weak authentication and old-fashioned parameter manip-ulation.

The scan results can be followed by either automatic or manual tests to verify the vulnerabilities. Again, an SSL VPN is just a Web application. Test it like one.

Finally, IPSec VPNs, like any firewall or network device, have default user accounts. These accounts are used for initial installation and aren’t needed after that. Either remove them or change their names, where possible. The same goes for any administrative accounts used for routine maintenance. Change default passwords.

A VPN isn’t sacred. It’s a network device like any other with flaws, blemishes and vulnerabilities. But, with proper pen testing, it can be hardened and secured, and effectively protect your network gateway.

Major Jane Raymond USAFA

MER/IT

UNCLASSIFIED / FOR OFFICIAL USE ONLY Information contained in this document is designated by the Department of Defense (DoD) as For Official Use Only (FOUO) and may not be released to anyone without the prior permission of NHQ CAP and/or CAP-USAF.

LINKS OR REFERENCES TO INDIVIDUALS OR COMPANIES DOES NOT CONSTITUTE AN ENDORSEMENT OF ANY PRODUCT OR SERVICE YOU MAY RECEIVE FROM SUCH SOURCES.

Copyright (c) 1993-2007 TSR Computers Inc. All rights reserved. For information on this website please email webmaster@mer.cap.gov