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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS 8.2.4 Load Balancers Load balancers distribute HTTP requests over multiple Web servers, allowing organizations to increase the capacity of their Web site by transparently adding additional servers. Load balancers act as virtual servers, receiving all HTTP requests to the Web site. These requests are forwarded, based on the load balancer’s policy, to one of the servers that hosts the Web site. The load balancer’s policy attempts to ensure that each server receives a similar number of requests. Many load balancers are capable of monitoring the servers and compensating if one of the servers becomes unavailable. Load balancers are often augmented by caching mechanisms. Many of the HTTP requests an organization’s Web server receives are identical and return identical HTTP responses. However, when dynamic content generation is in use, these identical responses need to be regenerated each time the request is made. To alleviate this requirement and further reduce the load on individual Web servers, organizations can deploy caching servers. Like network switches, load balancers are not specifically security appliances, but they are essential tools for maintaining the availability of a Web site. By ensuring that several individual Web servers are sharing the load, rather than placing it on a single Web server, the organization is better able to withstand the high volume of requests used in many DoS attacks. Firewalls, switches, and routers should also be configured (when possible) to limit the amount of traffic that is passed to the Web servers, which further reduces the risk of successful DoS attacks. 8.2.5 Reverse Proxies Reverse proxies are devices that sit between a Web server and the server’s clients. The term “reverse proxy” is used because the data flow is the reverse of a traditional (forward) proxy. Reverse proxies can serve as a valuable addition to the security of a Web server. The term reverse proxy is used rather loosely in the industry and can include some or all of the following functionality: Encryption accelerators, which off-load the computationally expensive processing required for initiating SSL/TLS connections Security gateways, which monitor HTTP traffic to and from the Web server for potential attacks and take action as necessary, acting in essence as an application level firewall Content filters, which can monitor traffic to and from the Web server for potentially sensitive or inappropriate data and take action as necessary Authentication gateways, which authenticate users via a variety of mechanisms and control access to URLs hosted on the Web server itself. Reverse proxies should be considered for any high-risk Web server deployment. While they do add risk by requiring the deployment of additional hardware and software, the risk is generally outweighed by the benefits. In addition to the functionality list above, Web proxies are also valuable because they add an additional layer between a Web server and its less trusted users. Due to their highly specialized nature, proxies are easier to secure than Web servers. Proxies also further obfuscate a Web server’s configuration, type, location, and other details that are pertinent to attackers. For example, Web servers have banners that frequently reveal the Web server type and version, and these banners sometimes cannot be changed. With a reverse proxy, this is not an issue because the proxy can rewrite the banner before it is sent to users. 8-12
GUIDELINES ON SECURING PUBLIC WEB SERVERS 8.3 Checklist for Implementing a Secure Network Infrastructure Completed Identify network location Action Web server is located in a DMZ, or Web server hosting is outsourced Assess firewall configuration Web server is protected by a firewall; if it faces a higher threat or is more vulnerable, it is protected by an application layer firewall Firewall controls all traffic between the Internet and the Web server Firewall blocks all inbound traffic to the Web server except TCP ports 80 (HTTP) and/or <strong>44</strong>3 (HTTPS), if required Firewall blocks (in conjunction with the IDPS) IP addresses or subnets that the IDPS reports are attacking the organizational network Firewall notifies the network or Web server administrator of suspicious activity through an appropriate means Firewall provides content filtering (application layer firewall) Firewall is configured to protect against DoS attacks Firewall detects malformed or known attack URL requests Firewall logs critical events Firewall and firewall OS are patched to latest or most secure level Evaluate intrusion detection and prevention systems Host-based IDPS is used for Web servers that operate primarily using SSL/TLS IDPS is configured to monitor network traffic to and from the Web server after firewall IDPS is configured to monitor changes to critical files on Web server (host-based IDPS or file integrity checker) IDPS blocks (in conjunction with the firewall) IP addresses or subnets that are attacking the organizational network IDPS notifies the IDPS administrators or Web server administrator of attacks through appropriate means IDPS is configured to maximize detection with an acceptable level of false positives IDPS is configured to log events IDPS is updated with new attack signatures frequently (e.g., on a daily basis) Host-based IDPS is configured to monitor the system resources available in the Web server host Assess network switches Switches are used to protect against network eavesdropping Switches are configured in high-security mode to defeat ARP spoofing and ARP poisoning attacks Switches are configured to send all traffic on network segment to network-based IDPS Evaluate load balancers Load balancers are used to increase Web server availability Load balancers are augmented by Web caches if applicable Evaluate reverse proxies Reverse proxies are used as a security gateway to increase Web server availability Reverse proxies are augmented with encryption acceleration, user authentication, and content filtering capabilities, if applicable 8-13
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: GUIDELINES ON SECURING PUBLIC WEB S
Page 97: GUIDELINES ON SECURING PUBLIC WEB S
show all

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

Create successful ePaper yourself

Delete template?

Save as template?