Richard Hicks' ISA/TMG Blog

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.

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.