The Microsoft ISA website contains lots of new information and guidance detailing how to security messaging environments(such as Exchange). Full details can be found here.
I’m sure many of you rely upon traditional firewalls from the prominent security vendors to protect your message infrastructure. I challenge you to consider exactly what protection such firewalls are really providing. Most firewalls focus their attention purely on information contained in the packet header and ignore the payload of the packet. Decisions are made based on information which can easily be tampered with – as is the case with the entire packet header – to determine whether traffic should be allowed to flow through the firewall – this is a crazy basis for securing the sensitive information in modern enterprises.
What is the difference in security terms between a firewall that ignores the content of the payload and a router – in my opinion there’s no difference at all and yet many organisations rely upon such technology to protect them.
This post is not intended to spark undue concern, merely to challenge your thinking on effective firewalling. For those of you who attend information security shows (such as InfoSec which takes place in London next week) you’ll be familiar with the “scare ’em” technique that’s often used in abundance. There are Firewalls out there that you may already own which can guard against the threats I’ve outlined – make sure you enable such features if you have them OR add an additional firewall that does inspect the payload.
At Microsoft we use the term “Application Firewalling” to describe inspection of the payload – Internet Security and Acceleration Server(ISA) is a product which exemplifies this technique. My job is not to push product at you, merely to raise your awareness of how to secure your environments with the minimum of fuss expense or complexity.
The documentation provided on the Microsoft ISA website explains in detail how ISA inspects both the header and payload to ensure that only valid(authenticated, RFC compliant) traffic reaches your message infrastructure. Specifically ISA can secure communications for the following scenarios:
- Outlook Web Access(OWA) to Exchange
- Outlook “thick(!)” client to Exchange
- Exchange to Exchange
- Outlook Mobile Access(OMA) to Exchange
Let’s look at the first scenario for a moment.
The user fires up their browser with a URL such as https://mail.contoso.com – clearly this signifies to establish a secure(SSL) connection with the target webserver – by default this traffic will hit port 443 on the webserver. The Outlook Web Access(OWA) server pages will be hosted on the webserver to provide a communications path to the Exchange server(s) which in turn handle the messaging infrastructure. The webserver will challenge the user to prove their identity(authenticate), if successful then a communications session will be enabled for the user’s browser session to transact with the Exchange server infrastructure.
Conventional thinking suggests placing a firewall between the webserver and the external network from which the user’s browser would be connecting. With a non-application aware firewall(that’s pretty much every firewall out there!) “protecting” the server environment then the incomming traffic (browser to webserver) will be inspected to ensure that it’s free of packet-header based denial of service attacks and that’s about it.
Placing ISA between the browser and webserver and configuring it to publish OWA results in real protection as follows:
- ISA will host the OWA forms based authentication pages thus ensuring effective authentication without the risk of denial of service to the web server. ISA actually pre-authenticates the user’s session and forwards their credentials to the webserver therefore providing single-sign-on.
- ISA will ensure that ONLY RFC compliant HTML is passed through the firewall to the webserver thus preventing tunnelled traffic which could be a hidden attack
- ISA can be configured (via ISA Graphical User Interface(GUI) or scripting of the XML policy) to block specific keywords or application commands
- ISA can integrate with a vast range of security applications including many anti-virus, anti-spam, content filtering, intrusion detection technologies to enable them to inspect the traffic
It’s important to understand that just because traffic has a destination port of 80 it’s not safe to assume that it’s actually HTTP, likewise 443 can’t be relied upon to be SSL/TLS. It’s only by inspecting the payload that a firewall can make sure that the traffic is actually that which is intended.