27.01.2014 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

GUIDELINES ON SECURING PUBLIC WEB SERVERS<br />

8.2.4<br />

Load Balancers<br />

Load balancers distribute HTTP requests over multiple <strong>Web</strong> servers, allowing organizati<strong>on</strong>s to increase<br />

the capacity of their <strong>Web</strong> site by transparently adding additi<strong>on</strong>al servers. Load balancers act as virtual<br />

servers, receiving all HTTP requests to the <strong>Web</strong> site. These requests are forwarded, based <strong>on</strong> the load<br />

balancer’s policy, to <strong>on</strong>e of the servers that hosts the <strong>Web</strong> site. The load balancer’s policy attempts to<br />

ensure that each server receives a similar number of requests. Many load balancers are capable of<br />

m<strong>on</strong>itoring the servers and compensating if <strong>on</strong>e of the servers becomes unavailable.<br />

Load balancers are often augmented by caching mechanisms. Many of the HTTP requests an<br />

organizati<strong>on</strong>’s <strong>Web</strong> server receives are identical and return identical HTTP resp<strong>on</strong>ses. However, when<br />

dynamic c<strong>on</strong>tent generati<strong>on</strong> is in use, these identical resp<strong>on</strong>ses need to be regenerated each time the<br />

request is made. To alleviate this requirement and further reduce the load <strong>on</strong> individual <strong>Web</strong> servers,<br />

organizati<strong>on</strong>s can deploy caching servers.<br />

Like network switches, load balancers are not specifically security appliances, but they are essential tools<br />

for maintaining the availability of a <strong>Web</strong> site. By ensuring that several individual <strong>Web</strong> servers are<br />

sharing the load, rather than placing it <strong>on</strong> a single <strong>Web</strong> server, the organizati<strong>on</strong> is better able to withstand<br />

the high volume of requests used in many DoS attacks. Firewalls, switches, and routers should also be<br />

c<strong>on</strong>figured (when possible) to limit the amount of traffic that is passed to the <strong>Web</strong> servers, which further<br />

reduces the risk of successful DoS attacks.<br />

8.2.5<br />

Reverse Proxies<br />

Reverse proxies are devices that sit between a <strong>Web</strong> server and the server’s clients. The term “reverse<br />

proxy” is used because the data flow is the reverse of a traditi<strong>on</strong>al (forward) proxy. Reverse proxies can<br />

serve as a valuable additi<strong>on</strong> to the security of a <strong>Web</strong> server. The term reverse proxy is used rather loosely<br />

in the industry and can include some or all of the following functi<strong>on</strong>ality:<br />

Encrypti<strong>on</strong> accelerators, which off-load the computati<strong>on</strong>ally expensive processing required for<br />

initiating SSL/TLS c<strong>on</strong>necti<strong>on</strong>s<br />

Security gateways, which m<strong>on</strong>itor HTTP traffic to and from the <strong>Web</strong> server for potential attacks and<br />

take acti<strong>on</strong> as necessary, acting in essence as an applicati<strong>on</strong> level firewall<br />

C<strong>on</strong>tent filters, which can m<strong>on</strong>itor traffic to and from the <strong>Web</strong> server for potentially sensitive or<br />

inappropriate data and take acti<strong>on</strong> as necessary<br />

Authenticati<strong>on</strong> gateways, which authenticate users via a variety of mechanisms and c<strong>on</strong>trol access to<br />

URLs hosted <strong>on</strong> the <strong>Web</strong> server itself.<br />

Reverse proxies should be c<strong>on</strong>sidered for any high-risk <strong>Web</strong> server deployment. While they do add risk<br />

by requiring the deployment of additi<strong>on</strong>al hardware and software, the risk is generally outweighed by the<br />

benefits. In additi<strong>on</strong> to the functi<strong>on</strong>ality list above, <strong>Web</strong> proxies are also valuable because they add an<br />

additi<strong>on</strong>al layer between a <strong>Web</strong> server and its less trusted users. Due to their highly specialized nature,<br />

proxies are easier to secure than <strong>Web</strong> servers. Proxies also further obfuscate a <strong>Web</strong> server’s<br />

c<strong>on</strong>figurati<strong>on</strong>, type, locati<strong>on</strong>, and other details that are pertinent to attackers. For example, <strong>Web</strong> servers<br />

have banners that frequently reveal the <strong>Web</strong> server type and versi<strong>on</strong>, and these banners sometimes cannot<br />

be changed. With a reverse proxy, this is not an issue because the proxy can rewrite the banner before it<br />

is sent to users.<br />

8-12

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!