A five-point strategy for secure remote access

By George Wrenn
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 zero-tolerance 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.

Simple Steps to Securing Your SSL 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 manipulation. 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.
Client-side security considerations for SSL VPNs
By Lisa Phifer, Vice President, Core Competence, Inc.
Companies tired of VPN client software installation and configuration are being increasingly drawn to "clientless" solutions like SSL VPNs. However, using a browser-based VPN to go "clientless" still requires client-side vulnerability analysis and mitigation.
The lure of SSL VPNs
According to Frost and Sullivan, the SSL VPN market exploded in 2002, growing at a compound annual rate of 49% through 2010. The big draw? SSL VPNs leverage browsers present on nearly every desktop and handheld to avoid adding software. Security policy can be largely dictated by the VPN gateway, reducing remote configuration.
Circumventing these IT pain points should cut the cost of remote access. What's more, browser-based VPNs enable remote access from more locations. Travelers can use public PCs at business centers and Internet cafes. Teleworkers can use home PCs without IT oversight. Business partners can use PCs administered by other companies. Permitting remote access from these venues increases convenience, availability and productivity. But, there's a catch: loss of IT control over the hosts used for remote access.

Leave nothing behind

Most public PCs contain traces of past user activity: Outlook inboxes filled with private e-mail, browser caches containing Webmail text and password-laced cookies, and file attachments saved to temp directories. Leaving this sensitive data behind on public PCs poses considerable risk, but relying on users to clean up after themselves is a very bad idea. Many have no idea what they leave behind; even those who know how to wipe their tracks clean make mistakes.
To address this risk, most SSL VPNs take steps to automatically clean up after each remote access session, no matter who owns the remote PC. Features to look for when considering SSL VPN products include:
• Secure logout-Forced session disconnection and browser window close, typically based on centrally defined inactivity or duration timeouts.
• Credential scrubbing-Deleting cached credentials at session end or preventing them from being cached on the client in the first place.
• Temp file clean up-Deleting files created during the session or blocking their creation, including cached pages, offline content and downloaded programs.
• Cookie blocking-Removing cookies at session end, or better yet, no personally identifiable or reusable information written to cookies during sessions.
• Auto forms completion disabling-Avoiding client storage of data entered in private Web page forms that might otherwise be visible to subsequent users.
• Personal information profile disabling-Preventing access to, and use of, user data commonly integrat-
ed with browsers, like Outlook Address Book entries.
• Browser history removal-Stopping VPN URLs from being used as a launch point for common Web server
attacks (e.g., password-guessing, DoS floods, script injection).

Prevent tunnel compromise
Post-session clean up is essential, but it doesn't go far enough. PCs available for public use in cafes, airports and conference centers are readily accessible to strangers 24/7, greatly increasing the risk of compromise. Attackers can install packet-capture tools, keystroke loggers and even desktop session recorders to obtain usernames, passwords and private data. Spyware, remote access Trojans and denial-of-service zombies can be implanted to probe or attack corporate resources during active VPN sessions.
To prevent IPsec/L2TP/PPTP VPN tunnel compromise on company laptops, most companies mandate client-side personal firewalls, antivirus software and up-to-date security patches. These measures are typically part of the "remote access bundle" that IT installs and configures on every host, either directly or by supplying software and instructions to employees. For "clientless" access, this may not be practical or possible.
Some argue that SSL VPNs pose less risk because network VPNs use secure tunnels to connect remote hosts to private networks, while SSL VPNs typically connect individual client applications to private servers. A narrower window of opportunity can eliminate some vulnerabilities-for example, preventing Trojan access to other systems and ports. However, this really depends upon the product and policy granularity.
To implement more granular policies, look for products that can define access rights based not just on application, but also on individual commands (e.g., permit read but not write or delete) and user/group-specific URLs and objects (e.g., folders, accounts). Granularity is a double-edged sword: Look for incremental or hierarchical grouping features, and design your policies with both maintenance and performance in mind.
These are just some of the steps you can take to address client-side security concerns for network-level and browser-based VPNs. Keep in mind that all VPNs pose some risk; effective VPN deployment requires understanding and managing inherent vulnerabilities. Going "clientless" with an SSL VPN may avoid new client-side software, but it still requires client-side vulnerability analysis and mitigation.