Security changes in the default settings of IIS 6.0

As Web servers are increasingly targeted by hackers and worms, IIS has become the primary concern of Microsoft's trusted computing program. Therefore, IIS 6.0 is completely redesigned to achieve default security and design security. This article describes how IIS 6.0 makes security changes in its default settings and design a platform for critical web applications.

Default Security

In the past, enterprises like Microsoft installed a series of default sample scripts, file processing, and minimum file authorization on their Web servers to improve the flexibility and availability of administrator management. However, these default settings increase the IIS attack surface or become the basis for attacking IIS. Therefore, IIS 6.0 is designed as a safer platform than earlier products. The most obvious change is that IIS 6.0 is not installed by default by Windows Server 2003, but needs to be explicitly installed by the Administrator. Other changes include:

· Only static HTTP servers are installed by default.

By default, IIS 6.0 is set to only install the required components on the Static HTML page, but dynamic content is not allowed. The following table compares the default installation settings of IIS 5.0 and IIS 6.0:

· No application example is installed by default.

IIS 6.0 does not include any sample scripts or applications such as Showcode. asp or codebrws. asp. TheseProgramOriginally designed to facilitate programmers to quickly view and debug database connectionsCodeBut because Showcode. asp and codebrws. asp do not properly perform the input check to determine whether the accessed file is located in the root directory of the site. This allows attackers to bypass it to read any file in the system (including sensitive information and the configuration file that should be invisible). refer to the following link to obtain more details about this vulnerability: http://www.microsoft.com/technet/treeview/default.asp?

Url =/technet/security/bulletin/MS99-013.asp

· Enhanced File Access Control

The anonymous account no longer has the write permission for the root directory of the Web server. In addition, ftp users are isolated from each other in their own root directories. These restrictions effectively prevent users from uploading harmful programs to other parts of the Server File System. For example, attackers can upload harmful executable code to the/scripts directory and remotely execute the code to attack the web site.

· The virtual directory no longer has the execution permission

Executable programs are no longer allowed in the virtual directory. This avoids many directory traversal vulnerabilities, code upload vulnerabilities, and MDAC vulnerabilities in early IIS systems.

· Remove the subverification Module

Remove iissuba. dll from IIS 6.0. Any account that needs to be verified by the DLL module in earlier versions of IIS needs to have "access to this computer from the network" permission. The removal of this DLL module can force all access requests to go directly to Sam or the Active Directory for authentication, thus reducing the possibility of IIS being attacked.

· The parent directory is disabled.

Access to the parent directory is disabled by default in IIS 6.0. This prevents attackers from accessing other sensitive files on the server, such as Sam files, across the directory structure of the web site. Of course, please note that the parent directory is disabled by default, which may cause some applications migrated from earlier versions of IIS to fail to use the parent directory.
Security Design

The fundamental security changes in IIS 6.0 Design are: improved data validity, enhanced log functions, quick failure protection, application isolation, and minimum permission.

Improved Data Validity

A major new feature in IIS 6.0 Design is the HTTP driver working in kernel mode-http. sys. It not only improves the performance and scalability of web servers, but also greatly enhances the security of servers. As a web server portal, HTTP. sys first parses users' requests to the Web server, and then assigns a suitable user-level workflow to process requests. A working process is restricted to the user mode to prevent it from accessing the core resources of an unauthorized system. This greatly limits the attacker's access to the server to protect resources.

IIS 6.0 integrates a series of security mechanisms in the kernel-mode driver to improve the designed security. These mechanisms include advanced URL Parsing mechanisms to prevent potential buffer overflow, improve LOG mechanisms to assist Event Response processes, and check user validity requests.

To immediately avoid potential buffer and memory overflow vulnerabilities, Microsoft implements in-depth defense in the security design of IIS 6.0 by setting special URL resolution in HTTP. sys. These settings can be further optimized by modifying the specific key values in the registry. The following table provides the location of the primary registry key values (both in the following path hklmsystemcurrentcontrolsetserviceshttpparameters ):

Enhanced Log Mechanism

A comprehensive log is the basic requirement for detecting or responding to a security accident. Microsoft also realized the importance of a comprehensive and reliable Log Mechanism in HTTP. sys. HTTP. sys logs a request before it is assigned to a specific worker process. This ensures that an error log is retained even if the worker process is interrupted. The log consists of the time stamp of the error, the source destination IP address and port, Protocol version, HTTP action, URL address, Protocol Status, site ID, and explanation of the cause of HTTP. sys. The cause description can provide detailed information about the cause of the error, such as an error caused by timeout or an error caused by the application pool force disconnection due to abnormal termination of the working process.

The following connection shows an example of the HTTP. sys Log File: http://www.microsoft.com/technet/treeview/default.asp

? Url =/technet/prodtechnol/IIS/IIS6/proddocs/resguide/iisrg_log_qlow.asp
Quick Failure Protection

In addition to modifying the registry, the IIS 6.0 administrator can also set the server to disable or re-run processes that fail over and over for a period of time. This additional protection measure is used to prevent application errors from being attacked. This feature is called quick failure protection.

You can configure quick failure protection in Internet Information Service Management Tools by following these steps:

1. Expand the Local Computer in the Internet Information Service (IIS) manager.

2. Expand the application pool.

3. Right-click the application pool to set the quick failure protection.

4. Select attributes.

5. Select the running status tab and select enable quick failure protection.

6. In the number of failures, enter the tolerable Number of worker process failures (before the process ends ). 7. Fill in the time period for calculating the total number of failed processes.

Application Isolation

In earlier versions of IIS (5.0 and earlier versions), isolation of Web applications from independent units will lead to severe performance degradation, so application isolation is not implemented. Generally, failure of a Web application affects other applications on the same server. However, when processing requests, IIS 6.0 isolates applications into isolated units called application pools. This design change doubles the performance. Each application pool is usually composed of one or more worker processes. In this way, the error location can be determined to prevent a worker process from affecting other worker processes. This mechanism also improves the reliability of the server and its applications.

Adhere to the principle of least privilege

IIS 6.0 adheres to a basic security principle-the principle of least privilege. That is to say, all codes in HTTP. sys are executed with the local system permission, and all worker processes are executed with the network service permission. Network Service is a strictly restricted account built in Windows 2003. In addition, IIS 6.0 only allows the Administrator to execute the command line tool to avoid malicious use of the command line tool. These design changes reduce the possibility of attacking servers through potential vulnerabilities. Some basic design changes and some simple configuration changes (including canceling the write permission for anonymous users to the root directory of the Web server, and isolating FTP users' access in their respective home directories) this greatly improves the security of IIS 6.0.

IIS 6.0 is the correct step Microsoft has taken to help customers improve security. It provides a reliable and secure platform for Web applications. These security improvements are attributed to the default security settings of IIS 6.0. security considerations and enhanced monitoring and log functions are highlighted during the design process. However, administrators should not think that comprehensive security can be achieved only through simple migration to the new platform. The correct solution is to implement multi-layer security settings to achieve more comprehensive security. This is also consistent with the in-depth security defense principles for the code red and Nimda virus threats.