SSL VPN Virtuoso
Organizations seeking remote-access solutions on a small scale can turn to unified threat management firewalls with built-in Secure Sockets Layer virtual private network functionality.
Enterprise-class appliances from manufacturers such as F5, Juniper Networks and SonicWALL incorporate large-scale remote-access solutions. But if you support fewer than 5,000, 500 or even 50 users, you might consider smaller-scale security devices from manufacturers such as Cisco, Fortinet and NETGEAR, which have a less comprehensive feature set than their bigger brethren, but also a lower price tag and easier management. What follows is some advice for using small-scale SSL VPNs effectively.
1. Compensate for simpler remote-access controls using UTM devices.
Midrange SSL VPN solutions have more limited capabilities to lock down user access and enforce endpoint security rules. This brings us back to the old days of IPSec remote access: full network extension without many controls. When your SSL VPN is built into a unified threat management appliance, you can (and should) apply antimalware and content filtering to any traffic coming in through the SSL VPN, even if you’re not using those features anywhere else. This gives you additional protection from the population most likely to be infected: home and traveling users.
2. Integrate with your directory from Day One.
You probably are already running Active Directory (or something similar). Tap that investment. Every SSL VPN can use your existing directory for user authentication, either through Lightweight Directory Access Protocol or RADIUS. It will take a few extra minutes to set up, but it’s worth it. Users will have fewer passwords to change (or forget) and you’ll have a single point of control when you need to shut down an individual user.
Most SSL VPNs will also allow you to use your group structure from your directory to differentiate among types of users. For small deployments, that might be overkill. However, you should define a broad group in your directory, such as “SSLVPNUsers,” that contains everyone allowed in through SSL VPN remote access. This helps ensure that any test account or service account you create with a less-than-stellar (or blank) password won’t be an inadvertent hole into your network.
While you’re doing that, don’t forget to also configure the SSL VPN to push logs and accounting data to your existing SYSLOG or RADIUS servers.
3. Install the remote-access client.
When building a smaller SSL VPN solution, focus on network extension as a way to bring in remote-access users. Other access methods, such as reverse proxy to web applications, might seem simpler and more secure, but these benefits are often outweighed by management and maintenance difficulties. Our testing at Opus One has also shown that midrange products often don’t have the same web application compatibility as high-end products.
All this adds up to requiring a piece of client software on the remote user’s computer.
Do everyone a favor and pre-install that client before someone needs to use the VPN. You’ll have the opportunity to test compatibility, and you can deal with any issues related to administrator rights or client configuration ahead of time.
If the SSL VPN you choose also offers a “dissolvable client” (one loaded through the web browser every time someone connects), run away screaming from that feature — unless you enjoy midnight support calls or walking someone through an upgrade of their browser or Java virtual machine over a Wi-Fi connection.
4. Keep mobility in mind.
As you explore remote-access solutions, don’t forget the new generation of mobile devices: smartphones and Linux-based netbooks. Mobility is not just a buzzword; it’s a new way of doing business. You may not see the need to give an iPhone access to the VPN today, but that doesn’t mean the need won’t pop up tomorrow. If your SSL VPN can’t handle non-Windows devices — and many existing SSL VPN products can’t — be ready with an answer when your boss comes in and wants to know what you’re going to do to about it.
