Microsoft Internet Security and Acceleration (ISA) Server 2004 Unleashed - page 130

Summary

Messaging is one of the most critical components of an organization's IT structure, and is therefore one of the most obvious candidates to secure. Fortunately, ISA's securing capabilities in this realm are extremely strong, and ISA makes it possible to protect OWA, SMTP, OMA, RPC-HTTP, ActiveSync, POP, and IMAP messaging traffic and protocols, making it a versatile tool in the fight against modern viruses and exploits.

Best Practices

Use ISA to reverse-proxy web-based mail products, such as OMA and EAS whenever possible.
Use a second external IP address, DNS host, and certificate if forms-based authentication for OWA is required to co-exist with OMA, ActiveSync, and RPC-HTTP.
Use POP and IMAP sparingly and only when it can be secured through ISA server and when configured to use SSL encryption.
Configure the SMTP Screener component to filter both inbound and outbound SMTP traffic where possible.
Use a third-party SMTP anti-virus product to further extend the capabilities of ISA's SMTP Screener service.
Consider placing Exchange and other messaging servers in a dedicated screened subnet that is secured by an ISA Server.

Chapter 14. Securing Web (HTTP) Traffic

IN THIS CHAPTER

Outlining the Inherent Threat in Web Traffic
Publishing and Customizing Web Server Publishing Rules
Configuring SSL-to-SSL Bridging for Secured Websites
Securing Access to SharePoint 2003 Sites with ISA 2004
Summary
Best Practices

Although ISA Server 2004 is designed to handle any type of network traffic, it does particularly well in the filtering and securing of the Hypertext Transport Protocol (HTTP), the most common protocol used on the Internet and the transport mechanism for delivering website information, pictures, and video across the Internet.

ISA Server 2004's Application layer filtering technologies enable organizations to properly secure their outward- facing web services from external attacks such as Code Red, Nimbda, and future HTTP-based exploits yet to be written. Although standard packet filter firewalls are limited to opening a port for HTTP, ISA Server 2004 includes the capability to filter the HTTP traffic by host header, path , content type, HTTP commands, and a whole host of other filter options.

In addition to providing for secure web filtering options as an edge firewall, ISA Server 2004 also provides for robust reverse proxy options in the DMZ of an existing firewall, allowing for additional layers of protection and providing for capabilities such as end-to-end SSL encryption, link translation, and more.

This chapter focuses on ISA Server 2004's HTTP securing capabilities. ISA deployment scenarios as an edge firewall and a reverse-proxy server are outlined, and step-by-step guides for securing web servers, SharePoint sites, and other custom web applications are outlined.

Outlining the Inherent Threat in Web Traffic

The Internet provides somewhat of a catch-22 when it comes to its goal and purpose. On one hand, the Internet is designed to allow anywhere , anytime access to information, linking systems around the world together and enabling free exchange of that information. On the other hand, this type of transparency comes with a great deal of risk. It effectively means that any one system can be exposed to every connected computer, either friendly or malicious, in the world.

Often, this inherent risk of compromising systems or information through their exposure to the Internet has led administrators to lock down access to that information with firewalls. Of course, this limits the capabilities and usefulness of the free information-exchange system that web traffic provides. Many web servers need to be made available to anonymous access by the general public, which poses a particular dilemma: Organizations need to place that information online without putting the servers on which the information is placed at undue risk.

Fortunately, ISA Server 2004 provides for robust and capable tools to secure web traffic, making it available for remote access but also securing it against attack and exploit. To understand how it does this, it is first necessary to examine how web traffic can be exploited.

Understanding Web (HTTP) Exploits

It is an understatement to say that the computing world was not adequately prepared for the release of the Code Red virus. The Microsoft Internet Information Services (IIS) exploit that Code Red took advantage of was already known, and a patch was made available from Microsoft for several weeks before the release of the virus. In those days, however, less emphasis was placed on patching and updating systems on a regular basis, as it was generally believed that it was best to wait for the bugs to get worked out of the patches first.

So, what happened is that a large number of websites were completely unprepared for the huge onslaught of exploits that occurred with the Code Red virus, which sent specially formatted HTTP requests to a web server to attempt to take control of a system. For example, the following example URL lists the type of exploits that were performed:

http://www.companyabc.com/scripts/..%5c../winnt/system32/cmd.exe?/c+dir+c:\

This exploit in particular attempts to launch the command prompt on a web server. Through the proper manipulation, viruses such as Code Red found the method for taking over web servers and using them as drones to attack other web servers.

These types of HTTP attacks were a wakeup call to the broader security community. It became apparent that packet-layer filter firewalls that could simply open or close a port were worthless against the threat of an exploit that packages its traffic over a legitimately allowed port such as HTTP.

HTTP filtering and securing, fortunately, is something that ISA Server does extremely well, and it offers a large number of customization options that enable administrators to have control over the web server's traffic and security.

Securing Encrypted (Secure Sockets Layer) Web Traffic

As the World Wide Web was maturing, organizations realized that if they encrypted the HTTP packets that were transmitted between a website and a client, it would make them virtually unreadable to anyone who might intercept those packets. This led to the adoption of Secure Sockets Layer (SSL) encryption for HTTP traffic.

Of course, encrypted packets also create somewhat of a dilemma from an intrusion detection and analysis perspective because it is impossible to read the contents of the packet to determine what it is trying to do. Indeed, many HTTP exploits in the wild today can be transmitted over secure SSL-encrypted channels. This poses a dangerous situation for organizations that must secure the traffic against interception, but must also proactively monitor and secure their web servers against attack.

ISA Server 2004 is uniquely positioned to solve this problem, fortunately, because it includes the capability to perform end-to-end SSL bridging. Because the SSL certificate from the web server is installed on the ISA Server itself, along with a copy of the private key, ISA can decrypt the traffic, scan it for exploits, and then re-encrypt it before sending it to the web server. Very few products on the marketplace do this type of end-to-end encryption of the packets, and fortunately ISA allows for this level of security.