Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Securing Web ServerBased Access to Internal Resources

Many IT pros think of the web server as a server that presents resources to the public, such as information and e-commerce. They therefore consider its security and that of its applications as a separate security domain. While one group of individuals administers and is responsible for securing the network, IT often delegates the administration of the web server and its security to a different group. The web server is a unique entity and should be administered by those who know it best. However, if web server security is divorced from mainstream network consideration, no one wins. In fact, if web server activities are not reviewed against the general security policies of the network, this can introduce additional vulnerabilities into the network.

This is because many web server applications require support from network resources and are administered from network computers. Intentionally or not, web servers have become remote access portalsanother way in which access is provided to the internal network. This section identifies general web server and web application security issues and addresses the use of the web server as a remote access portal. It does not pretend, however, to be a complete guide to web server and web application security.

Web Server Security Basics

Securing a web server starts with a secure implementation and hardening of the Windows Server 2003 computer on which it will be deployed. By default, web services are not installed on the Windows Server 2003 Enterprise and Standard Edition computers during installation, and they should not be installed at that time. Instead, install Windows Server 2003, install the latest service pack and security patches, and harden the server according to your organization's security policy and practices. Chapter 11 provides a methodology for securing domain member computers using security templates developed from those provided by Microsoft.

A default installation of IIS 6.0 can only serve static web pages. In fact, many services and extensions that you may require for web applications are not available, not installed, or not enabled. The first IIS security lesson is to remember to determine only what you need and enable that. Do not blindly turn everything on. When selecting applications, require vendor specification of the minimal IIS support that is required so that you will only have to enable the least number of items. When internally developed web applications will be used, ensure that developers have been trained in secure web application development and understand IIS 6.0.

The following steps should be taken to secure IIS 6.0:

Consider disabling services that are often enabled for other servers. Specifically, the following services, which may provide services critical to other servers, should be considered as possible candidates for disabling on web servers:

Automatic Updates
This service may be used to provide automatic updates either via the Windows Update site or by using a Software Update Services server. Disable this service if you will perform manual updates for the web server.

Background Information Transfer Service (BITS)
This service is used by Automatic Updates download patches using background processes. If Automatic Updates is disabled, disable BITS as well.

Remote Registry Service
This service is used by many administration tools to allow administrators to administer the computer. Consider using alternative administrative tools or administer the web server at the console.

Terminal Services
Do not install terminal services in application mode. If terminal services is required for administration, it is available in administrative mode as the Remote Desktop. You do not want ordinary users to obtain terminal service access to the web server.

Simple Mail Transfer Protocol (SMTP) Service
If a web application requires SMTP services to provide email services, this service may be required. However, if applications do not require it, disable it. If it is used, configure it securely by assigning SMTP operators (users who can configure or manage SMTP) and preventing relay. (Uncontrolled relay can result in spam that may both close your servers and network as well as others.)

NOTE: Preventing Relay

