If you missed the other parts in this article series please read:
- The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 1: SSL VPN 101
- The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 2: IAG Connectivity Options
Last week we took a detailed look at the connectivity options available in the IAG 2007. Those options included the advanced application layer inspection reverse Web proxy, the port and socket forwarder, and the network connector. This week we’ll change our focus from connectivity to file access and security features.
We will discuss the following topics:
- Remote File Share Access
- The ISA Firewall
- Attachment Wiper
- Robust authentication protocol support
- Positive and negative logical application inspection
- Host address translation
- Security Logoff and Inactivity Timeouts
- Advanced endpoint detection
File Access
As I mentioned in the first part of this series, remote access to network file shares was one of the major “definitions” that customers had for an SSL VPN. Customers realized that enabling remote access over the Internet to SMB/CIFS file shares wasn’t a very secure solution. So in their effort to understand “why” they needed an SSL VPN, they came up with the idea that an SSL VPN was something required for secure access to corporate file shares. While we now know better, many customers still harbor this belief and it’s something that you can leverage when trying to get an IAG 2007 into your customer’s network.
The IAG 2007 provides very robust support for remote access to file shares. The file share access component is easy to use and configure and all the settings can be done in the user interface. Unlike Exchange 2007, there’s no need to drop into an arcane command line interface to get it to work.
The figure below shows what the end user experience is with the remote file share access feature. The file share option shows up in the user’s portal page and when they click the file share access portal link, they’ll be presented with something that looks very much like Windows Explorer in an Internet Explorer window. Users can navigate to the server they want, and after clicking on that server they will see the file shares that you’ve made accessible to them. Once they locate the file of interest, they right click on it and click the download command from the context menu. The file is then downloaded to the client computer over the SSL VPN link.
I should note here that this is not a full SMB/CIFS client/server experience. If users are accustomed to editing files in-place on the server when working with network file shares, they will have to relearn some new behaviors when using the SSL VPN, because in-place editing is not available. If they want to make changes to a file, they will need to first download the file, then make changes, and the upload the file to the file server. However, if they only want to view the file, they can use the Open option from the context menu.
Figure 1
The figure below shows how the administrator configures access to servers. First, the IAG 2007 must be a member of the domain to which the file servers belong, or at least must participate in a trust relationship with those file servers. You then select the file servers you want the users to access by putting checkmarks in the checkboxes next to them. Once you’ve selected the file servers, you also have the option to select what file shares they have access to. It’s important to note here that all NTFS permissions are respected, so that users must have permissions to access folders and files before the IAG 2007 enables users to view or download the files.
Figure 2
The figure below shows that the IAG 2007 provides remote access not only to Windows based file shares, but also to those hosted on Novell file servers as well. In order for this to work, you will need to install the Novell client software on IAG 2007.
Figure 3
Another nice feature included with the file share capabilities in the IAG 2007 is the ability to support home directories and mapped network drives. In the figure below you can see that you have the options to Don’t Define Users’ Home Directories, Use Domain Controller Settings for Home Directories (that is to say, the home directory setting on the user account) and use the Following Template for Home Directories. You also have the option to have the User’s Home Directory Will be Displayed Every Time File Access is Loaded. Automatic support for Home Directories enables users to have a more “in office” user experience while on the road.
If you use script to map network drives for your users, you can use those same scripts to map network drives on the remote users’ computer. Just enable the Show Mapped Drives option and point the configuration to the correct script engine and you’re good to go. Users will see the mapped network drive in their Windows Explorer interface after they connect to the File Share option in their portal window.
Figure 4
Security Features
Up until now we’ve been focusing on the remote access features included with the IAG 2007. While remote access is an important first half of the story, it’s not the entire story. The second half of the story is security. If we just wanted remote access over an SSL VPN connection, we could use one of the IAG 2007’s competitors and get much of what we wanted. But the big story today is secure remote access. Without secure remote access, all we’ve done is create a bigger hole for attackers to steal, change and destroy our prized corporate information.
It’s the secure remote access story where the IAG 2007 really shines. It’s IAG 2007 security that puts it head and shoulders above competing SSL VPN solutions. In this section on the IAG 2007 security features, we’ll look at:
- The ISA Firewall
- Attachment Wiper
- Robust authentication protocol support
- Positive and negative logic Web application inspection
- Host Address Translation
- Secure Log off and Inactivity Timeouts
The ISA Firewall
Yep, the ISA Firewall. The ISA Firewall is installed on all IAG 2007 devices. The ISA Firewall is included because the IAG 2007 is designed to be an edge device. In order to make it feasible as an edge device, the IAG 2007 needed industrial strength firewall protection that protects both itself and hosts located behind the IAG 2007 box. What better solution than the ISA Firewall? In contrast to most “hardware” firewalls, you’ll find on a www.secunia.com lookup that the ISA firewall has no exploits described against it. This makes the ISA Firewall arguably the most secure firewall on the market today.
Figure 5
Attachment Wiper
One of the goals of SSL VPN solutions is to allow access from anywhere. While anywhere access can give a business an advantage by enabling employees to get to information faster than other solutions, there is also the potential that the “anywhere” is a very unsecure device. Allowing access from anywhere means allowing access from any computer with an Internet connection, a Web browser, and access outbound through TCP port 443 to the SSL VPN gateway.
Think about the types of devices that can be used to connect to corporate resources in an access from anywhere scenario:
- An airport kiosk
- A kiosk in a bar or restaurant
- An unmanaged computer at home that’s shared with the kids
- An unmanaged computer at a friends house, that’s shared with the entire neighborhood
- An unmanaged laptop computer that has been connected to dozens of hotel, airport, and conference center networks
- An Apple or Linux computer that has been unsecured by its owner because of the false belief that these operating systems don’t need to be secured
The access from anywhere scenario requires that we have a way to prevent information leakage onto these unsecured devices. The IAG 2007 solves this problem with it’s Attachment Wiper application. The goal of the Attachment Wiper is to make sure that information accessed during the SSL VPN session is not accessible to other users after the session is concluded.
The Attachment Wiper provides the following features:
- Clearing of the browser cache after session termination. This process is completely transparent to the user and does not require user intervention.
- Application optimizes extend cache clearing by cleaning out custom caches used by specific applications. And if there is no application optimizer for a specific application (such as a home grown in house app), there is support for custom scripts for file cleaning.
- Removal of a number of sources of private information including: downloaded files and page, contents entered on auto-complete forms, auto-complete URLs, cookies, history information and any user credentials that might have been entered during the SSL VPN session.
- Multiple triggers for wiping: when the user logs off, after an inactivity timeout is over, during a scheduled logoff, when the browser crashes, when the browser is closed, or when the operating system crashes. When the user connects to the SSL VPN gateway, a “run once” setting is made in the Registry to insure that the attachment wiper runs when the system is restarted
- Security policy controls. For example, you can set a “can’t wipe – can’t download” policy. You can also allow for a fall-back policy to “no-cache” (HTLM tag)
Another thing worth keeping in mind is that the Attachment Wiper does a full DoD wipe of the files. This causes the files to be completely erased from the disk, in contrast that other solutions that just delete the file but leave the actual file data on disk.
Robust authentication protocol support
Unlike the ISA Firewall, which supports only Active Directory authentication (unless you want to use RADIUS), the IAG 2007 supports a vast array of authentication protocols and authentication providers. LDAP is supported for all types of authentication providers, not just for Active Directory. Many other authentication providers as supported using a variety of authentication protocols, as seen in the figure below.
It’s important that the ISA firewall be installed on the IAG 2007 box because it is used to protect both the core IAG 2007 software and the underlying Windows operating system. When the ISA Firewall is installed on the box, the underlying Windows operating system is protected against established and zero-day exploits. There is no path an attacker can use to access any part of the core Windows operating system when the ISA Firewall is installed.
This means that even if there are exploitable components in the Windows operating system, no attacker will ever be able to reach them. Think of the ISA Firewall as a mountain above a hardened shelter that protects against nuclear attacks, even if the atomic bomb were dropped right on top of the shelter. It’s the ISA Firewall that protects the core operating system and IAG 2007 software from any possible attack from all types of attackers.
IAG 2007 and ISA Firewall configuration are tightly integrated. When you create portals and configure application providers on the IAG 2007, that information is used to automatically configure the ISA Firewall policy to provide least privilege access to the required devices and services. You should never need to enter the ISA Firewall console unless you want to use the ISA Firewall for non-IAG 2007 related purposes, such as configuring a remote access VPN server or VPN gateway using PPTP or L2TP/IPSec VPN protocols.
The figure below shows a number of rules that were automatically created by the IAG 2007 device.
Figure 6
Authentication protocol and provider support includes:
- ACE
- NT Domain
- Active Directory
- Netscape LDAP server
- Notes Directory
- Novell Directory
- RADIUS
- TACACS+
- WINHTTP
- Other
When “Other” is selected, you can configure the requirements for your authentication protocol and provider in the IAG 2007 console. This flexibility enables the IAG 2007 to support virtually any authentication protocol and provider available today.
Positive and negative logic application inspection
One of the two things that sets the IAG 2007 SSL VPN gateway apart from the rest of the SSL VPN solutions is the security provided by the IAG 2007 application layer inspection positive and negative logic filtering capabilities. No other SSL VPN at the time of this writing has a sophisticated and secure application layer intelligence.
Most SSL VPN offerings have only limited support for application layer inspection, and what application layer inspection they do have is limited to signatures you create yourself (like the ISA Firewall’s HTTP Security Filter) that use negative logic. A negative logic filter is one that blocks exploits based on “known bad”. If you are aware of a “known bad” string or command, you can configure a negative logic filter to protect yourself. The problem with negative logic filters is that they only protect you from known exploits – you can know protection from zero day exploits.
This is where the IAG 2007’s superior application layer intelligence comes into play. In addition to the negative logic filtering that other SSL VPN gateways use, the IAG 2007 also supports a very strong positive logic filtering system. Positive logic dictates that only “known good” communications are allowed to the published application. Positive logic filtering is only possible when the system has a deep understanding of the application.
For example, when you publish Outlook Web Access or SharePoint using the IAG 2007, positive logic filters are automatically applied. These filters are based on hundreds of hours of research that is required to determine what is legitimate traffic required for system functionality.
If there is a match on the negative logic filter, the connection is blocked. If there is no match on the positive logic filter, then the connection is dropped. By combining both positive and negative logic filtering, the IAG 2007 protects you not only from known exploits, but also protects you against zero day attacks.
The figure below shows an example of how sophisticated RegEx based filters are configured right out the box for basic components of the IAG 2007 configuration, such as the Whale portal site itself, the Whale internal site, and the Whale Event monitor.
Figure 7
The figure below shows the complex positive and negative logic filtering applied to a published OWA site. Unlike the ISA Firewall’s HTTP Security Filter which can only block based on specific strings, the IAG 2007 uses powerful regular expressions to reduce the number of rules and also allow both allow and block signatures. For OWA and other applications that are supported right out of the box, the positive and negative logic filter statements are already configured – there’s no requirement for you to “figure out” what should be done to secure the application.
Figure 8
Host Address Translation
A major technical challenge associated with providing secure remote access to internal applications from the Internet is that of internal references within the applications that might be exposed to external users.
Data, code and links may use system-naming conventions that do not work from external locations. Although all SSL VPN gateways offer technology to perform link translation, each translation algorithm and implementation is unique. The IAG 2007’s Host Address Translation engine encrypts all information related to the internal network so that external users never see anything that could be of assistance to them in launching attacks against internal resources.
External users never see the names of any internal servers and they never see any paths used to access those servers. This prevents users from leveraging the SSL VPN connection to reconnoiter the internal network server infrastructure.
Secure Log off and Inactivity Timeouts
To prevent credentials from being cached on the machine connecting to the SSL VPN gateway, the IAG 2007 uses a strong Secure Logoff technology. This innovative method was developed by Whale and is used by the IAG 2007 as a replacement for HTTP Basic Authentication, which eliminates the possibility of malicious users piggybacking on another user’s session.
Inactivity timeouts are required to protect companies from users who “forget” to log off at the end of their sessions. However, implementing timeouts can create inconvenience for legitimate users; for example, an SSL VPN gateway may automatically log a user out while the user is composing a long e-mail message or completing a long Web form and may result in the user losing his work. If you’ve been in this situation, you know how angry users can get when you logged them out after putting over an hour composing a detailed and complex e-mail to his boss.
To deal with the problem, the IAG 2007 uses a non-intrusive timeout mechanism where users are warned that a timeout based on inactivity is about to occur. The user then has the opportunity to prevent the timeout from logging him off and he can continue to work on his e-mail message or Web form. The figure below shows what it looks like from the user’s point of view.
Figure 9
Whale also offers non-intrusive forced periodic re-authentication. After an administrator determined time window has elapsed, users must re-enter credentials to continue working. If they do, they resume exactly where they left off, even if they were in the middle of completing a Web form. Of course, if they do not, their session will be terminated (and the Attachment Wiper will be activated).
The timeouts used by the Intelligent Application Gateway are also able to distinguish between automatic browser requests and true user activity, so that even user sessions with applications that leverage automatic refresh requests to keep data at the browser current (such as Microsoft Exchange and Lotus Domino) will be terminated if there is no true user activity. Other SSL VPN products often cannot distinguish between user and computer originating activity emanating from the browser and will leave such sessions live for an indefinite period.
Advanced Endpoint Detection
The second technology that sets the IAG 2007 apart from all other SSL VPN solutions is its sophisticated endpoint detection feature and policy control based on endpoint detection.
Endpoint detection is all about assessing the health status and configuration of the host connecting to the SSL VPN gateway. The need for endpoint detection comes from the fact that SSL VPN clients are often unmanaged computers that have been connected to multiple unsecured networks and have been exposed to multiple exploits and irresponsible and potentially malicious users.
One example of an endpoint security technology solution provided by Microsoft is the ISA Firewall’s VPN Quarantine solution. The goal of the ISA Firewall’s VPN-Q was to place a host on a restricted network while the host’s security status and configuration was being evaluated. If the host passed the security checks, it was allowed network access, if the host failed the tests, it was left on the quarantine network. While the VPN-Q feature looked wonderful on paper, it failed miserably in deployment because the product was only half-finished. In order to get the VPN-Q product to work, you had to purchase a third party solution or pay big bucks to a programmer to complete application programming required to make VPN-Q work in your organization.
Another example of endpoint detection is the Microsoft Network Access Protection (NAP) feature that will be included in Longhorn. The basic principles behind NAP are similar to those used by VPN-Q; put the clients on restricted network access until their current health status can be confirmed. If the client doesn’t pass the checks, then network access is either denied or limited. However, NAP adoption is at risk of failing in the same way that the ISA Firewall VPN-Q failed, as it may require significant investment in third party applications and programming support in order to make it functional in your organization.
If you’ve had the misfortune of working with other SSL VPN gateways, you’ve probably found that they’re endpoint checking solutions are similar to the limited support provided by the ISA Firewall’s VPN-Q or the current implementation of NAP. You have to either put in dozens or hundreds of hours of sweat equity to figure out how to get it working in your company, or you had to hire out for expensive consultants and programmers.
The good news is that the IAG 2007 developers have done all this work for you. You don’t have to spend weeks and months trying to figure out how to implement a functional endpoint detection policy for your organization because the IAG 2007 understands the applications and configurations you actually want to check! In the same way that the IAG 2007 developers did the heavy lifting for you to figure out how applications work to support positive and negative logic filtering, they’ve done the hard work for you so that you don’t have to make it an avocation to get a real-world endpoint detection policy to work right out of the box.
Check out the endpoint detection policy configuration dialog boxes in the figures below. Notice that the IAG 2007 team has done the complex work in advance that enables the IAG 2007 to detect these features. Compare this to the crippled VPN-Q and NAP interfaces (as well as those provided by the competitors of the IAG 2007) and you’ll think you’ve struck gold!
Figure 10
Figure 11
Figure 12
However, endpoint detection is only half the story. The other half is to determine policy based on the security status detected on the endpoint. In production networks, you’ll likely enable more liberal access to highly secured endpoints compared to those who fail most of the endpoint security checks.
Corporate security policies governing devices that connect to the SSL VPN gateway normally dictate conditions that must be met on the device in order for users to perform specific business functions. Yet, until the IAG 2007, SSL VPNs often have not been able to fully implement such policies; instead, they provided only the ability to limit access to entire sessions – and not specific functions – based on endpoint conditions. As such, competitors of the IAG 2007 have crippled access needlessly.
For example, when users accessed the SSL VPN from non-trusted machines without anti-virus software, instead of being permitted to download but not upload files, users were either denied file access completely (resulting in loss of productivity and convenience) or they were given full file-system access (putting the company at risk of becoming infected with a virus). Additionally, application-specific implementations of abstract concepts often caused incompatibilities with SSL VPNs.
For example, there was no way to instruct an SSL VPN to “block attachment download from e-mail messages” if the wiping of temporary files was not assured or to “ignore automatic refresh requests” when considering user activity for purposes of calculating session timeouts.
The IAG 2007 provides many endpoint security features, including:
- To identify machines and set security policies accordingly, users can download client certificates from the IAG 2007 (if security policies allow). Admins can configure policies regarding who can request certificates, whether certificates can be generated automatically, whether delivery is immediate or delayed. Certificates can be presented during future sessions to indicate to the IAG 2007 that the client is highly trusted and that appropriate security policies (i.e., more lax access controls compared to untrusted machines) should be used. Alternatively, the IAG 2007 can check the client machine for specific files, Registry values, or even hardware devices (such as SmartCards or USB tokens) to determine whether the system is a highly trusted device.
- When corporate policies mandate that remote users use a specific service provider such as iPass so that policies are enforced, the IAG 2007 will verify dial-up connection attributes an decide accordingly whether or not to allow access
- To determine the security level of machines not otherwise certified, the IAG 2007 can scan the client to check for conformity to policies set by the company. The IAG 2007 can check for AV software, host based firewalls, and other security settings as well as how recently the security software was updated. Policies for the user’s session can be dynamically set according to the results of the host health check scan. The granularity of IAG 2007 endpoint policy engine together with its exceptional application layer intelligence makes the IAG 2007 the most secure SSL VPN gateway solution on the market today.
The table below shows some examples of how the tight relationship between endpoint detection and user access policy works.
Table 1
There are many default endpoint policies that are configured for you right out of the box, as seen in the figure below.
Figure 13
In the figure below, you can see how granular access policy based on endpoint detection can be applied to several areas. These include:
- Session access policy
- Download policy
- Upload policy
- Restricted zone policy
Figure 14
Summary
In this article we moved our focus from remote access features and more toward the security features included with the IAG 2007. While every SSL VPN solution can provide remote access over an SSL tunnel, not all SSL VPNs can provide secure remote access. There is no point to providing remote access using an SSL VPN if it’s not secure – the only thing you accomplish with an unsecure SSL VPN is to allow attackers to bankrupt your business more quickly. The IAG 2007 SSL VPN gateway solves the problem of secure remote access by including many power security features. The two security features included in the IAG 2007 that puts its head and shoulders above the competition include its advanced positive and negative logic application layer inspection for a large number of line of business applications, and the IAG 2007’s exceptional endpoint detection and policy engine. Just these two features alone will convince you that the IAG 2007 is the most secure SSL VPN solution on the market today.
If you missed the other parts in this article series please read:
