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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS The following keywords are allowed: User-agent is the name of the robot or spider. A Web administrator may also include more than one agent name if the same exclusion is to apply to each specified bot. The entry is not case-sensitive (in other words, “googlebot” is the same as “GOOGLEBOT” and “GoogleBot”). An asterisk (“*”) indicates a “default” record, which applies if no other match is found. For example, if you specify “GoogleBot” only, then the “*” would apply to any other robot. Disallow tells the bot(s) specified in the user-agent field which sections of the Web site are excluded. For example, /images informs the bot not to open or index any files in the images directory or any subdirectories. Thus, the directory “/images/special/” would not be indexed by the excluded bot(s). Note that “/do” matches any directory beginning with “/do” (e.g. /do, /document, /docs, etc.), whereas “/do/” matches only the directory named “/do/”. A Web administrator can also specify individual files for exclusion. For example, the Web administrator could specify “/mydata/help.html” to prevent only that one file from being accessed by the bots. A value of just “/” indicates that nothing on the Web site is allowed to be accessed by the specified bot(s). At least one disallow per user-agent record must exist. There are many ways to use the robots.txt file. Some simple examples are as follows: To disallow all (compliant) bots from specific directories: User-agent: * Disallow: /images/ Disallow: /banners/ Disallow: /Forms/ Disallow: /Dictionary/ Disallow: /_borders/ Disallow: /_fpclass/ Disallow: /_overlay/ Disallow: /_private/ Disallow: /_themes/ To disallow all (compliant) bots from the entire Web site: User-agent: * Disallow: / To disallow a specific bot (in this case the Googlebot) from examining a specific Web page: User-agent: GoogleBot Disallow: tempindex.htm Note that the robots.txt file is available to everyone and does not provide access control mechanisms to the disallowed files. Thus, a Web administrator should not specify the names of sensitive files or folders because attackers often analyze robots.txt files to guide their initial investigations of Web sites. If files or directories must be excluded, it is better to use password-protected pages that cannot be accessed by bots. 5-8
GUIDELINES ON SECURING PUBLIC WEB SERVERS Password protection is the only reliable way to exclude noncompliant bots or curious users. See Section 7 for more information on Web-based authentication methods. Often, spambots ignore robots.txt and search for email addresses on the Web site and/or forms to which they can submit spam-related content. Spambots that merely scan the Web site typically do not affect its availability. Nevertheless, it may be beneficial to prevent them from harvesting e-mail addresses by performing address munging [Unsp06]—displaying e-mail addresses in an alternative human-readable format, such as listing name@mywww.gov as . Unfortunately, these techniques do not stop all spambots. The best defense against address harvesting is not to display e-mail addresses. Spambots searching for Web forms to submit spam-related content are a direct threat to the Web site. They can affect the organization’s image if visitors view the submitted content as an endorsement. They may also affect the Web site’s availability by making it difficult for users to find necessary content. There are several techniques available to reduce the amount of spam submissions, including— Blocking form submissions that use spam-related keywords Using the rel=“nofollow” keyword in all submitted links, which will cause search engines to omit the links in their page-ranking algorithms, directly affecting the goals of a spambot [Google05] Requiring submitters to solve a Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) prior to being allowed to submit content. These techniques all have benefits and drawbacks associated with them. For example, some CAPTCHA techniques, which can be implemented as an obscured word in an image, do not comply with American Disability Association (ADA) or Section 508 accessibility guidelines. Information about ongoing research on detecting spambots can be found through the Adversarial Information Retrieval on the Web (AIRWeb) workshops. 29 5.3 Checklist for Securing the Web Server Completed Securely install the Web server Action Install the Web server software on a dedicated host or a dedicated virtualized guest OS Apply any patches or upgrades to correct for known vulnerabilities Create a dedicated physical disk or logical partition (separate from OS and Web server application) for Web content Remove or disable all services installed by the Web server application but not required (e.g., gopher, FTP, remote administration) Remove or disable all unneeded default login accounts created by the Web server installation Remove all manufacturer documentation from server Remove any example or test files from server, including scripts and executable code Apply appropriate security template or hardening script to the server 29 The AIRWeb 2006 Web site is available at http://airweb.cse.lehigh.edu/2006. 5-9
Page 1 and 2: Special Publication 800</st
Page 3 and 4: GUIDELINES ON SECURING PUBLIC WEB S
Page 49: GUIDELINES ON SECURING PUBLIC WEB S
Page 101 and 102:
GUIDELINES ON SECURING PUBLIC WEB S
Page 103 and 104:
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?