Section 8.12. Securing It All | Learning Windows Server 2003

8.12. Securing It All

Ever since a Gartner Report stated that anyone using IIS as a production web server should immediately migrate to Apache, the popular Unix web server, Microsoft's web platform has gotten quite a bad rap. And a lot of it was deserved: buffer overflows,

Figure 8-44. Remote administration web page

what seems like 10 security bulletins each week, worms that take over computers faster than they could be secured while on the network, and so on. Part of the problem was that the version of IIS included with Windows NT and Windows 2000, Versions 4 and 5, respectively, were lax in their default permissions: everyone could do everything at any given time. Even the fact that IIS was installed by default during a Windows 2000 installation was a bad move: it didn't matter if you didn't want a web server because you got one anyway.

Those who prey on insecure web servers rely on users who are lax, lazy, or unknowledgeable about keeping their servers hardened and updated. Essentially, the climate of the Internet has degenerated into a situation in which even innocent users that get penetrated are used as attack mechanisms against other innocent but open servers. The responsibility lies not just with the attackers who propagate these worms, but also with the administrators who allow their machines to be used like toys.

In this section, I'll look at nine simple steps you can take to make sure you're not a victim, and that you're not an accessory to the hackers.

8.12.1. Enable IIS Only if You Use It

Although it's probably the simplest suggestion in this section, it's also the most effective. It's a lot harder to attack a web server through a vulnerability in the web server software when a machine isn't functioning as a web server. Unfortunately, Windows NT and Windows 2000 installed IIS by default for the most part and enabled it, too, so it was always running, waiting to serve either a legitimate HTTP request, or a message from a cracker.

IIS 6 fixes this problem somewhat: when you first install Windows, IIS isn't enabled at all, and even when you do enable it, it starts in a locked-down mode whereby dynamic content generation and script execution capabilities are disabled. In this default configuration, you can serve only static HTML pages. This is a big step in the right direction. In fact, when you upgrade a machine running Windows 2000 Server to Windows Server 2003, if it detects an IIS installation that still has the default settings engaged (a good sign it hasn't been modified or isn't in use), it will disable IIS upon the upgrade. You have to explicitly turn it back on.

If you do happen to be running IIS on a machine for any reason, and you want to decommission the machine as a web server but keep IIS on it anyway, you can do so by following these steps:

Open the Computer Management applet inside the Control Panel.
Double-click the Services icon to launch the Services console.
Scroll through the list and find World Wide Web Publishing Service, and select it.
Right-click the service, and select Stop.
If you don't intend to run the web server anymore, set the startup options to Disabled, and the service won't be restarted upon a reboot of the machine.

Better yet, get rid of IIS entirely if you're not using it anymore. Open the Manage Your Server console from the Start menu, and click Remove This Role under the Application Server heading. This is the most secure option.

8.12.2. Query All IIS Machines for Their Update Level

Given the number of patches released from 2001 to the present day, it can be tough to look at your network and determine the update level of each machine. Microsoft, sensing the need to remove a bit of egg from its face, purchased a license from Shavlik Technologies for the HFNetChk utility, short for Network Hotfix Checker. You can find hfnetchk.exe at:

http://www.microsoft.com/downloads/details.aspx?familyid=b13ebd6b-e258-4625-b0a3-64a4879f7798&displaylang=en

HFNetChk is exposed through the Microsoft Baseline Security Analyzer command-line interface through the following command: mbsacli.exe /hf. The latest version of the HFNetChk engine is available in Microsoft Baseline Security Analyzer (MBSA) v1.2.1.

HFNetChk is a command-line tool that scans Windows computers for installed updates and patches. The comparison is based on an XML file of all available updates and the criteria for those updates, and Microsoft updates the list constantly.

The first time you run the tool, the tool will download the signed XML file, verify its authenticity, and decompress the file. HFNetChk then scans the selected computers to figure out the level of the operating system, service packs, and programs installed on the systems. HFNetChk looks at three aspects of your system to determine if a patch is installed: the registry key that is installed by the patch, the file version, and the checksum for each file that is installed by the patch. By default, HFNetChk compares the files and registry details on the computer that is being scanned to the XML file that it downloads. If any of the three criteria discussed previously are not satisfied, the tool considers the associated patch to be absent and the results are displayed on the console. In the default configuration, HFNetChk output displays only those patches that are necessary to bring your computer up to date.

To use the tool, run the MBSA program and access HFNetChk from the command line with the -v option for verbose output, like so:

     Mbsacli.exe /hf -v

The utility will scan your system and report on any missing patches, sorted by KB number. You also can scan with this command:

     mbsacli.exe /hf -d HASSELLTECH

This will specify that all computers in the NetBIOS domain name HASSELLTECH should be scanned. It's a useful way to look at patch levels of multiple computers on the network at the same time.

8.12.3. Keep IIS Updated

