ISAserver.org Monthly Newsletter of April 2007 Sponsored by: GFI Software

Welcome to the ISAserver.org newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on ISA Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: tshinder@isaserver.org

1. Ten Dumb ISA Firewall Tricks

In the course of the month since the last newsletter, I've thought about what are some of the most common dumb things that ISA Firewall admins either choose to do, or are made to do, with the ISA Firewall. This month I want to share with you what I'll call "Ten Dumb ISA Firewall Tricks". These tricks include common misconceptions, errors, and just plain "WTF were you thinking" about the use and configuration of the ISA Firewall.

This list is not prioritized, so that top one isn't necessarily the most dumb, and the bottom one isn't necessarily the least dumb. Next month, I'll create a list opposite to this one - ten smart things you can do with the ISA Firewall.

You need a PIX/ASA in front of the ISA Firewall

No, you don't need a PIX or ASA in the front of the ISA Firewall. Putting a PIX or an ASA in front of the ISA Firewall is like putting a scarecrow in front of the tank. The ISA Firewall has never been compromised and there are no security issues that have been discovered regarding the ISA Firewall. Compare the security history of the ISA firewall with the PIX/ASA at www.secunia.com and you'll find that instead of putting a PIX/ASA in front of the ISA Firewall, you would be better off putting another ISA Firewall in front of the ISA Firewall.

You need the Firewall Client to allow outbound access to POP3

I don't know where this one got started. I think someone said something once on the Microsoft newsgroups regarding this, and the superstition quickly spread. The fact is that POP3 is a very simple protocol that requires only a single outbound connection. There's no reason in the world why the Firewall client would ever be required for POP3 access, unless you want to obtain strong user/group based outbound access control, in which case the Firewall client would be required. However, for pure protocol support, the Firewall client is not required for POP3 outbound connections.

The ISA Firewall can't be secure because it runs on Windows

This is, of course, the most mindless comment you can make about the ISA Firewall. This is a favorite of the "hardware" sales guys, who depend on their customer's ignorance about how the ISA Firewall works, and how insecure the "hardware" firewalls actually are (at least when compared to 'perfect' security, which is what the "hardware" guys try to offer to hapless customers). The fact is that the ISA Firewall protects itself very well. If the attacker can't get to the "insecure Windows", just how is the attacker going to leverage any of those exploits? Answer: they can't. The ISA Firewall's stateful packet inspection engine makes sure that the ISA Firewall is more secure than your typical "hardware" firewall, as least in terms of protecting itself. You can use the "but it runs on Windows" canard as a litmus test to inform you of how clueless the person you're talking to is.

The Domain Member ISA Firewall can't be secure

Where did this come from? This is one of the most mysterious ISA Firewall superstitions I've ever encountered. I'm sure some "security guys" once said that Firewalls that were domain members were not secure, and then it was said over and over again until everyone accepted it as fact. What is the fact? The fact is that an ISA Firewall configured as a domain member is more secure than a non-domain member. The domain member ISA Firewall provides a superior security posture than a non-domain member ISA Firewall, and you must never forget that. You can get support for this fact by reading my article that blows away this superstition at http://isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html

The FE and BE Exchange Server should be on the same network segment/security zone

In the physical sciences there are "laws" that describe behavior in the physical world. These laws are always true and are core tenets to the sciences to which these laws belong. In network security, there are two "laws" that must always be obeyed:

• The law of least privilege
• The law that Internet facing hosts must be placed in different security zones than non-Internet facing hosts

The network design for FE and BE Exchange Servers calls up the use of both of these laws of network security. The FE Exchange Server is an Internet facing host, the BE Exchange Server is not an Internet facing host. Thus, they must be on different security zones. Not only must they be on different security zones, but least privilege must be used to control traffic moving between the FE and BE Exchange Server. Putting the FE and BE Exchange Servers on the same network segment or security zone is irresponsible and represents abject disregard for core network security principles. There is plenty of guidance on ISAserver.org on how to configure FE and BE Exchange Servers in a secure fashion, and if you want detailed training on how to do this correctly, you can attend our seminar at Black Hat on how to do this with military grade designs. Check out http://www.blackhat.com/html/bh-usa-07/train-bh-us-07-tm-ms-bbe.html

SSL to HTTP Bridging is good

No, SSL to HTTP bridging is bad. I know that people want to use SSL to HTTP bridging to "offload" SSL connections, but a much better solution is an SSL accelerator card. They are very inexpensive and the cost is worth it, especially in light of the security hole that you create with SSL to HTTP bridging. A user who creates an SSL connection expects that SSL connection to remain intact over the wire from end to end. If you disable the protection on the internal network, anyone with a simple packet sniffer can read the contents and credentials moving over the wire. In most cases, people are using SSL to HTTP bridging because they think SSL to SSL bridging is too complex. It's NOT complex and there are dozens of articles on ISAserver.org on how to do it.

