The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 2: IAG Connectivity Options

If you would like to read the other parts in this article series please go to:

• The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 1: SSL VPN 101
• The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 3: IAG File Access and Security Options

Last week we did a short course on SSL VPNs to get you up to speed on the current state of the art for SSL VPN solutions. I thought this was important because if you’ve ever tried to figure out what an SSL VPN is and does, you might have been frustrated in your efforts. As you likely discovered, SSL VPN vendors aren’t very transparent regarding what they have to offer and hope that you’ll get sucked into their solution based on the general SSL VPN “hype”. This is especially true for the traditional “hardware” router and switch manufacturers, who are trying to expand their markets into areas where they may have little experience or expertise, but who can leverage their reputations in the layer 1 through 3 market.

In fact, this was also the case for the Whale product before Microsoft acquired Whale. Whale, like all the other players in the SSL VPN market, was less than enthusiastic in providing details of their solution. Why? Most likely because the competition in the SSL VPN market was intense, so each of the vendors made it a point to make it difficult for others to figure out what their solution did. Whale, like the other SSL VPN vendors, played their cards close to their vests and did whatever they could to control the flow of information about their product, in order to prevent competitors from figuring out what they were doing and copying features.

However, things have changed significantly since Whale was purchased by Microsoft. Unlike the “hardware” SSL VPN vendors out there today, Microsoft wants you to know the details of their solution. Microsoft wants you to know everything you want to know about the IAG 2007, so that you can make a thoughtful decision. You don’t have to depend on the attestations of the “sales guy” and hope that the sales guy wasn’t feeding you a load of <something> only to find out later that their solution didn’t exactly do what you thought it would do. With the IAG 2007, you’ll have comprehensive information about the solution, all in public, and you’ll be able to try it out for yourself without having to create a contract of any kind with the vendor in order to “get a box” for evaluation purposes.

It’s with this philosophy of openness about the IAG 2007 solution that I’m able to write these articles about the details of the IAG. In this article series (which will likely be two or three parts), we’ll take a fairly high level look at IAG 2007, which is built on the ISA 2006 Standard Edition firewall. We’ll look at the features that are included right out of the box and see how those features can be put to use in creating a secure remote access solution for your organization.

In this series we’ll take a look at the following

Connectivity methods:

• Advanced application layer inspection reverse proxy
• Port and socket forwarder
• Network Connector

File Access

Security Features:

• 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

Advanced endpoint compliance checking and policy based access

Connectivity Methods

With the IAG 2007 you’re not limited to a single type of connectivity when clients connect to the IAG 2007 VPN gateway. The IAG 2007 provides you with several options so that you have to provide the type of connectivity appropriate to the type of application access required. Unlike many of the other SSL VPN solutions out there, you’re not limited to a single method of connectivity.

There are three primary methods of connectivity provided by the IAG 2007. These are:

• Advanced application layer inspection reverse proxy
• Port and socket forwarder
• Network Connector

Advanced Application Layer Inspection Reverse Proxy

The advanced application layer inspection reverse proxy included with the IAG 2007 is similar to the Web Publishing Rules feature included with the ISA Firewall. However, there are some significant differences between ISA Firewall Web Publishing and the IAG 2007 advanced application layer reverse proxy. These include:

Superior application layer inspection

The ISA Firewall includes the HTTP Security Filter right out of the box. However, the HTTP security filter provides very minimal protection unless you configure it to block or allow specific methods and create deny signatures.

There are two major limitations of the HTTP Security filter included with the ISA Firewall:

1. The signatures you can create are block signatures, you can’t create “white list” signatures
2. Signatures are based on simple strings, so you can’t use Regular Expressions to perform most robust inspection of the URLs and data.

In contrast, the IAG 2007 supports Regular Expressions (RegEx) right out of the box and you also get support for both block and allow rules.

Positive and negative filtering

