Advertisement

An Inside Look At Secure Access Gateways

The confusion surrounding secure access gateways is understandable. More than 20 vendors market SSL-based, access control systems. And while their products sound similar, the underlying architectures and available system capabilities differ greatly, vendors often use different terminology to describe identical features, and a steady stream of new products, enhancements and marketing messages ensures that market knowledge quickly becomes outdated.

Starting in mid-2006 Breakaway Security adopted "Secure Access Gateway" as the general term for this class of products, indentified several product categories within it, and renamed our portal (formerly SSL VPN Central). This was done to recognize that while all these products employed SSL VPN technology, many had already added IPSec VPN services AND evolved down different paths in terms of "gateway" functionality. More specifically, important differences have emerged with the addition of advanced network and application level protections, downloadable endpoint security services and "network access control" functionality which enforces security policy compliance at the level of user devices. Also, a few systems are now touted as capable of supporting both remote and local access. To understand our current terminology please view the Secure Access Gateway Product Categories web page.

Throughout Secure Access Central there are hundreds of references to SSL VPN gateways that are a legacy of our earlier usage of this term. Instead of changing all these references we ask that you substitute "secure access gateway" in your mind whenever you encounter the other reference.

On this web page, we introduce a reference model for secure access gateways ("Gateways") which serves as an evolving framework for describing product capabilities. For an understanding of the significant changes now occuring in these system we invite you to view the presentation "Key Trends in SSL VPNs".

 

Remote User

Internal Application & File Servers

Figure 1- Secure Access Gateway Reference Model

Part of the "fuzziness" that surrounds the understanding of Gateways is due to the complexity of these systems. They are loaded with features and these capablities can be viewed from multiple perspectives. For example, a "user" can be an employee who wants to access email from his own laptop, a network administrator who needs to ensure the Gateway operates properly on the enterprise network, a security manager who wants to know that security policies are being enforced and not circumvented, and administrators who are charged with tactical activity of privilege management. Each person with a different role will evaluate and use a Gateway in a different way.

Refer to the reference model in Figure 1 as you read the following sections and keep in mind that while all gateways provide similar functions today, at the feature and implementation-level a great deal of variation exists. Also, vendors are not pursuing identical strategies nor possess similar R&D capabilities. So significant, though changing, differences will remain for several years.

Remote Devices

SSL VPN Gateways work with PC, Unix, Linux and Macintosh devices equipped with standard browsers (e.g., Internet Explorer, Navigator, Safari). And many also support mobile devices with "micro-browsers" (e.g., RIM Web, Opera). Each vendor provides a list of the software versions that are supported by their Gateway. In every case, the browser acts as the VPN client for access to web-based resources, and a downloaded "software agent" is usually required for access to non-web applications and file servers. The agent is usually written in either Java or ActiveX.

Gateway Access

Users access a Gateway by entering the URL of its web server either directly, through a desktop icon, or a browser bookmark. An authentication page is then downloaded to the device; any type of user and device authentication method can be enforced. Once authenticated, the user receives a menu that identifies the network resources he/she can access. When the user selects a specific resource, a separate SSL session is established between the user device and the Gateway. The Gateway then either immediately establishes a proxied connection to the network resource or it requires additional user authentication. An additional SSL session is established between the device and Gateway each time the user accesses another application.

The remote SSL sessions encrypt all data traffic between these points (unless privacy is disabled), including traffic to and from both web and non-web, applications and file servers. Traffic can also be encrypted on the path between the gateway and internal resources. SSL, SSH and IPSec encryption are all possible when both ends are equipped with required software.

Remote Access Versatility (application & network connectors)

Today most SSL VPN gateways support the full range of TCP and UDP, applications and file servers. Like firewalls, they employ application and circuit-level proxies that “broker” communications between remote devices and internal resources. That is, there is never a direct network connection between the remote device and the destination resource.

All Gateway vendors use a combination of access methods to accomplish broad resource connectivity (note: the actual mix of methods varies somewhat across vendors and can matter. This will be discussed in a future solution brief)

Most include HTTP reverse proxies which serve and protect multiple internal web servers. These proxies actually rewrite HTML pages and other web objects like JavaScript - a compute-intensive activity. Application proxies can also support thin client applications like telnet and terminal services.

Some Gateways use "webifiers" which translate between HTTP and proprietary protocols (e.g. Microsoft RDP and IBM 3270). For example, a Gateway might download an agent that provides a VT100 terminal display, handle keyboard input, and route data traffic from the device over SSL. Communications protocol conversion would occur at the Getaway.