Don't use autodiscovery for Web Proxy clients

I never understood this one. Autodiscovery can be configured on DNS and/or DHCP servers and provide granular control over what ISA Firewall to use as Web proxy. The Internet Explorer client is automatically configured to use autodiscovery. Then the clients automatically find the ISA Firewall and automatically download the autoconfiguration script, which enables you to control Direct Access for Web proxy clients. In most cases autoconfiguration is ridiculously easy to configure, and even in complex environments there are a number of options to make is easier to roll out autodiscovery. Conclusion: always use autodiscovery on your network.

Don't use a Split DNS infrastructure

A split DNS is the solution for so many networking and name resolution problems it's surprising that not everyone uses it. A split DNS infrastructure makes life easier for you and your users. Why wouldn't you use one? Most likely because of major misconceptions about split DNS that have been floating around over the Internet for years, and no one really wanted to take the time to correct the flawed thinking behind these misconceptions. The good news for you is that I have taken the time to help you understand the flawed thinking and help you move to the superior split DNS infrastructure. Check out http://isaserver.org/tutorials/2004illegaltldsplitdns.html for more details.

Allow all traffic to a specific host

What's up with this? The reason you have a firewall is to control traffic moving to and from specific hosts. If you want all traffic to reach a particular host, then use a router (like a PIX) and not an ISA Firewall. Almost every time I see a request on how to allow all traffic to a particular host, the reason for the request is that the firewall admin doesn't understand what traffic is required by the application running on that host. This is a very dangerous situation, because instead of learning about how to apply least privilege, a decision is made to allow MOST privilege, which is an attacker's dream. Don't hand hackers the keys to the mint - never allow "allow protocols" to any host through the ISA Firewall.

Disable automatic updates

How many times have you gone into a datacenter and saw that the firmware on routers, switches and firewalls hasn't been updated in the last five years? Why don't the "network guys" take care of business? Because it's often a real pain in the neck to update those devices or maybe they just forget to take care of it. One of the big advantages of using the ISA Firewall is that it updates its core operating system and firewall software automatically. If you turn this off, you lose one of the major advantages you have over the "hardware" firewalls. Solution: always enable automatic updates on your ISA Firewall

That's it for now. If you have other dumb ISA Firewall tricks you've seen, let me know! Write to me at tshinder@isaserver.org and we'll share out those dumb ISA Firewall tricks and hopefully prevent future fledgling ISA Firewall admins from making the same mistakes.

Thanks!

Tom

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

Quote of the Month - "Putting an ASA in front of an ISA Firewall is like putting a scarecrow in front of a tank"

-- Thomas W Shinder MD, Firewall and Network Security Specialist

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

2. Tom and Deb Shinder's Configuring ISA Server 2004 - Order 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:

• Offline Rule Bases and Objects
• Understanding the ISA Firewall Client (Part 1)
• Creating and Configuring Non-SSL Web Publishing Rules (Part 1)
• Creating and Configuring Non-SSL Web Publishing Rules (Part 2)
• Creating and Configuring Non-SSL Web Publishing Rules (Part 3)
• The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 1: SSL VPN 101
• The Microsoft Intelligent Application Gateway 2007 (IAG 2007) Part 2: IAG Connectivity Options

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
• Internet Security and Acceleration Server 2004 stops responding or performs slowly after you configure a Web listener to use OWA forms-based authentication
• The Firewall service may not start in Internet Security and Acceleration (ISA) Server 2004 after you select a certificate for a, SSL listener
• Error message when a Web browser tries to access external Web sites from behind an ISA Server 2004 computer that has Service Pack 2 installed
• Microsoft Internet Security and Acceleration (ISA) Server performance may be reduced if the Exchange Server 2003 server is processing unusually heavy traffic
• The Firewall service stops responding and Event IDs 14079, 1000, and 14057 are logged in the Application event log in ISA Server 2004
• The dial-up connection to a remote network is continually dialed when a client computer makes a request for a URL that is not defined in any LDT in ISA Server 2004
• ISA Server 2004 blocks UDP traffic between two networks
• Session state management may not work as expected when ISA Server 2004 accesses a Web site that uses the round robin feature of DNS to achieve load balancing
• You cannot specify a path statement that ends in a wildcard character when you create a Web publishing rule in ISA Server 2004
• The ReturnAuthRequiredIfAuthUserDenied property setting does not work if the access rules include a Content Type rule in ISA Server 2004

5. Tip of the Month

Using SecurID for ISA Firewall authentication has been no end of problems throughout the life of the ISA Firewall. If you're having problems solving SecurID related problems with the ISA Firewall, then you might want to check out this thread on the Web boards: http://forums.isaserver.org/m_2002032068/mpage_1/key_/tm.htm#2002042364

Having problems with VPN performance issues? Then check out this thread where a site to site VPN performance issue was solved: http://forums.isaserver.org/m_2002040501/mpage_1/key_/tm.htm#2002041978

