NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS Completed Action Reconfigure HTTP service banner (and others as required) NOT to report Web server and OS type and version Configure OS and Web server access controls Configure the Web server process to run as a user with a strictly limited set of privileges Configure the Web server so that Web content files can be read but not written by service processes Configure the Web server so that service processes cannot write to the directories where public Web content is stored Configure the Web server so that only processes authorized for Web server administration can write Web content files Configure the host OS so that the Web server can write log files but not read them Configure the host OS so that temporary files created by the Web server application are restricted to a specified and appropriately protected subdirectory Configure the host OS so that access to any temporary files created by the Web server application is limited to the service processes that created the files Install Web content on a different hard drive or logical partition than the OS and Web server application If uploads are allowed to the Web server, configure it so that a limit is placed on the amount of hard drive space that is dedicated for this purpose; uploads should be placed on a separate partition Ensure that log files are stored in a location that is sized appropriately; log files should be placed on a separate partition Configure the maximum number of Web server processes and/or network connections that the Web server should allow Ensure that any virtualized guest OSs follow this checklist Ensure users and administrators are able to change passwords Disable users after a specified period of inactivity Ensure each user and administrator has a unique ID Configure a secure Web content directory Dedicate a single hard drive or logical partition for Web content and establish related subdirectories exclusively for Web server content files, including graphics but excluding scripts and other programs Define a single directory exclusively for all external scripts or programs executed as part of Web server content (e.g., CGI, ASP) Disable the execution of scripts that are not exclusively under the control of administrative accounts. This action is accomplished by creating and controlling access to a separate directory intended to contain authorized scripts Disable the use of hard or symbolic links (e.g., shortcuts for Windows) Define a complete Web content access matrix. Identify which folders and files within the Web server document should be restricted and which should be accessible (and by whom) Check the organization’s password policy and set account passwords appropriately (e.g., length, complexity) Use the robots.txt file, if appropriate Configure anti-spambot protection, if appropriate (e.g., CAPTCHAs, nofollow, or keyword filtering) 5-10
GUIDELINES ON SECURING PUBLIC WEB SERVERS 6. Securing Web Content The two main components of Web security are the security of the underlying server application and OS, and the security of the actual content. Of these, the security of the content is often overlooked. Maintaining effective content security itself has two components. The more obvious is not placing any proprietary, classified, or other sensitive information on a publicly accessible Web server, unless other steps have been taken to protect the information via user authentication and encryption (see Section 7). The less obvious component of content security is avoiding compromises caused by the way particular types of content are processed on a server. As organizations have gotten better at protecting and hardening their network perimeters, OSs, and Web servers, attackers have increasingly turned to exploiting vulnerabilities in Web applications and the way information is processed on Web servers. These application layer attacks exploit the interactive elements of Web sites. 6.1 Publishing Information on Public Web Sites Too often, little thought is given to the security implications of the content placed on the Web site. Many organizations do not have a Web publishing process or policy that determines what type of information to publish openly, what information to publish with restricted access, and what information should be omitted from any publicly accessible repository. This is troublesome because Web sites are often one of the first places that malicious entities search for valuable information. For example, attackers often read the contents of a target organization’s Web site to gather intelligence before any attacks [Scam01]. Also, attackers can take advantage of content available on a Web site to craft a social engineering attack or to use individuals’ identifying information in identity theft [FTC06]. Absent compelling reasons, a public Web site should not contain the following information: Classified records Internal personnel rules and procedures Sensitive or proprietary information Personal information about an organization’s personnel or users 30 • Home addresses and telephone numbers • Uniquely identifying information, particularly SSNs • Detailed biographical material (that could be employed for social engineering) • Staff family members Telephone numbers, e-mail addresses, 31 or general listings of staff unless necessary to fulfill organizational requirements 30 31 For Federal agencies, this would include all items covered by the Privacy Act of 1974 (http://www.usdoj.gov/04foia/privstat.htm). This encompasses personally identifiable information (PII), which is information that can be used to uniquely identify, locate, or contact an individual. When an email address must be published on a Web site, consider the use of generic email addresses or aliases (e.g., webmaster@mydomain.gov as opposed to jane_doe@mydomain.gov). There are two reasons to do this. One, published 6-1
Page 1 and 2: Special Publication 800</st
Page 3 and 4: GUIDELINES ON SECURING PUBLIC WEB S
Page 51: GUIDELINES ON SECURING PUBLIC WEB S
Page 103 and 104:
GUIDELINES ON SECURING PUBLIC WEB S
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
show all

NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

Create successful ePaper yourself

Delete template?

Save as template?