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.

• By Roberta Bragg
• 08/01/2001

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.

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.

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.

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!")

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!