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:

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.