The remaining two access methods generally support client-server and UDP applications. In both cases, a ActiveX or Java agent is first downloaded to the client device. These agents redirect non-HTTP data traffic across an SSL tunnel (HTTPS) established between the device and the Gateway. If an application uses static ports on the server, the agent uses port forwarding technology. If it relies on dynamic ports, the agent provides a circuit-level connection to provide a tunnel similar to an IPSec VPN. This agent can also enable full network access (like an IPSec VPN), and resource viewing and access can be limited through selective filtering.

Clearly, the more types of application-proxies a gateway has, the better the security- if the protocol knowledge is used to make security decisions. But this security comes at a cost. Application-proxies require more memory and faster processors if they are going to be used to analyze IP packets at the level of the application protocol. (For an excellent overview of application and circuit-level proxies visit the FireTower web site).

Access Options
Specific Environments
VPN
Agent
Download

 
  Web Resources
  Webmail
  Microsoft® OWA™, IBM® IWA®
None
  Intranets and Extranets Applications
  All
None
  Web File Servers
  All
None
  Web-based Terminal Services
  Citrix®, Microsoft
None
  Web File Transfer
  All Web FTP Servers
None

  
  Non-web-based Resources
  Remote Access to Desktops    Proprietary F5 Application
  (PC, Unix and Linux desktops)
Yes
  Native Email Client-server   Microsoft Outlook, IBM Lotus
Yes
  Webified Standards-based Mail
   POP, IMAP, SMTP
Yes
  Client-server Applications     › Static Ports
Yes
      › Dynamic Ports
Yes
  Legacy Host Applications    IBM 3270/5250, DEC VT100/300, Telnet, SSH, x-term
Yes
  Terminal Services   Citrix®, Microsoft
 Yes
  Non-Web File Servers   Windows, Unix, Linux
Yes
  FTP Servers   Windows, Unix, Linux
Yes
  Collaboration (UDP)    IBM Lotus Sametime™,  
   Microsoft NetMeeting™
Yes
  Instant Messaging (UDP)  
Yes
  All TCP & UDP Applications   
Yes

Figure 2 - Typical SSL VPN Remote Access Capabilities

Authentication

SSL VPN Gateways can support all types of authentication- passwords, tokens, smartcards, client and server certificates, biometrics, etc - as long as the end users and their devices possess necessary hardware and software. And user certificates can be enabled through a Public Key Infrastructure (PKI). Gateway software allows organizations to leverage existing authentication servers like Microsoft Active Directory, and Radius and LDAP directories, and the access control capabilities built-in to individual applications. Single sign-on capabilities can be tailored to the user, the access device, internal resources and any other distinguishing variable pre-set by the security administer. For example, a user at his own home computer might be allowed automatic access to email and selected file servers after logging onto the Gateway with a password. However, access to a personal desktop might require additional - and even stronger- authentication. At a minimum, a second password.

Authorization

Both individual users and user groups can be assigned roles and access privileges. These privileges can be depend on a number of variables beyond authentication including the time and date; the device source IP address and address range, the destination URL (including parameters), IP address, network domain, subnet or IP range; arbitrary variables like the physical location of a desktop (e.g. nurses station in a public area versus a lab); encryption strength; and the integrity of the device (more about this topic in a following section). Access can be authorized for applications, file servers, personal desktops and individual network files.

Confidential Communications

All SSL VPN Gateways use 128-bit SSL for encrypting data traffic between the user device and the gateway. Some vendors also provide the option of AES 128-bit and 256-bit, encryption. Confidentiality can also be extended to the resource-side of the network (from the Gateway to the destination server) using either SSL, SSH or IPSec when the required software is installed.

End Device Security

End devices are clearly the potential achilles heel of any extended enterprise network. They can hold important confidential files; possess information useful for those who want to attack a network; can carry viruses, worms or trojan horses potentially damaging to the organization, or serve as platforms for attacking other users or networks (e.g., denial-of-service, spam). Gateways and a number of complementary security products can work together to minimize device-level vulnerabilities. Advanced firewalls also play a significant role. The following security mechanisms are currently available on some Gateways.

Application Protection

SSL VPN Gateways that employ application-level proxies can filter traffic at Levels 4-7. Since all Gateways use HTTP proxies, BMG expects vendors to build-in web application firewalls. These security products, and the attacks they are designed to thwart, are described in "Crank'in up the Heat, Beth Schulz, Network World, October 10, 2003. These firewalls can be either software-based or use specialized hardware - depending on performance requirements. Filtering of non-web application traffic is also expected, to control content and prevent intrusions.

