ISA Firewall Best Practices, Tips and Tricks (Part 1)

ISA Firewall Best Practices, Tips and Tricks (Part 1)

by Thomas W Shinder MD, MVP

If you would like to be notified when Tom Shinder releases ISA Firewall Best Practices, Tips and Tricks (Part 2) please sign up to our Real-Time Article Update.

On a recent plane ride back from a customer engagement, it occurred to me that I’ve never put up a list of what I consider to be key ISA firewall best practices, tips and tricks on the www.isaserver.org Web site. I thought about the things I do on a routine basis to get the ISA firewall configured correctly so that it provides the best level of security, reliability and performance possible. The following list is the result.

While I can’t go over each issue in detail (because there are so many of them), I will give a short description of each issue and how to deal with it. Most of this information is either in our book or on the Web site, but there are some things listed here that I hadn’t yet set down on paper, so this will be the first time they’ve been made public (by me, at least).

The following list of best practices, tips and tricks aren’t listed in any particular order and the order of the list does not imply that entries higher on the list are any better or more important than those on the bottom of the list.

Have fun and let me know if you have questions or additions to this list at [email protected]. 

1. Configure clients as Web proxy and Firewall clients I’ve beat on this drum for the last five years. If you want your ISA firewall to provide superior protection over and above what your “hardware” firewall provides, you must deploy the Firewall client and Web proxy client configuration. Otherwise, you’ll suffer from the same security weaknesses you have if you use only a “hardware” firewall. Get what you paid for and deploy the Firewall and Web proxy client configuration now! Check out http://isaserver.org/articles/2004dumbdownisa.html for the reasons why you don’t want your ISA firewall to be as dumb as a traditional stateful packet inspection-only firewall.
2. DNS server settings — configure the ISA firewall to use a DNS server on its internal interface; do not enter the same DNS server on multiple interfaces This is a very common issue. The ISA firewall should have only one DNS server configured on its interfaces, and that DNS server address must be configured on its internal interface (or whatever interface is closest to an internal DNS server that can resolve Internet host names). NEVER put an external DNS server on any of the ISA firewall’s interfaces, and NEVER enter a DNS server address on more than one ISA firewall interface.
3. Use www.arin.net to determine netblock of attackers, etc. Have you ever wondered where those attack packets are coming from? You see the IP addresses in the ISA firewall’s real time log viewer, but who are they? Check out www.arin.net and do a whois search on the IP address. This should always be your first place to go when investigating unusual activity in your ISA firewall’s firewall logs.
4. Network within a network scenario The network within a Network scenario is when you have multiple network IDs located behind the same ISA firewall network interface. It’s a simple concept, but it deviates quite a bit from how the ISA 2000 firewall worked. Check out these two articles by Clint Denham and myself: Network Behind A Network (2004) – v1.1 by Clint Denham http://isaserver.org/articles/2004netinnet.html and Understanding ISA Firewall Networks by me at http://isaserver.org/articles/2004isafirewallnetworks.html 
5. Plan deployment You must plan in advance how the ISA firewall will be deployed on your network. Remember, the ISA firewall is a key piece of networking gear: it’s NOT a server. That means the ISA firewall is an integral part of your network infrastructure and you need to drill that into the heads of the “open port button” networking guys who think that attacks attack “ports” (they don’t – www.tacteam.net/openport.htm). Some things to consider when planning your deployment include:

   Confirm protocol usage What protocols do you need to support? What protocols do your line of business applications need to use when connecting to resources through the ISA firewall?
   
   Confirm per user/group access policies
   Consider what users need to access what information. Consider in advance how you’ll build your ISA firewall user groups so that you give users access only to information they require, and no more. Enforce policy using least privilege and try to avoid creating Deny rules.
   
   Confirm logging requirements
   Confirm what level and type of logging you require. If you’re in a regulated environment, you want to log as much as possible. This means making the ISA firewall a domain member and deploying the Web proxy and Firewall clients. This not only increases the overall level of security provided by the ISA firewall, it also significantly improves your logging capabilities.

