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

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

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

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!