High-Security IIS Deployment

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%SecurityTemplates 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_MACHINESYSTEMCurrentControlSetControl FileSystemNtfsDisable8dot3NameCreation=4,1 and HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices LanmanserverParametersAutoShareServer=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.

The IIS Lockdown Wizard
Security guides consistently give the same advice for maintaining a secure environment: Turn off all unnecessary facilities that can introduce additional vulnerabilities. The IIS Lockdown Wizard has automated this process.

The IIS Lockdown Wizard works with Win2K and Windows NT 4.0 servers and lets you easily remove unnecessary IIS services. To install the tool, download the application from http://www.microsoft.com/downloads/release.asp?releaseid=33961. Install this tool in development environments until you verify that all aspects of your Web application function properly.

After you complete the introduction and End User License Agreement (EULA) windows, the Select Server Template window will appear, as Figure 1 shows. Select a role for the server you want to secure. The server role you select will define the default answers in subsequent wizard pages.

For most server roles, you can install URLScan, which screens all incoming requests and compares them with an administrator-defined rule set. Scanning and evaluating each incoming request helps IIS process only valid requests. This approach eliminates most attacks based on long URLs or alternate character sets. Choosing the server role that most closely matches your server's role will help specify a default rule set that's appropriate for your machine.

You can use the IIS Lockdown Tool to disable and remove unused IIS features, such as FTP, SMTP, or Network News Transfer Protocol (NNTP) services. You can disable unused script mappings (e.g., Index Server, server-side includes, Internet Database Connector—IDC, .hrt scripting, Internet Printing). You can also remove the default virtual directories that IIS installs, disable WWW Distributed Authoring and Versioning (WebDAV), and restrict privileges for anonymous users. These options are user-configurable, so you can keep all the facilities your Web applications require.

After you perform the IIS lockdown and apply the hisecweb.inf template, test your application to ensure that the changes haven't modified your ability to successfully run the application. If you find that the new settings are too aggressive for your application, simply rerun the tool to roll back the changes.

Vulnerability Assessment Tools
Administrators—and intruders—use vulnerability assessment tools to identify a given system's vulnerabilities and generate a report that helps them determine which areas to address. As part of its Trustworthy Computing initiative, Microsoft has provided the Microsoft Baseline Security Analyzer (MBSA) tool, which is available as a free download from http://www.microsoft.com/technet/security/tools/tools/mbsahome.asp.

MBSA isn't as robust as other tools on the market (such as Internet Security Systems'—ISS's—Internet Scanner), but it's free. MBSA lets you scan the OS (English versions of Windows XP, Win2K, and NT 4.0), IIS, and Microsoft SQL Server, and includes password-strength checking and integration with the HFNetChk tool (see the next section) for investigating hotfix installations on a given machine.

MBSA supports a command-line interface that lets you run the tool en masse or on a schedule by using a remote task scheduler. (Figure 2, page 16, shows the interface for scanning a single computer.) The tool also lets you scan entire domains or IP address ranges. After it completes the scan, MBSA generates an enumerated report.

Ongoing Security
Applying hotfixes in a timely manner is a crucial part of maintaining the integrity of your computing environment. Microsoft's HFNetChk tool helps administrators determine which systems need which hotfixes and helps keep them up-to-date with hotfix announcements.

In addition, MBSA uses HFNetChk as an optional component for vulnerability analysis. In "Automating Hotfixes," April 2002, InstantDoc ID 24268, I discuss HFNetChk in detail and describe how you can use it as the basis for an automated hotfix deployment system.

Going the Distance
Microsoft's tools provide basic security for Web servers, but they don't automate security. The tools don't cover IP Security (IPSec) policies, address TCP/IP filtering, disable parent paths for IIS applications, or remove Remote Data Services (RDS). You must manually secure the file systems for your applications and drives that are beyond the system partition. The tools remove the default virtual directories but don't remove the default application files or let you do more than disable FTP, NNTP, or SMTP services.

To get a leg up on security, read the IIS security white papers on the Internet and keep up with the intruder community. Microsoft's tools don't transform machines into fortresses, but they can provide reasonable security that can help reduce the threat of worm attacks and casual intruders.