Client-side security considerations for SSL VPNs

Clientless SSL VPNs may be attractive for their lack of software, but they still require client-side security measures.

This Content Component encountered an error

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.


MORE INFORMATION ON VPNs:
  • Join Lisa Phifer on March 30 at Noon ET for an interactive discussion on developments in VPNs. Pre-register for this live webcast.
  • Visit our Featured Topic, VPNs: IPSec vs. SSL.
  • Browse our collection of Best Web Links on VPNs.


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 integrated 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.

Stop problems before they start

A smaller window of opportunity helps, but is that enough? Depending upon your business risk, additional measures may be appropriate to secure your VPN.

  • To adjust permissions to reflect threat level, look for products that support policies that differentiate between company-administered hosts and all others. For example, Nokia's Secure Access System can restrict access to applications and features, depending upon the system from which a VPN session is initiated.
  • To defeat password compromise by keystroke loggers and session recorders, use one-time passwords or two-factor authentication. Options are more limited on public PCs -- for example, USB tokens or biometric devices require client software -- but other mobile methods are widely supported (e.g., RSA SecurID, S/Key).
  • To defeat session data capture and client-side malware, look for VPN products that integrate client-side security checks into access policies. A growing number of VPN products now offer scan-on-connect. Examples include Microsoft Windows Server 2003 Quarantine, CheckPoint's VPN-1 SecureClient (integrated with PestPatrol and others), Cisco's VPN Client (integrated with ZoneLabs' Integrity), Aventail's End Point Control (integrated with Bluefire and others), and Neoteris (integrated with WholeSecurity and others). Scan-on-connect may ensure that desktop security measures are active and up-to-date and can sometimes detect the presence of malware, preventing VPN session establishment by compromised hosts. Although many do require installed client software, some are "clientless" -- for example, Zone Labs' download-on-demand host integrity checker.

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.

About the author
As owner of consulting firm Core Competence, Lisa Phifer advises companies regarding security needs, product assessment and the use of emerging technologies and best practices. She has been involved in the design, implementation and evaluation of security and network management products for more than 20 years.


This was first published in March 2004

Dig deeper on VPN design

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close