Internet Information Server hacks are legendary, including many into Microsoft itself. Here's how to keep your Web sites from becoming famous for the wrong reasons.

9 Steps to Securing IIS

Internet Information Server hacks are legendary, including many into Microsoft itself. Here's how to keep your Web sites from becoming famous for the wrong reasons.

When IIS is involved, I feel kind of like the writer of the now infamous pamphlet 99 Ways to Cook Hamburger. This booklet was published in the early '60s when hamburger was cheap (less than a quarter a pound!) and got served a lot.

Writing about securing IIS allows me to generate my own such long list. Not because IIS is inherently insecure, but because its entire purpose is to be open for business. To ignore this fact and not invest heavily in protecting it on an on-going basis is like not continually inspecting the employees of a bawdy house for disease.

My list won't be 99 items long, but I'll give you potential IIS trouble areas and point you to excellent resources where you can dig out more specifics.

Before I get to my nine steps, I should remind you of a few things. You need to have a strong security policy, written and subscribed to by management. You also need to follow sound security practices. No quick-fix list applied after install and ignored henceforth will do. These steps will not only help you create a secure Web server, but maintain one as well.

1. Harden the OS
Do a minimal, clean install of Windows 2000, using the NTFS file system, and install only the things that you need. Phil Cox has a good article available at www.systemexperts.com/win2k/hardenW2K11.pdf. (Its base is an abstract from his book Windows 2000 Security Handbook.) I like this list a lot. It's not that you can't find his recommendations elsewhere (many can be found on Microsoft's site, in list advisories, and other security books); it's just that he's pulled them together in such a nice way, added original thoughts, and kept it updated with additions and corrections. Best of all, he does what few do: He cautions that some of his recommendations may break applications and possibly kill your system. To that end, he recommends that you work on a test server. In his article he details not only how to do a minimal install, but also how to remove some unnecessary elements like client applications, services and OS/2 and Posix subsystems after the install.

Special Note for IIS 4.0 Upgrades!
Look for the IISADMPWWD virtual directory. This allows you to reset passwords. This virtual directory was designed for intranet scenarios and isn't part of IIS 5.0. It wasn't removed in the upgrade from 4.0 and shouldn't be used on Web servers connected to the Web. See Knowledge Base article Q184619, "How to change Windows NT account passwords using Internet Information Server (IIS) 4.0," for more information.

Server components of your basic install also deserve tightening. Doing some of these simple things can go a long way:

  • If you're going to use the indexing service, set it to index only documentation—not your Web site!
  • If you're using a multi-homed server, remove Microsoft Networking and File Sharing services from the external interface.
  • Inspect all shares for necessity. Are file system shares necessary? Not to allow Web access, they aren't.
  • Inspect the file system and tighten access to all files and folders. Especially evaluate default file shares and permissions settings.
  • Turn on auditing and configure audit files so there's adequate room for growth.

2. IIS Install and Initial Cleanup
Install IIS on an NTFS file system. Install only the Web services you need.

Examine installation directories and script mappings. Sample IIS files aren't installed by default; but just in case you or some enthusiastic developer has installed them, remove them. Even sample files that can only be accessed from http://local should be removed. Look specifically in the directories \IISSamples, \IISHelp and \MSADC.

Remove any development tools! This begs the question "Where should development work be done?" On a separate development system, that's where—not on the production Web server. Development tools should never be placed on the production Web server! Yeah, yeah, I know. You would never do that; but is all your staff clear on the concept? This is an area you should continually return to. At some point there will be that quick fix for which a tool is loaded for "just a minute," and then not removed by the user.

Look for and remove script mappings linking file extension to execution, in other words, .printer for Internet printing or password reset .htr. Double-check all extension mapping. If you don't use them, remove them. To see what's currently available, look in the Web server under properties\master properties\www service\edit\ homedirectory\configuration.

If you'd followed this advice and removed the .ida and .idq mappings or if you had installed the hotfix provided by Microsoft (as recommended in Microsoft's checklist for hardening IIS available from www.microsoft.com/security) you would have protected your web site from the Code Red worm.

Disable the IP address in the Content Location header of static .html pages. Not doing so can expose internal IP addresses. See Q218180, "Internet Information Server returns IP address in HTTP Header (Content-Location)," for details.

3. Use Security Configuration and Analysis
Review your OS settings against those in the high security server/workstation template located in %system folder%\security\templates.

