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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS 7.7 Checklist for Using Authentication and Encryption Technologies for Web Servers Completed Action Configure Web authentication and encryption technologies For Web resources that require minimal protection and for which there is a small, clearly defined audience, configure address-based authentication For Web resources that require additional protection but for which there is a small, clearly defined audience, configure address-based authentication as a second line of defense For Web resources that require minimal protection but for which there is no clearly defined audience, configure basic or digest authentication (better) For Web resources that require protection from malicious bots, configure basic or digest authentication (better) or implement mitigation techniques discussed in Section 5.2.4 For organizations required to comply with FIPS 140-2, ensure the SSL/TLS implementation is FIPS-validated For Web resources that require maximum protection, configure SSL/TLS Configure SSL/TLS Ensure the SSL/TLS implementation is fully patched Use a third-party issued certificate for server authentication (unless all systems using the server are organization-managed, in which case a self-signed certificate could potentially be used instead) For configurations that require a medium level of client authentication, configure server to require username and password via SSL/TLS For configurations that require a high level of client authentication, configure server to require client certificates via SSL/TLS Ensure weak cipher suites are disabled (see Table 7.1 for the recommended usage of Federal cipher suites) Configure file integrity checker to monitor Web server certificate If only SSL/TLS is to be used in the Web server, ensure access via any TCP port other than <strong>44</strong>3 is disabled If most traffic to the Web server will be via encrypted SSL/TLS, ensure that appropriate logging and detection mechanisms are employed in the Web server (because network monitoring is ineffective against encrypted SSL/TLS sessions) Protect against brute force attacks Use strong authentication if possible Use a delay after failed login attempts Lock out an account after a set number of failed login attempts Enforce a password policy Blacklist IP addresses or domains known to attempt brute force attacks Use log monitoring software to detect brute force attacks 7-14
GUIDELINES ON SECURING PUBLIC WEB SERVERS 8. Implementing a Secure Network Infrastructure The network infrastructure that supports the Web server plays a critical role in the security of the Web server. In most configurations, the network infrastructure is the first line of defense between the Internet and a public Web server. Network design alone, however, cannot protect a Web server. The frequency, sophistication, and variety of attacks perpetrated today lend support to the idea that Web security must be implemented through layered and diverse protection mechanisms (defense-in-depth). This section discusses those network components that can support and protect Web servers to further enhance their overall security. Although security issues are paramount, network infrastructure considerations are influenced by many factors other than security, including cost, performance, and reliability. 8.1 Network Composition and Structure Firewalls and routers are devices or systems that control the flow of network traffic between networks. They can protect Web servers from vulnerabilities inherent in the TCP/IP suite and help reduce the security issues associated with insecure applications and OSs. However, an organization has many choices when determining a network environment for a Web server, and security may not be the principal factor in deciding among those options. Network composition and structure are the first and in many respects the most critical decisions that affect Web server security because they determine what network infrastructure elements protect the Web server. For example, if the Web server is located before the organization’s main firewall, then the firewall cannot be used to control traffic to and from the Web server. Network composition and structure also determine what other portions of the network are vulnerable if the Web server is compromised. For example, an externally accessible Web server located on the internal production network subjects the internal network to attack if the Web server is compromised. Also, an organization may choose not to have the Web server located on its network at all and to outsource the hosting to a third party. 8.1.1 Inadvisable Network Layout Some organizations choose to locate their public Web servers on their internal production networks. That is, their Web servers reside on the same network as the internal users and servers. The principal weakness of this layout is that it exposes internal network components to additional risks. Web servers are often targets of attackers. If attackers manage to compromise a Web server, they will have access to the internal network and will be able to more easily compromise internal hosts. Therefore, this layout is not recommended. Another network layout that is not generally recommended is placing the Web server before an organization’s firewall or router that provides IP filtering. In this structure, the network provides little, if any, protection for the Web server. Because the Web server itself has to maintain security, it provides a single point of failure. To be even somewhat secure in this location, the Web server OS and application have to be extremely well-hardened, with all unnecessary and insecure services disabled and all necessary security patches applied. To maintain the security of the setup, the Web server administrator must stay up to date on vulnerabilities and related patches. Another limitation of this structure is that providing any sort of secure remote administration or content update capability is difficult. 8.1.2 Demilitarized Zone A demilitarized zone (DMZ) describes a host or network segment inserted as a “neutral zone” between an organization’s private network and the Internet. It prevents outside users of the Web server from gaining direct access to an organization’s internal network (intranet). A DMZ mitigates the risks of locating a Web server on an internal network or exposing it directly to the Internet. It is a compromise solution that 8-1
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: GUIDELINES ON SECURING PUBLIC WEB S
Page 85: GUIDELINES ON SECURING PUBLIC WEB S
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?