Securing IIS

Use the following details to securely configure IIS. Most of the steps assume that the IIS server will be external-facing to the Internet, and need higher than normal security. Internal web servers may be fine with lesser settings.

Configure Network/Perimeter Security

Before hardening IIS can even begin, an administrator must make sure the network is safe and secure. The network should be free of rogue software, malicious mobile code, and malicious network sniffers. Any perimeter firewalls or routers should only allow the bare minimum of TCP/IP ports to or from the server. In most cases, that means just allowing TCP port 80 and maybe 443 (for HTTPS) from the Internet to the server. If the web server serves up only normal WWW traffic, the perimeter filters should not allow any other port, except maybe the remote management port, to have access to the server.

No port traffic should be allowed from the web server to the Internet, by default, unless it is a part of the web server's function. Temporary exceptions may be made for port 80 traffic (for browsing the web to get patch updates) and port 53 (for DNS queries). However, many web sites have these ports open from the web server to the Internet all the time, which is allowing too much access. If a hacker is successful in placing and executing a rogue program, and egress ports are allowed through the filter, the hacker may be able to send a command shell back from the server to his remote location over the open ports.

Ensure Physical Security

The web server computer should be in a physically secure location. Unauthorized users should not have physical access to the computer. Consider buying a computer that allows physical access to be controlled by a physical mechanism (e.g., lock or Smart card). Computers should have a locking case that prevents easy theft of the hard drive.

Unless otherwise contraindicated, IIS should always be installed on a dedicated computer. Any IIS server invites increased hacking attempts and puts any computer it is installed on at higher risk of successful exploitation. And any other application may make IIS vulnerable to a side-channel attack.

Prevent booting from anything but the primary boot drive. This will prevent local attacks that attempt to circumvent regular Windows security mechanisms (as covered in Chapter 4). It will also prevent boot viruses and other types of malware. Disable any unused USB, serial, and printer ports. Then password-protect the BIOS so that the configuration can be maintained. Use a BIOS password that is long and complex, but one that is not the same as your normal admin passwords.

Install Updated Hardware Drivers

Often forgotten, don't forget to check for and install updated hardware drivers for your computer's BIOS, motherboard, interface cards, video card, and hard drive controller cards. It is the rare computer that arrives with all the drivers updated. It would be a shame for a web server to be exploited because the server's hard drive controller card had a bug.

Install the Operating System

To prevent directory traversal attacks, IIS should be installed on a system with two separate, clean hard drives, each formatted with NTFS. IIS 6 has not been the victim of a directory traversal attack, but in the event that a hacker develops a successful one, having the IIS server software and content installed on one hard drive and the Windows operating system installed on another will prevent future traversal attacks.

Install the Windows operating system as you normally would. Most web servers should be installed as stand-alone servers, unless the web server will be participating in domain authentications (i.e., Integrated Windows Authentication, etc.). Unless you are dealing with an extranet server, most public-facing web servers don't need Active Directory. If Active Directory is accessible through the web server (because it is either a domain member or a domain controller), a successful hacker will be able to gather much more information.

Note 

IIS should never be installed on a domain controller. If it is, the IUSR account is a member of Domain Users, which by default is a member of Users on all domain computers.

You want to install the OS with the minimal settings, applications, and services loaded. If possible, load the OS with a static IP address. Dynamic IP addressing might give the hacker a way to exploit the server. Optimally, the web server would not be connected to the network until after all patches were installed.

Configure the Host Firewall

As soon as the OS is installed, install a host-based firewall on the operating system. You want to protect the web server from remote exploitation. Use Microsoft's Internet Connection Firewall or Windows Firewall if you do not have another better host firewall. Both of these host firewalls do a fine job at protecting Windows by preventing all inbound connections not initiated by an outbound connection.

Keep the firewall enabled with no port exceptions until OS and IIS patching has occurred. When the server is ready for operations, enable the firewall for only the port exceptions needed to run the web server. Often these exceptions would be ports 80, 443 (if HTTPS is needed), and a remote management port.

Configure Remote Administration

Decide what your remote administration method will be. Don't use one if all administration will be local. Remote Desktop is an excellent choice for remote administration, but it is susceptible to man-in-the-middle and replay attacks. If you want to use RDP, though, make the following changes:

