Full Metal Jacket (or: On server hardening)
One argument I often hear when discussing ISA server with my more Cisco-minded colleagues is that even though ISA 2004 can be seen as a firewall, the fact that it runs on a Windows-based machine makes it insecure by default. True, when comparing an ASIC-firewall to a Windows-based machine out-of-the-box, the attack surface on OS-level is significantly smaller. So far, the number of exploits on the Windows OS widely outnumber that of, say, Cisco IOS. The keyterm here, however, is 'out-of-the-box'.
Anyone who has worked with Windows OS, be it NT4, 2000, XP, etc, will know that an out-of-the-box configuration is hardly truely secure. Even though Microsoft has improved the level of security with the past releases, it still takes a little tweaking to add that little bit of extra. In this article, I'll be discussing hardening a Windows 2003 server machine to provide a satisfactory level of security for an ISA 2004 installation.
There are various moments during a Windows installation when the system is vulnerable to exploits; for that particular reason, do not connect your server to the Internet (or even to your own LAN, if you suspect a threat from that side) during installation. Install the OS, then install a virusscanner. Update both the OS and the virusscanner using a CD containing the most up-to-date patches and fixes.
After installation is complete, you will want to secure the network interfaces on your server. For the interface on the local network, this rather depends on your domain configuration. However, for the Internet-side interface, make sure to disable the following options:
- Client for Microsoft Networks
- File and printersharing for Microsoft Networks
- Automatic DNS registration
- Netbios over TCP/IP
- LMHOSTS lookup
The same can be applied to your local interface, of course. However, keep in mind that the File and Printersharing is required on the internal interface if you wish to distribute the Firewall client from the ISA server. Ideally, move this share to another server. For the NETBIOS options, disable them if you have no need for them (no WINS required). Often, you will require the Client for MS Networks to connect to your internal resources, so you might wish to leave that enabled.
Ideally, you'd apply the High Security template to your ISA server. However, as this template tightens security to the system to the highest possible level, you may find it too restrictive for your requirements. To ensure the template you've applied doesn't restrict your server too much, you might wish to apply the Member Server template to the system first and then tighten security further using the latest version of the Windows 2003 Security Guide, which can be found at http://go.microsoft.com/fwlink/?LinkID=14845
After you have installed ISA 2004 and the latest Service Packs, you will find that access to the server is nearly impossible; installation of ISA 2004 shuts down access to and through the server almost completely. The keyterm here is 'almost'. If you're working behind the console of the server, you won't have too much trouble. If you are installing ISA 2004 remotely, however, keep in mind that when working behind, say, a NAT-firewall, you may find access through RDP impossible after ISA 2004 services have started; by default, ISA 2004 adds the IP-address of the remote workstation to the list of allowed management stations.. you figure out the pitfall there.. ;o)
When securing and configuring your ISA server, try to ask yourself the following question:
What exactly do I wish my ISA server to do ? Based on the answers you give yourself there, you may wish to add access rules and published servers.
A question often heard in the ISAserver.org mailing list is 'How do I open up port X ?', which is the wrong question. The correct question is: 'What sort of traffic needs to flow where for whom and when to provide the required service ?'. You will require the following information to answer this question:
1) What ports/protocols are required ? Can I tighten these any further than the default config ? Very often, you can by, for example, editing registry settings on your servers.
2) Who will require access ? Can I narrow it down to a specific subset of workstations and/or IP-addresses ? Ideally, you will specify the exact address information minimally required.
3) What kind of traffic is to pass through ? Especially when publishing HTTP, HTTPS and FTP, this is an important question, as you can limit the exact protocol operations possible to be performed very nicely with the application-layer filters provided by ISA Server 2004.
Remember, the trick is to deny everything and then, very consciously, add only the minimum requirements to your configuration. Narrowing down the surface of attack on a system is a valuable start in keeping your systems secure.
PS: A little while ago a critical exploit in the Cisco IOS was discovered that allowed an attacker to execute remote code on the system. Apparently, this exploit had been in the software for a very long time. Just goes to show that every system can have its vulnerabilities, eh.. ? ;o)