Richard Hicks' ISA/TMG Blog

The flood mitigation features included in Microsoft ISA Server 2006 were one of many improvements over previous versions of ISA. Enabled by default, this enhanced network protection functionality allows the ISA firewall to withstand direct attacks (e.g. DoS or SYN flood) and provides resiliency in the event of a worm breakout. There are times, however, when this feature can impede valid network communication. If, for example, a host protected by the ISA firewall is very busy it may run in to connection limits imposed by the firewall. When this happens you may see the following error in the event log: ‘TCP connections per minute from one IP address limit exceeded’.

When legitimate network communication is dropped for this reason, it is possible to configure the firewall to allow more connections for this host. This is accomplished by opening the ISA management console, expanding the ‘Configuration’ node in the console tree, then clicking on the ‘Configure Flood Mitigation Settings’ link in the ‘Additional Security Policy’ section.

Too often I see administrators disable flood mitigation altogether. This is strongly discouraged. I also see administrators raise connection limits for ALL hosts by clicking on the ‘Edit…’ button and entering a new limit. This is also a bad practice. The best way to resolve this problem is to add the host(s) to a computer set, then add that computer set to the ‘IP Exceptions’ list.

In my experience this often needs to be done for DNS servers and for busy mail servers. Your alerts will tell you which systems are good candidates for the exception list though, so be sure to monitor your ISA firewalls closely.

In a recent blog post, Yuri Diogenes cautions us that we should not be installing IIS on ISA. I couldn’t agree with him more! There is, however, one exception – when it is installed from the factory on a Celestix MSA or WSA Series security appliance. Celestix installs and configures IIS on our ISA and IAG appliances to support our web-based remote management console. Under no circumstances should the IIS services on our appliances be used to support any other content or application. This configuration is definitely not supported and our support engineers will not be able to assist you if you attempt to do so!

When the ISA firewall is configured as a forward proxy server, the web proxy listener is configured to use integrated authentication by default.

A web proxy client makes its initial request anonymously. If there are no policies allowing anonymous access to the requested destination, the ISA firewall responds with a challenge for authentication in the form of an HTTP 407 response (proxy authentication required).

The client then resubmits the request, this time providing credentials to the firewall. This transaction is completely transparent to the end user. The credentials supplied to the ISA firewall are that of the current logged on user. If the user does not have permission, the ISA firewall denies the request without prompting. This behavior is by design.

There are situations in which this behavior is not desirable. Recently I was working with a customer who had workstations configured to log on automatically with a non-privileged domain service account. These workstations were used to access a web-based application on the local intranet. There are times when privileged users will need access to the Internet from these systems, but they will need to do so without logging the service account off. To meet these requirements we needed to configure the ISA firewall to prompt authenticated users for credentials if they are initially denied access.

Making this change required setting the value of the ReturnAuthRequiredIfAuthUserDenied property of the web proxy listener to ‘true’. When configured, the ISA firewall will prompt authenticated users for credentials when they are denied access. This change cannot be made via the management console; it can only be configured programmatically. The MSDN reference for this property contains a VBScript that is used for changing this setting, or you can download the script here. Run the script from the command line on the ISA firewall with the argument ‘true’ to enable prompting for authenticated users who are denied access and ‘false’ to disable it.

For example…

ReturnAuthRequiredIfAuthUserDenied.vbs true

…enables the prompting of authenticated users who are denied access, and…

ReturnAuthRequiredIfAuthUserDenied.vbs false

…disables it.

By default, the Microsoft ISA Server firewall is configured to deny all traffic that is not explicitly permitted by an access rule. This means that the firewall administrator will need to configure a number of access rules in order to facilitate domain and client communication, among other things.

Thankfully the ISA firewall includes a set of system policy access rules that simplify the configuration and operation of the firewall. The system policy contains a set of pre-configured access rules that allow ISA and the underlying operating system to communicate with things such as domain controllers, DNS servers, authentication servers, etc. The system policy rules are hidden from view by default. If you wish to see the system policy rules themselves, right-click on the ‘Firewall Policy’ node, highlight ‘View’, and then select ‘Show System Policy Rules’.

To edit the system policy rules, right-click on the ‘Firewall Policy’ node and choose ‘Edit System Policy…’.

If you have chosen to display the system policy rules you can double-click any rule or right-click a rule and choose ‘Edit System Policy’ to bring up the system policy editor as well.

Although having pre-configured system policy rules is convenient, some of the rules are broad or may not be required in your environment. I would highly recommend that you review and edit the system policy prior to deploying a production Microsoft ISA firewall. For example, by default the system policy is configured to allow DHCP requests from the ISA firewall to the Internal network.

From a security perspective it would be best to specify which DHCP servers your ISA firewall can communicate with. Create new computer objects for each of your DHCP servers and specify them as the source for this rule instead of the entire Internal network. If none of your firewall’s network interfaces are configured to use DHCP you can safely disable this rule.

Another instance where the system policy can be tightened up is the DNS system policy rule. By default this rule allows the ISA firewall to communicate to DNS servers on all networks – and that includes the external network! (see Jason Jones’ blog post on proper ISA firewall network configuration)

This is an excellent opportunity to improve the security posture of your ISA firewall. I would recommend that you specify which DNS servers the ISA firewall can communicate with explicitly. Create new computer objects for each of your DNS servers and specify them as the destination for this rule, removing of course the ‘All Networks (and Local Host)’ network object.

One more example of broad system policy configuration is the SMTP system policy rule. By default this rule allows the ISA firewall to communicate to any SMTP server on the Internal network.

Again, your configuration will be much more secure if you specify which SMTP servers the ISA firewall can communicate with. If you are not using STMP notifications on the ISA firewall you can safely disable this rule.

These are only a few examples of areas where the system policy rule set can be tightened to improve security on the ISA firewall. Once you have completed your initial configuration, I would strongly encourage you to review and edit these policies. By disabling unnecessary rules and restricting the access on others you can enhance the already secure configuration of the ISA firewall.

Microsoft ISA Server 2006 features role based administration to provide granular access to the ISA firewall configuration and security policies. When configured properly, users who have local administrative rights on the underlying operating system do not implicitly have administrative privileges on the ISA firewall. The security model of the ISA firewall is such that administrative access is defined by the firewall administrator explicitly. However, during the process of installing ISA Server 2006, the BUILTIN\Administrators group, along with the account of the user installing the software is automatically added to the ‘ISA Server Full Administrator’ role. This is done for the obvious reason that someone has to be able to administer the firewall once it is installed!

While this default configuration is good for functionality, it is not particularly ideal for security. The domain administrators group is typically a member of the local administrators group on all domain-joined Windows systems (your ISA firewall should be a member of the domain!). However, do you want all of your domain administrators to have full control over your firewall? In small to mid-sized deployments, perhaps. In larger enterprise deployments, not likely. Now I realize that if you can’t trust your domain administrators you have a serious problem, but I also believe strongly in the principle of least privilege. I would much prefer to keep the number of firewall administrators to a bare minimum.

In my opinion, one of the first things an ISA firewall administrator should do is immediately remove the local administrators group and explicitly define the firewall administrators. In fact, I recommend defining your administrators by their individual user accounts as opposed to using local or domain groups. I prefer this method because it provides more control over who has ISA firewall administrative rights. If you decide to define your ISA firewall administrators by group, be sure to use restricted groups to prevent someone from intentionally or unintentionally adding unnecessary users to the ISA firewall administrators group.