• Teaching Security to Non-ISA Firewall Administrators
• Tom and Deb Shinder's Configuring ISA Server 2004 -- Order Today!
• ISAserver.org Learning Zone Articles of Interest
• KB Articles of the Month
• Post of the Month
• ISA Firewall Links of the Month
• Ask Dr. Tom

1. Teaching Security to Non-ISA Firewall Administrators

I often get to work with non-ISA firewall administrators who are in the position of introducing an ISA firewall into their corporate networks. These non-ISA firewall admins are typically part of the network infrastructure team, and they manage not only the firewalls, but also network devices such as routers and switches. Because of this, it's often difficult to communicate with these people that there is no magic protection provided by hardware devices and that all computing devices depend on both hardware and software.

My conversations with these people are often extremely interesting and I learn much more from them than they might ever learn from me. One thing I've learned from these folks is that many of them don't really understand that the role firewalls play when protecting network perimeters have changed since the mid to late 1990s, which is when most of these people began their networking education and joined the community of IP networkers.

Since you're reading this newsletter, you either have an ISA firewall on your network, or you want to bring one onboard. In both these cases, there's a good chance that you'll have to interface with people who'll give you some push-back on introducing or integrating the ISA firewall to the corporate network's security infrastructure.

To help you deal with these people more effectively, I'll share with you some of the content of an e-mail I had a chance to read last week from someone who manages a non-ISA firewall network infrastructure. As you'll see when reading through this interaction, this fellow felt (note I say felt, not thought, because none of the opinions expressed we're backed up with facts) that introducing the ISA firewall into his network would reduce his overall security posture.

What he didn't realize is that by taking a stance based on ignorance of modern network security principles, he was actually trying to come up with arguments that would reduce the overall security of his company's Exchange organization.

We'll take a look at what this non-ISA firewall administrator had to say and comment on it, so that you can come back with some effective arguments when you run into similar people. The sections in quotation marks are those of the non-ISA firewall admin.

"Our Microsoft administrator wants to multihome an ISA firewall on our web DMZ with the other NIC connected to our internal network to allow the ISA firewall to communicate to the internal Microsoft Outlook Web Access (OWA) front end Exchange Server, which then communicates with the back-end Exchange Servers. All this to allow users on the Internet to access Exchange via a web browser."

No problem here. The ISA firewall provides a unique level of protection for remote access to all the Exchange Server services. The "Microsoft admin" probably has performed due diligence and learned that the ISA firewall is a true network firewall that performs both stateful packet inspection (stateful packet filtering) and stateful application layer inspection (application layer filtering) and that is has several technologies included in it, right out of the box, to provide secure remote access solution to Exchange. The "Microsoft admin" probably is very security conscious and realizes that heterogeneous firewall environments are more secure than a single firewall solution.

"I've read a lot of the documentation on the whole Windows2003 Exchange web pages solution and I think Microsoft is trying to bad mouth other firewalls while touting their own proxy/packet firewall as good as or better than "the rest of the world". Problem is, Checkpoint/Nokia is a far better technical solution compared to MS ISA (MS bigots take a deep breath and count to ten)."

I've heard a few non-ISA firewall admins state something similar to this. If we pin down this non-ISA firewall admin, you'll see that there is no information anywhere on the Microsoft Web site that "bad mouths" other firewalls or that implies that it's better than any other firewall in the world.

What is on the Microsoft Web site is information on how the ISA firewall provides a unique level of protection for remote access connections to Microsoft Exchange Servers and services, and that the ISA firewall is a stateful packet inspection and stateful application layer inspection firewall.

The statement that Checkpoint/Nokia or any other firewall represents a better technical solution shows that the non-ISA firewall admin has definite knowledge issues. This is one of the biggest problems you'll run into with the non-ISA firewall admin. They typically know nothing about the ISA firewall, and assume that it's just a "proxy" server.

The problem is, they don't really understand what firewalls are, what proxy servers are, and the types of security conferred by firewalls and proxies. They get into even more trouble when confronted with a blended packet filter/proxy firewall like the ISA firewall. You can counter these guys by asking them for specifics:

• How is the current firewall a better "technical" solution? How is it a better technical solution when it comes to providing specialized protection for the servers and servers the firewall is protecting?
• What specific technologies does the current non-ISA firewall have to provide unique network and application layer protection for the service require protection? Make sure to have him provide the specific application layer inspection and protection features. Any firewall on the market today performs layer 3 and 4 protection, so stateful packet inspection alone doesn't differentiate any firewall from another (in general).
• Where are the specific documents on the Microsoft site that say that the ISA firewall is categorically better than any other firewall?

These are easy questions to ask, and when the non-ISA firewall admin comes up empty, it softens him up for the rest of your interaction.

"I asked the Microsoft admin to single home his ISA firewall or forget about the ISA firewall altogether and just run a front end server in the web DMZ. The idea of breaking our Checkpoint architecture with an multihomed ISA firewall that interfaces with the internal network and our web DMZ is just too much to ask a decent security admin don't you think. Now I need ammunition to press the point home."

There are some profound security problems with the non-ISA firewall admin's requirements.

Right now, all we have is a single vendor firewall solution, which is Checkpoint in this example. A more secure configuration is to have multiple firewalls, from multiple vendors, interposed between the Internet and the protected services. A single NIC ISA firewall can't provide firewall protection for the Exchange Servers, because it needs to be in the path between the source and destination and connections must be forced through the ISA firewall. A single NIC configuration is easy to bypass because the ISA firewall can't be put in the path.

So, we see that the non-ISA firewall admin is actually attempting to reduce the overall security of his corporate network. This is a dangerous situation for this company's Exchange organization.

The next concern is that the non-ISA firewall admin in this example is concerned about the ISA firewall somehow "breaking" his Checkpoint solution. How could the ISA firewall break an existing firewall infrastructure? We have to read between the lines here. Its could be that the non-ISA firewall admin doesn't really understand how to configure the Checkpoint firewall and is concerned having to learn more to make minimal configuration changes on the non-ISA firewall to support the enhanced security solution provided by bringing the ISA firewall into the mix. It could be that the non-ISA firewall is too busy to make the required changes. Or, it could be that the non-ISA firewall admin is trying to justify the premium prices he's asked the company to pay for their current hardware firewall solution and would be embarrassed that the ISA firewall provides the same protection at a fraction of the price.

A blanket statement like "a multihomed ISA firewall is too much to ask of a decent security admin" sounds more like a canard than something a serious network professional would say.

Probably the best way to approach this problem is to query the non-ISA firewall admin on what he knows about the ISA firewall's security model. If he says "it's just a proxy server" or "it's just a software firewall" or "it runs on Windows" then you know that you're dealing with someone with a significant knowledge gap and you can help educate this person by pointing him to ISA firewall technical resources.

"A few questions:
1. If any of you run an ISA firewall for tunneling for the front end server I'd like to hear if you were able to do it using single homing (the documents say it's possible but not recommended and our Microsoft admin says he can't get it to work)."

Bingo! We now have the answer to the level of sophistication the non-ISA firewall admin has regarding what network security is all about. SSL tunneling is a dangerous situation, because the perimeter devices, like the firewalls, are typically not able to inspect data inside the SSL tunnel. The typical firewall admin is just concerned about "opening ports" and blocking network layer attacks against the firewall device itself.

This non-ISA firewall admin wants to tunnel an SSL connection to the Exchange Server, which prevents any stateful application layer inspection from taking place at the perimeter and leaves the entire responsibility for protecting the front-end Exchange Server to the front-end Exchange Server itself.

The ISA firewall performs SSL to SSL bridging, so that the ISA firewall can perform stateful application layer inspection on the commands and data moving inside the SSL tunnel between the Web client and the front-end Exchange Server. Their current firewall solution can't do this, so it's quite easy for any attacker to tunnel through the Checkpoint device to attack the front-end Exchange Server. In contrast, the ISA firewall's SSL to SSL bridging feature set makes it easy to stop out of bounds HTTP commands and data at the ISA firewall itself and prevents exploits from ever getting near the front-end Exchange Server.

In addition, the ISA firewall can pre-authenticate users and leverage forms-based authentication to further secure the connection. So, not only does the ISA firewall prevent attacks from hiding in an SSL tunnel through the firewall, you can prevent any unauthenticated and unauthorized connection to the front-end Exchange Server.

"2. Scrap the ISA server, I think the front end server should be on the web DMZ. Does everyone agree with this? Yes, I know I have to open up all those nasty MS ports but at least I can restrict it to talking to the DC's and a few other boxes - those would be hardened machines anyways."

This is really bad. Placing only a basic stateful packet inspection firewall in front of the front-end Exchange Server allows non-authenticated, non-authorized and non-inspected (at the application layer) connections to the Exchange Server's Web services.

This also shows a lack of concern over the overall security infrastructure, if he's willing to open the ports for intradomain communications instead of providing a good security solution, which is the ISA firewall. He ignores the advantages conferred by putting the ISA firewall behind the Checkpoint firewall, between the front-end Exchange Server and the Checkpoint firewall, not only for strong inbound access control and protocol inspection, but also for strong user/group based access control for all protocols by using the ISA firewall on the back-end.

"3. I think the Microsoft admin should just run a front end server internally and also another front end server on the web DMZ. That way, you can harden the web DMZ machine properly but don't have to worry about the one that's only for internal use (ok not too much worry). Make sense?"

No, it doesn't make sense.

Notice the pattern of thinking and rationalizing here. This actually isn't that unusual. What we have here is someone who doesn't understand the ISA firewall, and doesn't want to understand it. So, rather than making a due diligence attempt to understand the ISA firewall and the technologies used by the ISA firewall to provide a very secure remote access solution to Microsoft Exchange, he comes up with a bunch of low security options.

In and of itself, this doesn't make sense. But if you look at this in the context of someone who has a bias against Microsoft security technologies, perhaps an knowledge deficit regarding how firewalls and proxy works, and perhaps even a knowledge challenge regarding how to configure his current firewall solution, it all begins to make sense.

The key to getting your way with these non-ISA firewall admins is to be patient with them. While many of them might have an anti-Microsoft bias, this isn't always the case. Some of them just don't understand the importance of application layer inspection and they don't understand what the ISA firewall brings to the table when it comes to a strong defense in depth posture when providing secure remote access to Microsoft Exchange Servers and services.

If you find yourself in a similar situation where you want to bring an ISA firewall in to protect Microsoft Exchange, some things you can bring up are:

• The ISA firewall's Secure Exchange RPC filter that enforces protocol compliance on RPC communications between Outlook clients and Microsoft Exchange
• SSL to SSL bridging, which provides a secure end to end SSL connection, but also prevents attackers from hiding exploits in an SSL tunnel through the firewall
• Forms based authentication, which allows the ISA firewall to generate the form. The removes the requirement for allowing anonymous connections to the Exchange Server, and also allows you to enforce security policy on the OWA client
• The HTTP Security filter. You can configure the HTTP Security filter on the ISA firewall to block methods, headers, bodies and other aspects of an HTTP communications that are inappropriate when connecting to Exchange Server's Web services. Only known good commands and data are allowed to and from the Exchange Server
• Pre-authentication and authorization. The ISA firewall can authenticate users, and then authorize them before a connection to an Exchange Server's services is allowed. This prevents attacks from anonymous users, or users that authenticate but should not be accessing the Exchange Server from remote locations. RADIUS authentication can be used for ISA firewalls that aren't part of a Windows domain.
• Built in support for SecurID two-factor authentication. If you SecurID in place, you can take advantage of SecurID two-factor authentication to authenticate incoming connections to the OWA Web site.

Once the non-ISA firewall admin gets in tune with the security advantages conferred by these technologies, you'll find that not only will they be less resistant but they might even want to take over the management of the ISA firewall!

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:

• Enabling NLB Bi-Directional Affinity (BDI) on ISA Server 2004 Standard Edition Firewalls
• The ISA Firewall's Default Post Installation System Policy and Configuration
• Comparing the ISA Firewall to non-ISA Firewall Solutions
• Configuring Sites for Direct Access: Part 2 - Configuring Direct Access for Firewall Clients and Publishing Scenarios
• Configuring Sites for Direct Access: Part 1 - Configuring Direct Access for Web Proxy Connections
• How to build an ISA firewall lab with Virtual PC 2004
• ISA/SBS Series: Controlling Internet Access: Denying Access to Certain Websites During Business Hours by Amy Babinchak

4. KB Articles of the Month

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

• Cannot configure access to Exchange Server between two routed networks in ISA Server 2004
• Differences between server publishing rules and access rules in ISA Server 2004
• You receive a "The request was rejected by the HTTP Security filter" error message when you try to open a message from an Exchange Server that is published in ISA Server 2004
• The features and limitations of a single-homed ISA Server 2004 computer
• How to configure networks in ISA Server 2004
• Configuration changes that are made to Routing and Remote Access when you install Internet Security and Acceleration (ISA) Server 2004
• An unknown network protocol appears in an ISA Server report
• Active mode FTP client programs cannot access an FTP server from behind Internet Security and Acceleration Server 2004

5. Post of the Month

Been wondering about how the ISA firewall's HTTP Security Filter protects your company? Check out Jim Harrison's observations on a problematic application:

I was wandering through my ISA logs (I have no life; I admit it) and I discovered a little trick Fandango is using to insert ads into your browser:

http://www.fandango.com/eyeblaster/addineyeV2.html?strHTML=%3Cscript%3E%0D%0A%0A%3C%21--%0Avar%20gfEbInIframe%3Dfalse%3B%0Avar%20gEbAd%20%3D%20new%20Object%28%29%3B%0AgEbAd.nFlightID%20%3D%2061803%3B%0A//Remote%20servers%0AgEbAd.playRS%20%3D%20new%20Object%28%29%3B%0AgEbAd.playRS.strNUrl%20%3D%20%22http%3A//ad.doubleclick.net/imp%3Bv1%3Bi%3B12979394%3B0-0%3B0%3B5755652%3B468%7C60%3B8301289%7C8319185%7C1%3B%3Bcs%3Dy%253fhttp%3A//m3.doubleclick.net%22%3B%0A//Interactions%0AgEbAd.interactions%20%3D%20new%20Object%28%29%3B%0AgEbAd.interactions%5B%22_eyeblaster%22%5D%20%3D%20%22ebN%3Dhttp%3A//ad.doubleclick.net/click%253Bh%3Dv3%7C31f4%7C2%7C0%7C%252a%7Cm%253B12979394%253B0-0%253B0%253B5755652%253B1-468%7C60%253B8301289%7C8319185%7C1%253B%253B%257Esscs%253D%253fhttp%3A//m3.doubleclick.net%3B%22%3B%0A//--%3E%3C/script%3E%3Cscript%20src%3D%27http%3A//ds.serving-sys.com/BurstingScript/ebServing.js%27%3E%3C/script%3E

Luckily, since I run my own blocking scripts, the HTTP Filter saw the "%0D%0A" sequence and said "Heck NO!"

12217 0x80 Blocked by the HTTP Security filter: URL contains sequences which are disallowed

OK, you may ask - what does "%0D%0A " mean to me? When decoded, "%0A%0D" translates to <CR><LF>; something that should NEVER exist in a URL.

There are also other characters that are normally associated with a technique called "script injection"; a method whereby the sender tricks your browser or server into doing something you'd really rather it didn't.

Those characters are shown as "script" and "/script" surrounded by "%3C" and "%3E"; "<" and ">", respectively. This is an older (pretty useless, too) script injection method. They also try to obfuscate other characters that might trigger filtering mechanisms, such as:

"http%3A//" (translates to http://).

Since none of my current scripts include the "%3Cscript" sequence, I'll create another blocking definition and post it.

Thanks Jim! This is some great information and it reminds all of us that we need configure our HTTP Security Filters to protect not only inbound, but also outbound connections.

6. ISA Firewall Links of the Month

This month has been an exceptional month for ISA firewall Webcasts. Check 'em out:

TechNet Webcast: ISA Server 2004 Technical Overview (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032265790&EventCategory=5&culture=en-US&CountryCode=US

TechNet Webcast: Deploying ISA Server 2004 (Level 300)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032265787&EventCategory=5&culture=en-US&CountryCode=US

TechNet Webcast: Configuring Exchange and VPN Connectivity with ISA Server 2004 (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032265785&CountryCode=US

TechNet Webcast: Technical Drilldown Into ISA Server Appliances (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032265783&CountryCode=US

TechNet Webcast: Securing the Network Perimeter with ISA Server 2004 (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032265781&CountryCode=US

TechNet Webcast: SurfControl Web Filter for ISA Server 2004 - Helping You STOP Unwanted Content Risks (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032266214&CountryCode=US

TechNet Webcast: Tips and Tricks for Administering/Managing ISA 2004 (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032266226&EventCategory=5&culture=en-US&CountryCode=US

TechNet Webcast: Securing Your Messaging Traffic - Comprehensive Protection for Your Microsoft ISA Servers (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032266236&EventCategory=5&culture=en-US&CountryCode=US

TechNet Webcast: How Microsoft IT Deploys Microsoft ISA Server 2004 within Microsoft IT (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032266234&EventCategory=5&culture=en-US&CountryCode=US

TechNet Webcast: Inside Application Layer Filtering (Level 300)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032265794&EventCategory=5&culture=en-US&CountryCode=US

TechNet Webcast: ISA Server 2004: Networks and Rules (Level 300)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032266232&EventCategory=5&culture=en-US&CountryCode=US

I want to point out again the great information in the ISA deployment kits. There are kits for rolling out the ISA firewall in the branch office, using the ISA firewall to protect Exchange Servers, using the ISA firewall as a cutting edge VPN server and VPN site to site VPN gateway, and more. Check out the kits listed below for more info:

ISA 2004 Branch Office Deployment Kit
http://download.microsoft.com/download/1/8/8/188ab94a-4ec5-4746-ac0f-a18177040fbf/ISA2004SE_branchoffice-Rev%201%2003.doc

ISA 2004 Exchange Deployment Kit
http://download.microsoft.com/download/1/8/8/188ab94a-4ec5-4746-ac0f-a18177040fbf/ISA2004SE_exchangekit-Rev%201%2005.doc

ISA 2004 Quick Start Guide
http://download.microsoft.com/download/3/7/b/37b0cbc4-e578-4082-a779-de4fbe876f06/ISA2004SE_quickstartguide-Rev%201%2003.doc

ISA 2004 Configuration Guide
http://download.microsoft.com/download/3/7/b/37b0cbc4-e578-4082-a779-de4fbe876f06/ISA2004SE_configguide-Rev%201%2003.doc

ISA 2004 VPN Deployment Kit
http://download.microsoft.com/download/3/7/b/37b0cbc4-e578-4082-a779-de4fbe876f06/ISA2004SE_vpnkit-Rev%201%2004.doc

Finally, if you want to get some hands-on experience with the ISA firewall software and don't want to incur the overhead of installing the software on a test network, check out the free hands-on labs provided by Microsoft.

http://www.microsoft.com/technet/traincert/virtuallab/isa.mspx

7. Ask Dr. Tom

QUESTION: The clients on my Internal Network are configured as Web Proxy clients. I created an Access Rule allowing outbound access to authenticated users for the HTTP and HTTPS protocols. This rule works fine except for users who need to connect to MSN Messenger using HTTP. Each time the Web Proxy clients attempt to connect to MSN Messenger via the Web Proxy, the connection attempt fails. Why is this happening and how can I fix it? Thanks! -William.

ANSWER: The problem is that the MSN Messenger is sending the MSN user account credentials to the ISA firewall when the Web Proxy authentication request is returned to the MSN Messenger. Since its unlikely that that user's MSN Messenger credentials are the same as the user's domain credentials, the authentication attempt fails. To solve this problem, you need to bypass the HTTP 407 response returned by the Web Proxy filter on the ISA firewall. The best solution to this problem is to configure the clients as Firewall clients, and then configure the MSN Messenger sites for Direct Access. You can configure Direct Access in the Properties dialog box for the Network(s) from which the client(s) connect to the MSN site. When Direct Access for the MSN Messenger sites is enabled, the Web Proxy client ignores connections for those sites and hands off the connection to the client's Firewall client or SecureNAT client configuration. Since you want to require authentication for outbound access, you should install the Firewall client on all client operating systems. The Firewall client transparently sends user credentials to the ISA firewall's Firewall Service.