• Remote Desktop is often disabled by default. Enable it, and add to the Remote Users group any remote user you want to use Remote Desktop who is not already a member of the Administrators group. Remote Desktop can be enabled or disabled under the Remote tab in the System applet in the Control Panel.

• On the server, change the default RDP port from TCP 3389 to something else random and high. It is changed using a regedit at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Change the value to decimal (versus hexadecimal). On the client side, the RDP client must include the port number at the end of the connection string to connect to a non-default port, for example: www.example.com:33089. See http://support.microsoft.com/?id=187623 for more details.

• Specifically deny access to IIS anonymous user and anonymous null session. This can be done by adding the user accounts to the Deny logon through Terminal Services privilege in Group Policy or Local Computer Policy at \Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

• Enable High level encryption under \Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Encryption and Security\Set client connection encryption level. In the same area, enable Delete temporary folders on exit and Use temporary folders per session, disable Active Desktop, set Permission capability to Full Security, and restrict each user to one session.

• Force users to close a session after being disconnected. These options are available in the Terminal Services Configuration console (see Figure 12-9) or in an Active Directory domain, under the user's Sessions tab in their User Account properties.

• Enable Do not allow an initial program to be launched. Always show desktop in the Terminal Services Configuration console. In the console, disabled all mappings except Clipboard under Client Settings.

• Last, and most important, protect RDP admin sessions using an adjunct protection tunnel, such as IPSec or SSL. The current implementation of RDP contains known weaknesses that, although not popularly abused at this time, are serious enough to require an offsetting protection. You can enable SSL for RDP on W2K SP2 and later. It is hoped that in the future, Microsoft will improve RDP so additional protections are not needed. For more information on remotely administering IIS, see http://support.microsoft.com/default.aspx?scid=kb;en-us;324282.

Figure 12-9

Install IIS In Minimal Configuration

Using Add/Remove Programs under Control Panel, install IIS with the default options. After hardening the OS and installing patches, we will install any additional IIS functionality needed.

Install Patches

Install all OS and application patches, making sure to install service packs before other patches. This may be complicated by the fact that the server may not be connected to the network, or a filtering device may be blocking access to Windows Update from the server (as previously recommended). Install as many patches as you can without connecting to the network. In most cases this means downloading OS and IIS patches from another already patched computer and then installing them manually on the server. If you must open port 80 to run Windows Update and download the patches from Microsoft, open only ports 80 and 53 outbound. Run Windows Update, install the patches, and then disconnect. Run the patching routine until no more patches are missing.

Administrators may want to consider enabling the Automatic Updates (AU) service. If so, AU should download the patches, but never automatically install. Consider installing and using the Microsoft Baseline Security Analyzer (MBSA) to check for any missing patches. If not connected to the Internet, you can download MBSA and the latest Mssecure.xml file from another patched machine and manually install and test. Delete any temporary folders used by the patches and reboot the server as required.

Harden the Operating System

Now is the time to harden the underlying OS. Basically, you want to disable or remove any service or feature that is not needed to support the web server, its applications, or its administration. This section will detail how to harden a stand-alone web server needing a bare minimum of services. Web servers with complex requirements (e.g., down-level client compatibility, domain membership, etc.) will not be able implement all the suggestions.

If you have Windows Server 2003 SP1, run the Security Configuration Wizard (SCW) and install the server in the role of a web server. The SCW (see Figure 12-10) can usually be launched right from the Start button. When prompted to choose a server role, choose only the Web Server role. Deselect all other roles, including File Server and Middle-tier Application Server (COM+/DTC), unless needed. Then use the SCW to turn off all services not needed, or manually configure.

Figure 12-10

A stand-alone web server facing the Internet and not needing domain authentication only needs the following services enabled:

• Application Layer Gateway Service (if ICF or Windows Firewall is used)

• Automatic Updates (if used)

• Background Intelligent Transfer Service (if used)

• COM+ Event Service (if COM objects are used on the server; when in doubt, leave enabled)

