Archive
Microsoft ISA Server 2004/2006 Migration to Forefront Threat Management Gateway (TMG)
Jim Harrison and Mohit Saxena discuss Forefront Threat Management Gateway (TMG) migration strategies with David Tesar in this video on TechNet Edge.
ISA 2006 with Integrated Websense and the /3GB Switch
The /3GB boot.ini switch is perhaps the most misunderstood Windows tuning parameter there is. If you are not familiar with this switch, enabling it allows user mode processes to address 3GB of virtual memory instead of the usual 2GB. It does this at the expense of valuable kernel memory, however. The ISA firewall relies heavily on kernel memory (fweng.sys is the heart of the firewall core and runs in kernel mode) and cutting it in half can dramatically affect stability and performance by reducing the amount of available Paged and Non-paged Pool memory and reducing the maximum number of System Page Table Entries (PTEs). It has been well documented that the use of the /3GB boot.ini switch can cause serious issues, and in fact the ISA Best Practices Analyzer complains when it finds this switch in use.
Applications must be configured to take advantage of this additional memory made available by the /3GB switch. You can verify which applications are configured in this manner by using the dumpbin.exe utility that is included with Microsoft Visual C++ and specifying the /HEADERS parameter. Websense has enabled this functionality for some of their core services, and by looking at the headers for eimserver.exe version 7.1.0.1154 we can see that this image does indeed support large address space.
Websense is now optionally recommending that the /3GB switch be enabled when applying certain hotfixes. If you have Websense components installed on the ISA firewall itself I would strongly dissuade you from enabling the /3GB switch. If you are experiencing memory related issues with Websense services on your ISA firewall, add additional RAM. If memory related issues persist, remove all Websense services other than the filtering plug-in and place them on a separate system outside of the ISA firewall. You can then safely enable the /3GB switch on that system.
Microsoft ISA Server 2006 Web-based Management Console?
In response to my recent blog post about system policies in Microsoft ISA Server, several people asked me about a rule called ‘Web Management’…
The description of the rule states that “Enabling this configuration group enables system policy rules that allow remote management of ISA server from selected computers using Web applications”. This rule is disabled by default when you install the ISA firewall software. If you view the access rule itself, you will notice that the protocol defined is “ISA Server Web Management” and is configured to use TCP port 2175 outbound.
So, is there a native web-based management application for Microsoft ISA Server 2006? The answer is no; at least not natively. According to Jim Harrison, this system policy rule was implemented to provide OEM’s a way to enable remote web-based management of an ISA appliance. Embarrassingly enough, I work for Celestix Networks but didn’t know this. ; ) In my defense, however, the web-based management utility that ships with the Celestix MSA Series security appliance is configured to use port 10000. Since the ISA defined protocol was TCP port 2175, which coincidentally is near other native Microsoft ISA Server ports, it sure sounded plausible that maybe there was a native Microsoft ISA web-based management console (or perhaps there were plans for one at some point).
So there you have it. In spite of what the system policy rule might look like, there is no native Microsoft ISA Server web-based management console. If you would like the ability to manage ISA with a web browser, I would strongly encourage you to check out the Celestix MSA Series security appliance featuring Microsoft ISA Server 2006. Not only will you get an intuitive web-based management console, you’ll get plenty of other benefits as well.
Security Update for Microsoft ISA Server 2006 (MS09-031)
Microsoft today announced the availability of a security update for Microsoft ISA Server 2006. This update addresses a vulnerability with RADIUS One Time Password (OTP). This update is rated important, and affects only ISA Server 2006 (and only in very specific scenarios). Previous versions of ISA are not affected, nor is Forefront Threat Management Gateway. For additional information, please read this post from the ISA product team.
DNS Security Enhancements and Web Proxy Auto Discovery
Using Web Proxy Auto Discovery (WPAD) is a simple and effective way to configure web browsers to use the ISA firewall as a proxy server. WPAD can be implemented using DNS or DHCP, with DNS being the more common of the two. For WPAD using DNS, configuration is simple and straightforward; all that is required is that you configure a host record in DNS called WPAD that resolves to the IP address of your ISA firewall’s internal network interface.
On the ISA firewall, enable the ‘Publish automatic discovery information for this network’ option on the ‘Auto Discovery’ tab for the Internal network.
For Internet Explorer, navigate to ‘Tools/Internet Options/Connections/Lan Settings’ and select the option to ‘Automatically detect settings’ and your work is done!
Unfortunately this functionality can be easily leveraged for nefarious purposes. An attacker could create their own WPAD record (which can be accomplished simply if dynamic DNS is not configured correctly) and redirect traffic through a host that they control. From there they could have full view in to all web-based communication between a client and an Internet-based remote host.
In order to address this security concern, Microsoft has made changes to the way DNS works beginning in Windows Server 2008. DNS in Windows Server 2008 now includes a feature called the global query block list. Essentially this is a list of names that the DNS server will not respond to if queried. By default this list includes two entries; WPAD and ISATAP. You can view this list by executing the following command from an elevated command prompt:
dnscmd /info /globalqueryblocklist
If you are using Windows Server 2008 DNS and you wish to leverage DNS WPAD functionality you must instruct the DNS server to respond to these requests. Simply creating the DNS record by itself is not enough. On Windows Server 2008 you can configure WPAD by creating your DNS record as usual, then remove WPAD from the global query block list by executing the following command from an elevated command prompt:
dnscmd /config /globalqueryblocklist isatap
This command replaces the existing global query block list with only isatap. Remember to execute this command on each DNS server that is authoritative for your zone.
Although not recommended, you can also disable the global query block list functionality altogether by executing the following command from an elevated command prompt:
dnscmd /config /enableglobalqueryblocklist 0
Of course this functionality can be restored by executing the following command from an elevated command prompt:
dnscmd /config /enableglobalqueryblocklist 1
The global query block list functionality is also now included in security update MS09-008 for Windows Server 2003 DNS and WINS servers. This means that everything we’ve discussed here applies to Windows Server 2003 DNS servers with the MS09-008 update installed, with the exception of how the block list is configured. With Windows Server 2003 DNS and the MS09-008 update, management of the global query block list is done through the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services
\DNS\Parameters\GlobalQueryBlockList
If you have already configured WPAD record in DNS, the good news is that if you perform an in-place upgrade to Windows Server 2008, WPAD functionality will not be disabled. The same holds true if you install the security update for MS09-008. Any existing functionality will remain if it was in place prior to the upgrade or update. For additional information on the MS09-008 security update, read this blog post by the Microsoft Security Research and Defense team.
Security Update for Microsoft ISA Server 2006 and Forefront Threat Management Gateway (MS09-016)
Microsoft today announced the availability of a security update for Microsoft ISA Server 2006 and Forefront Threat Management Gateway. This update addresses two vulnerabilities; Web Proxy TCP State Limited Denial of Service Vulnerability [CVE-2009-0077] and a Cross-Site Scripting Vulnerability [CVE-2009-0237]. Please refer to Microsoft Knowledge Base Article 961759 for more information.
Using the ISA HTTP Filter To Modify Via Headers And Prevent Information Disclosure
The ISA firewall’s powerful HTTP filter allows us to inspect and modify HTTP request and response headers at a very granular level. The HTTP filter by default will allow only valid, RFC compliant HTTP communication to pass through it, and it will also limit the length of request headers. The HTTP filter is highly configurable though, allowing us to control which types of HTTP methods are allowed, which file extensions are allowed, which request or response headers are allowed, as well as giving us the ability to block content containing specific signatures defined by the ISA firewall administrator. Most often these advanced inspection features are used to block specific content using HTTP, such as instant messaging or peer-to-peer applications, or to prevent certain types of attacks against our systems by searching for and blocking communication based on a given string contained in request and response headers and bodies
An often overlooked use of the HTTP filter is the ability to control the HTTP Via header. The HTTP Via header is required when a proxy intermediates requests between a user and a remote host (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html – section 14.45). By default, the HTTP filter sends the default header, which is the hostname of the ISA firewall that handled the request. Since the hostname of your ISA firewall could (and should) be considered sensitive information, it is a good idea to configure the HTTP filter to send something other than the default header. This is accomplished by right-clicking on each access rule that includes HTTP as a defined protocol and choosing ‘Configure HTTP’. Select the ‘Headers’ tab, then select the option to ‘Modify header in request and response’. In the ‘Change to:’ field, enter something ambiguous. Typically I enter ‘PRIVATE’. If you have multiple ISA firewalls handling outbound Internet communication you may wish to choose something that is ambiguous but still allows you to identify which firewall processed the request, such as FW1.
The Perils of Virtualization
With all of the talk recently regarding the availability of Microsoft’s Intelligent Application Gateway (IAG) SP2 and its official support for running in a virtual infrastructure, as well as the support for Microsoft’s Forefront Threat Management Gateway running in virtual environments, there has been a quiet debate running among my colleagues and peers regarding the virtualization of security systems.
I realize that by virtue of the fact that I work for a hardware vendor (Celestix Networks) that my opinions will be considered by many to be biased. Somewhat perhaps, but the fact remains that virtualization, especially the virtualization of a security system, can prove to be extremely risky. Without proper planning, deployment, and ongoing monitoring of the virtual infrastructure the likelihood of a configuration error leading to a total and complete compromise of your security model is extremely high.
For those of you who might think this is just an alarmist’s point of view, I would encourage you to read this story posted recently at InformationWeek.Com. The article talks about a new virtualization security product, but the interesting thing to note here is that it includes a reference to a documented case where the misconfiguration of a virtual network resulted in a sensitive internal database server being connected directly to the public Internet. According to the article, this was put in to operation and was running for some period of time, until someone later discovered the error. Can you imagine if in this case it wasn’t a database server, but a security system responsible for protecting your entire internal private network?
This of course illustrates clearly the point I am trying to make – that there are substantial security risks associated with virtualizing your security infrastructure. Yes, there are some benefits, but I firmly believe that the risks far outweigh the rewards.
Microsoft ISA Server 2006 Now Common Criteria Certified
This morning it was announced that Microsoft ISA Server 2006 Standard and Enterprise editions have completed Common Criteria evaluation. Common Criteria Evaluation Assurance Level 4+ (EAL4+) is the highest level possible that is mutually recognized by all countries participating in certification. This new level of certification validates what those of us in the ISA community have know for quite some time – that the ISA firewall is truly an enterprise class firewall on par with any firewall product available.
ISA SecureNAT and Firewall Clients Can Bypass Websense Content Filtering
Websense content filtering software is an excellent add-on product for the Microsoft ISA firewall. If you have deployed the ISA firewall to secure outbound Internet access for your organization, I would strongly encourage you to consider this powerful software suite. An ISA/Websense solution will provide unparalleled protection against spyware, malicious mobile code, and many other threats. Websense features granular, user and group based filtering policies and with its modular design is highly scalable. With Websense Web Security you also get features such as enhanced security categories as well as real-time security updates, ensuring that your users are protected at all times, even from today’s advanced blended threats.
Although under most circumstances the Websense content filtering does a fantastic job, it is possible to bypass Websense filtering policies if the software is not configured correctly. For instance, if a workstation is configured as a web proxy client to the ISA firewall, communication is filtered properly. If the workstation also has the Firewall Client installed, the user can simply disable any proxy settings in their web browser, resulting in their HTTP communication being sent to the ISA firewall by the Firewall Client. Due to some vagaries with the inner workings of the Websense filtering mechanism, this communication may not be filtered.
The good news is that this issue is simple to resolve. A little known, and perhaps often overlooked, configuration change needs to be made if you expect content filtering to work correctly for ISA SecureNAT and Firewall Clients. That change is documented in the Websense Installation Guide Supplement for Microsoft ISA Server. On page 13 under the ‘Configuring the ISAPI Filter’ section you will see that in order to correctly filter SecureNAT and Firewall Clients you must create a file called ‘ignore.txt’ in the Windows\System32 folder. This file should contain the hostname of the ISA firewall that the filtering plug-in is installed on (note also that this entry should be in all caps). Recycle the Websense services in order for this change to take effect.
Connect
Richard Hicks' Forefront TMG Blog 