Remote Access

Securing Remote Access with SSL VPNs
Part 4: Adding SSL VPN endpoint controls

We continue our SSL VPN primer series by expanding our policies to assess endpoint security state and safeguard access from unmanaged devices.

by Lisa Phifer VP Core Competence, Inc. [July 10, 2008]

Series Summary
Securing remote access with SSL VPNs

Part 1: Reinventing remote access
Part 2: Deploying an SSL VPN appliance
Part 3: Defining SSL VPN access policies
Part 4: Adding SSL VPN endpoint controls
Part 5: Using SSL VPN access methods

Earlier in this series, we used the SonicWALL Aventail EX-1600 to configure a demo SSL VPN to secure access by staff, suppliers, and customers (see parts 1, 2, and 3). Granular policies let us deliver very selective access to these entirely different communities, through a single SSL VPN appliance.

But how can we avoid letting staff access sensitive resources when logging into our VPN from high-risk public PCs? And how can we evade malware that might live on supplier and customer devices we cannot control? Here in Part 4, we augment our policies to deal with threats posed by unmanaged and non-compliant endpoints.

Endpoint threats
ISP-Planet readers may recall last year's Network Access Control (NAC) series. NAC architectures being developed by Cisco, Microsoft, and others can stop non-compliant or infected local users that try to connect inside corporate networks. In fact, NAC builds upon several SSL VPN techniques that were originally created to safeguard remote users connecting from outside corporate networks. (As network perimeters evaporate, some argue that SSL VPNs could support both needs.)

Malware is growing more malicious and pervasive. Companies simply must find more effective ways to stop malware from entering their networks. To help you wage this war, SSL VPN products can perform security checks at login, provide a safe environment throughout the VPN session, and clean up at logoff.

Whether and how endpoint controls work can depend on device type, operating system, browser type and settings, administrative privileges—and of course SSL VPN product, third-party endpoint security programs, and their configured policies. Let's illustrate a few key concepts by applying a related EX-1600 features to our demo VPN policies.

Start me up
Many SSL VPN appliances use the browser to conduct pre-admission endpoint checks. This process starts from the moment the user opens a web browser or launches a persistent SSL VPN agent.

Recall from Part 1 that SSL VPN users connect (at least initially) by browsing a web portal, hosted on the appliance. That page is protected by SSL; the appliance's server certificate lets users verify that they landed on a legitimate portal. This all-important step is frequently overlooked. During SSL VPN deployment, buy your appliance a certificate issued by a root CA trusted by all browsers, or install your own trusted CA's certificate on every user's device. We used a self-signed cert for our demo, but never do this for a production VPN accessed by unmanaged endpoints.

What comes next depends upon SSL settings and Realm / Authentication Server. When a user establishes an SSL session to your portal, tunneling protocols and parameters are negotiated, session keys are generated, and user sub-authentication is conducted over the encrypted SSL tunnel. For example, companies in regulated industries may disable less-secure SSL protocols and ciphersuites, like SSLv3 or RC4 encryption (see figure).

Those worried about password sharing may prefer an Authentication Server that supports tokens (e.g., SecurID) or client certificates. For our simple demo, we authenticated users by login/password. To deter keylogger password capture (a significant risk on public PCs), the Aventail Workplace portal gives users the option of entering text logins and passwords by clicking on a virtual keyboard (see figure).

Go to page two: Classify me >