• What's New and Cool in ISA Server 2006
• 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. What's New and Cool in ISA Server 2006

It seems like only yesterday when we saw the release of the 2004 ISA firewall. It felt like decades between the releases of ISA Server 2000 and ISA 2004. Not so for the upcoming ISA Server 2006 product! It should be available sometime later this year.

I've noticed a few of you are concerned about having to learn about the new ISA firewall, as you've been working hard trying to understand ISA 2004. I can understand your concern, as there was a steep learning curve between ISA Server 2000 and ISA 2004. The good news is that you won't have to worry about a difficult learning curve with the 2006 ISA firewall because it looks and works almost exactly the same as 2004. The only things you need to get a handle on are the new features.

First, it might be a good idea to discuss what the 2006 update is all about. What ISA Server 2006 brings to the table are significant enhancements to the ISA firewall's Web proxy and caching feature set. Web proxy and Web caching are hot topics these days and the ISA firewall is staying in touch with them. ISA Server 2000 and ISA 2004 are already the thought leaders when it comes to Web proxy and Web caching, and the ISA Server 2006 update further solidifies the ISA firewall as the leader in the Web proxy and caching space.

So, what are some of the things the ISA Server 2006 Web proxy and caching update brings to the plate? Get this:

• Enhanced SharePoint Portal Server support. ISA Server 2006 was designed from the ground up to provide high security for remote access connections to SPS
• Enhanced Exchange Web Services support. This includes enhancements in security for publishing OWA, OMA, Exchange ActiveSync, and RPC/HTTP. In addition, the ISA Server 2006 Web proxy and caching updates are fully ready to support new features included in Exchange 12 - including secure access to network shares (yes, that's an SSL VPN!).
• Single sign on. ISA Server 2006 provides for single sign on for published Web sites. When a user logs on to OWA and then wants to access information stored on the SharePoint Portal Server, the user doesn't have to log on again. Single sign on significantly improves the end user experience
• New authentication options for Web Publishing Rules. With the Web proxy updates included in ISA Server 2006, the ISA firewall will be able to delegate much more than basic authentication. There will be support for Kerberos delegation, NTLM authentication, and much more. Support for Kerberos constrained delegation enables you to use user certificate authentication and delegate it as Kerberos authentication
• Web publishing load balancing for Web farms. This new Web proxy update included in the ISA Server 2006 firewall will allow you to publish a Web farm and have those connections automatically load balanced and fault tolerant. If one of the members of the farm becomes unavailable, the ISA firewall will be aware of the downed status of that server and rebalance the connections to an online Web server. All this is done without having to get involved with the complexities and network infrastructure issues involved with NLB
• Enhanced link translation. Link translation enables the ISA firewall to rewrite URLs so that private URLs that are hard coded into Web pages returned to users are rewritten to include publicly available links. With previous versions of the ISA firewall, the link translation dictionaries had the potential to become very complex depending on the number of sites you published. With the ISA Server 2006 Web proxy and caching updates, link translation dictionaries build themselves in the background and require a fraction of the administration overhead seen with previous versions

In addition to these Web proxy and caching features, the ISA Server 2006 firewall will include all the features included in the ISA 2004 Service Pack 2 updates for branch offices. Much of the SP2 update for branch offices feature set was targeted at the Web proxy and caching components of the ISA firewall. These include:

• BITS caching. BITS caching allows the ISA firewall's Web proxy and caching components to cache not only completed files, but also range requests. The caching methodology allows the ISA firewall to cache content from Windows Update and Windows Server Update Services (WSUS). This has the potential to significantly cut bandwidth utilization on both Internet and WAN links, making that bandwidth available for other uses
• Diffserv support. Diffserv allows you to prioritize packets by setting bits in the TOS IP header. The ISA firewall's SP2 updates and those included in ISA Server 2006 will allow you to apply Diffserv QoS features to HTTP communications. This allows you to configure preferential service for mission critical URLs.
• Web compression support. Internet Web servers can compress their responses before returning them to the Web proxy. With the ISA 2004 SP2 updates and with the ISA Server 2006 Web proxy and caching feature enhancements, the ISA firewall can be configured to support Web compression and decompression for both Web publishing and forward proxy scenarios. Support for compressed content can significantly save on bandwidth cost and utilization and free up that bandwidth for other network applications.

Although the bulk of the improvements have been in the Web proxy and caching features, there is an improvement in the next ISA firewall's firewall feature set: enhanced Worm and flood protection. This feature builds on the flood protection included with ISA 2004.

For more information on ISA Server 2006, check out the Microsoft ISA Web site at www.microsoft.com/isaserver. And if you want to get a first look at the installation experience for beta 1, then check out my article at http://www.isaserver.org/tutorials/ISA-Server-2006-Installing-ISA-2006-Enterprise-Edition-beta-Unihomed-Workgroup-Configuration.html

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

Quote of the Month - "Whether you think you can or can't, you're right" -Anon.

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

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:

• ISA Server 2006: Installing ISA 2006 Enterprise Edition (beta) in a Unihomed Workgroup Configuration
• Hardening ISA Server 2004 (Part 2)
• ISA Firewall Quick Tip: Controlling Access to Published RDP Servers
• Hardening ISA Server 2004 (Part 1)
• ISA Firewall Quick Tip: Blocking MSN Messenger Access through the ISA Firewall while Enabling Access to Some Users
• Installing and Configuring Microsoft ISA Server 2004 SP2
• ISA Server 2004 Best Practice Analyzer

4. KB Articles of the Month

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

• Scenarios that are supported when you run ISA Server 2004 on a computer that has only one network adapter
• Changes that you make in the ISA Server 2004 firewall client program are not applied to all users
• The Advanced Logging (MSDE) component and the Firewall Client share component may not install correctly when you run the ISA Server 2004 Setup program
• 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
• Users receive an "Error Code 502: Proxy error. The parameter is incorrect. (87)" error when they visit certain URLs after you configure HTTP content filtering based on signatures or on extensions in ISA Server 2004
• Error message when you try to connect to a Web site that is published by using ISA Server 2004 Service Pack 2: "403" or "500"
• Web proxy clients cannot access some Web sites through ISA Server 2004
• The Firewall service may not start in Internet Security and Acceleration (ISA) Server 2004 after you select a certificate for a, SSL listener
• Changes that are made to the Cache Array Routing Protocol (CARP) in ISA Server 2004 Service Pack 2
• You may receive a "Setup failed while creating the services configuration" error when you try to install ISA Server 2004 on a Windows Server 2003-based domain controller
• The daily summary and the log report do not contain details of network traffic that passes through an ISA Server 2004 computer
• ISA Server 2004 stops forwarding traffic between networks and the Internet

5. Tip of the Month

A lot of ISA firewall admins would like to bind multiple certificates to a single Web listener that listens on a single IP address and use that listener to publish multiple SSL Web sites. While that would be nice, it doesn't work. It's not an ISA firewall issue, but a basic SSL issue. This month's "tip" is not so much of a tip but instead is an explanation on this issue. Once you understand the problem by reading the information below, you'll stop asking for this feature:

"Binding several server certificates to a single IP is not supported by SSL protocol (at least by the current versions).

The reason is simple, when the client sends the "CLIENT HELLO", server is expected to send back a server certificate. However, the "CLIENT-HELLO" does not contain any indication to the name of the server that the client is interested in (this indication appears only in the Host header of the HTTP request, sent only *after* the SSL handshake have already been established). Server has no choice but to return a single server certificate per the (IP,Port) pair (aka listener), which is the only thing he "knows" before receiving the HTTP request.

Future versions of SSL protocol may support this. If case they do, ISA will probably use this support to allow multiple server certificate assigned to a single IP.

The multiple certificates per IP in ISA 2006 is targeted in completing the SSO scenario. ISA 2006 provides SSO, when administrator uses with a single listener. E.g. administrator can configure two publishing rules for site1.contoso.com and site2.contoso.com assigend to the same web listener (with SSO domain: contoso.com), in a way, that will require user to uthenticate only once.

However, since user might probably use SSL, the administrator must be able to return two different server certificates from the same listener. He (the administrator) will still have two use at least two IPs on that listener due to the issue described in the first paragraph."

6. ISA Firewall Links of the Month

Want to run your TSAC/Remote Desktop Web site on an alternate port? Check out:

http://forums.isaserver.org/m_2002003033/mpage_1/key_/tm.htm#2002011551

With the Service Pack 2 branch office updates, you get Diffserv support for the HTTP protocol. Do you know what Diffserv is and what it does? If not, check out:

http://www.rhyshaden.com/qos.htm

Need information on a true silent installation of the ISA Firewall Client? Then head on over to the ISAserver.org Web boards at:

http://forums.isaserver.org/m_410002100/mpage_1/key_/tm.htm#2002011132

Have you been asked to assess the ISA firewall's performance? There are many ways to test firewall performance, some better than others. Check out this article for an insightful analysis on how to performance test firewalls and what those "hardware" firewall vendors don't want you to know:

http://www.scmagazine.com/asia/news/article/419801/a-practical-realistic-approach-testing-performance-firewalls-security-vendors-dont-want-know/

Tired of reading but still want more information about the ISA firewall? Then check out some ISA firewall Webcasts. There's a bunch of them here (some of them were even done by me!):

http://www.microsoft.com/events/series/isaserversecurity.mspx and

Did you know that there are "hardware" versions of the ISA firewall? If you're not into white box implementations, and want a hardware firewall vendor to install, configure and manage your ISA firewall, then check out your ISA hardware firewall options here:

http://www.microsoft.com/isaserver/hardware/default.mspx

7. Ask Dr. Tom

QUESTION: I notice that you don't have a lot of information on the ISAserver.org site on how to harden the ISA firewall. It seems to me that since the ISA firewall runs on Windows that it would be critical to include hardening as a core post-installation task. What's up with that? -David.

ANSWER: That's an excellent question. I get a lot of calls with questions regarding "hardening" the ISA firewall. Its interesting that people worry about hardening the ISA firewall, but accept without question the default configuration of most "hardware" firewalls, where these devices allow all traffic outbound (and without authentication!) and have default passwords and other insecure default settings.

My stance on system hardening for the ISA firewall is that if you don't enable access to the service via firewall policy, it doesn't matter how secure that service is because no one is going to be able to take advantage of it. For example, suppose there is a problem with the server service on the ISA firewall. One option is to disable that service. Another option is to not allow access to the service. In both cases, no one will be able to access the service to exploit it.

One argument might be "yes, but if you don't disable or uninstall the service, an attacker that 'owns' the ISA firewall could leverage that service in an attack". That's true, but if your ISA firewall is "owned" to the extent where they can change firewall policy, then they have owned it enough to start services and even install new Windows components.

Given that this is true, why waste a lot of time "hardening" the ISA firewall to disable and remove services? You time is better spent (and it will be faster) studying and configuring the ISA firewall's system policy and locking down any and all Access Rules that control traffic to and from the ISA firewall's Local Host Network. Once you do that, it doesn't matter what's running on the ISA firewall, since no one is going to get at it.

However, one way you can completely harpoon your ISA firewall configuration is to install extraneous services on the ISA firewall and use the firewall as a workstation. For example, you should never configure the firewall as a domain controller, or run Web sites on the firewall. In addition, you should never use client applications on the ISA firewall. That means you never run Outlook Express, Internet Explorer, or any other client application that opens a hole for exploits. Of course, network monitoring and diagnostic tools are an exception. Tools such as Network Monitor, ping, tracert, arp, etc are all legitimate tools for use on the ISA firewall.

Note that I'm not saying that comprehensive "hardening" of the ISA firewall isn't without merit. If you have a lot of spare time to carry out the hardening process, and have even more spare time to troubleshoot the unintended side effects of such "hardening", then knock yourself out and go for it. Microsoft has comprehensive guidance on ISA firewall system hardening over at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/securityhardeningguide.mspx. You can also use the Windows Server 2003 Security Configuration Wizard (SCW) to perform some system hardening. Check out my article on this subject at http://www.isaserver.org/tutorials/Windows-Server-2003-Security-Configuration-Wizard-Harden-ISA-Firewall.html

QUESTION: I've read in a lot of places on the ISAserver.org site that joining the ISA firewall to the domain is a best practice. The problem is that I have to deal with "open a port" network guys who don't understand the ISA firewall and who are also totally clueless about application security. Can you tell me when the ISA firewall should always be joined to the domain, when it might be joined to the domain, and when you might not join the ISA firewall to the domain? Thanks! -Mike.

ANSWER: Domain membership for the ISA firewall generates more FUD than just about any other area of ISA firewall deployment and configuration. One of the problems with domain membership is that network infrastructure staff who don't understand the ISA firewall and network security in general have an inordinate amount of input regarding how the ISA firewall should be deployed. Another major problem is that compliance "auditors", with clipboard and checkboxes in hand, state that the ISA firewall cannot be joined to the domain.

The "auditors", like the network infrastructure guys, have no idea why the ISA firewall shouldn't be joined to the domain. It's some kind of "tribal knowledge" handed down from one clueless reporter to another. It often reminds me of Columbus, when the tribal knowledge of the day said that he would fall off the edge of the flat Earth. Fortunately, the tribal knowledge then was wrong, and the tribal knowledge regarding the ISA firewall is equally wrong.

OK, now that we have the realities of network politics out of the way, let's answer the questions.

The ISA firewall should always be joined to the domain when:

• The ISA firewall has an interface on the user network. This enables authentication for all connections to and through the ISA firewall. This is a real compliance issue, unlike the guy with the clipboard with the checkboxes
• When the ISA firewall is a back end firewall behind another firewall (the front-end firewall can be an ISA firewall or a third party firewall

• The ISA firewall is configured as a unihomed Web proxy only device for outbound connections. In this case, you can use RADIUS authentication for outbound Web connections. However, you must deal with the performance and authentication limitations of RADIUS
• The ISA firewall is configured as a unihomed Web proxy only device for inbound connections (Web Publishing Rules). In this case, you can use RADIUS authentication for inbound authentication and deal with the performance and authentication limitations of RADIUS

• The ISA firewall is a front-end firewall with another ISA firewall behind it acting as a back-end ISA firewall. In this case, the back-end ISA firewall is joined to the domain, while the front-end ISA firewall is configured in standalone mode.
• There is no domain to join
• When the ISA firewall is configured never to require authentication