6. Use DMZs to segment security zones The ISA firewall supports an unlimited number of network interfaces (at least to the limit of your hardware). Use DMZ networks connected to the ISA firewall to limit access to different security zones within your organization. Put ISA firewalls between different security zones to make sure you are protected against attacks sourcing from different security zones. Check out http://isaserver.org/articles/2004tales.html for more information on how to use the ISA firewall to provide the highest level of security possible for communications between different security zones. The article, when printed out, makes for a nice wad to bludgeon packet filter firewall admins who think in terms of “opening ports”.
7. Don’t install Server services on the firewall The ISA firewall should never be part of your server consolidation plan. The ISA firewall was designed from the ground up as a network firewall. Never make the ISA firewall a file server, Web server, FTP server, or BearShare server. The ISA firewall is a firewall, not a fire sale. The only exception to this is when the ISA firewall is installed on an SBS 2003 SP1 box; but that scenario falls outside the ISA firewall’s status as a network firewall, as its security model is compromised by the increased attack surface provided by all the applications installed on the SBS box.
8. Harden the server using Win2003 SCW or the ISA firewall hardening guides The ISA firewall should always be installed on a hardened version of the based OS. They to avoid installing the ISA firewall on Windows 2000, and always attempt to install the ISA firewall on Windows Server 2003 operating systems when you deploy ISA firewalls. Harden the operating system using the Windows Server 2003 Security Configuration Wizard (SCW) and pay close attention to what the SCW does to your system. If you prefer to not use the SCW, then study the ISA firewall hardening guidance located at http://www.microsoft.com/isaserver/techinfo/guidance/2004/planning.mspx
9. Install Network monitor for troubleshooting The only way to you can get to the bottom of many network and firewall troubleshooting issues is to do a network trace. Microsoft Network Monitor comes with Windows 2000 and Windows Server 2003, so there’s no reason to purchase a custom network analyzer. However, you can purchase your own network analyzer if you want, as many of them provide advantage diagnostic and troubleshooting tools. Another excellent option is Ethereal. You can install Network Monitor either before or after the ISA firewall software is installed.

Figure 1

10. Single default gateway The ISA firewall supports only a single default gateway. One of the most common troubleshooting issues I run into relates to users putting multiple gateways on multiple interfaces on the ISA firewall. The ISA firewall supports a single route of last resort, and that gateway address is usually entered on the interface closest to the Internet. If the ISA firewall needs to reach remote networks that aren’t reachable via the default gateway, then configure routing table entries on the ISA firewall so that it knows the correct gateway to use to reach those remote networks.
11. Disable NetBT on the external interface There typically isn’t a reason to enable NetBT on the external interface of the ISA firewall. If you don’t need it, then disable it.

Figure 2

12. Disable the Server Service on the external interface There typically isn’t a reason to enable the Server service on the external interface of the ISA firewall, as the Server service is used to enable access to shared resources on the ISA firewall. In general, the Server service should be disabled on all interfaces of the ISA firewall, but there can be side effects, such as being unable to access the Firewall client share on the ISA firewall if you installed it there. If you did install the Firewall client share on the ISA firewall, you should remove it and place it on a file server someone on the corporate network. There might also be issues with connecting to various MMC consoles, such as the RRAS console, when the Server service is disabled. You shouldn’t run into any issues if the Server service is unbound only from the external interface, though.
13. Disable the Alerter and Messenger service The Alerter and Messenger services should be disabled on the ISA firewall. This is more of an issue with Windows 2000, where these services are on by default. Windows Server 2003 either turns off these services by default, or they are turned off as part of running the Security Configuration Wizard on a Windows Server 2003 Service Pack 1 ISA firewall.
14. Don’t browse from the Firewall. Don’t disable enhanced IE security on the ISA firewall The ISA firewall isn’t a workstation; it’s a network firewall representing a critical piece of your network security infrastructure. Not only isn’t a workstation, the ISA firewall isn’t a server, so it should not be made part of your company’s server consolidation plan. Don’t use client applications, such as Internet Explorer, on the ISA firewall and don’t disable the enhanced IE security configuration that is part of Windows Server 2003 Internet Explorer. In addition, don’t “browse” the corporate network from the ISA firewall. If files need to be downloaded to the ISA firewall, download the files to a management station on the corporate network, scan the files for viruses, test them in the test lab, and if the files pass scanning and testing, then copy them to the ISA firewall over a dedicated channel, such as an encrypted RDP session.
15. Configure Web Proxy clients to use HTTP 1.1 through proxy connections Very often I’ll hear people say that Web performance has gone down since installing the ISA firewall. Two things you can do to significantly increase Web browsing performance for your users is to 1. Configure the clients as Web proxy clients and 2. Configure the Web browsers to use HTTP 1.1 through proxy connections. You can find this setting on the Advanced tab in Internet Explorer’s Internet Options dialog box.