• Computer Browser (only if needed to NetBIOS browse or connect to other computers' drives or printers)

• Cryptographic Services

• DCOM Server Process Launcher (if Distributed COM objects are used)

• DHCP Client (if used)

• DNS Client (if used)

• Event Log

• HTTP SSL (needed even if HTTPS is not needed)

• IIS Admin Service

• IPSec Services (if IPSec is enabled)

• Net Logon (if authenticated remote domain logons are used)

• Network Connections

• Plug and Play

• Protected Storage

• Remote Procedure Call (RPC)

• Security Accounts Manager

• Terminal Services (if RDP is used)

• Web Element Manager (installed with W2K3 Web edition, if the server is managed remotely using the Remote Admin web site)

• Windows Firewall/Internet Connection Sharing (if used)

• World Wide Publishing Service (of course)

Every other service should be disabled unless explicitly needed. See Chapter 7 if you need further guidance. When in doubt, turn a service off. Uninstall or remove all other non-needed applications and services. Use Local Computer Policy or Group Policy to obtain the following settings:

• Set the minimum password size to 14 (largest value possible right now).

• Give 15-character passwords to all custom application pool identity accounts.

• Enable password complexity.

• Enable Account Lockouts (3–5 bad passwords in 1 minute, locked out for 1 minute).

• Rename the admin account.

• Rename the Administrator and Guest accounts.

• Remove the Everyone group from Access this computer from the network user right.

• Under User Rights Assignment, remove Power Users and Backup Operators as members of the Access this computer from the network user right (unless you do remote backup of the web server).

• Change Unsigned Driver behavior from Warn to Don't Allow.

• Enable Message Text for Interactive Logon (just to defeat any brute-force logon tools).

• Disable Logon caching.

• Enable the Do not allow the anonymous access of SAM accounts and shares option (although this may disable some remote management tools).

• Enable the Do not allow the storage of credentials or Passports for network authentication option.

• Enable the Do not store Lan Man hash value on next password change option.

• Change the LM Authentication Level to NTLMv2; refuse LM and NTLM (unless you need down-level clients to authenticate using Integrated Windows authentication).

• Enable the Clear virtual memory page file option (although this will cause long shutdown and bootup times, so measure against availability concerns).

• Remove Posix as an optional Windows subsystem.

• Restrict CD-ROM and floppy drive use to local logged-on users only.

• Deny Log On Locally right to IIS anonymous users.

• Enable the Interactive Logon: Do not display user info option.

• Remove DFS$ and COMCFG from file shares that allow anonymous logon.

• Disable Active Desktop.

• Disable File and Printer Sharing in the Network Configuration dialog box.

If the web server is not Windows Server 2003 SP1 or XP Pro SP2 or later, harden the TCP/IP stack with the registry edits recommended at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod109.asp. This will prevent many network-level attacks and make the web server more resistant to denial-of-service attacks.

Reboot the system and troubleshoot any resulting error messages.

Configure and Tighten IIS

Now that the OS is hardened, let's turn out attention to IIS. Here are web server—specific changes to make (as compared to web site changes):

Installing Additional IIS Features

Now is the time to choose which IIS features to install. If features beyond static content are needed, rerun the Add/Remove Programs applet and install the needed IIS components. Table 12-6 discusses the various IIS components and subcomponents and makes recommendations.

Table 12-6

Subcomponent	Default Setting	Recommended Setting	Comment
Application Server Console	Enabled	Enable if required	Provides an MMC snap-in that includes administration for all of the Web Application Server (WAS) components. On a dedicated web server, this component is not required because only IIS Manager is used.
ASP.NET	Disabled	Enable if required	Provides support for ASP.NET applications. Enable this component when you need to run ASP.NET applications on the web server.
Enable network COM+ access	Enabled	Enable if required	Allows the web server to host COM+ components for distributed applications. Disable this component unless it is required by your applications.
Enable network DTC access	Disabled	Enable if required	Allows the web server to host applications that participate in network transactions through Distributed Transaction Coordinator (DTC). Disable this component unless it is required by your applications.
Internet Information Services (IIS)	Enabled (see below for subcomponents)	Enabled	Provides basic web and FTP services. This component is required on a dedicated web server. Note: If this component is not enabled, then all of its subcomponents are not enabled.
Message Queuing	Disabled (see below for subcomponents)	Enable if required	Provides guaranteed messaging, security, and transactional support for applications that communicate through messaging services provided by Message Queuing (also known as MSMQ). This component is required when your web sites and applications use Message Queuing. Note: If this component is not enabled, then all subcomponents are not enabled.
Subcomponents of Internet Information Services (IIS)
Background Intelligent Transfer Service (BITS) server extension	Disabled	Enable if required	BITS is a background file transfer mechanism used by applications such as Windows Updates and Automatic Updates. Enable this component when you have software that depends on it, such as Windows Updates or Automatic Updates to automatically apply service packs, hot fixes, or install other software on the web server.
Common Files	Enabled	Enabled	These files are required by IIS and must always be enabled.
File Transfer Protocol (FTP) Service	Disabled	Enable if required	Allows the web server to provide FTP services. Because the FTP credentials are always sent in plaintext, it is recommended you connect to FTP servers through a secured connection, such as those provided by IPSec or a VPN tunnel.
FrontPage 2002 Server Extensions	Disabled	Disabled	Provides FrontPage support for administering and publishing web sites. Disable when no web sites are using FrontPage Server Extensions. FrontPage extensions have been used in early hacking attacks.
Internet Information Services Manager	Enabled	Enabled	Administrative interface for IIS. Disable when you do not want to administer the web server locally.
Internet Printing	Disabled	Disabled	Provides web-based printer management and allows printers to be shared using HTTP. This component is not required on a dedicated web server.
NNTP Service	Disabled	Disabled	Distributes, queries, retrieves, and posts Usenet news articles on the Internet. This component is not required on a dedicated web server.
SMTP Service	Enabled	Enable if required	Supports the transfer of electronic mail. This component is not required on a dedicated web server unless it is used to send e-mail from a web site. Required for servers running Exchange Server 2003. Users familiar with ASP.NET may consider using ASP.NET for SMTP delivery instead.
World Wide Web Service	Enabled	Enabled	Provides Internet services, such as static and dynamic content, to clients. This component is required. Note: If this component is not enabled, then all subcomponents are not enabled.
Subcomponents of Message Queuing
Active Directory Integration	Disabled	Enable if required	Provides integration with Active Directory whenever the web server belongs to a domain
Common	Disabled	Enable if required	Required by Message Queuing
Downlevel Client Support	Disabled	Enable if required	Provides access to Active Directory and site recognition for clients that are not Active Directory-aware
MSMQ HTTP Support	Disabled	Enable if required	Provides the sending and receiving of messages over the HTTP transport
Routing Support	Disabled	Enable if required	Provides store-and-forward messaging as well as efficient routing services for Message Queuing
Triggers	Disabled	Enable if required	Provides support to associate the arrival of incoming messages at a queue with functionality in a COM component or stand-alone program. This component is required when your web sites and applications use Message Queuing and Message Queuing triggers.
Subcomponents of World Wide Web Service
Active Server Pages	Disabled	Enable if required	Provides support for Active Server Pages (ASP). Disable this component when none of the web sites or applications on the web server use ASP. You can disable this component in Add or Remove Windows Components, which is accessible from Add or Remove Programs in Control Panel, or in the Web Service Extensions node in IIS Manager.
Internet Data Connector	Disabled	Enable if required	Provides support for dynamic content provided through files with .idc extensions. A very old method, it can usually be disabled. Consider using ASP, ASP.NET, or a similar scripting language with equivalent functionality instead. Disable this component when no web sites or applications on the web server include files with .idc extensions. You can disable this component in Add or Remove Windows Components, which is accessible from Add or Remove Programs in Control Panel, or in the Web Service Extensions node in IIS Manager.
Remote Administration (HTML)	Disabled	Enable if required	Provides an HTML interface for administering IIS. Use IIS Manager instead to provide easier administration and to reduce the attack surface of the web server. This component is not required on a dedicated web server. Use an adjunct protection tunnel as well.
Remote Desktop Web Connection	Disabled	Enable if required	Includes Microsoft ActiveX controls and sample pages for hosting Terminal Services client connections. Use IIS Manager instead to provide easier administration and to reduce the attack surface of the web server. This component is not required on a dedicated web server. Consider using RDP with an adjunct protection tunnel instead.
Server-Side Includes	Disabled	Enable if required	Provides support for .shtm, .shtml, and .stm files. Disable this component when no web sites or applications on the web server include files with these extensions.
WebDAV Publishing	Disabled	Enable if required	Web Distributed Authoring and Versioning (WebDAV) extends the HTTP/1.1 protocol to allow clients to publish, lock, and manage resources on the web. Disable this component on a dedicated web server. You can disable this component in Add/Remove Windows Components or in the Web Service Extensions node in IIS Manager
World Wide Web Service	Enabled	Enabled	Provides Internet services, such as static and dynamic content, to clients. This component is required on a dedicated web server.

Choose to install only the options necessary to make your web server meet its operational requirements. Every additional feature is a potential attack point.

Enabling Web Service Extensions

In IIS 6, all web service extensions are disabled by default. Choose which extensions to enable, if any. There are six default options and you can add your own. Table 12-7 discusses the six default web service extensions.

Table 12-7
Open table as spreadsheet

Web Service Extension	Description
Active Server Pages	Enable this extension when one or more of the web sites and applications contains ASP content.
ASP.NET	Enable this extension when one or more of the web sites and applications contains ASP.NET content.
FrontPage Server Extensions 2002	Enable this extension when one or more of the web sites use FrontPage Server Extensions.
Internet Data Connector	Enable this extension when one or more of the web sites and applications use the Internet Data Connector (IDC) to display database information (content includes .idc and .idx files).
Server-Side Includes	Enable this extension when one or more of the web sites use server-side include (SSI) directives to instruct the web server to insert various types of content into a web page.
WebDAV	Enable this extension when you want to support WebDAV on the web server.

Minimize the number of web service extensions to the bare minimum needed to meet the functional requirements of the web site.

IIS 7 Modules

In IIS 6, much of the core IIS functionality is built into a few monolithic Dll files. For instance, all the authentication methods, static rendering, and request processing are built into one Dll file. All the code for each authentication method is in memory whether the administrator ever uses it or not. IIS 7 has divided key functionality into dozens of task-specific Dll modules. These modules can be loaded and unload globally or per web site or per application. For example, if none of your web sites will ever use SSL client certificate mapping, you can unload the Authmap.dll. Table 12-8 shows some of the security modules that can be loaded or unloaded (details could change by IIS 7's release date).

Table 12-8
Open table as spreadsheet

Module Name	Description	Module Dll
AnonymousAuthModule	Performs Anonymous Authentication when no other authentication method succeeds	Inetsrv\Authanon.dll
BasicAuthModule	Performs Basic Authentication	Inetsrv\Authbas.dll
CertificateMappingAuthenticationModule	Performs Certificate Mapping Authentication using Active Directory	Inetsrv\Authcert.dll
DigestAuthModule	Performs Digest Authentication	Inetsrv\Authmd5.dll
IISCertificateMappingAuthenticationModule	Performs Certificate Mapping Authentication using IIS certificate configuration	Inetsrv\Authmap.dll
RequestFilteringModule	Performs URLScan tasks such as configuring allowed verbs and file extensions, setting limits, and scanning for bad character sequences	Inetsrv\Modrqflt.dll
UrlAuthorizationModule	Performs URL authorization	Inetsrv\Urlauthz.dll
WindowsAuthModule	Performs NTLM integrated authentication	Inetsrv\Authsspi.dll
Taken from www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis7/TechRef/.mspx

Strengthen NTFS Permissions

On dedicated web servers, remove NTFS permissions that are granted to the Everyone group on the root folder of disk volumes supporting web server content. Remove any compilers, development environments, or sample files.

If not needed, disable the IWAM and default IIS anonymous accounts in the User Manager tool. Create a new IIS anonymous account. This is an optional step but allows for better control over what access the IIS anonymous user has to the web server. Create an Anonymous Web Users group and add the new IIS anonymous user account to the group. Using Windows Explorer, set Full Control permission to Deny on the \%windir% and %windir%\System32 folders for the Anonymous Web Users group. Then add Everyone Deny permissions to the Windows\Temporary Compressed Files, unless web compression is needed. Deleted all files in the iisadmpwd folder.

Install URLScan 2.5

Download and install Microsoft's free URLScan version 2.5 tool (www.microsoft.com/downloads/details.aspx?familyid=&displaylang=en). Much of URLScan's original functionality is already enabled in IIS 6, but the new version (versions newer than 2.0) has increased, must-have functionality not present in the included version.

URLScan will load itself as an ISAPI filter program, which must be enabled in Web Service Extensions. When enabled, it will inspect incoming commands looking for signs of maliciousness. You can and should further customize the information URLScan blocks. Look for the URLScan.ini file (see Figure 12-11) and make the following non-default changes:

• Set UseAllowExtensions to 1. This will enable URLScan to deny-by-default any extension not specifically allowed. Then, under the AllowedExtensions section, type in only the file extensions needed on the web server. Only content files being downloaded or uploaded need to be added. Be sure to add a period (.) to AllowedExtensions to cover files that don't end in an extension.

• Set MaxURL to 70 or some other number that indicates the maximum size of the URL string that your server will accept. You want to prevent overly long URLs, possibly containing buffer overflow or directory traversal attacks, from being uploaded.

• Set MaxAllowContent Length to 100000 or something acceptable that indicates the maximum size of any single content component. Again, the idea is to prevent unauthorized uploading or downloading.

• Set AllowVerbs to GET and HEAD, plus any other HTTP verbs that should be sent to the server. For instance, if the PUT command (which can place or write content to the web server) should never be used, it should not appear on the AllowVerbs list.

• Lastly, change the default URLScan log directory to a central log location to ease pick-up.

Figure 12-11

For more information on URLScan, see http://support.microsoft.com/default.aspx?scid=307608 or http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod114.asp.

Note 

IIS 7 will have more of URLScan's functionality built in.

Secure Web Site(s)

Now that the overall web server is secured, the following settings should be made to each web site.

Harden NTFS Permissions

Do not install any web sites to \Inetpub\wwwroot. That's where any hacker will look for web files. Instead, install to almost any other randomly created directory. Consider naming the directory something innocuous, like D:\Temp, if you want to fool any local hackers. Most hackers and web server scripts expect web sites to be in the default locations, so use another directory name.

Each web server should have its own web content directories. Each web application pool identity should only have the bare minimum access that it needs to each related content directory. Content directories should be structured to maximize security simplicity. Most administrators structure their web site directories according to the web site's overall linking structure. For example:

 \Inetpub\wwwroot \Inetpub\wwwroot\Examplecom \Inetpub\wwwroot\Examplecom\Main \Inetpub\wwwroot\Examplecom\Company Structure \Inetpub\wwwroot\Examplecom\Mission \Inetpub\wwwroot\Examplecom\Recruiting 

Most administrators make subdirectory structures that mimic the linking structure and place all content into common parent directories that describe the web site's logical structure. Most of the time, all the files in the same folder share the same permissions. This is completely wrong.

Instead, web site folders should be structured along security lines, so that all content in the same directories truly describes common security permissions. Using the preceding example but improving on it:

 \Temp\Web \Temp\Web\Examplecom \Temp\Web\Examplecom\HTML content \Temp\Web\Examplecom\HTML content\Main \Temp\Web\Examplecom\HTML content\Company Structure \Temp\Web\Examplecom\HTML content\Mission \Temp\Web\Examplecom\HTML content\Recruiting \Temp\Web\Examplecom\Scripts \Temp\Web\Examplecom\Scripts\Main \Temp\Web\Examplecom\Scripts\Company Structure \Temp\Web\Examplecom\Scripts\Mission \Temp\Web\Examplecom\Scripts\Recruiting \Temp\Web\Examplecom\Executables \Temp\Web\Examplecom\Executables\Main \Temp\Web\Examplecom\Executables\Company Structure \Temp\Web\Examplecom\Executables\Mission \Temp\Web\Examplecom\Executables\Recruiting \Temp\Web\Examplecom\Pictures \Temp\Web\Examplecom\Pictures\Main \Temp\Web\Examplecom\Pictures\Company Structure \Temp\Web\Examplecom\Pictures\Mission \Temp\Web\Examplecom\Pictures\Recruiting 

Although this structure may look unnecessarily complicated at first, it's really simple. In the first example, the administrator would have to manually look at each file in each directory and determine what security it should have. In the latter example, the appropriate permissions can be set at the higher parent directories (i.e., HTML content, Scripts, Executables, Pictures), and all the related files automatically inherit the correct permissions. It may take a little bit longer to set up, but it saves in overall administration time and ensures greater security. The former model is bound to break down and cause a security issue. The latter structure makes good security occur naturally.

Then, using Windows Explorer (for NTFS permissions) and IIS Admin (for IIS permissions), set the bare minimum permissions needed for the web site to function appropriately. Remember to tie NTFS permissions to the appropriate application pool identity and the appropriate impersonated user account (e.g., IUSR).

You will have to ensure that identities are in the IIS_WPG group and that identities and impersonated user accounts have the normal User permissions to \System32\Inetsrv. Ensure that any IIS-related user accounts (i.e., IUSR, web pool identity, etc.) do not have access to any files or folders to which they should not have access. There is no reason for IIS-related user accounts to have access to most high-risk files, folders, and registry keys, as detailed in Chapters 5 and 6. For example, unless there is a legitimate reason for the IUSR account to have access to Cmd.exe, Command.com, or Debug.exe, give the IUSR account Deny-Full Control permissions to those files. That way, if the IIS anonymous user account "breaks out" of IIS, then the hacker won't be able to readily access the Windows command prompt, as they often expect. This will defeat many hackers and hacking tools. Appropriately set permissions will help increase the security of any web site.

Web Site IP Settings

Change the IP address of the web site in the IIS Admin console to be a static private address instead of All Unassigned. This will prevent hackers from using unintended IP addresses to gain unauthorized access to the web server. Install the web site to a non-default port, as discussed above, if possible. Moving web servers off ports 80 and 443 will do much to increase the security risk of any affected web site.

Enabled Host Headers

Require a host header to match the appropriate URL name (see Figure 12-12). Host headers are the URLs that are submitted by connecting clients. It's an HTTP standard that allows one web server IP address to host multiple, different web sites. By enabling host headers on all web sites, any request to the web server without a host header will be automatically denied. Most browsers support host headers, but many hacking tools do not. Users almost always connect using fully qualified domain names. Most scanning scripts and worms connect to web servers using IP addresses. The host header requirement would defeat those tools. See www.iisanswers.com/hinders_rant.htm for more details.

Figure 12-12

Application Pool Changes

Application pools and their identities should be locked down to just the files and folders they need in order to allow the web site to function appropriately. In most cases, every web site should have its own application pool. You can create new application pools in the IIS Manager by right-clicking the Application Pool container object and choosing New ð Application Pool. You can create a custom application pool from scratch or use an existing application pool as a starting template (see Figure 12-13).

Figure 12-13

If your web site does not need Kerberos authentication, consider creating a new identity account for the web pool. It should not be named anything that might attract the attention of a hacker. It should be named using a similar convention of your regular users. Then give it just the permissions and privileges it needs to load the web site correctly. Don't forget to add new identity accounts to IIS_WPG. Then add the new identity to the web pool (see Figure 12-14).

Figure 12-14

After making the appropriate changes, stop and restart IIS to let the new changes take effect. Then rerun the MBSA to check for missing patches.

Configure Logging

Enable Object Access auditing for all files on the web server not authorized to be seen by any IIS accounts. For instance, the IUSR account doesn't access Cmd.exe on most web sites, so enable Object Access auditing for that file and tell it to record success or failure audit events for the user IUSR_<computername>.

Create a new centralized log directory on the server and configure all logs to write there. Enable hourly IIS log files, enable all fields, and configure logs to be saved in the new log folder. Configure URLScan to save its log files to the new central location. Configure the host-based firewall to monitor all successful and dropped packets and to save the log file to the new centralized location.

Clean and Test

When setting up and patching any new computer, there are bound to be temporary files and folders left around. For example, delete the \wutemp folder left over by patching. Look for other temporary files and delete them too. Then empty the Recycle Bin and reboot once more. Check error logs after bootup for any messages to investigate.

Install and Tighten Applications

Now the even harder part. Securing an OS and IIS server are easy compared to installing a secure application. Many penetration experts swear they have never met a secure web application. Coders and the web server administrator should work together to ensure that a secure application is installed on IIS and that the bare minimum permissions have been defined and configured as discussed above.

Conduct Penetration Tests

Open the appropriate web server ports on the host-based firewall to allow for internal penetration testing. Penetration tests, using their own wits or automated tools, should test the OS, IIS, and the application. Any noted deficiencies should be corrected before go-live. Lessons learned should be incorporated into future roll-outs.

Deploy to Production

Finally, open the appropriate web server ports on the perimeter firewall and let the web site be exposed to the world. You've done your job well and there is little to worry about. Every web site can be hacked, but yours should be one that is not easily cracked. You can also open the web site to external penetration testing if another round of testing is required.

Monitor Log Files

Monitor the firewall and log files located in the centralized log directory. Investigate critical or persistent threats.

More Resources

See the following resources for more information on securing IIS:

• IIS 6 Resource Kit: www.microsoft.com/downloads/details.aspx?FamilyID=&DisplayLang=en

• Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0: www.microsoft.com/technet/prodtechnol/windowsserver2003/plan/appisoa.asp

• Microsoft IIS 6 Technet Resources: www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/featured/iis/default.mspx

• Brett Hill's IIS Answers.com: www.iisanswers.com