• ISA Firewall's Getting Ready for a Whale of a Good Time
• Tom and Deb Shinder's Configuring ISA Server 2004 -- Order Today!
• ISAserver.org Learning Zone Articles of Interest
• KB Articles of the Month
• Tip of the Month
• ISA Firewall Links of the Month
• Ask Dr. Tom

1. ISA Firewall's Getting Ready for a Whale of a Good Time

One of the sore points ISA firewall fans and admins have had to deal with for some time is the issue of SSL "VPN". This issue has been a complicated one, because most people aren't really sure why they need an SSL VPN. One camp says they want a "clientless" solution and another camp says they need firewall transparency. Other camps aren't even sure why they need an SSL VPN, but they think they need it because everyone else seems to want an SSL VPN.

SSL "VPN" technology has matured over the last few years. Historically, there have been four main types of SSL "VPNs":

• Reverse Web proxy for Web-enabled applications
  This type of SSL VPN takes advantage of server applications that have built-in support for Web access to server hosted data. Microsoft Office Outlook Web Access is the best example of this type of application. Microsoft Internet Security and Acceleration (ISA) Server 2004 provides the reverse Web proxy for the Outlook Web Access site.
• Reverse Web proxy with application gateways for non-Web-enabled applications
  For server applications that do not have native Web integration, some SSL VPNs include application gateways that translate data returned from the server application and reformat the server data dynamically so that it can be rendered in a Web browser.
• Application proxy for HTTP encapsulated client/server protocols
  Some SSL VPNs enable client applications on the SSL VPN client to encapsulate or "wrap" the native server application protocol in an encrypted HTTP header (SSL). The encapsulated communications are sent to an SSL VPN proxy that "unwraps" the HTTP header and exposes the native application protocol and forwards it to the server. Outlook 2003 RPC over HTTP is an example of this type of SSL VPN, and ISA Server 2004 can provide reverse proxy for the encapsulated connection.
• Network extension
  SSL VPNs that act like network level VPNs are referred to as network extension SSL VPNs. These SSL VPN implementations can make the SSL VPN client a virtual node on the corporate network and provide functionality for all protocols, including complex multi-connection application protocols.

ISA firewall provide SSL VPN functionality for the first and third types of SSL VPNs. For example, you can use the ISA firewall as an SSL VPN secure reverse proxy for OWA, OMA, and Exchange ActiveSync because these are Webified versions of the core Exchange Server services.

The ISA firewall can also provide SSL VPN functionality for non-Webified applications, but this functionality is limited to providing a secure reverse application proxy for Outlook 2003 RPC/HTTP clients.

The major shortcomings in the ISA firewall SSL VPN story are the second and third types of SSL VPNs mentioned above. These two types allow organizations access to key business applications that aren't already Webified. And while SSL VPNs aren't in widespread use at this time, the adoption rate of SSL VPNs is on an accelerating curve and when prices come down from their current confiscatory levels, you'll find that SSL VPN will be sine qua non for just about any network.

This is why Microsoft's acquisition of Whale last week is a significant event. Whale is a thought leader in the SSL VPN space and Microsoft's acquisition is a major investment in the future of SSL VPN technology and the ability to make it available to the general public. While the main story might seem that the Whale acquisition is a "catch up" play for the ISA firewall, I think the major story here is that Microsoft will make SSL VPNs an affordable technology for the masses, just as the ISA firewall enables companies to have the same level of security as a Check Point or a PIX, but at a much lower price.

What do you think? Do you think the Whale acquisition is a big deal? Let me know at tshinder@tacteam.net

=======================

Quote of the Month - "Natural ability without education has more often attained glory and virtue than education without natural ability." - Cicero (106 BC - 43 BC).

=======================

2. Tom and Deb Shinder's Configuring ISA Server 2004 - Order Today!

By Thomas W Shinder Tom and Deb Shinder's best selling books on ISA Server 2000 were the "ISA Server Bibles" for thousands of ISA Server 2000 network administrators. Tom and Deb Shinder present you with their next ISA Server book, Configuring ISA Server 2004. This book leverages the over two years of pre-release experience Tom and Deb have had with ISA Server 2004, from pre-alpha to RTM and all the versions and builds in between. They've logged literally 1000's of flight hours with ISA Server 2004 and they have shared the Good, the Great, the Bad and the Ugly of ISA Server 2004 with their no holds barred coverage of Microsoft's new one of a kind application layer inspection firewall. While the ISA Server 2000 books were good, Configuring ISA Server 2004 is even better. Tom and Deb bring their unique "insider's perspective" to provide you with information that isn't and won't be available anywhere else! Order your copy of Configuring ISA Server 2004 by clicking the link. You'll be glad you did.

Click here to Order your copy today

3. ISAserver.org Learning Zone Articles of Interest

We have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:

• Optimizing ISA performance (Part One) - Nine Basic Steps
• ISA Server 2006: Installing ISA 2006 Enterprise Edition (beta) in a Unihomed Workgroup Configuration - Post Installation Tasks Part 4
• Configuring Domain Members in a Back to Back ISA Firewall DMZ - Part 1: Concepts in DMZ/Perimeter Networking and Security Zones
• ISA Server 2006 Overview
• Configuring Domain Members in a Back to Back ISA Firewall DMZ - Part 2: Configuring the Back-end ISA Firewall
• Optimizing ISA performance (Part Two) - Performance Tweaking
• Configuring Domain Members in a Back to Back ISA Firewall DMZ - Part 3: Configuring the DMZ Web Server and Front-end ISA Firewall