The HTTP Security Filter with the ISA Firewall requires that you do a tremendous amont of work in order to discover what legitimate communications to your published Web server are. Even after all the work you put into finding out what are legit communications to your published Web server, you still need to figure out what you need to block in order to cover all the known exploits that are out there “in the wild”.

In contrast, the IAG 2007 has deep application layer intelligence built in for a number of line of business applications that you will want to publish. The IAG 2007 application layer intelligence team has put in thousands of hours figuring out what are legitimate communications for a number of line of business applications and includes that in the filtering mechanism right out of the box. There is no need for you to figure this information out on your own – the IAG 2007 team has done the heavy lifting for you.

In addition to this “positive logic” (where you only allow know legitimate communications to your published Web server), the IAG 2007 includes a host of “negative logic” filters. The negative logic filters block known bad communications that come from known exploits already out in the wild. The end effect is that negative logic filtering blocks known bad communications, and the positive logic filters protects you from zero-day attacks.

Out of the box filtering supports not only key Microsoft applications that you might publish to the Web, but also many popular non-Microsoft offerings. Microsoft applications for which there is robust built-in application layer intelligence include Exchange Web services (OWA, OMA, ActiveSync and RPC/HTTP), SharePoint services and Microsoft CRM. In addition to the Microsoft Web services are other popular applications, such as SAP Enterprise Portal, Webtop Documentum, Domino Web access, SecureView and many more. IAG 2007 is designed to protect remote access connections to the heterogeneous enterprise.

The figure below shows an example of the impressive application intelligence and filtering for a published SharePoint server.

Figure 1

Automatic Portal Creation

One thing that all SSL VPNs do that the ISA Firewall doesn’t do is automatically create a portal site for users to connect to your published applications. With ISA Firewall Web Publishing Rules, users need to remember the URL to which they connect to each published Web server. If you publish a number of applications, users will either have to remember the URLs to all of these applications, or if you’re feeling charitable, you can create a portal page to help your users. However, that takes a lot of overhead, and if you’re not a Web programmer, it is unlikely that you’ll find it a pleasant experience.

The figure below shows an example of a portal that is automatically created by the IAG 2007. Once you create the portal, you assign published applications to the portal and they appear on the portal page. Although we’re focusing on publishing Web applications in this section (as an example of the IAG 2007 reverse proxy feature), you can see in the figure that non-Web applications can be included in the portal as well. This portal appears only after the user logs on.

Figure 2

Customizable Portal Creation based on authentication and authorization

In addition to creating the portal, the portal can be customized based on the user account of the user who logged into the portal and the security state of the machine connecting to the portal. The user account and the reported security state (as part of the IAG 2007 endpoint detection feature) act as rate limiters (or filters) for what the user’s portal experience will be. You might not want to create multiple portals. The IAG 2007 allows you to create a single portal and then automatically configure application access based on user account, user group membership, or security state of the machine the user is connecting from.

The figure below shows an example of how you can assign applications to specific users or groups, so that these applications may appear or not appear in the portal.

Figure 3

Superior Authentication Provider support

The ISA Firewall supports a number of authentication protocols, most of which are aimed at targeting a Microsoft Active Directory domain for user authentication. The IAG 2007 includes support for the same authentication protocols as the ISA Firewall, but extends those to other authentication providers. For example, the IAG 2007 supports LDAP not only for Active Directory, but also for Notes, Netscape and Novell, in addition to its support for TACACS+. The IAG 2007 can also be customized to support any application protocol and provider you require. In addition, the IAG 2007 will “walk” the authentication provider list, so that it doesn’t quit when it fails to find a match with the first provider. This is a great advantage when you have situations such as mergers where you are trying to federate your authentication scheme at the gateway.

Port and Socket Forwarder

You can also publish non-Web applications through the IAG 2007 device. Unlike Server Publishing Rules that are used to publish non-Web applications through the ISA Firewall, the IAG 2007 enables secure SSL encrypted remote access for all non-Web applications. There are some serious advantages to the IAG 2007’s approach to Server Publishing compared to the ISA Firewall’s Server Publishing Rules. These include:

Encryption for non-encrypted application protocols

When you create Server Publishing Rules for non-encrypted protocols using the ISA Firewall, information that moves between the client and server travels over the Internet in the clear and anyone with a network sniffer will be able to read the communications. The most common example of this type of exploit is POP3. Users love to use POP3 to connect to their corporate mailbox using a variety of e-mail client applications. POP3 sessions are not secured, so both the user name and password, as well as the data, will travel over the Internet in the clear when using an ISA Firewall Server Publishing Rule.

In contrast, when you use the IAG 2007 SSL VPN gateway to publish POP3, the connection between the client and the IAG 2007 device is protected in an SSL tunnel. Intruders with network sniffers will not be able to capture user names and passwords and they will not be able to read the mail. This will be true for all non-encrypted protocols, such as SMTP, POP3, IMAP4, RPC/MAPI, SMB/CIFS, RDP, NNTP and many others. The IAG 2007 SSL VPN provides security and privacy in scenarios where the ISA Firewall can’t.

Pre-authentication for non-Web protocols

ISA Firewall Server Publishing Rules do not support pre-authentication for non-Web protocols. This is not only true for the ISA Firewall, is true for all firewalls that provide port-forwarding or reverse NAT capabilities for non-Web protocols. It’s not a firewall limitation, it’s a limitation in the protocols themselves, since you need some type of proxy component to intercept the authentication requests.

The IAG 2007 solves this problem by providing non-Web protocol access via a Web proxy, which is what the SSL VPN gateway actually is. In order to get access to the non-Web protocol, the user must be able to first authenticate with the IAG 2007 SSL VPN gateway. After successful authentication, the user may or may not be authorized to use the non-Web protocol, which will appear in the portal page if the user is authorized. This provides pre-authentication for non-Web protocols, something that only SSL VPN gateways like the IAG 2007 can do.

Reduced overhead for access anywhere (simplified DNS)

One problem that many ISA Firewall admins seem to balk at is the creation of a split DNS. A split DNS can greatly simplify the life of your users, as they are able to use the same name when accessing resources regardless of their location. They use the same name when they’re located on the corporate network as the name they’d use when locating someone out on the Internet. The split DNS is a great solution for organizations of all sizes, but I’ve often seen push-back when this subject comes up because admins might not understand DNS correctly or they have been led to believe in misconceptions when it comes to the configuration of a split DNS infrastructure.

The IAG 2007 completely removes the requirements for a split DNS, as users only need to know the name of the portal. Once users connect to the portal, all name resolution is handled by the IAG 2007, so that users never need to remember anything but the name of the portal and admins don’t need to deal with the technical and political issues that might crop up when it comes to creating a split DNS infrastructure.

Application control over socket access

The socket forwarding feature enables you to control not only what ports applications on the clients are allowed to connect to through the IAG 2007 SSL VPN gateway, it also allows you to control what application is used to connect to that port. This feature is similar to the functionality provided by the ISA Firewall’s firewall client application, where you can configure access based on image name. The drawback of the Firewall client approach is that it’s easy for even unsophisticated users to change the name of the application on disk.

The IAG 2007 takes the Firewall client method of application control one step further by controlling access based on a hash value of the application. For example, we want to allow RPC access for the native Outlook client through the SSL VPN gateway, but we don’t want any other application to use RPC through the gateway. We can set policy on the IAG 2007 by allowing RPC access through the SSL VPN gateway, but only to the Outlook 2003 application, based on the hash value of the application making the call to the RPC endpoint mapper port. This is much more secure than the Firewall client approach, because even if the user or a piece of malware changes the name of another file to outlook.exe, connections by the non-Outlook application will not work because the hash value won’t match.

The figure below shows a dialog box available on the user’s computer showing the connections made by the port and socket forwarders.

Figure 4

You can use one of two methods to provide support for non-Web applications through the IAG 2007 SSL VPN gateway:

The Port Forwarder

The Port Forwarder is an SSL VPN component that listens on a specific local address and port for each application that you published, and causes the application to send the traffic to this address rather than to the address of the actual application server. The SSL VPN Port Forwarder client then tunnels the traffic within SSL and sends it to the SSL VPN gateway. Port forwarding is secure since the SSL VPN encrypts the tunnel containing the unencrypted application protocols, as discussed earlier. The port forwarder supports only simple applications that do not require secondary connections.

The Socket Forwarder

The Socket Forwarder SSL VPN client hooks into the Microsoft Winsock service provider interface and uses the Windows LSP/NSP (Layered Service Provider/Name Space Provider) interfaces to provide low0-level handling. The Name Service Provider is used to resolve internal server names to ensure that they will be tunneled and not sent over the Internet. One major security advantage of socket forwarding is that the SSL VPN Socket Forwarding client is able to identify the user and the process generating the traffic, and set appropriate application specific security parameters on that communication. This feature allows the application specific control discussed earlier.

In addition, split tunneling is avoided by trapping and forwarding all traffic to the SSL VPN gateway. This features increases security and avoids common network compromises due to users enabling Internet connection sharing on a network level SSL VPN client connection, which is a common exploit used against many of the “hardware” implementations of SSL VPN, where the SSL VPN client is configured as a kernel mode virtual adapter.

Network Connector

In contrast to reverse proxy and port/socket forwarding, the Network Connector provides true SSL VPN connectivity. With reverse proxy and port/socket forwarding, there is no virtual network connection. With the Network Connector, you have a true SSL VPN connection that actually tunnels IP within IP and assigns the remote access VPN client a valid IP address on the corporate network and provides PPTP or L2TP/IPSec-like VPN network connectivity to the corporate network.

The Network Connector is implemented as a network device and appears in the Network Devices window on the client computer. If the network connector is enabled in the portal, the Network Connector application will automatically install on the client computer. Of course, you’ll want to be careful about which computers are allowed to run the Network Connector, as it wouldn’t be a good idea to allow users at computer kiosks at an airport or bar this level of access. You can use the IAG 2007 endpoint detection and secure access policies to make sure that only trusted endpoint computers are allowed to use the Network Connector.

The Network Connector provides the following features:

• Autodetection and manual tuning of corporate networking parameters, such as WINS, DNS, DNS suffix
• Provision IP addresses using a static address pool or DHCP
• Split tunneling control
• Protocol mask filters for TCP, UDP and ICMP
• Supports Windows 2000, Windows XP and Windows Server 2003 clients
• Installation of the IAG 2007 Network Connector client does not require a reboot
• Session icon provides statistics and a disconnect option
• Full IP unicast functionality

The Network Connector allows you to have full network level access, with full support for complex protocols that might require multiple primary and secondary connections. If there are complex protocols that you require, such as VoIP, which isn’t supported by the port or socket forwarder, then you can use the Network Connector. However, be aware that unlike the ISA Firewall’s strong user/group access control over remote access VPN connections, you will not get this level of access control with the Network Connector. The Network Connector will act as a typical “hardware” VPN gateway, that lets everything through the link, including hackers and malicious mobile code. If you need strong stateful packet and application layer inspection for remote access VPN connections, you should consider using the ISA Firewall’s PPTP or L2TP/IPSec VPN remote access VPN server.

Summary

In this article we examined the IAG 2007 connection methods. We saw that there are three ways for clients to connect to the IAG 2007 SSL VPN gateway depending on application requirements: reverse Web proxy, port/socket forwarding and via the Network Connector. Reverse Web proxy works by allowing reverse proxying for Webified applications with enhanced application layer intelligence. Port and socket forwarding is useful for providing controlled access to non-Web applications and the Network Connector is focused on providing full network level access in the same way as any other network level VPN might provide. Next week we’ll talk about the file access and security features included with the IAG 2007. See you then! –Tom.