Figure 3

16. Configure local addresses for Direct Access Direct Access allows Web proxy clients to bypass the Web proxy configuration to connect to resources configured for Direct Access. One thing you should never do it loop back through the ISA firewall to access resources on the same ISA firewall Network on which the requesting client is located. Direct Access prevents this from happening. Configure the ISA firewall to use Direct Access for both your corporate domain name and all addresses on the corporate network. The exception to this is when you have multiple internal NICs on the ISA firewall and you’re using the ISA firewall for access control across multiple internal NICs. In that case, you’ll need to review your requirements to determine if Direct Access is the best configuration for you.

Figure 4

17. Patch the OS before installing the ISA firewall This might seem like common sense, but many ISA firewall admins are so excited about getting the ISA firewall software installed that they forget to patch the base operating system before installing ISA. Make sure you install the base operating system on a protected network, so that you can safely install the operating system and then update the operating system before installing the ISA firewall software. Connect the ISA firewall device to the Internet only after the operating system is patched and the ISA firewall software is installed.
18. Rename the connections on the ISA firewall’s interfaces This is a trick I regularly employ when working with a new ISA firewall. In the Network Connections folder, you can rename the interfaces installed on the ISA firewall. Instead of looking at Local Area Connection 1 and Local Area Connection 2 and Local Area Connection 3, you can rename the connections to something more meaningful, such as WAN, LAN, and DMZ. This is especially helpful when you have 10-20 interfaces installed on the same ISA firewall device. In the Network Connections window, just right click the interface and click Rename and give the interface a new name.

Figure 5

19. Configure network interfaces to show the icon in the system tray Speaking of network interfaces, I really like to see the status of all the NICs installed on the ISA firewall appear in the system tray. You can use this to see the inbound and outbound traffic patterns for each NIC, and if gives you a very rough idea of the traffic patterns on each NIC for “eyeballing” purposes. You can enable the interfaces to show up in the system tray by opening the properties of the interfaces and putting a checkmark in the Show icon in notification area when connected.

Figure 6

Have Questions about the article? Ask at: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=24;t=000793#000000

20. Use ipconfig, netstat, arp and nbtstat for troubleshooting The ISA firewall is a key piece of network infrastructure, just like your routers and switches. When something goes wrong with network communications and you suspect that the ISA firewall might be part of the problem, or even if the ISA firewall isn’t the problem but is in the path between the source and destination host that’s having a connectivity issue, then you’ll need some tools to help you troubleshoot networking problems. I mentioned Network Monitor earlier. Some other tools that you can use to help troubleshoot networking issues are ipconfig, netstat, nbtstat and arp. To learn more out each of these tools, just enter the command with the /? Switch after it. I use each of these tools often to diagnose and treat networking problems at the ISA firewall.

Figure 7

