Using ISA Server 2004 to Secure Applications


One of the distinct advantages to an ISA Server 2004 solution is the software's capability to scan all traffic that hits it for exploits and threats, before that traffic hits its intended target. As previously mentioned, ISA performs these functions through a process of scanning that traffic at the Application layer through a series of customizable filters, such as an HTTP filter for web traffic that knows to look for common exploit strategies such as those employed by the Code Red, Nimbda, and Ject viruses. These capabilities are the central selling point for one of ISA's most popular features, the capability to secure and protect Internet-facing applications from attack.

Securing Exchange Outlook Web Access (OWA) with ISA Server 2004

The current single most common deployment scenario for ISA Server 2004 involves an ISA server being set up to provide reverse proxy to Exchange Outlook Web Access (OWA) servers. The ISA development team worked very closely with the Exchange development team when developing specific OWA filters for this, and the integration between the two technologies is very tight. In addition to the standard benefits that reverse-proxy capabilities provide, deploying ISA to secure OWA also has the following key selling points:

  • SSL to SSL end-to-end encryption ISA Server 2004 is one of the few reverse-proxy products to currently support end-to-end Secure Sockets Layer (SSL) support from the client to the ISA Server and back to the Exchange OWA server. This functionality is provided via certificates installed on both Exchange and the ISA Server, allowing the OWA traffic to be unencrypted at the ISA box, scanned for exploits, then reencrypted to the Exchange servers. This allows for a highly advanced ISA design, particularly in configurations where ISA is deployed in the DMZ zone of an existing firewall.

  • Forms-based authentication on ISA Introduced with Exchange Server 2003, forms-based authentication (FBA) enables users to authenticate against an OWA server by filling out information on a form, such as the one shown in Figure 1.8. This also has the added advantage of preventing any unauthenticated traffic from accessing the Exchange server.

    Figure 1.8. Using ISA forms-based authentication to authenticate against OWA servers.


  • Unihomed ISA server support ISA OWA Publishing also can be deployed on a unihomed (single network) card in the existing DMZ of a firewall such as a Cisco PIX or other packet-filter firewall. In fact, this is one of the more common deployment scenarios for ISA Server. This flexibility enables ISA to function as an appliance server that serves as a bastion-host to Exchange services.

NOTE

Many Exchange deployment designs are replacing Exchange front-end servers in the DMZ with ISA Servers in the DMZ that communicate with front-end servers in the internal network. This has the added advantage of securing the services in a DMZ configuration, but without opening the multitude of ports required by a front-end server to be able to communicate with Exchange database servers and Global Catalog servers.


In addition to filtering and protecting OWA traffic, ISA also includes custom filters to scan and protect other mail-related traffic such as Simple Mail Transport Protocol (SMTP) and Exchange MAPI (Outlook-style) access. For more information on securing mail-related services, including step-by-step deployment scenarios, see Chapter 12.

Locking Down Web Application Access

As previously mentioned, the HTTP filter included with ISA Server 2004 includes pre-installed knowledge to identify and eradicate HTTP threats before they access any web services, including traditional web servers and web applications. It is under this pretext that ISA can be deployed to secure external-facing web servers and web traffic. In addition, the HTTP filter is customizable, and can be modified or extended manually or can use third-party software products to do things such as limit specific HTTP calls, block executable downloads, or limit access to specific web sites. For more information on setting up ISA to secure web services, refer to Chapter 14, "Securing Web (HTTP) Traffic."

Securing Remote Procedure Call (RPC) Traffic

One of the more potent threats to Windows infrastructure in recent years has been the rise of viruses and exploits that take advantage of Remote Procedure Call (RPC) functions to take over computers and wreak havoc on client operating systems. Many of these threats have been extremely damaging to the infrastructure of organizations, and the method of containing the spread of them in the past has involved a complete shutdown of the RPC communications infrastructure between network segments.

ISA Server 2004 provides an invaluable tool against these types of RPC exploits through its capability to screen RPC traffic and intelligently open only those ports that are necessary for specific RPC services to function. For example, an ISA server could be positioned as a router between multiple network segments, a server segment, and client segments, and filter all RPC traffic between those segments, as the diagram in Figure 1.9 illustrates. It could then be configured to allow only Exchange MAPI Access (a form of RPC traffic) to that segment, blocking potentially infected clients from infecting servers or other clients on other segments.

Figure 1.9. Securing RPC traffic between network segments.


For more information on the RPC Filtering capabilities of ISA Server 2004, see Chapter 15.



    Microsoft Internet Security and Acceleration ISA Server 2004 Unleashed
    Microsoft Internet Security and Acceleration (ISA) Server 2004 Unleashed
    ISBN: 067232718X
    EAN: 2147483647
    Year: 2005
    Pages: 216
    Authors: Michael Noel

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net