4. KB Articles of the Month

Here are some interesting and useful ISA Server related articles posted by Microsoft in the last month:

• Update for HTTP issues in Internet Security and Acceleration Server 2004 Service Pack 2
• You receive error messages if the Internet Security and Acceleration Server 2004 Firewall Client program is configured for auto-discovery or if you try to configure this program for auto-discovery
• When you configure the No Connectivity alert to send an e-mail notification to an SMTP server, only every second e-mail notification may reach the recipient in Internet Security and Acceleration Server 2004
• Error message when ISA Server 2004 Web Proxy client users try to access an external FTP site by using passive FTP functionality: "Error Code: 502 Proxy Error"
• Error message when you try to access a Web site from a Web browser client that is located behind a computer that is running ISA Server 2004 with SP2: "Error Code: 502 Proxy Error"
• VPN connections time out when the "Requests appear to come from the ISA server computer" server publishing rule is applied in ISA Server 2004
• A client computer connection request fails, or the client takes a long time to connect to a secure Web site through a downstream ISA Server 2004 proxy server
• The daily summary and the log report do not contain details of network traffic that passes through an ISA Server 2004 computer
• Web proxy clients cannot access some Web sites through ISA Server 2004
• The ReturnAuthRequiredIfAuthUserDenied property setting does not work if the access rules include a Content Type rule in ISA Server 2004
• You cannot specify a path statement that ends in a wildcard character when you create a Web publishing rule in ISA Server 2004

5. Tip of the Month

The HTTP Security Filter can be configured for both forward and reverse proxy scenarios. The most common reverse proxy configuration is to publish OWA, OMA, Exchange ActiveSync and RPC/HTTP. Here are some tips on which to watch out for when configuring the HTTP Security Filter for your Exchange Web Publishing scenarios:

• Blocking .exe file extensions and enabling Block responses containing Windows executable content for Outlook Web Access will block access to the S/MIME control. If the S/MIME control is required for Outlook Web Access on Exchange Server 2003, do not include .exe in the blocked extensions list or enable Block responses containing Windows executable content.

• Blocking .dll file extensions for Outlook Web Access will block access to the online spelling checker that is built into Outlook Web Access.

• Including the strings "..", "%", and "&" can prevent certain types of potential attacks but it will also reduce access to certain e-mail messages. An e-mail message subject line forms part of the URL to access the message and thus any e-mail message containing one of these characters will be blocked. A balance must be found between extra security and functionality. Do not include the ":" character in this list because this will block access to the majority of e-mail messages. Many message subject lines contains RE: and FW: if they are replies or forwards.

For more information on how to configure the HTTP Security Filter in a number of scenarios, check out: http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/httpfiltering.mspx

6. ISA Firewall Links of the Month

Microsoft Virtual Lab Express: Introduction to ISA 2006 Beta
http://www.microsoftvirtuallabs.com/express/registration.aspx?LabId=83ea771a-9cf7-4c6a-b520-080b78849561

Secure Application Publishing with ISA Server 2006 Virtual Lab
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032291850&EventCategory=3&culture=en-US&CountryCode=US

Branch Office Gateway and Web Access Protection with ISA Server 2006 Virtual Lab
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032291851&EventCategory=3&culture=en-US&CountryCode=US

Case Studies About ISA Server 2004 Key Scenarios
http://www.microsoft.com/isaserver/evaluation/casestudies/scenarios.mspx

ISA 2004 Common Criteria Evaluation
http://www.microsoft.com/isaserver/techinfo/deployment/commoncrit.mspx

7. Ask Dr. Tom

QUESTION: I've brought an ISA firewall into our network and am wondering what is the best method for publishing my front-end Exchange Server. I've read the Microsoft Exchange Server team's recommendations on putting the front-end and back-end Exchange Servers on the same network, but that doesn't seem right to me. Do you have any recommendations?

ANSWER: You're right to be a bit suspicious about putting the front-end and back-end Exchange Servers on the same network. The reason for this is that the front-end Exchange Server is an Internet facing device. It's a universally accepted concept that Internet facing devices need to be placed in a separate security zone that is distinct from the security zones that non-Internet facing devices are located. Because the front-end Exchange Server is an Internet facing device and the back-end Exchange Server is not an Internet facing device, standard computer security practice is to put them on different networks.

A more secure configuration is to put the front-end Exchange Server in an ISA firewall DMZ network. However, this DMZ network isn't a conventional DMZ. Instead, this DMZ network is an authenticated access DMZ. In an authenticated access DMZ configuration, users must pre-authenticate at the ISA firewall before the connections are allowed to the front-end Exchange Server. This type of DMZ is much more secure than a traditional anonymous access DMZ, where all Internet users are allowed access to the servers located on that DMZ.

One common misconception is that you need to make "swiss cheese" out of the firewall to allow the intradomain communications between the authenticated access DMZ. This is a canard because you only need to allow five protocols between the authenticated access DMZ and the back-end Exchange Server and DCs for this to work. This is in stark contrast to the thousands of protocols that would be allowed when the front-end and back-end are in the same security zone.

Remember, the core concept in computer security is least privilege. The ISA firewall enables you to enforce least privilege between the front-end and back-end Exchange Servers and thus insures the most secure configuration possible.

Got a question for Dr. Tom? Send it to tshinder@isaserver.org.