Installing ISA Server 2006 Enterprise Edition (beta) in a Unihomed Workgroup Configuration
Post Installation Tasks Part 4
|
Have Questions about the article? |
If you would like to read the other parts in this article series, then check them out at:
Specify Certificate Revocation Settings
The ISA firewall can be configured to verify that incoming certificates are not included in a CRL. You have the following options:
- Verify that incoming client certificates are not revoked – I’ve often found the term “client certificate” to be an unfortunate one, because it lacks intuitive precision. What do I mean by that? What I mean is that you should use terms that provide clear and distinct meanings, and help create contrast for similar terms. Do you know what a client certificate is? If there was actually an entity called a “client certificate”, then you should be able to request one from a Certificate Server. Unfortunately, you can’t request a client certificate from a Certificate Server because there is no such thing as a client certificate. The term “client certificate” is a misnomer for a User Certificate. When you enable this option, the ISA firewall will check the CRL to determine if the User Certificate presented to the ISA firewall is revoked. Note that this option only applies when you have enabled User Certificate authentication on the ISA firewall’s Web listener for Web Publishing Rules.
- Verify that incoming server certificates are not revoked in a forward scenario – This option applies when the ISA firewall, acting as a Web proxy, initiates a secure connection to an upstream ISA firewall or Web server. In the upstream Web proxy scenario, the ISA firewall can provide HTTP to SSL bridging, where the client behind the downstream ISA firewall sends the request via HTTP and the downstream ISA firewall forwards the request to the upstream ISA firewall using HTTPS (SSL secured HTTP). Note that SSL is used only for the Web proxy connection. The original HTTP request is then forwarded by the upstream ISA firewall as an HTTP connection request to the destination server.
- Verify that incoming server certificates are not revoked in a reverse scenario – This setting applies when the ISA firewall publishes a Web site. When the ISA firewall creates the second SSL session (between itself and the published Web site on the corporate network), it will check the CRL for the certificate presented by the published Web site.
Figure 1
The default settings are fine. However, if you want to make sure that connections are not made to a published Web server that sports a revoked certificate, then you should enable the last option in the dialog box above.
Specify Diffserv Preferences
Diffserv is a method used to provide Quality of Service (QoS) to packets moving over a network. Diffserv is short for Differentiated Services. Diffserv uses bit settings in the TOS IP header to mark packets for different levels of service. That is to say, Diffserv marks packets at different levels of priority. Those with higher priority are handled by Diffserv enabled network devices (routers and switches) first and lower priority packets are held in queue for a period of time determined by the algorithm used by the network device manufacturer.
You can access the Diffserv options on the General node under the Configuration node in the left pane of the ISA firewall console. Click the Specify Diffserv Preferences link in the middle pane and you’ll see what appears in the figure below.
Figure 2
I’m not going to spend much time with Diffserv, as it’s a complex topic that requires you understand both how the ISA firewall handles Diffsrv bits and how your current network infrastructure is configured to support Diffserv. If you have never heard of Diffserv, then you can comfortably ignore the ISA firewall’s support for it. If you have heard of Diffserv, and you know that your corporate networking infrastructure supports Diffserv based levels of service, then you can benefit from it. Keep in mind that Diffserv bits are added only to HTTP communications and no other protocols. That’s fine for our unihomed Web proxy only ISA firewall, but hopefully in the future we’ll see QoS support of some kind for all protocols (including VoIP).
For more information about Diffserv and how it works, check out http://www.rhyshaden.com/qos.htm
Define LDAP and RADIUS Servers
The ISA firewall supports a variety of authentication mechanisms. These include:
- Integrated authentication – Integrated authentication is available when the ISA firewall is a domain member. When the ISA firewall is a domain member, you can take full advantage of all authentication protocols supported by Active Directory. The ISA firewall communicates directly with the domain controllers to authenticate users. This option provides by the highest level of authentication support for all protocols and access scenarios
- RADIUS authentication – RADIUS authentication requires that you have one or more RADIUS servers deployed on your network. The ISA firewall forwards the user credentials in clear text to the RADIUS server and then the RADIUS server forwards them to the Active Directory authentication server. RADIUS authentication support is used only for Web proxy filter mediated requests, which include forward and reverse (Web Publishing) proxy scenarios. There are significant performance and administrative overhead costs you pay when using RADIUS authentication
- LDAP authentication – This is a new feature included in ISA Server 2006. Now you can configure an ISA firewall that is not a domain member to use LDAP calls to the domain controller. This allows you to take advantage of Active Directory users and groups, unlike RADIUS authentication, where you cannot use Active Directory groups.
The figures below show how to configure both RADIUS and LDAP servers. You should configure your RADIUS and LDAP servers before creating Access Rules, because at this time (Beta 1), you can’t create these servers “on the fly” when configuring an Access Rule or Publishing Rule.
To access the RADIUS and LDAP server configuration interface, click the General node located under the Configuration node in the left pane of the ISA firewall console. In the middle pane of the console, click the Define LDAP and RADIUS Servers link.
Figure 3
Figure 4
|
Have Questions about the article? |
Configure Intrusion Detection and DNS Attack Detection
The ISA firewall includes a built-in IDS/IPS system for basic network level and DNS attacks. To reach the configuration interface for the ISA firewall’s IDS feature set, click the General node located under the Configuration node in the left pane of the ISA firewall console. Click the Enable Intrusion Detection and DNS Attack Detection link in the middle pane of the console.
The Enable intrusion detection option is enabled by default. Detection for all of the attacks except for port scans is enabled by default. I highly recommend that you do not enable the port scan attack detection unless you have a network intrusion analyst on your staff who understands the nature of port scans and how to perform follow up investigations on these events. If you do not have an intrusion analyst available, the only thing you gain by enabling port scan detection is undue anxiety in your customer base without achieving any higher level of security.
Figure 5
The ISA firewall can also detect common DNS related attacks. The DNS attack detection is enabled by default, the DNS host name overflow and DNS length overflow attacks are automatically selected. The DNS zone transfer attack is not selected by default. If you don’t want to allow zone transfers from your published DNS servers, then enable this option. Remember to configure an Alert Definition for DNS attacks if you want to be notified when these take place.
Figure 6
Define IP Preferences
The ISA firewall’s IP Preferences configuration interface includes a loose collection of options aimed at customizing support for IP level communications. To reach the IP Preferences configuration dialog box, click the General node located under the Configuration node in the left pane of the ISA firewall console.
In the IP Preferences dialog box, click the IP Options tab. The Enable IP options filtering option is enabled by default, and the Deny packets with the selected IP options is automatically selected with a number of IP options to block pre-selected by the ISA firewall. Do not change these default IP Options settings unless you have a specific reason to do so.
Figure 7
Click the IP Fragments tab. The Block IP fragments option is disabled by default. The reason for this is blocking IP fragments from traversing the ISA firewall can interfere with L2TP/IPSec communications and also can adversely affect performance and reliability for streaming media.
In a unihomed Web proxy only ISA firewall configuration, L2TP/IPSec VPN connections is not an issue, since the unihomed Web proxy only ISA firewalls do not support VPN connections. Streaming media over HTTP may be less affected by fragmentation than streaming media over their native protocols, so you should enable this option for the unihomed Web proxy only ISA firewall and follow up on issues with streaming media, if any.
When you enable blocking of IP fragments, you’ll see a dialog box warning you that Enabling this option may result in the blocking of protocols that use large packets. For example, VPN connections that are based on L2TP or IPSec, and request for RADIUS authentication requiring certificates, may also be blocked. This brings up a good point that I should have mentioned earlier. IP Fragment blocking might interfere with EAP based communications with a RADIUS server. However, since this is primarily an issue with VPN certificate based EAP authentication, you shouldn’t have any problems in a unihomed Web proxy only configuration.
Figure 8
The IP Routing tab is perhaps one of the most confused options in the entire ISA firewall configuration. This has nothing to do with what you might consider IP Routing. Instead, this has to do with communications for complex protocols are handled by the ISA firewall.
For example, when you establish an active mode FTP connection, the data connection from the FTP server to the ISA firewall represents a secondary connection established by the FTP server to the ISA firewall. This session can be run in user or kernel mode. When IP Routing is enabled, performance for the secondary connection is much better.
The downside of enabling IP Routing on the ISA firewall is you won’t be able to enforce IPSec between Web proxy clients and the ISA firewall.
Figure 9
Configure Flood Mitigation Settings
While the bulk of improvements included in ISA Server 2006 are squarely focused on the ISA firewall’s Web proxy filter, there is one firewall oriented improvement you should definitely know about. This is the enhanced Flood Mitigation feature that allows you to configure and fine tune how the ISA firewall handles situations where it’s under worm and related network flood attacks.
The 2006 ISA firewall allows you to configure protection based on the following settings:
- TCP connect requests per minute, per IP address – Mitigates worm propagations that occur when an infected host scans the network for vulnerable hosts. Also mitigates flood attacks that occur when an attacker sends numerous TCP connect messages
- TCP concurrent connections per IP address – Mitigates TCP flood attacks that occur when an offending host maintains numerous TCP connections with ISA Server or with victim servers behind ISA Server
- TCP half-open connections – Mitigates SYN attacks where an offending host sends numerous TCP SYN messages without completing the TCP handshake. Note that the default limit for this mitigation is automatically calculated as half the limit set for concurrent TCP connections per IP address
- HTTP requests per minute, per IP address – Mitigates HTTP DoS attacks where an offending host sends numerous HTTP requests to victim Web sites
- Non-TCP new sessions per minute, per rule – Mitigates non-TCP DDoS (distributed denial of service) attacks that occur when numerous zombie hosts participate in an attack against a victim server or throttle the network by sending numerous non-TCP packets
- UDP concurrent sessions per IP address – Mitigates UDP flood attacks that occur when an offending host sends numerous UDP messages to victim hosts behind ISA Server
- Set event trigger for denied packets – Triggers an event notifying the ISA Server administrator about an offending IP address that has flooded ISA Server with numerous TCP and non-TCP packets denied by ISA Server policy. Also reduces logging and system resource consumption when ISA Server settings specify that traffic should not be logged.
Figure 10
The default settings are good to start with, but you’ll likely want to create exceptions for some servers, such as busy published Web servers and mail servers. You should keep a close watch on the ISA firewall alerts regarding these flood mitigation settings and then create exceptions based on the results of your inquires.
The figure below shows the IP Exceptions tab and the Computer Sets dialog box you’ll see after clicking the Add button. Here you can select an existing Computer Set, or create a new set for which there should be exceptions to the Flood Mitigation settings.
Figure 11
|
Have Questions about the article? |
Summary
In this article we concluded our post-installation tasks for unihomed Web proxy only mode ISA firewalls configured in a single server array. Now that we’ve finished that up, we’ll get to more interesting tasks, such as publishing SharePoint Portal Servers and Exchange Web services, using the new ISA Server 2006 feature set! See you then.
If you would like to read the other parts in this article series, then check them out at:
