IIS 5/5.1 Deployment Review for Security

Note: See online on MSDN: http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh22.asp

In This Module

* Reviewing network and host configuration
* Reviewing base Windows 2000 configuration
* Reviewing IIS and .NET Framework configuration
* Reviewing Web application and Web service configuration
* Reviewing Enterprise Services configuration
* Reviewing Remoting configuration
* Reviewing SQL Server configuration

Overview

Web application security is dependent upon the security of the underlying infrastructure on which the application is deployed. Weak network or host configuration settings result in vulnerabilities that can and will be exploited. The deployment review covered in this chapter inspects the configuration of the network and host. The host includes Windows 2000 Server and, depending on the server role, it can also include IIS, the Microsoft .NET Framework, Enterprise Services, and SQL Server.
The main configuration elements that are subject to the deployment review process are shown in Figure 22.1.

{Insert figure: CH22 – Deployment Review.gif}

Figure 22.1 - Core elements of a deployment review

Web Server Configuration

The goal for this phase of the review is to identify vulnerabilities in the configuration of the base operating system on your Web server. This does not include IIS configuration, which is dealt with separately. For further background information about the issues raised by the review questions in this section, see Chapter 16, "Securing Your Web Server."
To help focus and structure the review process, the review questions have been divided into the following configuration categories:
* Patches and updates
* Services
* Protocols
* Accounts
* Files and directories
* Shares
* Ports
* Registry
* Auditing and logging

Patches and Updates

Verify that your server is updated with the latest service packs and software patches. You need to separately check operating system components and the .NET Framework. Review the following questions:
* Have you run MBSA?
* Make sure you have run the MBSA tool to identify common Windows and IIS vulnerabilities, and to identify missing service packs and patches. Respond to the MBSA output by fixing identified vulnerabilities and by installing the latest patches and updates. For more information, see "Step 1. Patches and Updates" in Chapter 16, "Securing Your Web Server."
* Have you installed .NET Framework updates?
* To determine the current version of the .NET Framework, see Microsoft Knowledge Base article 318785, "INFO: Determining Whether Service Packs Are Installed on .NET Framework." Then compare the installed version of the .NET Framework against the current service pack. To do this, use the .NET Framework versions listed in article 318836, "INFO: How to Obtain the Latest .NET Framework Service Pack."

Services

Make sure that only the services that you require are enabled. Check that all others are disabled to reduce your server's attack profile. To see which services are running and enabled, use the Services and Applications Microsoft Management Console (MMC) snap-in available from Computer Management. To disable a service, make sure it is stopped and set its startup type to manual.

Review the following questions to verify your services configuration:
* Do you run unnecessary services?
* Review each service that is running by using the Services snap-in and confirm that each service is required. Identify why it is required and which solutions rely on it. Make sure all unnecessary services are disabled.
* Have you disabled the Telnet service?
* Telnet is often used for remote IIS administration. However, it is an insecure protocol susceptible to many attacks. Check that the Telnet service is disabled. For a more secure administration solution, use Terminal Services.
* Have you disabled FTP, SMTP, and NNTP services?
* These services are not secure protocols and have known vulnerabilities. If you do not need them, disable them. If you use them, find secure alternatives. These services are listed in the Services MMC snap-in as FTP Publishing Service, Simple Mail Transport Protocol (SMTP) and Network News Transport Protocol (NNTP).

Note: "IISLockdown" disables these services.

* Do you use the ASP.NET session state service?
* To see whether your applications use this service, review the <sessionState> element in your application's Web.config file. If Web.config does not contain this element, check its setting in Machine.config. You use the session state service on your Web server if the mode attribute is set to "StateServer" and the stateConnectionString points to the local machine, for example with a localhost address as shown below:

		 <sessionState mode="StateServer"
		           stateConnectionString="tcpip=127.0.0.1:42424" />
	

* If you do not use the service on the Web server, disable it. It is listed as "ASP.NET State Service" in the Services MMC snap-in. For more information on how to secure ASP.NET session state, refer to "Session State" in Chapter 19, "Securing Your ASP.NET Application and Web Services."

Protocols

