Archive
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.
Controlling ISA Enterprise Configuration Storage Server Replication
One thing I believe that most ISA firewall administrators take for granted is the Configuration Storage server (CSS). Rightfully so however, because with very few exceptions you simply install the CSS (preferably two for redundancy!) and forget about them.
Something that can easily be overlooked with large, complex enterprise deployments with multiple Configuration Storage servers (deployed in multiple geographic locations) is replication. If you are not familiar with the ISA CSS, it is an instance of Microsoft’s Active Directory Application Mode (ADAM); essentially a small, self-contained LDAP directory that is used as the data repository for configuration and policies for Microsoft’s ISA Server 2004 and 2006 Enterprise editions. And exactly like Active Directory Domain Services (AD DS), it is a multi-master database which replicates in much the same way.
When you install the first CSS, a default site is created named ‘Default-First-Site-Name’. When you add additional Configuration Storage servers to this enterprise, regardless of physical location, they are all included in this same default site. In most cases this is not an issue. Having all Configuration Storage servers in a single site ensures that configuration changes between the array members and the CSS are quickly propagated. The assumption of course is that all of these Configuration Storage servers are well connected. If they are not – for instance if you have Configuration Storage servers in your enterprise that are located on the other side of a slow WAN link – this replication can consume a lot of bandwidth and may not be desirable.
In cases such as these it becomes necessary to create ADAM sites, which are identical to AD DS sites. These sites are logical boundaries that typically correspond to physical network locations and can be used to define replication parameters. Intrasite replication assumes that systems are well connected, and as such are optimized for speed. Intersite replication assumes that systems are not well connected, and are therefore optimized for reduced bandwidth consumption.
Configuring ADAM sites is accomplished with the use of the ADAMSites tool. With the ADAMSites tool you can create, view, and delete ADAM sites. Once you have created your ADAM sites you can use the tool to also create, view, and delete site links as well. When creating the site links you can specify the cost of the site link, as well as the replication interval. Once you have established the necessary site links you can then move Configuration Storage servers in to the sites as necessary.
For more information I recommend that you read my good friend Jason Jones’ blog post entitled “Using the ADAM Sites Tool with ISA Server 2006 Enterprise Edition“. Jason also has a very detailed and informative CSS FAQ that is definitely recommended reading for anyone wanting to know more about the Configuration Storage server.
ISA Server Detected Routes…
Another common ISA alert that I often get questions about is the following:
“ISA Server detected routes through the network adapter [network interface] that do not correlate with the network to which this network adapter belongs. When networks are configured correctly, the IP address ranges included in each array-level network must include all IP addresses that are routable through its network adapters according to their routing tables. Otherwise valid packets may be dropped as spoofed. The following ranges are included in the network’s IP address ranges but are not routable through any of the network’s adapters: [address ranges];. Note that this event may be generated once after you add a route, create a remote site network, or configure Network Load Balancing and may be safely ignored if it does not re-occur.
The routing table for the network adapter [network interface] includes IP address ranges that are not defined in the array-level network [network object], to which it is bound. As a result, packets arriving at this network adapter from the IP address ranges listed below or sent to these IP address ranges via this network adapter will be dropped as spoofed. To resolve this issue, add the missing IP address ranges to the array network. The following IP address ranges will be dropped as spoofed: [network object][address ranges];”
Essentially what this alert means is that there is a there is a mismatch between the configuration of the network object in the ISA management console and the routing table of the corresponding network interface. If you are not experiencing any network connectivity issues, or you just made changes to your network configuration, you can probably safely disregard this message. You will not, in most cases, see this message again. If you are seeing this alert on a consistent basis however, you might wish to look at your networking configuration more closely. For the networking to work correctly on the ISA firewall, each network interface should contain routes that correspond to any networks that are reachable through that particular network interface. The network objects in the ISA management console should be configured to include this network and all reachable networks as well. This is critical because if the routing table is configured to include networks that are not included in the ISA network object, the ISA firewall will reject this traffic as spoofed.
There are times when you will have network objects configured with addresses or networks that do not have routes associated with them, and in which case you will see this alert. A case in point would be when a situation arises that you need to exclude a particular address , address range, or subnet that your underlying routing infrastructure routes through another gateway. A common scenario that I have encountered is when registered IP addresses are used for private connectivity over dedicated circuits when connecting to business partners. In this case I would include the IP address(es) of the business partner in the ‘Internal’ network object so that my web proxy and firewall clients would bypass the ISA firewall when communicating with hosts on these networks.
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 Server 2006 Workgroup Deployment Certificate Renewal
One question that I hear with regularity is “how do I renew the machine certificate for my CSS?” when ISA Enterprise is configured in a workgroup. In the past I have recommended running a repair from the installation media, then specifying the new certificate when prompted by the installation wizard. Recently I asked my good friend Yuri Diogenes if there was a better or easier way to accomplish this. In an article he just published on the ‘Tales From The Edge’ community site, he recommended using the ISACertTool utility.
The ISACertTool can be downloaded from Microsoft here. Before running the ISACertTool, make sure that you have a valid server certificate available in an exported (.pfx) file. Also, be sure to place the root certificate of the issuing CA is in a location that is accessible to all array members before running the tool. Once you have downloaded and extracted the ISACertTool according to the documentation, open a command window and execute the following command:
isacerttool.exe /st filename /pswd password /keepcerts
/st filename installs the exported certificate on the CSS. filename specifies the path and name of the exported certificate file.
/pswd password specifies the password that may be required when installing the server certificate
/keepcerts specifies that existing certificates should not be deleted.
Extract the ISACertTool on each array member, then open a command prompt and execute the following command:
isacerttool.exe /fw filename
/fw filename installs the root CA certificate in the local computer store. filename is the path and name of the root CA certificate.
Connect
Richard Hicks' Forefront TMG Blog 