Client-side security considerations for
SSL VPNs
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.