- Understanding the Need for ISA Server 2006
- Detailing the Additional Advantages of ISA Server
- Understanding the History of ISA Server 2006
- Exploring ISA Server 2006's New Features
- Detailing Deployment Strategies with ISA Server 2006
- Augmenting an Existing Security Environment with ISA Server 2006
- Administering and Maintaining an ISA Server 2006 Environment
- Using ISA Server 2006 to Secure Applications
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using ISA Server 2006 to Secure Applications
One of the distinct advantages to an ISA Server 2006 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 like 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 with ISA Server 2006
The current single most common deployment scenario for ISA Server 2006 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 2006 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 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.
)
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 2006 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 2006 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 2006, see Chapter 14.