Now that you know what hotfixes you need, you can update all your IIS boxes around your network. You can do this in a few ways, depending on how involved you as the administrator want to get. I'll look at two, with a tip for a third method.

8.12.3.1. Using Windows Update

Microsoft has recently improved its Windows Update web site utility. When you surf to http://www.windowsupdate.com, the site will search your system to see at what update level you are, and then list which hotfixes and service packs are applicable for your machine. This is a good, if not automated, way to ensure that you're completely recent in all code on your machine. The downside is that you are never quite sure what's been installed where because you don't actually go through the installation process yourself.

You also can set up the Automatic Updates utility in Windows by right-clicking My Computer and selecting Properties from the menu. Navigate to the Automatic Updates tab, and you can indicate to Windows Server 2003 if you want updates to trickle down to your computer automatically and be installed on a set schedule. If you set patches to automatically download and install, you will never have to worry about not being up to date. Alas, some people don't trust Microsoft enough to come out with robust patches that simply can be installed on the day of their release; most administrators are in the habit of waiting a few days after a patch and letting other businesses be guinea pigs. But if you're a one-man shop and have eight other tasks to do at one time, the Automatic Updates solution might be good for you.

8.12.3.2. Using network-based hotfix installation

You also can download the individual security hotfixes and service packs one by one, save them to a central directory, and manually update each IIS machine on your network. Simply look at each security bulletin, or download the appropriate service packs (as of this writing, Windows Server 2003 is available), and store them in the same directory. Then, prepare a batch file.

Let's say you have two hotfix files to install. You surf the Web, find the files, and download them to \\mercury\xd5fe. Each hotfix is a separate executable. To simplify installation, I'll use two switches, -z and -m, that instruct the hotfix setup process to do so quietly (without raising dialogs to the user) and to not reboot at the end. Armed with this knowledge, I'll simply prepare a batch file similar to the following:

     Set qfedir=\\mercury\qfe\     %qfedir%Q554147_wxp_sp2.exe -z -m     %qfedir%Q711041_wxp_sp2.exe -z -m

I'll type that text in Notepad and save it as a file called UPDATE1.BAT. The first line sets a variable for the path to the hotfix files, and the variables are used in the lines that call each hotfix. This way, if you decide to change the location of the hotfixes, you have to update only the first line, not each individual line.

Now, just run UPDATE1.BAT on all the computers that require those updates, or assign it via a login script through GP.

If you deploy your Windows Server 2003 machines using RIS, you can automatically preinstall all hotfixes before actual Windows installation is complete, saving you the time and tedium of applying them manually after Setup finishes. See the latter half of Chapter 2 for a complete walkthrough of this.

8.12.4. Use Both IIS and NTFS Security

IIS has a bit of virtual directory security in that it has permissions for reading, writing, and executing scripts, as well as other basic privileges within a virtual directory; these permissions also are independent of filesystem permissions. Here's a reminder of the available rights:

Script source access: Enables users to view the source code to scripts and applications within the selected directory, assuming they have read or write permissions to that directory.
Read: Enables users to view or download files or directories, along with their individual properties.
Write: Enables users to upload files to the selected directory. It also enables them to change existing files within that directory.
Directory browsing: Enables users to view an HTML page listing the contents of the selected directory, including any subdirectories. Note that these subdirectories listed in this view are physical filesystem directories, not IIS virtual directories.

As I mentioned earlier in the chapter, users browsing web content on your IIS machines are actually logging in to a guest-like IUSR account on your machine or directory service. Out of the box, Windows Server 2003 sets the following restrictions on the NTFS permissions given to the IUSR account:

A user logged on through the IUSR account can only read and list the contents of the web root directory. No execute permissions are present, so scripts cannot run and no one can write files to the directory.
The IUSR account has read, execute, and list contents permissions inside the Windows directory, just as the Authenticated Users group does.

Other than those exceptions, the IUSR account has no NTFS permissions across any file or folder on a disk. You can use the NTFS permissions, as covered in Chapter 3, to lock down IUSR's ability to further access content on your site.

8.12.5. Evaluate the Indexing Service

The installation process for Windows Server 2003 does not install the Indexing Service out of the box, so that ounce of prevention is a good step. However, indexing files on your hard disk or network opens up a whole host of issues that might be difficult to predict without careful planning. For example, what if you indicate to the Indexing Service that you want to index all files on your drive? The service would gladly do so, but it might also find angry letters to your users' superiors, love notes to their wives or girlfriends, salary information from the payroll department, memos from the boss on the latest round of layoffs, and so on. You can see that access to these bits of information by just anybody could create a disaster.

You can manage the Indexing Service using the MMC snap-in ciadv.msc. Loading the applet will present the dialog shown in Figure 8-45.

Figure 8-45. The Indexing Service management console