Network Protection

SSL VPN Gateways protect the internal network in a number of ways. They hide network IP addresses and URLs, and mask addresses that are referenced by internal applications. Most Gateways are also "hardened" to prevent them from compromise. Although not common today, network level intrusion detection capabilities will become a standard feature in 2004. Since Gateways are installed behind network perimeter firewalls it is possible to take advantage of the firewall security features even though the inbound SSL traffic is encrypted when it initially passes through the firewall. For example, incoming traffic can initially pass through the firewall on port 443 and travel to the Gateway where the SSL tunnel ends. Then, the unencrypted traffic can be re-routed through the firewall a second time. The performance impact of traversing the firewall twice is expected to be low. Outbound traffic is handled in a similar manner; initially screened by the firewall and then sent to the Gateway. Future integrated products will reduce customer costs by eliminating separate appliances.

Application Adaptation Logic

Today few Gateways are "application-aware"; and these offer capabilities that only scratch the surface of what is possible. Beyond application level filtering which detects and blocks attacks; gateways have the potential of "understanding" application logic and making access control decisions at this level. Also, gateways could understand the behavior of applications and ensure that the gateways accomodate them without impacting application useability. This area will be discussed in greater detail in a future solution brief.

Security Policy Engine

The security policy engine provides the core intelligence for the SSL VPN gateway as this is where security policies are actually implemented- i.e., defined, enforced and monitored. Through an administrative interface, different user roles and privileges are established, access criteria are set, and linkages to authentication services, directories and network resources are made. The more granular the access controls, the more complex the administrative tasks. Well-designed Gateways will minimize this work. In the future, as access controls are extended to operations within specific applications and web services are supported, advanced productivity tools will become essential.

Service Level Performance

No SSL VPN vendor publishes data on the actual system-level performance of their Gateways. Instead, vendors size and price basic systems according to the number of concurrently connected users (CCUs) the vendors claims the model will support. Small systems are rated at either 50 or 100 CCUs and large ones at around 1000 CCUs. If one assumes 20% of all potential users will be accessing the system during peak times, a 100 CU system could support a community of 500 users. Beyond this "specification" vendors tout the performance of subsystems, e.g., the number of SSL sessions that can be set-up per second, or the availability of performance-enhancing features like page caching, SSL acceleration hardware, hardware encryption and high speed network cards. Most Gateways are also available in multi-unit clusters with load-balancing capabilities that optimize performance. Generally, the load balancers are external and provided by another vendor.

In December 2003, Light Reading published performance and scalability tests on eight products - both server-based and appliance. This online reports reveals some surprising results. The performance tests included: the maximum number of SSL session set-ups/teardowns per second without a transaction failure, the maximum number of actual ( logged on AND active) concurrent users, and several measures on how well the Gateways handled Microsoft's Outlook Web Access. One clear finding: performance varies widely and is highly dependent not only on hardware but how well the Gateway reverse proxy software is optimized. Organizations evaluating Gateways are strongly encouraged to perform tests that represent their environments and not accept general test data from either vendors or test labs.

Gateway System Availability

Gateway vendors configure high-availability systems using multi-unit clusters and load-balancers. A single active system with a "hot standby unit" is a option for small, price-sensitive organizations. Fault-tolerance capabilities are generally not built into single Gateways appliances although some offer dual power supplies.

Security Administration

Security policy administration can be either centralized, distributed or split in a hierarchical fashion. Most gateways provide a web-based console and a command line interface which supports secure remote policy administration. Role-based policies can be implemented to improve administrator productivity and accuracy. Gateways can take advantage of existing user directories and access control policies (e.g. Radius, LDAP, Active Directory).

All Gateways provide data on the activity of both users and administrators and a few generate management-level reports. However, none yet provide sophisticated tools for analyzing traffic and user access activities (successful or not) and alerting security managers - in real time - to potential problems.

Gateway Administration

The administrative console enables the Gateway to be easily installed and configured into existing networks. Neither applications nor file servers are impacted by Gateway installation. Most offer both browser and command line interfaces; remote administration is protected by authentication and confidentiality measures.

Conclusion

SSL VPN Gateways are feature-rich today and will become even more robust in 2006. As usual, vendor and product selection should center on specific customer requirements not on the length of product feature lists.

Advertisement