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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS Demonstrates that vulnerabilities are not purely theoretical Provides the “realism” necessary to address security issues Allows for testing of procedures and susceptibility of the human element to social engineering. 9.5 Remotely Administering a Web Server It is strongly recommended that remote administration and remote updating of content for a Web server be allowed only after careful consideration of the risks. The most secure configuration is to disallow any remote administration or content updates. However, that might not be viable for all organizations. The risk of enabling remote administration or content updates varies considerably depending on the location of the Web server on the network (see Section 8.1). For a Web server that is located behind a firewall, remote administration or content updating can be implemented relatively securely from the internal network, but not without added risk. Remote administration or content updating should generally not be allowed from a host located outside the organization’s network unless it is performed from an organization-controlled computer through the organization’s remote access solution, such as a VPN. If an organization determines that it is necessary to remotely administer or update content on a Web server, following these steps should ensure that content is implemented in as secure a manner as possible: Use a strong authentication mechanism (e.g., public/private key pair, two-factor authentication). Restrict which hosts can be used to remotely administer or update content on the Web server. • Restrict by authorized users • Restrict by IP address (not hostname) • Restrict to hosts on the internal network or those using the organization’s enterprise remote access solution. Use secure protocols that can provide encryption of both passwords and data (e.g., SSH, HTTPS); do not use less secure protocols (e.g., telnet, FTP, NFS, HTTP) unless absolutely required and tunneled over an encrypted protocol, such as SSH, SSL, or IPsec. Enforce the concept of least privilege on remote administration and content updating (e.g., attempt to minimize the access rights for the remote administration/update accounts). Do not allow remote administration from the Internet through the firewall unless accomplished via strong mechanisms, such as VPNs. Change any default accounts or passwords for the remote administration utility or application. Do not mount any file shares on the internal network from the Web server or vice versa. 9-13
GUIDELINES ON SECURING PUBLIC WEB SERVERS 9.6 Checklist for Administering the Web Server Completed Perform logging Action Use the combined log format for storing the Transfer Log or manually configure the information described by the combined log format to be the standard format for the Transfer Log Enable the Referrer Log or Agent Log if the combined log format is unavailable Establish different log file names for different virtual Web sites that may be implemented as part of a single physical Web server Use the remote user identity as specified in RFC 1413 Store logs on a separate (syslog) host Ensure there is sufficient capacity for the logs Archive logs according to organizational requirements Review logs daily Review logs weekly (for more long-term trends) Use automated log file analysis tool(s) Perform Web server backups Create a Web server backup policy Back up Web server differentially or incrementally on a daily to weekly basis Back up Web server fully on a weekly to monthly basis Periodically archive backups Maintain an authoritative copy of Web site(s) Recover from a compromise Report the incident to the organization’s computer incident response capability Isolate the compromised system(s) or take other steps to contain the attack so additional information can be collected Investigate similar hosts to determine if the attacker has also compromised other systems Consult, as appropriate, with management, legal counsel, and law enforcement officials expeditiously Analyze the intrusion Restore the system Test system to ensure security Reconnect system to network Monitor system and network for signs that the attacker is attempting to access the system or network again Document lessons learned Test security Periodically conduct vulnerability scans on Web server, dynamically generated content, and supporting network Update vulnerability scanner prior to testing Correct any deficiencies identified by the vulnerability scanner Conduct penetration testing on the Web server and the supporting network infrastructure Correct deficiencies identified by penetration testing 9-14
Page 1 and 2:
Special Publication 800</st
Page 3 and 4:
GUIDELINES ON SECURING PUBLIC WEB S
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62: GUIDELINES ON SECURING PUBLIC WEB S
Page 111: GUIDELINES ON SECURING PUBLIC WEB S
show all

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?