Thanks to Microsoft's recent commitment to security, locking down an IIS server has never been easier. The problem isn't that Microsoft ignored security in its products; the problem is that we administrators and developers ignored it.
Let's look at the facts. Organizationally, our greatest security concerns lie in people and processes, not necessarily in technology. Microsoft has always given us the ability to secure the registry and file systems, as well as easy methods to disable unused services, but administrators tended to simply adopt the default settings.
Security isn't just a concern for external-facing Web servers anymore. We also need to look at how we apply security to servers on the internal network. In this article, we'll look at some of the free Microsoft tools you can use to secure your IIS 5.x servers.
Social Engineering
When you use Microsoft's tools to secure individual servers, look closely at processes that might compromise your computing environment. Examine any team that has the ability to talk with the outside world (e.g., Help desk, internal systems administration groups). Make sure those users don't have more privileges than their jobs require. Find out whether your tools perform any human-to-human authentication when you call for a password reset on your highly privileged user accounts.
Examine the tools and processes you use to change or terminate accounts for users who change jobs or companies. For example, do you have a program that assigns unique identifiers to all user accounts so that you can reconcile and terminate user accounts? When an IT staff member leaves the company, are that person's accounts disabled and service account passwords changed to prevent access?
Despite our best efforts to secure technology, some of our greatest enterprise-security vulnerabilities aren't technology-based. Instead, they find their roots in faulty procedures and myopic views within the organization. These vulnerabilities can often be extremely difficult and expensive to address.
Application Architecture
Developer ignorance is no excuse for poor application security. Many developers don't have a good handle on security concepts. Every organization seems to have a horror story about how an architectural oversight compromised an application or knows of an application that received special security-compromising concessions so that it could run properly.
Security is a bit like electricity: Exploits follow the path of least resistance. Although you can set ACLs on every file and registry key and turn off unnecessary services, if an application is poorly designed, it can become a welcome mat for people who want to exploit a server. So after you identify glaring people or process concerns that exist in your enterprise, you should take a look at how applications influence enterprise security.
Predefined Templates
In Windows 2000, Microsoft provides several default security templates in the \%systemroot%\Security\Templates folder that help administrators apply baseline configurations to servers. These files come in several flavors, from low to high security, with each upward step impacting application compatibility.
The "Predefined security templates" article on the TechNet Web site (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/proddocs/sag_scedefaultpols.asp) describes the default templates in more detail. Choose a template that most closely resembles your security policy and modify the policy as needed. If you aren't familiar with how to use these templates, you'll find basic instructions in the Microsoft article "HOW TO: Apply Predefined Security Templates in Windows 2000" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q309689). These templates can drastically modify your system, so test them before you apply them in a production environment.
Security templates are cumulative; a single template might not provide full coverage for your server. For example, although the Microsoft article "IIS 5: HiSecWeb Potential Risks and the IIS Lockdown Tool" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q316347) tells you to download and apply the hisecweb.inf file, this template ignores file-system and registry security. Instead, it applies default templates to provide these configuration settings. Applying the securews.inf template and a slightly modified hisecweb.inf template creates a secure but usable IIS server.
Before applying the templates, review each setting and make any amendments necessary to support your application. Two settings in the hisecweb.inf template tend to be troublesome for application installation and support: the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control \FileSystem\NtfsDisable8dot3NameCreation=4,1 and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Lanmanserver\Parameters\AutoShareServer=4,0 registry subkeys. The first setting disables 8.3 filename creation in NTFS; the second setting disables the administrative shares. As always, before you apply templates, consider how they compare with your organization's current security policies.