Archive
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.
Scalable Networking Pack and the ISA Firewall
If you’ve spent any time at all looking at alerts on a Microsoft ISA firewall, you have no doubt seen the following alert:
“The Windows Server 2003 Scalable Network Pack, which is included in Windows Server 2003 Service Pack 2, is enabled. Some ISA Server features will not work properly if a network adapter installed on an ISA Server computer supports and uses the Scalable Network Pack features. For more information, see the Microsoft Knowledge Base article 948496. If you do not have a network adapter that supports the Scalable Network Pack features, you can disable the Windows Server 2003 Scalable Network Pack Enabled alert.”
What does this mean? What is the Scalable Network Pack? Why are we being alerted about it? How did it get installed? Well, let me answer some of those questions for you!
The Microsoft Windows Server 2003 Scalable Networking Pack (SNP) provides support for network acceleration and offloading technologies available in today’s advanced network interface adapters to increase performance and scalability. It was made available as an update to Microsoft Windows Server 2003 SP1, and was later included in Windows Server 2003 SP2. The Scalable Networking Pack consists of the following three new features:
TCP Chimney Offload – Provides for automated, stateful offload of TCP processing to a network adapter that includes a TCP offload engine (TOE). For certain types of network communication (typically large file transfers) TCP Chimney Offload reduces CPU overhead by offloading network packet processing tasks such as packet segmentation and reassembly to the network adapter.
Receiver-side Scaling – Enables the processing of inbound networking traffic to be shared across multiple CPUs. Applications that rely heavy on inbound network communication that run on a multiprocessor system can benefit from Receiver-side Scaling.
NetDMA – Enables memory management efficiencies through direct memory access (DMA), provided the server supports this.
All of these features are wonderful, and have the ability to dramatically increase throughput and substantially reduce processor utilization for network intensive applications. At first you might think that these features would be beneficial to the ISA firewall, but unfortunately, they are not. TCP offloading is designed primarily for large file transfers, and provides little benefit for short-lived conversations that are typical of network traffic handled by the ISA firewall. There are also some incompatibilities as well. For instance, Receiver-side Scaling is incompatible with both NAT and NLB, both commonly configured on an ISA firewall.
It is for these reasons that you will see this alert generated by the ISA firewall, and as a best practice you should disable these features to prevent unexpected behavior. Microsoft Knowledge Base article 948496 includes an update to turn off the default SNP features, as well as instructions on how to disable these features by editing the registry.
The History of Microsoft
I learned recently from my good friend Kurt Shintaku that Tina from MSDN Channel9 is publishing a video series of the history of Microsoft. Although this is not directly related to Microsoft ISA Server or Forefront Threat Management Gateway, I did think this was interesting and wanted to pass it along to everyone. Each Thursday they will be airing a brand new episode, which will being with the year 1975 when Microsoft was formed.
RunAs Radio Appearance
Recently I was invited to be a guest on RunAs Radio, a weekly Internet audio talk show for IT professionals working with Microsoft products. I had the opportunity to chat with hosts Richard Campbell and Greg Hughes about the Microsoft ISA firewall, the forthcoming release of Threat Management Gateway, as well as the Celestix MSA security appliance. RunAs Radio has been around since 2007 and has featured guests such as Mark Minasi, Clint Huffman, Steven Choy, Brian Komar, and Steve Riley, just to name a few.
Forefront Threat Management Gateway Program Manager Interview
An interview with Ori Yosefi, Threat Management Gateway Program Manager, about the recently released Microsoft Forefront Threat Management Gateway – Beta 2.
Forefront Threat Management Gateway Beta 2 – Now Available!
The second beta for the forthcoming release of Microsoft Threat Management Gateway is now available. The new features in this latest beta release are impressive! Among them are support for ISP redundancy (multiple gateways!), advanced intrusion prevention, anti-malware scanning for both e-mail and web traffic, forward SSL content inspection with selective inspection capabilities, and URL filtering. This product is now a comprehensive unified threat management system that is tightly integrated, easy to deploy and manage, and will afford exponentially improved security protection over Microsoft ISA Server 2006.
ISA Connectivity Verifier Refresh Rate
One of the advanced features of the Microsoft ISA firewall’s monitoring capabilities is the connectivity verifier. A connectivity verifier allows us to monitor services on remote hosts that the ISA firewall depends upon to provide service (such as infrastructure services like DNS or Active Directory domain controllers), or perhaps that the ISA firewall is responsible for protecting (such as a published server). When you configure a connectivity verifier, you have the option to choose from one of three methods of verifying connectivity; you can send an HTTP ‘GET’, send a ping (ICMP) request, or establish a TCP connection to a specific port (obviously your best choice!). In the event a monitored resource fails to respond to a connectivity verifier, a no connectivity alert is raised for which you can configure any number of responses, such as recording the event in the event log, sending an e-mail to an administrator, stopping or starting services, or running a program. We also have the ability to control the number of times an event occurs before the alert is triggered, as well as what happens when the alert thresholds are met subsequent to the alert.
By default, connectivity verifiers are configured to perform their checks once every thirty seconds. In some instances, however, this may not be adequate. While there is no option in the GUI to alter this parameter, it is exposed via COM. Please refer to the Microsoft KB article Setting the Refresh Rate for Connectivity Verifiers for more information and to find the VBScript that allows this configuration change to be made.
Connect
Richard Hicks' Forefront TMG Blog 