You can delete catalogs by simply right-clicking their names within the listing and selecting Delete. You can adjust the indexing properties for each catalog by right-clicking the name and selecting Properties. If you want the service not to index something, you can tell it directly (without the need for adjusting permissions) by right-clicking a catalog and selecting Directory from the New menu.

Now, bear with me for a moment as we delve into some seemingly backward logic: by default the Indexing Service takes a directory that you give it and indexes all its contents, including child files and subfolders. The key to excluding directories from indexing is to add a directory to the catalog, and then instruct the service not to index it. On the Add Directory dialog, you see an option to the right called Include in Index. This is where you can indicate whether to index a particular directory. So you can enter the base directory for the indexlet's call it C:\Documentsand tell the Indexing Service to index it by clicking Yes to the option on the right. But for this example, suppose you have a folder in C:\Documents called Top Secret. Tell Indexing Service to ignore it by adding C:\Documents\Top Secret as a directory, but before you click OK switch the Yes to a No under Include in Index.

Of course, that's a very backward way of doing things, and it would have been a far better decision on the part of Microsoft to include an option that gives you the choice of which subfolders, if any, to index, within the management console of the Indexing Service. In true Microsoft form, you can indeed make these changes somewhat intuitively, albeit in a different placethe Advanced Attributes section of the Properties sheet of any file or folder. Just right-click any folder, select Properties, and then on the General tab click Advanced. The top section, archive and index attributes, contains an option that allows you to enable or disable the Indexing Service's access to this object. When you make a change and click OK, a dialog box will appear, asking if you want to apply the changes to subfolders and files within those subfolders.

So, with those points out of the way, consider the following suggestions about deploying the Indexing Service in your organization:

Immediately remove the two catalogs the service creates upon installation by default, called Web and System. These index all web content and all files on your system, respectively.
Understand the hierarchical nature of the indexing permission. If you give a top-level folder permission to be indexed, any subfolders contained within that folder will automatically have permission to be indexed as well.
Explicitly enable the permission on only files and folders that you're sure you want indexed. It's easier to control what is being indexed when everything is not indexed by default.

The Indexing Service is a good thing, when kept under control. Unfortunately, a few worms have decided to take advantage of some flaws in its construction, so if you use the service you need to especially ensure you keep your IIS machines updated early and often.

You can find out more about the Indexing Service in Chapter 13.

8.12.6. Kill Unused Ports

This should really go without saying as firewalls become more pervasive, but you should protect your IIS machines by allowing traffic only on those ports that are required for its operationby allowing traffic only on ports 80 and 443, for example. I know there are remote administration features that are great for internal servers, but with the continued security flaws that IIS has had, why take a chance exposing what amounts to root access to the outside world? Kill everything but ports 80 and 443 into your IIS machine and rest a bit easier at night.

You can disable these ports through a hardware or software firewall, or through an IPsec filter. I cover configuring IPsec filters in Chapter 11.

8.12.7. Delete Default Directories

Lots of web-based programs often come with sample files, instruction pages, and installation scripts that assist you in setting up and using the programs easily. When I was running my web hosting business, more than 75% of the scripts I used on a day-to-day basis, either that my customers needed installed or that I used to manage the systems, came with install scripts and default pages that left access to an account, a database, or even worsea machinenearly unguarded. These scripts don't advertise their presence, but it isn't hard for a nefarious person to look in standard places, such as a directory called INSTALL off of the web root, and wreak havoc on a machine.

IIS is no different from these other programs. Here's an action list of items to remove from the server, assuming none is being actively used:

IIS comes with a web-based program so that you can remotely administer an IIS server from afar. I'll make my comment on that in as few words as possible: bad idea. Don't install it at all.
FrontPage Extensions also expose a lot of functionality that might not be needed otherwise. If you're using FrontPage, by all means continue to use the bots, but if you've installed the extensions only because you don't feel like digging the Server 2003 CD out if you ever need it again, go ahead and uninstall it.
If you're not using the extensions or any type of SharePoint site, be it from Team Services or the full-fledged Portal Server product, delete the Microsoft SharePoint Administration site.
Get rid of web-based printingdoes anyone actually use it anyway?by deleting the folder called Printers from the web root.

8.12.8. The Ins and Outs of ISAPI

ISAPI is CGI's like-minded brother on the Windows platform. It allows for dynamic extensions to static HTML content, and new technologies such as Active Server Pages and other dynamic languages use ISAPI filters to interact with IIS. Of course, this opens up a potential security hole.

You need to make sure that the only ISAPI filters configured on your system are those that are in use. (You can find ISAPI filters in the Properties sheet for any web site.) For most systems, that would be the ASP.NET service. Look through your web root directory, and note the extensions on all your content. Do any differ from .HTM? If not, make sure any filters that are listed in the Properties tab are removed.

As a colleague points out, the entire Code Red virus could have been prevented had the IDA ISAPI filter been removed from IIS installations worldwide.