Knowledge Base articles 324285 (http://support.microsoft.com/default.aspx?scid=kb;en-us;324281) provide instructions on preventing relay. An article on securing IIS 6.0 SMPT virtual servers can be found at http://www.microsoft.com/resources/documentation/IIS/6/all/techref/en-us/iisRG_CFG_39.mspx.

When web servers must also serve other purposes, ensure protection of these services and applications. Do not allow weak security of these other applications to compromise the web server, and do not allow weak security of the web server or its applications to compromise other applications and resources.

Use ACLs and identities to isolate web sites and web applications and to protect server resources. Applications can be isolated by using application pools. Application pools are groups of web sites and applications that use the same worker process. Application pools are isolation boundaries, and applications running outside the application pool have no access to the process or web site running inside the application pool.

Design authentication to meet the needs of the web site. Enable only those forms of authentication that are necessary. See the sidebar "Design Web Site Authentication" for more information.

Locate web server content on a separate disk or volume from the operating system to prevent directory traversal attacks. In a directory traversal attack, the attacker gains access to some minor data area of the web site and uses an attack to move about the directory on the disk and gain access to sensitive areas, such as operating systems files and commands.

Set the root access permissions on the web server content disk to administrators and SYSTEM Full Control. Grant access elsewhere on the disk as required by the applications.

Use a single top-level folder for web sites and applications, but provide a unique subfolder for each web site and web application.

If anonymous accounts are used to access public web site data, ensure that the accounts are not granted access elsewhere on the site or server.

If Windows accounts are given access to parts of a web site, ensure that they only have the type of access that they require.

Set correct ACLs on all folders and files to support the protection and proper functions of web applications and data.

You can enable the use of all unknown (not specifically defined for this web server) ISAPI extensions in the Web Services Extension node of the Internet Information Services (IIS) Manager console. Do not change the status of the Allow All Unknown ISAPI Extension web service extension to Allowed from Prohibited, as shown in Figure 14-47. Instead, only allow those ISAPI extensions that are required and that have been reviewed to determine if they can be safely used.

Secure the use of the following web site roles:

IUSR_servername
This account is used for anonymous access.

IWAM_servername
This account is provided for compatibility with IIS 5.0. IIS 5.0 could be run in isolation mode, a different construct than the IIS 6.0 worker process isolation mode. When applications are run in IIS 5.0 isolation mode, they are run in the context of the privileged local systems account. Applications run out-of-process in IIS 5.0 run under the context of the IWAM_servername account, which has fewer privileges on the server.

Process identity
The account that a process runs under. When anonymous access is allowed, the IUSR_servername account is the process identity.

Application pool identity
The user account that is the process identity for a worker process that services an application pool. Each application pool should have a separate application pool identity. You restrict and grant access to resources based on this identity.

IIS_WPG group
A default group added when IIS is installed. The group has default access to write log files, access to the metabase, and access that is required for IIS applications to run. Instead of applying the proper access rights and permissions to each new user account created as an application pool identity, add them to this group.

Use web site permissions. Web site permissions are used by IIS to determine what type of access is allowed to a web site or virtual directory. Web site permissions are not used instead of NTFS permissions. If both web permissions and NTFS permissions are used, the most restrictive permission will be applied. Web site permissions, however, only affect those who visit the web site. NTFS permissions affect all visitors to the data. NTFS permissions should always be used to protect files and folders. Web site permissions are

Read view the content and directory and file properties
If all content is scripted, such as ASP pages, the Read permission is not required and can be removed. Do not combine Read and Script Source Access on the same folder. Visitors might find sensitive information in script files such as passwords.

Write
Change the content and properties of files and folders. Do not combine Write and Execute permissions on the same folders. To do so would allow a visitor to add a script or program to the web site and then execute it with potentially disastrous results.

Script Source Access
Permits access to source files. If Script Source Access and Read are set on the same folder, visitors to the web site can read scripts, and if Write is set, they can modify the source files. Script Source Access is required when WebDAV is used.

Directory Browsing
View file lists.

Log Visits
A log entry for each visitor is added. Enable logging. Having information on who visited the web site and at what time may help determine the source of an attack.

Index this resource
Permits the indexing service to index the resources so that searches can be made.

Execute
Has three different levels of access: Noneno scripts or executables can run; Scripts Onlyonly scripts can run; Scripts and Executablesscripts and executables can run on the server.

Keep different file types in different folders and set appropriate permissions on the folders.

Back up web site data and the metabase. The metabase is the structure that store IIS configuration.

Remote Access Considerations

Many of the security considerations listed previously will also help to protect the internal network. If the web server is compromised, its authorized connections to internal resources can turn it into a backdoor to the network and enable compromise:

Restrict access from the web server to internal resources. Instead of simply allowing the web server access to the network, reduce that access to specific servers only. For example, an internal firewall between the web server on the perimeter network and the internal network can allow access to specific ports on specific servers by the web server.

Consider the protection of data as it leaves and comes to the web server. E-commerce transactions are often protected with Secure Sockets Layer (SSL), but these are not the only communications processes that should be considered. Both customer transactions and communications between the web server and backend servers, such as databases, may need protection. Consider SSL or IPSec as possible communication protection options. SSL, for example, can be used to secure communications between the web server and Internet Security and Acceleration (ISA) server, and between the web server and Microsoft SQL server. IPSec can also be used to secure communications between the web server and resources it needs to access.

Consider protection for administrative access to web servers. Consider isolating administrative access to specific administrator computers and protect communications with IPSec.

Do not install the Remote Administration (HTML) Tool. This tool provides remote administration via a web browser. Port 80 access to administration tools is not a good idea because port 80 will always be open to the Internet if a web server is used.

Consider the use of terminal services for administration from the LAN. Terminal services communications are encrypted, and the user is authenticated.

Require VPN access for administration across the WAN if such access is allowed.

Protect the process of content management. Not only should an approval process exist, but you also should require authenticated access to the server and use ACLs to ensure that only authorized individuals can change content.

Provide additional change control management to ensure appropriate and timely addition of service packs and security patches as well as equipment updates.

Restrict access to intranet sites. Use the web site Directory Security Property page and its IP address and name restrictions button to limit access by specifying domain names and IP addresses. This may prevent remote access or access from unauthorized computers. Remember, however, that IP addresses can be spoofed. To restrict access, click the Denied access radio button and then use the Add button to enter the IP address or domain name of the approved computers. Figure 14-48 shows the configuration to only allow access from computers joined in the chicago.local domain.

WARNING: Performance Issue

Using domain names to restrict access to web sites requires the use of a reverse lookup for each attempted request. This can hamper performance.

Use FTP user isolation when access by multiple, diverse populations to FTP services is required. When multiple FTP sites are established on the same server, it is difficult to configure FTP and the server to keep malicious users from obtaining access to other sites. Directory traversal attacks are used to gain access. FTP user isolation solves this issue. When FTP user isolation is used, each FTP site appears to be at the root of the FTP server, and directory traversal attacks cannot be used to gain access to other sites. A user with credentials for one site cannot access the resources on another. For more information, see KB article 816525 at http://support.microsoft.com/default.aspx?scid=kb;en-us;816525.