By Deb and Tom Shinder
ISA Server is completely secure when you first install it. The default configuration settings on ISA Server prevent all inbound and outbound access (with the exception of some DNS and ICMP packets that are allowed by the default packet filters). ISA Server only becomes insecure after you start configuring it.
Note: Before evening getting into the specifics of ISA Server configuration, you should always install the latest hotfixes for both Win2k and ISA Server. At the time of writing this article, MS has released a Security Hotfix Rollup that updates the operating system with all the currently available hotfixes since SP2. You should also install the ISA Server SP1.
In this section we'll focus on ISA Server security in the following realms:
- Packet Filters
- Web Proxy Listeners
- Site and Content Rules
- Protocol Rules
- Publishing Rules
- Application Filters
Packet filtering must be enabled on the ISA Server. If you don't enable packet filtering, all ports that are opened by applications and services on the ISA Server will be open for business! The goal of enabling packet filtering on the ISA Server is to close off all ports on the external interface except those you have explicitly opened.
You have the option to allow IP Routing when packet filtering is enabled (actually, you can enable IP Routing even when packet filtering is disabled, but you will never want to do this). IP Routing is somewhat of a misnomer when it comes to moving packets between the Internet and the internal network. The reason for this is that all LAT hosts must use NAT to access the Internet. Even though NAT is considered a routing protocol, packets are not directly routed from the Internet to the internal network, so you don't have to worry about Internet packets being directly routed into your internal network.
However, IP Routing does allow non-TCP/UDP packets to move outbound from the internal network. IP Routing must be enabled to allow PPTP (which uses IP Protocol 47 GRE packets) and ICMP through the ISA Server. The problem with allowing IP Routing of these protocols is that you do not have any degree of access control over the routing of these packets. If you enable IP Routing everyone has access to outbound non-TCP/UDP protocols (as long as the packet filter is in place to support them).
This brings up the security weakness of packet filters and why you never use packet filters to control outbound or inbound access unless you really need to use them. Always use Protocol Rules and Publishing Rules to control outbound and inbound access.
You should also enable filtering of IP Options and IP Fragments. One of the most popular exploits on the Internet today involves bypass firewall protection through the use of fragmented packets. However, if you filter out IP fragments, you will find that some multimedia will not work correctly. Jim Harrison informs me that streaming over 100K is especially susceptible to breaking if fragment filtering is enabled. There should be some improvement in this regard with SP1, which allows for larger UDP packets. Be sure to test your application to ensure they work with fragment filtering enabled. IP Options filtering should always be enabled. This prevents source routed packet attacks.
Incoming Web Proxy Listeners
Incoming Web Proxy listeners should be created and enabled only if you plan to use Web Publishing Rules to publish Web Servers on the internal network. If you do not plan to use Web Publishing Rules, eliminate all Web Proxy service listeners.
You can remove Incoming Web Proxy Listeners by selecting the Configure listeners individually per IP address and then deleting any listeners that might be there. If you have not already created listeners, then the list should be empty. If so, leave it empty.
If you do plan on use Web Publishing, then you will need to use Incoming Web Proxy listeners. You can force authentication at the listener if you like, but many prefer to authenticate at the Web server itself. Its up to you. One thing you probably want to avoid is authenticating at both the listener and the Web site. I say this because there have been issues with this setup, although they may be resolved with Service Pack 1.
Site and Content Rules
On a stand-alone ISA Server, a default Site and Content Rule is created that allow access to all sites, and all content, at all times, to everyone. You should change this as soon as possible. You can delete this rule, or you can change it to allow Domain Users. If you leave this rule as is, you will have an anonymous access rule, and all Web Proxy clients will use the anonymous access rule first. That is the nature of the HTTP Protocol and there's nothing you can do about it. So, make the change to the default Site and Content Rule.
Keep in mind that if you have an anonymous access rule, that rule will always be applied before any other rules. For example, if you have a Deny rule that prevents the temps group from accessing www.hotmale.com , the Deny rule will be ignored because the anonymous access rule is applied first. However, if you have an anonymous access rule that Denies access, then the Deny anonymous access rule will be applied before the Allow anonymous access rule.
If you use Enterprise Policies, you'll notice that a default Site and Content is not created.
Note: If you change the default Site and Content Rule to a rule that requires authentication, you will have problems with servers that do not have logged on users. You can solve this problem by creating a Client Address Set for your servers and allow your servers access to the protocols they need access to.
There are no Protocol Rules configured on ISA Server after its installed. Because Protocol Rules are required for outbound access, no outbound access is possible until your create them.
There is a security concept known as the principle of least privilege. This means that you should only allow outbound access for those protocols that you require. Also, you should only access to those protocols to the users that require the user of those protocols. If there is no business need for a particular protocol, do not allow access to it.
How do you know which protocols you require? The best way to find out is to survey the users for the applications they require to get their jobs done. Then you can confer with the security team in your organization to determine which protocols are required by the organization. After you determine the required protocols and who needs to use them, create the appropriate Protocol Rules.
You should make it a daily policy to review the Firewall, Packet Filter and Web Proxy logs. Your review will be helpful in determining if users are attempting to use unapproved applications. The firewall logs are especially helpful in this regard because applications report to the Firewall client and service their names.
If you find that users are attempting to use warez applications like Napster, Kaaza and Morpheus, you must take action immediately as this places the company at risk. Make a network use policy and get the highest levels of management to sign off on it, so that employees can be fired if they violate corporate security policy.
Note: During your testing of ISA Server, you may have created "All Open" Protocol Rules and Packet Filters. After your testing is done, you must remove these settings to protect the integrity of your internal network.
Publishing Rules allow Internet and other external network users to access services on your internal network. Protocol Rules themselves don't offer must in terms of access control or protection from external network intrusion. If you create a Protocol Rule that allows access to your internal network servers, then anyone that has access can access the server service just as if they were on the internal network accessing the same service.
Web Publishing Rules allow you to control access based on user/group and client address sets. Server Publishing Rules allow you to grant access to the rule based on client address set. But once the user is allowed in, they have as much access as you have granted the user on the published server.
This means that Publishing Rules do not obviate your responsibility to maintain a high level of host based security. You must keep your internal network servers up to date with the latest security patches, and you must harden the servers as you would as if they were directly connected to the Internet. Do not think of Publishing Rules as a security measure. Think of them as a convenience measure that allows you to bring those servers onto your internal network so as to more easily manage them.
The ISA Server will always post an alert to the Event Logs in the event that an enabled alert was triggered. Alerts are strange things in ISA Server. You have the option to create new alerts, but you can't create any new alerts other than those that have already been configured on the server! I admit, you can create new alerts to allow you to perform extra actions, but you cannot create new alerts (at least there no non-programmatic way of doing this).
Nevertheless, you should review all the alerts available in the Alerts node. Some of them are more interesting than others. For those alerts that are more serious, such as an intrusion alert, you should configure an email be sent to you notifying you the alert took place. If you are in a high security environment, you should decide if you want to stop the services in the event of a major alert or start a monitoring program of some kind.
There are no hard and fast rules regarding alerts. You can leave the default configuration as it is, as all enabled alerts will report to the Event Logs.
Logging should always be enabled for each service. This is the default setting. You should never disable logging for any of the services because the logs are your first line of defense against a major attack or troubleshooting a problem with access and access controls.
New log files should be created each day, and the log files should be copied from the ISA Server to a safe location each day so that they are available if a hacker or hardware failure makes it impossible to retrieve them. The format isn't important, unless you want to use local time. Then you should save the logs in ISA Server file format.
The more fields you log, the more system resources will be required to log all of those fields. Review the fields included in you log files. The default settings are good and you are unlikely to need to change them. However, you might want to consider logging Rule#1 and Rule#2 for troubleshooting purposes.
By default, ISA Server will save the last 30 log files. If you create a new log file each day, then it will save one month's worth of log files. You might want to increase the number of log files to a larger number. I store a years worth of log files. Make sure that you select the compression option for the log files so that they do not overwhelm your disk space. I highly recommend that you get a 100+ GB drive dedicated to the storage of your log files. With compression, you should be able to keep about 200 GB of log files. The logs can grow very fast, and you may wish to save the logs on an extendable volume so that its easy to add disk space when required.
Hand in hand with Log Files are the log summaries. The ISA Server reports are constructed using the Log Summaries. You must select the Enable Reports option to create the reports. You must enable the Enable daily and monthly summaries options. To enable the greatest flexibility when creating reports, you should save a bunch of them. I saved two years worth of Daily summaries and three years worth of monthly summaries.
There are a number of application filters that ship with ISA Server. Several of them are important in generating security alerts. These filters are:
These application layer filters are able to examine the application layer data portion of the packet and alert you to certain security related concerns about that data. You should enable each of these filters, and for the DNS filter, enable each option. The SMTP filter allows for a greater number of options when used together with the SMTP Message screener.
Even if you do not use the SMTP Message Screener feature, the SMTP filter will examine SMTP commands and look for buffer overflow conditions for these command. The SMTP filter is disabled by default, but you should enable it before connecting the ISA Server to the Internet.
There are few legitimate users for the SOCKS filter unless you are in a hybrid environment. If you use a Windows environment, all clients will have the Firewall client software installed and thus will not need the SOCKS filter. The SOCKS filter can be used by dangerous applications, such as instant messengers, to subvert your security scheme.
The Local Address Table (LAT) defines what addresses are trusted by the ISA Server. Connections to trusted addresses are not handled by the ISA Server firewall service. This prevents wastage of processor cycles for internal client access to internal resources. One of the most egregious errors you can make is to try and "loopback" access to internal network resources through the ISA Server. This loopback situation is a result of a misconfigured DNS infrastructure, and not a problem with the ISA Server itself.
Never include external network addresses in the LAT. You can seriously subvert the security configuration of the ISA Server if you enter external addresses in the LAT. The ISA Server will see those addresses as local and will not subject requests from those clients to the rules engine.
The local domain table serves the same purpose as the LAT. You should put only local domains in the LDT. If you put external domains in the LDT, access to external resources in those domains will not be subject to the ISA Server rules engine. That explains why you can use the LDT workaround to get Outlook Express to access Hotmail. But this should be considered a security lapse. Any time an external domain is included in the LDT, you are weakening your security configuration on the ISA Server.
Note: You should add your external domain into the LDT if you've installed an internal DNS to avoid the dreaded 14120 error.
ISA Server includes some very nice Wizards that walk you through the process of configuring a VPN server and a gateway to gateway VPN configuration. However, keep in mind that the only ISA Server configuration made is to create packet filters to allow PPTP and L2TP/IPSec connections. All other VPN related configurations are made in the RRAS console.
If you allow VPN connections, you should configure RRAS Policies to limit who and how VPN connections are made to your server. There are a great number of options available to you via RRAS Policies and it's definitely worth your time to check these out.
If you use PPTP, you must require complex passwords. The level of security offered by PPTP is dependent on the complexity of the password. If your users use simple passwords, it will be relatively simple for a intruder to access your network via the VPN connection. If at all possible, you should use L2TP/IPSec as your VPN protocol. L2TP/IPSec requires the use of machine certificates. It can be difficult for an intruder to get access to a machine certificate from your organization. This provides an extra layer of security to your VPN solution.
In this article we went over what I consider to be important steps you should take to secure your ISA Server. Keep in mind that ISA Server is only one facet of your network security scheme. Host based security must also be implemented. The ISA Server is not the "total network security solution". Several other things you should think about in terms of securing your network include:
These are just a few of things you should consider when securing your network. ISA Server can do a lot, but it can't do it all. No firewall product can. But ISA Server does a damn good job at being a firewall!
Now for the checklist:
- Do not install services and applications on the ISA Server
- Harden the Windows 2000 OS
- Always install the latest security updates to Win2k and ISA Server
- Disable all services that aren't required by the base operating system and ISA Server
- Do not install ISA Server on a domain controller unless it's a dedicated ISA Server domain and forest
- Disable File and Printer sharing on the external interface
- Disable Client for Microsoft Networks on the external interface
- Disable NetBIOS over TCP/IP on the external interface
- Change the method for resolving unqualified names by choosing the Append these DNS suffixes (in order) option in the DNS tab in the Advanced TCP/IP settings Properties dialog box
- Determine whether your network infrastructure requires enabling the Microsoft Client, File and Printer sharing, and NetBIOS on the internal interface. If you do not require these features, try turning them off.
- Turn on packet filtering
- Do not enabled IP Routing unless absolutely required
- Enable fragment filtering
- Enable intrusion detection
- Enable filtering of IP Options
- Remove all Incoming Web Proxy listeners if you do not plan to use Web Publishing Rules
- Change the default anonymous access Site and Content rule so that it applies to domain users, or delete the rule entirely.
- Use the principle of least privilege
- Create Protocol Rules for only required protocols
- Limit access to protocols only to users that require them
- Allow access to Publishing Rules only for those that require access to the published server
- Configure the published server to allow access only to those that require access to the server
- Harden the published server as you would if the server were directly connected to the Internet
- Review the Available Alerts
- Configure important Alerts with response actions as determined by your corporate security policies
- Store Logs and Summaries on a dedicated, extendable disk
- Increase the number of saved log files
- Copy the log files each day to a safe location
- Increase the number of saved summaries
- Enable the DNS, POP and SMTP application filters
- Use the SMTP Message Screener if you require detection of more than SMTP command buffer overflows
- Disable the SOCKS filter
- Put only internal network addresses in the LAT
- Put only internal network domains in the LDT
- Do not "loopback" access to internal network resources through the ISA Server
- Use RRAS Policies to control access to your VPN server
- Require complex passwords, especially if you are using PPTP
- Migrate to an L2TP/IPSec VPN solution as soon as possible