Review hisecWeb.inf, the security template for Web servers provided by Microsoft, http://download.microsoft.com/download/win2000srv/SCM/1.0/
NT5/EN-US/hisecweb.exe. Many of the security recommendations touted by independent security experts are part of this template. To use the template, you'll need to copy it to the \security\templates folder on the IIS server. Use the Security Configuration and Analysis console to examine the template, analyze your current IIS server against it, and—if you agree with its changes—apply the template. Before proceeding with this step, it's critical you understand the changes that will be made to your system. If not, you may find your system locked down too tight.

Your best bet, as always, is to find the right settings for your Web server and create a baseline template, which may be a combination of these templates and the ideas expressed here and by others. Once you know the template's effective on a Web server, it can easily be applied to others and used to audit the server to determine if settings are being maintained in a secure state. If Web servers are in an Active Directory (AD) domain, the template can even be imported into a Group Policy Object, linked to a "Web server" Organizational Unit (OU), and pushed to all.

Trusting Certificates
To understand which trusted root certificates to remove and which to keep requires an understanding of what certificates are used for. Having lots of trusted root certificates allows the typical user to be able to identify Web sites and other authorities they may wish to trust or do business with (register with the Web site or make a purchase from, for instance) A Web server, on the other hand, should only trust a few appropriate sources. There's no need for a large assortment of trusted root certificates to exist in the store.

Before you begin removing trusted root certificates willy-nilly, make sure you understand which ones are absolutely necessary for your Web server to function. Microsoft lists the following minimum collection of trusted root certificates required for Win2K to function.

Issued to and by Microsoft:

  • Microsoft Timestamp Root, expiration date 12/30/1999
  • Microsoft Authenticode Root, expiration date 12/31/1999
  • Microsoft Root Authority, expiration date 12/31/2020

Issued to and by VeriSign:

  • VeriSign Time Stamping CA, expiration date 1/7/2004
  • VeriSign Commercial Software Publishers CA, expiration date 1/7/2004

For more information, try Q293781, "Trusted Root Certificates That Are Required By Windows 2000."

—Roberta Bragg

4. Choose The Best Authentication Method for The Purpose
While anonymous access may suit most Web sites, you may want to restrict it to some areas of your Web site. If you're going to configure authentication to allow users with accounts to access this otherwise restricted data, understand and use the most secure form available.

When basic authentication's used, the password is "encoded," not encrypted. A network sniff can capture this information, which can be easily decoded. You might wish to ensure protection of these passwords by using Secure Sockets Layer (SSL.) With SSL, the entire session, including the password transmission, can be encrypted.

Use Integrated Windows authentication to allow negotiation of the appropriate Windows method (Kerberos, NTLM, and the like), but realize that not all browsers are capable of performing this type of authentication, and it isn't passed through a firewall by default. Digest authentication, which can be performed by other Web browsers and does work through a firewall, and certificate authentication—which requires clients to possess trusted certificates—are other choices. They require additional changes in your IIS, and possibly your AD, infrastructure.

Don't make the IUSR_computername (the default anonymous user created during IIS installs and used whenever a user anonymously access the Web site) or IWAM_computername (the account used by out-of-process Web applications, which run in a separate memory space) a member of privileged groups or give them additional user rights or privileges.

On the Web site root, deny access to the IUSR_computername and IWAM_ computername name account. At the folder level where you wish to allow anonymous users access, give them the same. Clear the "Allow inheritable permissions from parent to propagate to this object" check box.

Require authenticated access to the Web site root. IIS by default uses the local user database. To modify this, change to domain user database, if necessary, in the IIS snap-in.

For those command-line OS or other tools that can't be removed, deny "execute" access to the ISUR_computername and IWAM_computername accounts.

Check IIS Code—Specific Uses

Writers of code to be implemented on Web servers have a special responsibility. As administrators we may not be able to validate every line of this code, but we should be checking for adherence to proper practices, including:

Is user input validated? You can't assume that users won't make mistakes, sometime malicious mistakes. Many failures to validate user input result in buffer overruns. Need I say more?

Does code call functions such as MapPath that might allow users to operate outside the regular IIS structure? You can prevent this by unchecking the "Disable parent paths" box. Allowing use of parent paths allows use of calls to functions such as MapPath. The check box is found within IIS properties\homedirectory\configuration\app options.

