Archive
Automatic Detection Fails for ISA Firewall Clients
When configuring the Web Proxy listener on a Microsoft ISA firewall, one of the things you will find in addition to the authentication methods available is an option to ‘require all users to authenticate’.
Selecting this option produces the following warning message:
Now why would Microsoft give us this option, then complain when we attempt to use it? I have no idea. But it is important to read this message thoroughly and understand what it is saying and why.
As the message indicates, requiring all users to authenticate may block traffic to sites such as Windows Update. The reason for this is that the Windows Update client on our servers and workstations runs in the background, under the context of the service host (svchost.exe) and is unable to provide authentication information to the ISA firewall. This same scenario applies to any unattended processes or services you might have running that require access to the Internet.
One thing that the warning message does not mention is that requiring all users to authenticate to the Web Proxy listener also breaks the automatic detection mechanism for Firewall Clients. The reason for this is that the ISA Firewall Client lacks the ability to respond correctly to the ‘HTTP 401 Unauthorized’ response that the ISA firewall returns when the Firewall Client attempts to retrieve the ‘wspad.dat’ file.
As the aforementioned warning goes on to say, Microsoft recommends enforcing user authentication on firewall policy access rules and publishing rules instead of requiring all users to authenticate to the Web Proxy listener. In this case it would seem that just because you can, doesn’t mean you should. If you must for some reason enable this setting (and honestly, I can’t think of any reason you would need to) there are some workarounds to allow automatic detection by the Firewall Client under these circumstances. Refer to Microsoft knowledge base article 88563 for more information.
Scripting with Microsoft ISA Server 2006
One of my very favorite things about the Microsoft ISA firewall is the fact that you can do just about anything by leveraging the ISA Server administration COM object. Through scripting you can alter the configuration, automate repetitive or complex tasks, gather session information, import and export data, and much more. Here is a short example of a script that will display the version information for the ISA software you are running:
Option Explicit
Dim Root, Server
Set Root = CreateObject(“FPC.Root”)
Set Server = Root.GetContainingServer
WScript.Echo Server.ProductVersion
Set Server = Nothing
Set Root = Nothing
If you are interested in scripting the ISA COM object at all, ISA Server Administration Scripting on MSDN is a great place to get started. There you will also find a complete reference to all of the ISA related COM objects, as well as some sample scripts. There are some great web sites that have some excellent ISA scripts you can download and use as is. Jim Harrison’s ISATools.org is an excellent resource, as is Jason Fossen’s ISAScripts.org.
ISA Firewall Client Command Line Options
The Microsoft ISA Server Firewall Client is a wonderfully amazing piece of software that allows you to very granularly control network communication on hosts which it is installed (you can download it here). If you are not familiar with the Firewall Client, it is a software component that can be installed on Windows hosts that allows you to proxy any TCP or UDP based communication. There is no need to configure individual applications to work with the Firewall Client. It is a layer service provider that transparently intercepts Winsock calls and if the destination is remote, the Firewall Client sends that communication to the ISA firewall. Your routing infrastructure becomes transparent to your clients, and you gain the ability to enforce user and group based access control. Best of all, the Firewall Client logs not only the user name for each request, but the application that made the request as well. Very powerful stuff!
Troubleshooting Firewall Client communication can sometimes be difficult, however. Thankfully enough, there is a command line utility included with the Firewall Client that makes that job much easier. If you navigate to the ‘Program FilesMicrosoft Firewall Client 2004’ folder you will find a program called ‘fwctool.exe’. This tool allows you to do things like enable and disable the client software itself:
fwctool.exe enable
fwctool.exe disable
It can also be used to display the version of the Firewall Client software you currently have installed:
fwctool info
You can alter the configuration of the Firewall Client:
fwctool SetManualServer
fwctool SetAutoDetectServer
And you can display the current configuration information as well:
fwctool PrintConfig
fwctool PrintServerConfig
fwctool PrintUserConfig
fwctool PrintGlobalConfig
The Firewall Client has the ability to automatically configure the web browser that is installed on the workstation. This option can be displayed, enabled, or disabled from the command line as well:
fwctool DisplayBrowserConfig
fwctool EnableBrowserConfig
fwctool DisableBrowserConfig
You can also verify connectivity to the ISA firewall by using the PingServer option:
fwctool PingServer
I absolutely love the Firewall Client because of its power and flexibility. Having the ability to leverage strong user and group based authentication on ALL TCP and UDP protocols is fantastic. Look for more posts here on my blog about the Firewall Client and how to troubleshoot it as well as to leverage it.
ISA Behind a Cisco ASA?
Several people have written to me in response to my earlier blog post ‘HTTP 2.0 Specification?‘ asking why I would have my ISA firewall behind a Cisco ASA. The answer is simple: enhanced security! I am following a long standing security best practice by implementing security in layers; defense in depth. Now, it’s not that the ISA firewall isn’t totally and completely capable of acting as an edge firewall, because it most certainly is. In this case though, I have elected to use an ASA as my edge firewall because I don’t need any real intelligence there. All I want is to do some very simple packet filtering here; basically just filtering out the bulk of the noise from the Internet and allowing my internal ISA firewall, with its advanced deep application layer inspection capabilities and granular user and group based access controls to do the important network communication inspection.
In addition to enhanced security, there are some other benefits to using the ASA (or another firewall) at the network edge. If someone were to circumvent the access controls that are in place on that edge firewall, they would not be able to use those same methods of exploitation on the ISA firewall. If I practice security in layers but deploy the same model firewall at each layer, an attacker can use the same method used to bypass my internal firewalls as they used to bypass my edge firewall.
An additional benefit by using another firewall at the network edge is that by squelching ‘Internet noise’, the logs on the ISA firewall become much more meaningful. It allows me to find important information much more quickly than having to sift through mountains of data this is mostly port scans and probes that occur constantly on the public Internet. This also frees up resources on my ISA firewall that are better put to use on inspecting important traffic.
HTTP 2.0 Specification?
I wanted to share with everyone what I thought was an entertaining issue that was brought to my attention by one of our (Celestix) support engineers recently. The issue was a classic one for most seasoned ISA firewall administrators; 502 proxy error (request not supported) when accessing a specific site, but the same site can be reached without issue behind any other firewall or router. Clearly the ISA firewall, with its deep application layer inspection capabilities, is objecting to something in the communication stream and denying our request. Now, there are plenty of other documented examples of this type of scenario, but what I found particularly entertaining about this specific one (and hence compelled to write about it here) was the response I see coming from the remote web server…
HTTP/2.0? This was not a specification I was aware of, but as a sanity check I posed this question to some folks that know a lot more about this stuff than I do. Thankfully, Jim Harrison did confirm for me that HTTP/2.0 is not a valid specification. Thanks Jim!
Again, this is a fairly common scenario when you deal with the ISA firewall. Because the ISA firewall is capable of understanding communication at the application layer (layer 7), it is designed for security reasons to disallow ANY non-RFC compliant communication. That includes any fictitious HTTP specifications that vendors decide to dream up as well. And once again, this is another shining example of the power and security of the ISA firewall. With these advanced features, the ISA firewall does far more to protect your network communication than any firewall on the market today. In this instance, had this been a malicious site, any other firewall (certainly my ASA!) would blindly allow the communication.
TCP/IP Fundamentals for Microsoft Windows
I wanted to bring to your attention today a wonderful document authored by Joe Davies called ‘TCP/IP Fundamentals for Microsoft Windows‘. This is an incredible resource, with over 500 pages of detailed information regarding TCP/IP networking in Microsoft Windows. Recently it was updated to include information for Windows Server 2008. What is really amazing is that it is a free download! Joe Davies has authored (and co-authored) many Microsoft Press books on networking, including the TCP/IP Protocols and Services books, Understanding IPv6, Windows Server 2008 Networking and Network Access Protection (NAP), and many more. Joe is also the author of ‘The Cable Guy‘ column that is featured in Microsoft Technet magazine and online.
DNS Resolver Behavior in Windows Vista
Recently while working with one of my customers I came across some odd behavior on a Windows Vista client workstation. We noticed that Windows Vista workstations that were configured as Web Proxy and Firewall Clients only (no default gateway) were unable to access non-web based remote resources (e.g. RDP and FTP) by hostname (single label or fully qualified). They could, however, connect by IP address. The odd thing was that Windows XP clients configured in the identical manner did not exhibit this behavior. Windows XP clients configured as Web Proxy and Firewall Clients without a default gateway could access non-web based remote resources without issue, by hostname or IP. In either case, web proxy communication (HTTP, HTTPS, tunneled FTP) worked perfectly.
Name resolution on the Windows Vista client worked flawlessly, so I opened a case with Microsoft so they could shed some light on this for me. After some additional research on their part they were able to determine that this was expected behavior on Windows Vista. Apparently the DNS resolver in Windows Vista filters out hostnames for destinations that are not reachable from the local host. Without a default gateway, Vista had determined that it couldn’t connect to the resource because it had no route to the remote network (obviously not aware of the Firewall Client) and so communication fails.
The resolution was simple enough…add static routes to any remote internal networks, or if Winsock access to the general internet was required, then add a default gateway. And while you may not encounter this particular scenario in complex, large scale corporate networks, it is fairly common in small, flat networks deployed at many SMB’s. If you are like me and have recommended in these scenarios that you deploy only the Firewall Client, it appears that option is no longer available.
Using DHCP to Assign Static Routes
In order to facilitate testing in a lab environment, I make extensive use of virtual machine technology. Today I employ a combination of VMWare Workstation and VMWare ESX Server in order to simulate distributing computing environments. Included with these technologies is virtual networking, which is tremendously useful when creating complex routed networks in my lab.
There are times when I will add static routes (host routes or network routes) to my local workstation in order to conduct testing. Occasionally there will be times when I forget the ‘-p’ switch to make the route persistent, then I find myself wondering why my connectivity to my test environment isn’t working. Another common scenario is when I grab another system (a laptop or another VM perhaps) and I end up having to manually add more routes before testing can resume.
Recently I decided to make my life easier and use DHCP to add these routes to all of my workstations. Configuring static routes using DHCP is quick and simple. You can add a static route by configuring a DHCP option 249 on Windows Server 2003 DHCP servers, or option 121 on Windows Server 2008 DHCP servers. You can configure the option at the server level, but it is more likely that you will configure the option at the scope level, or as I often do, on a specific reservation.
For demonstration purposes here we’ll make this change at the scope level. To begin, right-click Scope Options and choose Configure Options…. On Windows Server 2003 DHCP servers, select option 249 Classless Static Routes (Option 121 on Windows Server 2008 DHCP servers).
Click Add Route…, then enter the static route you wish to configure.
Now, regardless of which system I log on to, I am assured that I will have connectivity to all of my virtual environments.
Note: DHCP Option 121 is ignored by DHCP clients prior to Windows Server 2008 and Windows Vista. This may not work if you are using a Windows Server 2008 DHCP server to assign networking configuration to these clients. Windows Vista and Windows Server 2008 DHCP clients use both Option 121 and Option 249.
Importing Hammer of God Country IP Block Network Sets Into ISA Enterprise Policies
Recently I was called upon to assist a customer with configuring their ISA firewall to block all traffic to or from specific country IP address blocks. Fortunately this task is made much simpler thanks to the wonderful work by Thor at Hammer of God. At the Hammer of God web site you can download pre-configured ISA computer sets that you can easily import in to your ISA firewall configuration.
These networks sets were exported from ISA 2006 Standard edition. If you are importing these computer sets in to the Standard version of Microsoft ISA Server, the process is very straightforward. Simply download the computer set for the country you wish to block and import them in to your policy. If you wish to import these computer sets in to ISA 2006 Enterprise, that’s a little different. ISA does not support importing/exporting objects to/from Standard and Enterprise versions natively. There is a workaround, however. It can be accomplished easily by changing the fpc4:Edition element in the XML export file from “16” to “32”, as shown here…
…but that will only allow you to import the network set in to an array policy. If you would like to import these network sets in to an an enterprise policy, you can follow the procedures outlined here.
Start by downloading a network set from Hammer of God. For demonstration purposes here I have chosen the network block for the country of Albania (nothing personal against Albania, it’s just that the network set was small and convenient!).
1. Create a computer set at the enterprise level. Give the computer set a descriptive name, then choose ‘Ok’ to continue.
2. Hightlight the computer set you just created, then right-click on the computer set and choose ‘export selected’.
3. The ‘Welcome to the Export Wizard’ dialog box appears. Choose ‘Next’ to continue.
4. Specify the file name and location to save the export to. Choose ‘Next’ to continue.
5. Choose ‘Finish’ to complete the export.
6. Next, open the network set downloaded from Hammer of God with an XML editor or Notepad. Select and copy all of the data between and including the fpc:4AddressRanges tags…
…clip…
7. Open the blank enterprise network set export created earlier with an XML editor or Notepad. Highlight and select the entire following line:
Paste the data you copied previously here, then save the file.
8. In the ISA Management console, highlight the blank enterprise network set created earlier and choose ‘import to selected’.
9. The ‘Welcome to the Import Wizard’ dialog box appears. Choose ‘Next’ to continue.
10. Specify the location of the file you just saved, then choose ‘Next’ to continue.
11. Choose ‘Finish’ to complete the import, then apply the changes to the enterprise configuration.
Your enterprise network set is now populated with information and is ready to be used in both enterprise policies and array policies.
It Starts…
After many years of consuming blog information from a variety of different sources, I have finally decided to become a contributor by creating this blog. My plan is to share with you some of the knowledge and experience I have gathered in working with Microsoft ISA Server for over ten years (dating back to Proxy 2.0!). I am currently employed by Celestix Networks as a Senior Sales Engineer, specializing in the MSA security appliance featuring Microsoft ISA Server 2006. I will endeavor to share with you relative, pertinent information that you will hopefully find useful. One of my mottos is “you can’t fix something if you don’t know how it works correctly in the first place”, so in support of that you will likely find references to information that I consider to be fundamental. A strong, foundational knowledge of any complex system is essential to any troubleshooting that takes place, and that is especially true in the world of enterprise networking.
Connect
Richard Hicks' Forefront TMG Blog 