Hardening the Base ISA Firewall Configuration and Operating System - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Hardening the Base ISA Firewall Configuration and Operating System

While the ISA firewall software does an exceptional job of protecting the firewall from attack, there are things you can do to further harden the ISA firewall configuration and the underlying operating system.

In this section, we'll discuss the following hardening and local security issues:

ISA firewall service dependencies You need to know what services the ISA firewall depends on before disabling services on the firewall. In this section, we'll present the list of ISA firewall software dependencies.

Service requirements for common tasks performed on the ISA firewall There are several maintenance tasks that you can run on the ISA firewall that depend on features provided by the underlying operating system. In this section, we'll examine some of these features and the services they depend upon.

Client roles for the ISA firewall client rules This ISA firewall may need to act as a network client to a variety of network services. In this section, we'll review some of the network client roles and operating system services required for the ISA firewall to fulfill those roles.

ISA firewall administrative roles and permissions Not all ISA firewall administrators are created equal. In this section, we'll discuss the ISA firewall administrative roles and how to provide users more granular control over the ISA firewall configuration and management.

ISA firewall lockdown mode The ISA firewall needs to protect itself and the networks dependent on it in the event that an attack shuts down the ISA firewalls Firewall Service. In this section, we'll discuss the ISA firewall's Lockdown Mode.

ISA Firewall Service Dependencies

One of the more frustrating aspects of the ISA Server 2000 firewall was that there was never any definitive guidance regarding what services were required for full firewall functionality. Many ISA fans attempted to divine the service dependencies, but no hard and fast guidance was ever developed. To make life even more difficult for the ISA Server 2000 firewall administrator, the ISA Server 2000 System Hardening Templates invariably broke key features of the firewall and the underlying operating system.

These problems are corrected with the new ISA firewall. Now we know the exact services required by the ISA firewall software. Table 6.13 lists the core services that must be enabled for ISA Server and the ISA Server computer to function properly.

*The startup mode for the Server service should be set as Automatic in the following circumstances:

You install Firewall client installation share on the ISA firewall

You use Routing and Remote Access Management, rather than ISA Server Management, to configure a virtual private network (VPN). Required if you want to use EAP user certificate authentication for demand-dial VPN connections and troubleshooting of demand-dial VPN connections

IF other tasks or roles table require the Server service

The startup mode for the Routing and Remote Access service is Manual. ISA Server starts the service only if a VPN is enabled. Note that the Server service is required only if you need access to Routing and Remote Access console (rather than Microsoft Internet Security and Acceleration Server 2004 management console) to configure a remote-access VPN or site-to-site.

Service Requirements for Common Tasks Performed on the ISA Firewall

Specific services must be enabled in order for the ISA firewall to perform necessary tasks. All services that are not used should be disabled. Table 6.14 lists a number of tasks the ISA firewall's underlying operating system may need to perform. Enable those services required to perform the tasks you want to perform on the ISA firewall and disable services responsible for tasks you will not be using.

Client Roles for the ISA Firewall

The ISA firewall may need to act in the role of client to network services located on protected and non-protected Networks. Network client services are required for the ISA firewall to act in its role of network client. Table 6.15 lists possible network client roles the ISA firewall may act as, describes when they may be required, and lists the services that should be enabled when you enable the role.

After determining the appropriate service configuration for your ISA firewall, you can save the configuration in a Windows security template (.inf) file. Check www.isaserver.org for sample ISA security templates covering several common scenarios. ISA Firewall Administrative Roles and Permissions Not all firewall administrators should have the same level of control over the ISA firewall's configuration and management. The ISA firewall allows you to provide three levels of control over the firewall software based on the role assigned to the user.

The ISA firewall's Administrative Roles are:

ISA Server Basic Monitoring

ISA Server Extended Monitoring

ISA Server Full Administrator

Table 6.16 describes the functions of each of these roles.

Users assigned to these roles can be created in the ISA firewall's local SAM, or they can be domain users if the ISA firewall is a member of the Internal network Active Directory domain. Any users can be assigned to one of the ISA firewall's Administrative roles, and no special privileges or Windows permissions are required. The only exception to this is when a user needs to monitor the ISA Server performance counters using Perfmon or the ISA Server Dashboard; the user must be a member of the Windows Server 2003 Performance Monitors User group.

Each ISA Server role has a specific list of firewall administrator and configuration tasks associated with it. Table 6.17 lists some firewall tasks and the Administrative roles that are allowed to perform each task.

To assign administrative roles, perform the following steps:

Click Start, point to All Programs, point to Microsoft ISA Server, and click ISA Server Management.

Click the server name in the left pane of the Microsoft Internet Security and Acceleration Server 2004 management console. Click Define Administrative Roles on the Tasks tab.

