- Use the Right Access Controls on Network Servers
- Use the Right Access Controls On Public Web Servers
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Use the Right Access Controls On Public Web Servers
Most Web server host operating systems provide the ability to specify access privileges individually for files, devices, and other data or code objects stored on that host. Any information that a Web server can access using these controls can potentially be distributed to all users accessing an organization's public Web site. Web server software is likely to provide additional object, device, and file access controls specific to its operation. Consider two perspectives about how best to configure these access controls to protect information stored on a public Web server:
How to limit the Web server software's access
How to apply access controls specific to the Web server when more detailed levels of access control are required
Why This Is Important
A public Web server typically stores information intended for widespread publication. It may also store information requiring restricted access, such as server log files, system software and configuration files, applications software and configuration files, and password files.
Using the access controls provided by both the server operating system and the Web server software can reduce the likelihood of inadvertent disclosure or corruption of information and violations of confidentiality and integrity. In addition, using access controls to limit resource use can reduce the impact of a denial-of-service attack against your public Web site, a violation of availability.
How to Do It
Establish New User and Group Identities
Establish new user and group identities to be used exclusively by the Web server software. Make these new user and new group identities independent and distinct from all other users and groups. This is a prerequisite for implementing the access controls described below.
Although the server may have to run as root (UNIX) or administrator (Windows) initially to bind to port 80, do not allow the server to continue to run in this mode.
Identify the Protection Needed
The general approach for identifying required access controls for files, devices, and objects specific to Web servers is outlined above.
In addition, determine if the Web server's operating system provides the ability to limit files accessed by the Web services' processes. These processes should have read-only access to those files necessary to perform the service, and should have no access to other files (such as server log files). If this feature is not available, skip some of the following steps and implement other security controls (described below) to limit exposure.
Use Web server host operating system access controls to enforce the following rules:
Public Web content files can be read but not written by Web service processes.
The directories in which public Web content is stored cannot be written by Web service processes.
Public Web content files can be written only by processes authorized for Web server administration.
Web server log files can be written by service processes, but log files cannot be read or serve as Web content. Web server log files can be read only by administration processes.
Any temporary files created by Web service processes (such as those that might be generated in the creation of dynamic Web pages) are restricted to a specified and appropriately protected subdirectory.
Access to any temporary files created by Web service processes are limited to the service processes that created these files.
Some of these controls are reiterated below when they can be achieved using alternate methods.
Mitigate the Effects of Denial-of-Service (DoS) Attacks
Resource-intensive DoS attacks against a Web server host operating system can involve several approaches, including the following:
Taking advantage of the number of simultaneous network connections by quickly establishing connections up to the maximum permitted so that no new legitimate users can gain access
Filling primary memory with unnecessary processes to slow down the system and limit Web service availability
Filling file systems with extraneous and incorrect information (some systems will not function if specific assets such as file systems are unavailable)
Logging information generated by the Web server host operating system may help to recognize such attacks.
Institute the following controls to limit the use of resources by the Web server host operating system and thus mitigate the effects of DoS attacks:
Network connection time-outs (time after which an inactive connection is dropped) should be set to a minimum acceptable time setting. Established connections will then time out as quickly as possible, opening up new connections to legitimate users. This procedure only mitigates the effects, however; it does not defeat the attack. If the maximum allowable open connections (or connections that are half-open—that is, if the first part of the TCP handshake was successful) are set to a low number, an attacker can easily consume the available connections with bogus requests. By setting the maximum to a much higher number, the impact of such attacks may be reduced, but additional resources will be consumed.
Secure Web servers often impose self-limiting constraints, and are configured to make most processes unavailable. Assigning priorities to Web service processes can help to ensure that high-priority processes obtain sufficient resources, even while under attack. Note, however, that doing so may create the potential for a denial-of-service on the lower-priority services.
It is unusual to be able to fill the available disk space of Web servers. Requests are typically processed quickly, and other "writes" should be disabled. Create separate directories for log files and other information from system directories and user information. Establishing effective boundaries between these information objects can be accomplished by specifying separate partitions and/or disk locations.
These controls will not fully protect your Web server against DoS attacks. However, by reducing the impact of these attacks, the Web server may be able to "survive" during the time period when the DoS attacks are occurring.
Protect Sensitive and Restricted Information
Configure the public Web server so that it cannot serve files outside the specified file directory tree for public Web content. This may be a configuration choice, either in the server software or in how the server process is controlled by the operating system. As much as possible, ensure that such files (outside of the specified directory tree) cannot be served, even if users know the names (URLs) of those files.
Avoid the use of links or aliases in your public Web content file directory tree that point to files elsewhere on the server host or the network file system. If possible, disable the Web server software's capability to follow links and aliases. As stated earlier, Web server log files and configuration files should reside outside of the specified file directory tree for public Web content.
In the event that the public Web server needs to access files that are sensitive or restricted, refer to the practice Configure the Web Server to Use Authentication and Encryption Technologies in the references noted at the beginning of this article.
Configure Web Server Software Access Controls
To configure Web server software access controls, perform the following steps:
Define a single directory, and establish related subdirectories exclusively for Web server content files, including graphics but excluding CGI (Common Gateway Interface) scripts and other programs.
Define a single directory exclusively for all external programs executed as part of Web server content.
Disable the execution of CGI scripts that are not exclusively under the control of administrative accounts. This is accomplished by creating and controlling access to a separate directory intended to contain authorized CGI scripts.
Disable the use of hard or symbolic links as ordinary files and directories.
Define a complete Web content access matrix. Identify which pages are restricted and which pages are accessible (and by what user groups).
Most Web server software vendors provide directives or commands that can restrict user access to public Web server content files. For example, the Apache Web server software provides a Limit directive that restricts which optional access features (such as New, Delete, Connect, Head, and Get) are associated with each Web content file. The Apache Require directive supports restricting available content to authenticated users or groups.
Many of the directives or commands can be overridden on a per-directory basis. The convenience of being able to make local exceptions to global policy is offset by the threat of a security hole being introduced in a distant subdirectory, which could be controlled by a hostile user. We recommend disabling a subdirectory's capability to override top-level security directives unless that override is required.
Disable the Serving of Web Server File Directory Listings
A common implementation of the Web protocol (HTTP) specifies that a URL ending in a slash character be treated as a request for a listing of the files in the directory with that name. As a general rule, prohibit the Web server from responding to such requests, even if all the files in the directory can be read by the general public.
Such requests may indicate an attempt to locate information by means other than that intended by the Web site. Users may try this if they are having difficulty navigating through the site, or if a link appears to be broken. Intruders may attempt this action to locate information hidden by the Web site's interface. We recommend investigating requests of this type found in Web server log files.