Are Web applications following proper procedures as outlined in the certification specifications for Win2K? While these procedures and processes aren't specifically Web server-based, they do ensure that default security doesn't have to be weakened in order to support applications, and ensure compatibility with Win2K functionality. Don't know the specs? Visit www.veritest.com and download them. Check out www.rational.com for a product that can help during the development cycle.

—Roberta Bragg

5. Use NTFS and Virtual Directory Permissions
Set Directory Access Control Lists (DACLs) on IIS virtual directories. Set DACLs on files and folders. Think of virtual directory or Web share permissions like you do network share permissions. If there's a conflict between the share and the underlying folder permission, the most restrictive wins.

To make the most effective use of DACLs, make sure that directories hold like files—one folder for html, one for scripts, one for executables, one for images; you get the idea. If you like, create folders for different applications, then create subfolders to hold the different types of files. If a folder holds multiple file types, you can't set the strongest permission settings. If they're separated, you can allow only the action required (execute for executable, read for .html, and so on). If you must allow writing to IIS folders, you can remove or even deny execute permission on those folders to prevent the intentional saving and executing of malicious code there. Make sure you account for inheritance. Here's some suggestions from Microsoft's downloadable document on securing IIS 5.0, located at www.microsoft.com/
TechNet/security/iis5chk.asp:

  • In all areas, provide Admins and SYSTEM Full Control (you may want to restrict administrative access to a limited set of administrators).
  • Folders that contain executables or scripts (and these should be separated) should give Everyone execute, but disable other types of anonymous access (disable read, write and directory browsing).
  • Folders that contain static content such as .gif, .jpg, .html, and .txt should have DACLS set to Everyone read.
  • For executables like .exe, .dll, .cmd, and .pl, Web permissions should be set to "none." Don't allow scripts to run.
  • For scripts (.asp), set Web permission to "script." Executable permission isn't necessary as long as the script extension is mapped to a script engine.
  • For static content Web permissions can allow anonymous access and read permissions. You may also want to allow directory browsing. Remember to use advanced permission pages to assign only R, as the generic Read permission is RX (read and execute). Should you forget and use RX, you're allowing executables erroneously or maliciously placed here to be executed.
  • Secure Front Page server extensions using NTFS permissions. Use the FrontPage Tools\Security\Permissions property sheet and remove the Everyone group. On the Users tab, select "Everyone has browse access." This assures that the IUSR_computername account, which is a member of Everyone, doesn't have Author access and can't open the Front page Web site. On the root Web site and sub-Webs, use unique permissions. (For more on this, see Chapter 8 of the Windows 2000 Server Resource Kit, "Internet Information Services IIS 5.0 Resource Guide." Also see the Front Page Server Extensions Resource Kit.)
  • Place tighter control on inetpub\ ftproot and inetpub\mailroot. Default DACLS are Everyone Full Control. You'll want to change this, but your changes should reflect your intended usage of these folders.

6. Install Hotfixes and Service Packs
Subscribe to Microsoft Security Notification service at www.Microsoft.com/tech net/security/notify.asp. Once you've done that, respond to the alerts. There have been many Web site defacements, much information theft, and other successful hacks to IIS Web servers that could have been prevented had the administrators installed the available hotfixes.

7. Evaluate Other Security Tools
Consider using IPSec to filter packets entering the Web server. Allow only those necessary. Also consider using IPSec to secure communications between your Web server and back-end servers.

There are other tools available too. Review the tools that ship with the OS, those on Microsoft's Web site, or from the Resource Kit. (See "I Didn't Know You Could Do That!")

I Didn't Know You Could Do That!

As I'm sure you know, setting security on Web sites can be a nightmare. You make sure you've properly hardened the OS, removed sample IIS files, kept development tools out of the live production environment, chosen the correct authentication methods and set permissions properly on every folder and site. Then, just when you thought you'd caged your princess and protected her from the slobbering, raging, spittle-dripping beasts that lie in wait to ravish her, along comes another bug report, sending you scurrying to patch the harem walls.

Microsoft tried to help you by providing standard security templates for IIS 5.0, including the secureinternetWebserver.inf and secureintranetWebserver.inf templates available in the Resource Kit, and the Win2K Internet Server Security Configuration Tool, available for download from the list at www.microsoft.com/TechNet/security/
tools.asp.

But I'd like to tell you about three tools, one recently made available at the same site and two in the Resource Kit. I'm talking about the hotfix checker, the IIS Permission Wizard Template Maker and IIS performance testing with WCAT.