Review which protocols are enabled on your server and make sure that no unnecessary protocol is enabled. Use the following questions to help review protocols on your server:
* *Do you use WebDAV? *
* If you use the Web Distributed Authoring and Versioning protocol (WebDAV) to publish content then make sure it is secure. If you do not use it, disable the protocol.
For information on how to secure WebDAV, see Microsoft Knowledge Base article 323470, "How To: Create a Secure WebDAV Publishing Directory." For information about disabling WebDAV, see article 241520, "How To Disable WebDAV for IIS 5.0."
* Have you hardened the TCP/IP stack?
* Make sure the TCP/IP stack is hardened to prevent network level denial of service attacks including SYN flood attacks. To check whether the stack is hardened on your server, use Regedt32.exe and examine the following registry key:

		 [HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
	

* The presence of the following child keys indicates a hardened TCP/IP stack: SynAttackProtect, EnableICMPRedirect, and EnableDeadGWDetect. For a full list of the required keys and the appropriate key values for a fully hardened stack, see "How To: Harden the TCP/IP Stack" in the "How To" section of this guide.
* *Have you disabled NetBIOS and SMB for internet facing network cards? *
* Check that NetBIOS over TCP/IP is disabled and that SMB is disabled to prevent host enumeration attacks. For more information, see "Protocols" in Chapter 16, "Securing Your Web Server."

Accounts

Review the use of all the Windows accounts on the server to make sure that no unnecessary accounts exist, and that all of the necessary accounts are configured with the minimum privileges and the required access rights. The following questions help you identify account vulnerabilities:
* Have you deleted or disabled all unused accounts?
* Perform an audit to verify that all your accounts are used and required. Delete or disable any unnecessary accounts. The local administrator account and Guest account cannot be deleted. You should disable the Guest account and rename the Administrator account, making sure it has a strong password.
* Have you disabled the Guest account?
* To check if the Guest account is disabled, display the Users folder in the Computer Management tool and check that the Guest account appears with a cross icon next to it. If it is not disabled, display its Properties dialog box and select Account is disabled.
* Have you renamed the default administrator account?
* The default local administrator account is a prime target for attack. Verify that you have renamed the administrator account and given it a strong password.
* Have you created a custom anonymous Web account?
* Check that the default IUSR_MACHINE account is disabled and that you have configured an alternate anonymous user account for use by your Web applications.
* Do you use strong password policies?
* Use the Local Security Policy tool to review password policy. For information about the recommended password policy, see "Step 5. Accounts" in Chapter 16, "Securing Your Web Server."
* Do you restrict remote logons?
* Check the user rights assignments within the Local Security Policy tool to ensure that the Everyone group is not granted the "Access this computer from the network" user right.
* Have you disabled null sessions?
* Check that null sessions are disabled to prevent anonymous (unauthenticated) sessions from being created with your server. To check this, run Regedt32.exe and confirm that the RestrictAnonymous key is set to 1 as shown below.

		 [HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1]
	

Files and Directories

The following review questions enable you to verify that you have used NTFS permissions appropriately to lock down accounts such as the anonymous Web user account.
* *Is IIS installed on an NTFS volume? *
* This allows you to use NTFS to configure ACLs on resources to restrict access. Do not build a server that uses FAT partitions.
* Have you restricted the Everyone group?
* Use Windows Explorer to ensure that the Everyone group does not have access to the following directories:
*Root (:\)
*System directory (\WINNT\system32)
*Framework tools directory (\WINNT\Microsoft.NET\Framework\{version})
*Web site root directory and all content directories (default is \inetpub\)

* Have you restricted the anonymous Web user account?
* Make sure that the anonymous Internet user account does not have the ability to write to Web content directories. Use Windows Explorer to view the ACL on each content directory. Also check the ACL on the %windir%\system32 directory to make sure that it cannot access system tools and utilities.

Note: If you ran "IISLockdown", the Web Anonymous Users group and the Web Applications group can be used to restrict access. By default, the Web Anonymous Users group contains the IUSR account and the Web Applications group contains Internet Web Application Manager (IWAM). From an administrative perspective, restricting access to a group is preferred to individual account restriction.

* Have you secured or removed utilities and SDKs?
* Verify that you have no utilities or software development kits (SDKs) on your server. Make sure that neither Visual Studio.NET nor any .NET Framework SDKs are installed. Also make sure that you have restricted access with NTFS permissions to powerful system tools such as At.exe, Cmd.exe, Net.exe, Pathping.exe, Regedit.exe, Regedt32.exe, Runonce.exe, Runas.exe, Telnet.exe, and Tracert.exe. Finally, make sure that no debugging tools are installed on the server. IISLockdown automatically restricts access to system tools by the Web Anonymous Users group and the Web Applications group.
* Have you removed unused DSNs?
* Verify that all unused data source names (DSNs) have been removed from the server because they can contain clear text database connection details.

Shares

Review the following questions to ensure that your server is not unnecessarily exposed by the presence of file shares:
* What shares are available on your server?
* To review shares and associated permissions, run the Computer Management MMC snap-in and select Shares beneath Shared Folders. Check that all the shares are required. Remove any unnecessary shares.
* Can the Everyone group access shares?
* Verify that the Everyone group is not granted access to your shares unless intended, and that specific permissions are configured instead.
* Have you removed the administration shares?
* If you do not allow remote administration of your server, then check that the administration shares, for example, C$ and IPC$ have been removed.

Ports

Review the ports that are active on your server to make sure that no unnecessary ports are available. To verify which ports are listening, run the following netstat command.

		 netstat -n -a
	

This command generates the following output:

{Insert figure: CH22 – gif}

Figure 22.2 - Netstat output

This output lists all the ports together with their addresses and current state. Make sure you know which services are exposed by each listening port and verify that each service is required. Disable any unused service.
To filter out specific string patterns from netstat output, use it in conjunction with the operating system findstr tool. The following example filters the output for ports in the “LISTENING” state.

		 netstat -n -a | findstr LISTENING
	

You can also use the Portqry.exe command line utility to verify the status of TCP/IP ports. For more information about the tool and how to download it, see Microsoft Knowledge Base article 310099, "Description of the Portqry.exe Command Line Utility."
Also review the following:
* Internet-facing ports are restricted to TCP 80 and 443.
* Intranet traffic is restricted or encrypted.

Registry

Review the security of your registry configuration with the following questions:
* Have you restricted remote registry administration?
* Use Regedt32.exe to review the ACL on the WinReg registry key, which controls whether or not the registry can be remotely accessed.

		 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
	

* By default in Windows 2000, remote registry access is restricted to members of the Administrators and Backup operators group. For maximum security, restrict all remote access to the registry by using an empty Discretionary Access Control List (DACL).

Note: Some services require remote access to the registry. See Microsoft Knowledge Base article 153183, "How to Restrict Access to the Registry from a Remote Computer," to see if your scenario demands limited remote registry access.

* Have you secured the SAM?
* This only applies to stand-alone servers. Check that you have restricted LMHash storage in the Security Account Manager (SAM) database by creating the key (not value) NoLMHash in the registry as follows:

		 [HKLM\System\CurrentControlSet\Control\LSA\NoLMHash]
	

Auditing and Logging

Review your use of Windows auditing with the following questions.
* Do you log all failed logon attempts?
* Use the Local Security Policy tool to check that you have enabled the auditing of failed logon attempts.
* Do you log all failed actions across the file system?
* Use the Local Security Policy tool to check that you have enabled object access auditing. Then check that auditing has been enabled across the file system.

IIS Configuration

By reviewing and improving the security of IIS configuration settings, you are in effect reducing the attack surface of your Web server. For more information about the review points covered in this section, see Chapter 16, "Securing Your Web Server."
The review questions in this section have been organized by the following configuration categories.
* IISLockdown
* URLScan
* Sites and virtual directories
* ISAPI filters
* IIS Metabase
* Server certificates

"IISLockdown"

The IISLockdown tool identifies and turns off features to reduce the IIS attack surface area. To see if it has been run on your server, check for the following report generated by IISLockdown:

		 \WINNT\system32\inetsrv\oblt-rep.log
	

For more information about IISLockdown, see "How To: Use IISLockdown" in the "How To" section of this guide.

"URLScan"

URLScan is an ISAPI filter that is installed with IISLockdown. It helps prevent potentially harmful requests from reaching the server and causing damage. Check that it is installed and that it is configured appropriately.
* To see if URLScan is installed:

1. Start Internet Information Services.
2. Right-click your server (not Web site) and then click Properties.
3. Click the Edit button next to Master Properties.
4. Click the ISAPI Filters tab and see if URLScan is listed.

To check the URLScan configuration, use Notepad to edit the following URLScan configuration file.

		 [%WINDIR%\System32\Inetsrv\URLscan\Urlscan.ini]
	

For more information about URLScan, see "How To: Use URLScan" in the "How To" section of this guide.

Sites and Virtual Directories

The review questions in this section relate to the specific configuration of your Web sites and the virtual directories of your applications. In this section, you review the following categories:
* Web site location
* Script mappings
* Anonymous Internet user accounts
* Auditing and logging
* Web permissions
* IP address and domain name restrictions
* Authentication
* Parent path setting
* Microsoft FrontPage Server extensions

Web Site Location

Check that your Web site root directory is installed on a non-system volume. By relocating your Web site root to a non-system volume, you prevent attackers who use directory traversal attacks from accessing the system tools and executables such as Cmd.exe.

Script Mappings

Check that you have mapped all unnecessary file extensions to the 404.dll, which is installed when you run IISLockdown.

* To review script mappings:

1. Start Internet Information Manager.
2. Right-click your Web site and click Properties.
3. Click the Home Directory tab and then click the Configuration button within the Application Settings group.

Anonymous Internet User Accounts

Verify that your application is configured to use a non-default anonymous Internet user account. If you have multiple Web applications on your server, check that each application is configured to use a separate anonymous account. This allows you to configure permissions and to track activity on a per Web application basis.

Auditing and Logging

Check that you have configured IIS auditing to help detect attacks in progress and to diagnose attack footprints. The following review questions help identify vulnerabilities in IIS auditing:
* Are log files located on a separate non-system volume?
* Right click your Web site in IIS and click the Web Site tab. Click the Properties button to check the log file location. Check that the log files are located in a non-default location using a non-default name, preferably on a non-system volume.
* Do you restrict access to the log files?
* Use Windows Explorer to view the ACL on the log files directory. Check that the ACL grants Administrators and System full control but grants access to no other user.

Web Permissions

Review the default Web permissions configured for your Web site and for each virtual directory. Check that the following conditions are met:
* Include directories restrict Read permissions.
* Virtual directories for which anonymous access is allowed are configured to restrict Write and Execute permissions.
* Write permissions and script source access permissions are only granted to content folders that allow content authoring. Also check that folders that allow content authoring require authentication and Secure Sockets Layer (SSL) encryption.

IP Address and Domain Name Restrictions

Do you use IP and domain name restrictions to restrict access to your Web server? If so, have you considered the risks of IP spoofing?

Authentication

Check the authentication settings for your Web sites and virtual directories. Ensure that anonymous access is only supported for publicly accessible areas of your site. If you are selecting multiple authentication options, thoroughly test the effects and authentication-precedence on your application.
If Basic authentication is selected, check that SSL is used across the site to protect credentials.

Parent Path Setting

Check that you have disabled the parent path setting to prevent the use of ".." in script and application calls to functions such as MapPath. This helps prevent directory traversal attacks.

* To review the parent paths setting

1. Start Internet Services Manager.
2. Right-click your Web site, and click Properties.
3. Click the Home Directory tab.
4. Click Configuration.
5. Click the App Options tab.
6. Check that the Enable parent paths check box is clear.

FrontPage Server Extensions (FPSE)

FrontPage Server Extensions are used for accessing, authoring, and administering the FrontPage–based Web site. Use the latest versions of these extensions to avoid security vulnerabilities. If you do not use FPSE, disable them to reduce the attack surface.
For more information, see "Step 11. Sites and Virtual Directories" in Chapter 16, "Securing Your Web Server."

ISAPI Filters

Make sure that no unused ISAPI filters are installed to prevent any potential vulnerabilities in these filters from being exploited.
* To review ISAPI filters

1. Start Internet Information Manager.
2. Right click your server (not Web site) and then click Properties.
3. Click the Edit button next to Master Properties.
4. Click the ISAPI Filters tab to view the installed filters.

IIS Metabase

The IIS Metabase contains IIS configuration settings, many but not all of which are configured through the IIS administration tool. The file itself must be protected and specific settings that cannot be maintained using the IIS configuration tool should be checked. Review the following questions to ensure appropriate metabase configuration:
* Have you restricted access to the metabase?
* Check that the ACL on the metabase file allows full control access to the system account and administrators. No other account should have access. The metabase file and location is:

		 %windir%\system32\inetsrv\metabase.bin
	

* Do you reveal internal IP addresses?
* By default, IIS returns the internal IP address of your server in the Content-Location section of the HTTP response header. You should prevent this by setting the UseHostName metabase property to true. To check if it has been set, run the following command from the \inetpub\adminscripts directory:

		 adsutil GET [w3svc/UseHostName]
	

Confirm that the property value has been set to true. If the property is not set, this command returns the message "The parameter 'UseHostName' is not set at this node." For more information, see "Step 14. IIS Metabase" in Chapter 16, "Securing Your Web Server."

Server Certificates

If your applications use SSL, make sure that you have a valid certificate installed on your Web server. To view the properties of your server's certificate, click View Certificate on the Directory Security page of the Properties dialog of your Web site in IIS. Review the following questions:
* Has your server certificate expired?
* Are all public keys in the certificate chain valid up to the trusted root?
* Has your certificate been revoked?
* Check that it is not on a Certificate Revocation List (CRL) from the server that issued the certificate.

---

Return to PatternsAndPracticesSecurityWiki