Auditing Web Servers

There are certainly differences among the many web servers available, but there are many commonalities that you need to check. These are listed in the steps that follow. Each step may or may not apply to your situation, but you need to take the time to find out. If these steps apply, then we suggest that you test for the following components of a web server. Keep in mind that we examine the applications that are running on the web server in a separate list that follows this one.

1 Verify that the web server is running on a dedicated system and not in conjunction with other critical applications.

If the web server were hacked with other applications running on the same host, then they also might be subject to compromise. You should use a dedicated machine as a web server. For example, you would never want to install your web server on a domain controller.

How

Determine the infrastructure location with the administrator, and carefully consider other applications that also may be running on the same host as the web server. If other applications exist, question the need for running other applications on the web server.

2 Verify that the web server is fully patched and updated with the latest approved code.

Failure to run adequately patched systems subjects the web server to unnecessary risk of compromise from vulnerabilities that may have been patched with updated code releases.

How

Every organization has its own patch-management systems and policies. Verify that the web server is running the latest approved code with the help of the administrator according to the policies and procedures in the environment. Also review the policies and procedures for appropriate and timely demands for keeping and verifying that systems are up-to-date with the latest code releases.

3 Determine if the web server should be running additional tools to aid in the protection of the web server.

Web servers often come with additional measures designed to protect them, such as IISLockdown and URLScan. These tools are recommended often by the vendors or developers. The additional controls put in place by these tools can lower the overall risk of the server to compromise greatly.

How

Determine through research at the web developer's website and discussions with the web administrator what tools are available and the additional controls the tools offer for the given increase in administration. These tools might include validation checking or tools that monitor web server connections. Some tools offer quite a bit of additional protection for very little additional overhead. In the Microsoft environment, IISLockdown and URLScan should be run on every Window IIS web server with very few exceptions. Check to see if your organization has procedures governing how to configure these tools, and verify that they are configured correctly.

Note 

IISLockdown is only for IIS 5.x. IIS 6 is already semisecure; you still can install URLScan on IIS 6 to further harden and reduce functionality. With Windows Server 2003 SP1, the Security Configuration Wizard provides a way to strip all unnecessary functionality from the IIS so that only components that are necessary for the web server to fulfill its role in life are installed and/or running.

4 Verify that unnecessary services or modules are disabled. Running services and modules should be operating under the least privileged accounts.

Unnecessary services and modules present additional opportunities for malicious attackers and malware.

How

Discuss and verify with the help of the administrator that unnecessary services are disabled and that the running services are operating under the least privileged account possible. Verify that FTP, SMTP, Telnet, FrontPage Server Extensions, and NNTP services are disabled if they are not required.

If you are running Apache, only enable modules that are absolutely necessary. Table 8-2 presents a list of modules considered to be the bare minimum. Question the need for anything else that might be running.

Table 8-2: Minimum Apache Modules

Apache Module	Purpose
httpd core	Core module, foundation of the web server
mod access	Necessary for allow, deny, and order directives
mod auth	Supports HTTP basic authentication
mod dir	Supports index files (e.g., index.html)
mod log config	Supports logging
mod mime	Provides support for character set, content encoding, content language, and MIME types of documents

5 Verify that only appropriate protocols and ports are allowed to access the web server.

Minimizing the number of protocols and ports allowed to access the web server reduces the number of attack vectors available to compromise the server.

How

Discuss with the administrator and verify with the administrator's help that only necessary protocols are allowed to access the server. For example, the TCP/IP stack on the server should be hardened to allow only appropriate protocols, and NetBIOS and SMB should be disabled on IIS servers. Note any additional controls that may be in place, such as firewall rules or network access control lists (ACLs) to limit the protocols and ports allowed to access the web server. In general, only TCP on ports 80 (HTTP) and 443 (SSL) should be allowed to access the web server.

6 Verify that accounts allowing access to the web server are managed appropriately and hardened with strong passwords.

Inappropriately managed or used accounts could provide easy access to the web server, bypassing other additional security controls to prevent malicious attacks. This is a large step with a wide scope, covering controls around account use and management.

How

Discuss with the administrator and verify with the administrator's help that unused accounts are removed from the server or completely disabled. The administrator's account on Windows servers should be renamed, and all accounts should be restricted from remote login except for those used for administration.

The root account on Unix flavored hosts (Linux, Solaris, etc) should be strictly controlled and never used for direct remote administration. Never run Unix web servers such as Apache under the root account. They should be run under a distinct user and group such as http://www.-apache. Please see Chapter 7 for more information about the root account.

In general, accounts never should be shared among administrators, and administrators never should share their accounts with users. Strong account and password policies always should be enforced by the server and by the web server application.

Additional considerations for IIS web servers include ensuring that the IUSR_MACHINE account is disabled if it is not used by the application. You also should create a custom least-privileged anonymous account if your applications require anonymous access. Configure a separate anonymous user account for each application if you host multiple web applications.

7 Ensure that appropriate controls exist for files, directories, and virtual directories.

Inappropriate controls for files and directories used by the web server and the system in general allow attackers access to more information and tools than should be available. For example, remote administration utilities increase the likelihood of compromising a web server.

How

Discuss with the administrator and verify with the administrator's assistance that logs and website content are stored on a nonsystem volume where possible. Verify that files and directories have appropriate permissions, especially those containing

• Website content

• Website scripts

• System files (e.g. %windir%\system32 or web server directories)

• Tools, utilities, and software development kits

Sample applications and virtual directories should be removed. These would include IISSamples, IISAdmin, IISHelp, and Scripts virtual directories in IIS web servers.

Also verify that anonymous and everyone groups (world permissions) are restricted except where absolutely necessary. Additionally, no files or directories should be shared out on the system unless necessary.

8 Ensure that the web server has appropriate logging enabled and secured.

Logging auditable events helps administrators to troubleshoot issues. Logging also allows incident response teams to gather forensic data.

How

Verify with the administrator that key audit trails are kept, such as failed logon attempts. Ideally, these logs should be relocated and secured away from the same volume as the web server. Log files also should be archived regularly. They should be analyzed regularly, preferably by an automated tool in large information technology (IT) environments.

9 Ensure that script extensions are mapped appropriately.

Scripts might allow an attacker to execute the code of his or her choice, potentially compromising the web server.

How

Verify with the web administrator that script extensions not used by the web server are mapped to a 404 web page handler or simply denied altogether. Examples of extensions that you may or may not use include .idq, .htw, .ida, .shtml, .shtm, .stm, .idc, .htr, and .printer.

10 Verify that unnecessary or unused ISAPI filters are removed from the server.

ISAPI filters are tightly wrapped with the web server and were intended to allow rapid script execution, faster than CGI scripts. Support for ISAPI is designed into several web servers, but there have been problems with ISAPI in the past. Unsecured or unused ISAPI filters may present another avenue of attack.

How

Verify with the web administrator that any ISAPI filters installed on the web server are necessary. Unnecessary or unsecured web filters should be removed from the server.

11 Verify the validity and use of any server certificates in use.

Server side certificates enable clients to trust your web server's identity or that your web server is who you say your server is supposed to be. Old or revoked certificates suggest that your website may or may not be valid to end users.

How

Verify with the help of the administrator that any certificates are used for their intended purpose and have not been revoked. Certificate data ranges, public key, and metadata all should be valid. If any of these have changed, then consider the need for a new certificate that reflects your current needs.