Setting Web Permissions Across the Enterprise
If you've been working with IIS 5.0, you've no doubt discovered the Permission Wizard. This handy tool steps you through setting Access Control Permissions, authentication methods and IP address restrictions for properties on a site. The setting generated is stored in the metabase with the rest of your IIS settings and can be manually changed through the normal Web site interface. The concept is simple. Instead of having to remember all of the areas that need to be addressed, you manage them all by following the wizard steps. You don't have to use it, but it can make life easier, especially for the newbie.

But what if you have multiple sites to manage? Running wizards can be tedious, and with or without this tool you might still question whether the same standard settings (where applicable) have been applied uniformly across all servers and sites.

So quit your complaining, shove that anxiety and stop that compulsive behavior pattern of continuously double-checking your site settings. A simple tool exists—and you've probably already got it at hand. This tool, the IIS Permissions Wizard Template Maker, can be found in the cdroot>\apps\iispermwizazd\x86 folder on the Resource Kit CD-ROM. To install, double-click setup.exe and follow the directions. Documentation exists in the docs folder at the same location.

Making Sure Your Defenses are Mended
It's not enough anymore to follow a list of steps and expect this to forevermore create an IIS impenetrable fortress. You've got to keep alert—that is, you must follow the announcements of hotfixes specifically directed at IIS. That's not easy. IIS is a popular Web server, and hackers love to attack Microsoft, so this will always be a growing list. Fine. No worries, mate. It's HFCheck (hotfix checker) to the rescue. This handy tool, available online, scans your Web server and lets you know if it's up to date.

You can configure it to display a dialog or write messages to the event log. While it can be run by connecting to the Web site, administrators can download the tool and run it under their own network controls. The tool, HFCheck.exe, can be run continuously or set to run at a preconfigured frequency.

A Cool WCAT
All this security is a good thing, right? Well, some will tell you that security will slow things down. And, yes, some security techniques—encryption, for example—will reduce performance. Others will tell you that the degradation caused by encryption can be compensated for by adding an SSL accelerator board or special network cards that can offload IPSec encryption. So the issue isn't whether security decreases performance, but whether it slows it enough to warrant external and/or optional devices to improve it. WCAT can help you determine that. This tool can be used to test how well your server responds to various workloads. Use it when your Web server is first installed to get a baseline, then test after adding security. That will tell you what impact security is having on performance. WCAT is on the Resource Kit CD-ROM. If you find a need for increased hardware spending, remember: While additional hardware improvements cost money, they're inexpensive in terms of the gains in security they make possible.

—Roberta Bragg

8. Enable Logging (And Use The Results)
Let's do this step-by-step: Right click the site. Chose properties. Click the Web site tab. Check enable logging. Then read the logs! Some things to watch for:

  • Multiple failed commands, especially in the /scripts directory or other directories that hold executables.
  • Attempts to upload files, especially to /script directories.
  • Attempts to access .bat, .exe or .cmd files—especially attempts to modify or use them in invalid ways.
  • Attempts to send .bat or .cmd commands to the /scripts directory.
  • An excessive amount of requests from a single IP address might be a hacker attempting to overload the server or cause a denial of service failure.
  • "Error 5—access denied" messages. Use Net helpmsg error_number_of_the_ error_you_want_to_know to find information.

9. Review The Machine Certificate Store
Load the computer Certificates console and remove certificates from companies you don't recognize or from those you do but see no need for a Web server to trust. This list of trusted root Certificate Authorities (CA) means a certificate issued by them is automatically trusted on this machine. By removing unknown certificates, you're following the same principle as removing unused services, files and applications. If the certificate isn't present, an attack relying on it won't be successful. Be careful not to remove necessary certificates, such as those provided by Microsoft, by software you're using, or by the CA for your SSL certificate.

To remove unnecessary certificates, open an MMC console and add the Certificates snap-in. When prompted, select the computer account radio button, and choose "Select this machine."

Expand the Trusted root certification authorities. If you're using SSL, make sure you don't remove the root certificate for the issuing CA for your IIS Server's certificate.

Words to The Wise
Finally, don't just rely on one author, columnist, security guru or Microsoft to provide you with the ultimate guide to hack-proofing your Web site. You must continually be alert for new ideas, and after appropriate confirmation and testing, use them if appropriate to your situation. Remember, Chicken Little was right. One last thing: Never, never, never store users" credit card numbers on your Web server!

Featured

Most   Popular