Editing the ISA Server 2004 System Policy (Part 2)

Read Editing the ISA Server 2004 System Policy (Part 1)

Configuring System Policy Rules

After ISA 2004 installation it is highly recommended that the System policy rules be reviewed. This in turn will ensure that the security professional understands the rules applied and the rules that need to be mapped to the firewall security policy. The firewall security policy is a high level document that forms part of an IT professional’s security policy document that in turn maps to the acceptable use policy that HR gets a user to sign when joining the organization in some instances it may form part of the terms of employment. All System policy rules that are not used or that do not map to the security policy should be investigated and disabled. The reason for this is because if a firewall rule is not required it should be disabled explicitly. This type of behavior promotes good security practice. An analogy would be if you have a whole lot of switches controlling many lights. Only turn on the lights the IT professionals need to let IT professionals see. Leave the other lights turned off.


Figure 1.1: The system policy editor has many options that can be configured within the console. One specific policy that is useful is the one displayed above to do with DHCP servers that can service requests. Within this option you can configure the ISA server to use trusted DHCP servers. It is best to specify a computer instead of a network range as this is the most restrictive option.

Configuration Management Note
After major administration tasks are carried out, it is recommended that the system policy be reviewed, this practice should form part of IT professional’s configuration management on ISA 2004 documentation.

System policy rules should also only apply to required network entities. There should be no rules on a firewall that applies to a group called All. When the system policy is applied to the Local Host network these map directly to communication with the Microsoft Firewall service, and not with the ISA Server Host. (Exceptions: Remote Management configuration group)

A common mistake is when a system policy configuration group is disabled; this may not necessarily prevent use of a particular protocol. This is because the same protocol may be specified in a different rule, which is enabled by a different configuration group. Disable all rules independently and ensure they are not within other configuration groups.

System policy do’s

  1.  It is strongly recommended that the system policy be reviewed after ISA 2004 installation.

  2.  IT professionals should consider limiting the destinations for these system policy configuration groups, so that they apply only to specific computers on the applicable network.

  3.  After installation ISA has basic network capabilities, ISA Server can access name resolution servers and time synchronization services on the internal network. Although these basic services have been enabled you may want to disable them if you feel they may be a risk.

  4.  It may be that network services are required but reside on a different network; IT professionals should then modify the applicable configuration group sources to apply to the specific network. Be aware that incorrect modification of this portion of the system policy may introduce higher risk to the network.

  5.  The system policy should be configured, so that only particular computers on the internal network can be accessed. Alternatively, IT professionals can add additional networks or network sets, if the services are found elsewhere. Do not allow more access than is required.

  6.  In system policy ensure that the authentication servers are specific. The IT professional is able to create specific network sets that define the Directory servers (for Windows authentication) or the RADIUS servers located on the Internal network. Allowing the whole internal network is not a problem but defining a specific network set is more restrictive especially if it constricts the IP address to just one or two computers. The whole reason for this is because if an intruder wanted to spoof your directory servers he would have to have physical access to the machines to turn the machine off, etc.

  7.  Remote management is enabled by default; ISA Server can be managed by running a remote Microsoft Management Console (MMC) snap-in, or by using Terminal Services.


Figure 1.2: This depicts the remote management computer’s screen where specific computers can be added that will administer the ISA server remotely. By default, this empty computer set is created. Until the IT professionals do so, remote management is not available from any computer.

  8.  Restrict any diagnostic protocols unless they are dually needed. By default ICMP is allowed to all networks. This allows NetBIOS communication, by default to computers on the internal network.

  9.  It is recommended that IT professionals use Secure Sockets Layer (SSL) to encrypt the communication between the client and ISA Server. This type of solution secures the communication so that it can not be sniffed. Irrespective of if it is over wireless or copper.

  10.  In defining the ISA 2004 system policy always use the principle of least privilege allowed. Do not lock yourself out. To avoid this situation always make a backup of your ISA server. I recommend using a product like Virtual PC or Virtual Server to test your future ISA configurations. These great tools let you test the preferred configuration before applying them to the live ISA machine.

Do not browse the internet from your ISA machine. When testing internet access it is ok to quickly test through your ISA machine but it is important not to use ISA 2004 to browse as you will infect your ISA server with Malware and spyware downloaded from the internet website that you may visit. Rather use a client for browsing purposes. Do not install other applications that are not related to ISA as these introduce flaws in security and can bypass the system policy by some unknown backdoor system. It is always best to not allow anything to be installed on your ISA server as this may cause unnecessary risk.

It is a good idea to log as much as you can on the ISA server. The performance cost is low and you may at very least have some sort virtual “paper” trail in the event of some sort of intrusion attempt.

DCOM traffic is blocked even if RPC traffic is allowed. If IT professionals want to allow DCOM traffic, disable the remote management system policy rule. Instead, create a rule that applies to RPC traffic. Configure the RPC traffic for that rule so that Enforce RPC is disabled.

By default, these rules apply to the built-in Remote Management Computers computer set. When IT professionals install ISA Server, an empty computer set is created. This empty computer set can be used with computers that will remotely manage ISA Server.

The firewall client installation option is useful as you can restrict the computers you want to allow to install the firewall clients as this policy restricts access to the shares. You can also add exceptions to the access policy. It is recommended that this option be carefully guarded.

Note:
If the ISA computer is not in a secure location and if physical access is not restricted to the computer you may run into serious issues if an intruder were to come across the machine even if your System policy is configured correctly.

In system policy a connectivity verifier is disabled by default. This feature bypasses the ISA policy in order to verify correctly. When you create a HTTP connectivity verifier, ISA 2004 checks connectivity by sending a HTTP GET request to a defined computer. A system policy rule named Allow HTTP/HTTPS from firewall to all networks, for HTTP connectivity verifiers is configured as necessary, to allow these requests. This can be used to determine if certain sites are up for verification purposes.

There are many options outside of the system policy that modify the configuration of the policy that is why it can not be stressed enough that you have the system policy documented and compare it every time you make a change to ensure that the policy complies with stringent restrictions.

Summary

In the second part of this series I took IT professionals though system Policy and the details and defaults associated with system policy. Protocols like ICMP and monitoring protocols like NetBIOS are used for most diagnostic purposes however if these protocols are not managed correctly an intruder could use them against the network as these protocol reveal pertinent information mapping and detailing the resource within. In this article I have also taken you through the dos and don’ts of ISA 2004 system policy editing.

Read Editing the ISA Server 2004 System Policy (Part 1)

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top