On the Welcome to the ISA Server Administration Delegation Wizard page, click Next.

On the Delegate Control page, click Add.

In Group (recommended) or User dialog box, enter the name of the group or user to which the specific administrative permissions will be assigned. Click the down arrow in the Role drop-down list and select the applicable administrative role. Click OK.

Click Next on the Delegate Control page.

Click Finish on the Completing the Administration Delegation Wizard page.

Click Apply to save the changes and update the firewall policy

Click OK in the Apply New Configuration dialog box.

Lockdown Mode

The ISA firewall sports a new feature that combines the need to isolate the firewall and all Protected Networks from harm in the event that the ISA firewall is attacked, to the extent that the Firewall services are shut down. The ISA firewall accomplishes a combination of protection and protective accessibility by entering lockdown mode.

Lockdown mode occurs when:

An attack or some other network or local host event causes the Firewall service to shut down. This can happen from a fault, or you can do it explicitly by configuring Alerts and then configuring an Alert Action that shuts down the Firewall service in response to the issue that triggered the Alert.

Lockdown mode occurs when the Firewall service is manually shut down. You can shut down the Firewall service if you become aware of an ongoing attack while configuring the ISA firewall and the network to effectively respond to the attack.

Lockdown Mode Functionality

When in lockdown mode, the following functionality applies:

The ISA Firewall's Packet Filter Engine (fweng) applies the lockdown firewall policy.

Firewall policy rules permits outgoing traffic from the Local Host network to all networks, if allowed. If an outgoing connection is established, that connection can be used to respond to incoming traffic. For example, a DNS query can receive a DNS response on the same connection. This does not imply that lockdown mode allows an extension of existing firewall policy for outbound access from the local host network. Only existing rules allowing outbound access from the local host network are allowed.

No new primary connections to the ISA firewall itself are allowed, unless a System Policy Rule that specifically allows the traffic is enabled. An exception is DHCP traffic, which is always allowed. DHCP requests (on UDP port 67) are allowed from the Local Host Network to all Networks, and DHCP replies (on UDP port 68) are allowed back in.

Remote-access VPN clients will not be able to connect to the ISA firewall. Site-to-site VPN connections will also be denied.

Any changes to the network configuration while in lockdown mode are applied only after the Firewall service restarts and the ISA firewall exits lockdown mode.

The ISA Server will not trigger any Alerts.

Connection Limits

The ISA firewall puts a limit on the number of connections made to or through it at any point in time. Connection limits allow the ISA firewall to block connections through the firewall for clients that may be infected with worms that attempt to establish large numbers of connections through the ISA firewall. Examples of such worms are mass mailing worms and the Blaster worm.

For Web Publishing Rules, you can customize a total number of connections limit by specifying a maximum number of concurrent connections in the Properties of the Web listener. Any new client requests will be denied when the maximum number of connections configured to the Web listener is reached.

You can limit the total number of UDP, ICMP, and other Raw IP sessions allowed by a Server Publishing Rule or Access Rule on a per-second basis. These limitations do not apply to TCP connections. When the specified number of connections is surpassed, new connections will not be created. Existing connections will not be disconnected.

You should begin by configuring low connection-limit thresholds. This enables the ISA firewall to limit malicious hosts from consuming resources on the ISA Server computer.

By default, connection limits for non-TCP connections are configured to 1000 connections per second per rule and to 160 connections per client.

Connection limits for TCP connections begin at 160 connections per client. You should not change these limits unless you notice that legitimate hosts are being blocked because the limiting is too low. You can determine if a host is being blocked because it has exceeded its connection limit by an associated Alert. The Alert will provide the IP address of the host exceeding its allowed number of connections.

Perform the following steps to configure connection limits:

Click Start, point to All Programs, point to Microsoft ISA Server, and click ISA Server Management.

Expand the server name in the left pane of the Microsoft Internet Security and Acceleration Server 2004 management console, and expand the Configuration node. Click the General node.

Click Define Connection Limits in the details pane.

On the Connection Limit tab (Figure 6.32), check the Limit the number of connections checkbox. You can then configure the number of Connections created per second, per rule (non-TCP) and Connection limit per client (TCP and non-TCP). Some machines may need access in excess of these numbers, such as busy published servers. In that case, you can click Add and select a Computer Set to apply the Customer connection limit value.

Figure 6.32: The Connection Limits Dialog Box

New connections will not be created after the specified number of connections is exceeded. However, existing connections will not be disconnected. Up to 1000 new connections are allowed per rule, per second by default. When this default limit is exceeded, an alert is triggered.

A log entry is recorded when the limit is exceeded:

Action is Connection Denied