21. Use DHCP for WPAD with Windows XP Service Pack 2 One of the best kept secrets out there is that WPAD for DHCP works great for Windows XP Service Pack 2 hosts. WPAD allows you to automatically configure Web proxy and Firewall clients to use the ISA firewall of your choice. WPAD entries can be configured in either DNS or DHCP. The challenge with WPAD and DNS relates to branch office issues where the branch office machines are part of the same domain. The problem with using DHCP to deliver of WPAD information is that the user had to be logged in as an administrator, which obviously isn’t a security best practice. The good news is that Windows XP Service Pack 2 now supports WPAD delivery via DHCP to non-admin users logged into the Windows XP Service Pack 2 workstations. This solves the problem with branch offices that are part of the same domain using DNS for WPAD. All they need to do is install a DHCP server at the branch office (which could be on the ISA firewall itself) and configure the DHCP WPAD entry to connect to the local ISA firewall.

Figure 8

22. Don’t use the firewall as a workstation — never run client apps I know I’ve said it before, but I’m going to say it again (and again and again), don’t use the ISA firewall as a workstation. Don’t use client apps, such as Internet Explorer, Outlook Express, FTP, or any other client application that would expose the ISA firewall to viruses, worms, and other exploits. The only “client” applications you should use are those that you use to troubleshoot network problems. I know it’s a hard habit to break, but the effort you put into avoiding using the firewall as a workstation will pay off manifold in an increased level of security.
23. Don’t allow connections to the Local Host Network Its scary to see the number of ISA firewalls out there where the ISA firewall administrator, in the process of troubleshooting some problem, allows connections to and from the Local Host Network without appreciating the dire security implications of these rules. You should never create Access Rules allowing traffic to the ISA firewall, or from the ISA firewall, unless you have a very specific reason for doing so. Never create rules allowing all traffic to or from the Local Host Network. If you need to control traffic to and from the Local Host Network, check your ISA firewall’s System Policy. System Policy is designed to control what legitimate traffic should be allowed to and from the ISA firewall itself.
24. Set connection limits The ISA firewall can mitigate worm and other automated attacks by enforcing connection limits. You can set connection limits by going to the General node in the ISA firewall console and clicking the Define Connection Limits entry. If you find that busy mail servers and other servers that require a higher connection limit value than other hosts, then make sure you configure custom connection limits for those servers.

Figure 9

25. Prevent remoting of Firewall client ports (EE only) The Firewall client software is the unheralded “killer app” of the firewall world. The Firewall client enhances security and flexibility to any ISA firewall deployment. One very nice addition to the Firewall client’s security armamentarium is a new Firewall client configuration file entry that enables you to prevent remoting of specific ports to the ISA firewall. The Firewall client is a Winsock proxy client and establishes connections directly with the ISA firewall’s Firewall Service. You can use the DontRemoteOutboundTcpPorts key in the Firewall client settings file and prevent the Firewall client from remoting connections to the ISA firewall for well know worm ports, such as 445,1434, 5554, etc. This causes worm generated traffic from being sent to the ISA firewall and its dropped at the client.

Figure 10

26. Use remote desktop for firewall management There are two methods you can use to manage the ISA firewall: secure encrypted RDP connections and remote ISA firewall MMC console. I always use RDP because monitoring and configuration is more efficient this way, and more importantly, it’s more secure. The RDP connections use 128-bit encryption and require only TCP 3389 be available on the ISA firewall to trusted management stations. There is, for some reason, the impression that RDP is not secure. This is a false impression, so don’t fall prey to it.
27. Don’t connect to the Internet when installing the ISA firewall I mentioned this before, but it’s worth mentioning again: don’t connect the ISA firewall to the Internet until after the ISA firewall software is installed. The ISA firewall device isn’t secure until after the ISA firewall software is isntalled. I can’t tell you the number of times I’ve seen ISA firewall devices compromised, not because of a problem with the ISA firewall software, but because the device was connected to the Internet before the ISA firewall software was installed.

That’s all for now. I’ll finish up my list of ISA firewall best practices, tips and tricks in part two of this article series. If you have your own ISA firewall best practice, tip or trick, send them along to me at [email protected] and I’ll update the article with your info. Thanks! –Tom.

If you would like to be notified when Tom Shinder releases ISA Firewall Best Practices, Tips and Tricks (Part 2) please sign up to our Real-Time Article Update.