NLB generates a lot of questions on the ISAserver.org Web boards. Here's some advice on how to solve a specific Web Publishing problem with a hotfix where NLB was involved: http://forums.isaserver.org/m_2002040501/mpage_1/key_/tm.htm#2002041978

6. ISA Firewall Links of the Month

ISA Firewall Tools of all kinds

http://www.microsoft.com/technet/isa/downloads/2006/tools/default.mspx

Collection of ISA Firewall Webcasts

http://www.microsoft.com/technet/isa/community/sharpen.mspx

Best Practices for ISA Firewall Performance

http://www.microsoft.com/technet/isa/2006/perf_bp.mspx

Network Load Balancing Integration Concepts for Microsoft Internet Security and Acceleration (ISA) Server 2006

http://www.microsoft.com/technet/isa/2006/nlb.mspx

Troubleshooting VPN over IPsec

http://www.microsoft.com/technet/isa/2006/ts_vpn_ipsec.mspx

7. Blog Posts

• Follow Up on the Insecurity of RDP Access to the Corpnet
• DNS RPC Exploit May Need Immediate Attention by ISA Firewall Administrators
• Microsoft's Recommendations Regarding Windows Server 2003 SP2 and the ISA Firewall
• Getting Prompted for Authentication When You Enable Firewall Client and Web Proxy Client Autodiscovery?
• Allowing Remote Access to RDP Connections is Hazardous to Your Network's Health
• Oh, Gimme a Break, Willya?!? Some Details Would be Useful - WPAD
• The Firewall Client is NOT Required to Access POP3 Servers

8. Ask Dr. Tom

QUESTION: Dear Tom,

Thank you for your great Articles and Tutorials about the ISA Server. I want to configure Front-end and Back-end Firewall to support Front-end Exchange 2003 or 2007. Have you published any Articles similar to that? As I have searched many times but I didn't find.

Most of out customers are having Pix and ASA 5500 that set as an Edge Firewall for their network, and keeping ISA Server with single Nic as a Cache Server only. And creating a DMZ Zone where all the Servers Internet Facing are setting there and normal Natting forwarding the concern traffic to the correct server.

What I have learned from you and other colleagues in this great site, is to integrate the ISA Server in the Network as a Back-end Firewall which will provide us a Second Layer of Security for the internet Facing Servers. Is it possible to make the same scenario using both the Front-end and Back-end as an ISA Firewall? And once it's successfully implemented, then I can easily recommend for out customers the Front-end to be the Pix or the ASA and the back-end is ISA Server.

But for the DMZ Concern, where the DMZ Zone will be setting? is it in the Internal Network of the Front-end Firewall? And all the publishing rules will be via the Front-end Firewall? In this case if the ISA Server set as an Edge Firewall, but what about if the ISA Server is set a Back-end Firewall, where the DMZ Zone will set?

Best Regards, Hussain Al Sayed

ANSWER: Hi Hussain, there are a number of articles on the ISAserver.org Web site that can help you with creating an Exchange Web publishing solution using back to back ISA Firewalls. For example, check out http://isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part1.html for the first part of a multipart article series on how to securely publish Exchange Servers behind a back to back ISA Firewall configuration.

In your scenario, you can easily make the ISA Firewall the back-end firewall. Since the ASA devices are unable to perform application layer inspection on SSL connections, you can configure the ASA to forward all incoming TCP port 443 to the ISA Firewall. In this way, the ASA acts as a simple router that forwards connections to the ISA Firewall, and then the ISA Firewall performs the real security work - application layer inspection of the contents of the SSL tunnels.

Regarding topology, you'll want to put the FE Exchange Server in a DMZ segment that is separated from the BE Exchange Servers. It's a security best practice to separate Internet facing devices from devices that never receive incoming connections from Internet hosts. Since the BE Exchange Server never accepts incoming connections from Internet hosts, it must be separated from the FE Exchange Server. The best way to do this is to create a DMZ segment on the back-end ISA Firewall and put the FE Exchange Server there.

QUESTION: Hi Tom,

I have an ISA 2004 server and two DSL connections to two different ISP's. Is it possible to use ISA 2004 to use one connection, and if the link to this connection goes down for ISA to change and automatically use the second connection? I have tried setting up two network cards, each with its own default gateway but ISA server reports issues with Multiple Default Gateways and it does not seem to work correctly.

Kind Regards

Jeff Morgan

ANSWER: Hi Jeff, you are correct - the ISA Firewall does not support multiple WAN connections at this time. The only solution to your problem right now is to use a device in front of the ISA Firewall that supports multiple gateways. There are many devices available that can do this for you. The main thing you want to watch out for is whether you want to have redundancy for incoming connections as well as outbound connections. If you want redundancy for incoming connections, you'll need a device that does DNS for you so that when one of the links goes down, the DNS records returned to external users will reflect the absence of the downed link and only return addresses for the live connection.

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