Result code is FWX_E_RULE_QUOTA_EXCEEDED_DROPPED

You should limit the number of connections hosts can make to prevent flood attacks. Many requests are sent from spoofed source addresses when a UDP or IP flood attack occurs, and this can result in a denial of service.

Try the following when the limit is exceeded:

If the malicious traffic appears to originate from an ISA firewall Protected Network, this may indicate a host on the Protected Network has a virus or worm infection. Immediately disconnect the computer from the network.

Create a rule denying access to a computer set that includes the source IP addresses if the malicious traffic appears to originate from a small range of IP addresses on an external network.

Evaluate the overall status of your network if the traffic appears to originate from a large range of IP addresses. Consider setting a smaller connection limit so that ISA Server can better protect your network.

If the limit has been exceeded due to a heavy load, consider setting a higher per-rule connection limit based on your analysis of your network's requirements.

In firewall chaining, and in some back-to-back ISA firewall scenarios, make sure to configure customized connection limits for the IP addresses of the chained server or back-end ISA firewall. Also, if your system publishes more than one UDP-based or raw IP-based service to the External network, you should configure smaller limits to help keep your network secure from flood attacks.

You can limit the total number of UDP, ICMP, and other Raw IP connections allowed per client. You can specify custom limits to apply to specific IP addresses. This is useful when you want to allow specific servers to establish more connections than allowed to other clients.

For TCP connections, no new connections are allowed after the connection limit is exceeded. Make sure you set connection limits high enough for TCP-based services, such as SMTP, so that SMTP servers can send outbound mail and receive inbound mail. For other connections (Raw IP and UDP), older connections are terminated when the connection limit is exceeded so that new connections can be created.

DHCP Spoof Attack Prevention

Some of you may want to use DHCP on the external interface of the ISA firewall so that it can obtain IP addressing information from your cable or DSL company's DHCP server. You might encounter problems with obtaining an IP address on the external interface when that interface is configured to use DHCP to obtain IP addressing information. A common reason for this problem is the DHCP Spoof Attack prevention mechanism.

It's important to understand the DHCP attack prevention mechanism to solve this problem. For each adapter on which DHCP is enabled, the ISA firewall maintains the list of allowed addresses. There is an entry in the registry for each DHCP enabled adapter:

The registry key name is

HKLM\SYSTEM\CurrentControlSet\Services\Fweng\Parameters\DhcpAdapters\<Adapter's MAC>/<Adapter's hardware type>

The values under the key are:

The adapter's name

The ISA network name of the adapter

The adapter's MAC address

ISA network addresses

The adapter's hardware type

Figure 6.33 shows an example of the registry key:

Figure 6.33: Registry Key for DHCP Attack Prevention

When the ISA firewall's driver sees a DHCP Offer message, it validates the offer using the following logic:

Using the DHCP 'Client Ethernet Address' field and the 'Hardware Type' field, the driver finds the corresponding registry key of the adapter.

If there is no registry key, the packet is allowed (this will be the case during initial setup of the ISA firewall software).

The driver verifies that 'Your IP Address' field in the DHCP Offer contains an IP address within the addresses of the adapter's network element (as written in the registry).

If the verification fails, the packet is dropped, and an ISA alert is raised.

Figure 6.34 shows an example of a DHCP offer packet (the relevant fields are marked).

Figure 6.34: Network Monitor Capture of a DHCP Offer Packet

The invalid alert contains the following information (Figure 6.35):

Figure 6.35: An Invalid DHCP Offer Alert

In case the network adapter should receive the offered address, the administrator should use the 'Renew DHCP addresses' task that appears in the Task pane of the ISA firewall console. Figure 6.36 shows the warning dialog box you'll see when you click Renew DHCP Addresses in the Task pane .

Figure 6.36: The Renew DHCP Addresses Warning

After clicking Yes, all registry keys related to DHCP attack prevention are deleted, and an 'ipconfig /renew' is performed. This means that during this period, no offered address will be dropped by the driver (because there are no registry keys). Once the adapters receive their addresses, new registry keys are written with the new values, and the mechanism will be activated once again.

Dropped DHCP offers due to DHCP Attack Prevention may happen in the following scenarios:

If you have two DHCP adapters and you switched them. For example, the one that was connected to the internal network is now connected to the external network, and vice versa.

A DHCP adapter was moved to a different network. For example, ISA's external NIC was connected to a home network where another router made the connectivity to the ISP (and the Internet), and now you try replacing this router to use ISA's external NIC for connecting the ISP.

In such cases you need to use the Renew DHCP Addresses task, in order to allow the DHCP assignment. Note that once it's allowed, you will not need to allow it anymore. This procedure is needed only after changing the DHCP adapter in such a way that it becomes a member of a different ISA network element