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 />

Block all inbound traffic to the <strong>Web</strong> server except traffic which is required, such as TCP ports 80<br />

(HTTP) and/or <str<strong>on</strong>g>44</str<strong>on</strong>g>3 (HTTPS)<br />

Block all inbound traffic with an internal IP address (to prevent IP spoofing attacks)<br />

Block client c<strong>on</strong>necti<strong>on</strong>s from the <strong>Web</strong> server to the Internet and the organizati<strong>on</strong>’s internal network<br />

(this will reduce the impact of some successful compromises)<br />

Block (in c<strong>on</strong>juncti<strong>on</strong> with the intrusi<strong>on</strong> detecti<strong>on</strong> or preventi<strong>on</strong> system [see Secti<strong>on</strong> 8.2.2]) IP<br />

addresses or subnets that the IDS or IPS reports are attacking the organizati<strong>on</strong>al network<br />

Notify the network or <strong>Web</strong> server administrator or appropriate security pers<strong>on</strong>nel of suspicious<br />

activity through an appropriate means (e.g., page, e-mail, network trap)<br />

Provide c<strong>on</strong>tent filtering<br />

Protect against DoS attacks<br />

Detect malformed or known attack URL requests<br />

Log critical events, including the following details:<br />

• Time/date<br />

• Interface IP address<br />

• Manufacturer-specific event name<br />

• Standard attack event (if <strong>on</strong>e exists)<br />

• Source and destinati<strong>on</strong> IP addresses<br />

• Source and destinati<strong>on</strong> port numbers<br />

• Network protocol.<br />

Most firewalls perform some type of logging of the traffic they receive. For most firewalls, the default<br />

logging c<strong>on</strong>figurati<strong>on</strong> is suitable, provided logging is enabled. Administrators should c<strong>on</strong>sult the<br />

manufacturer’s documentati<strong>on</strong> if they believe they require additi<strong>on</strong>al informati<strong>on</strong> to be logged. Certain<br />

firewalls include an ability to track and log informati<strong>on</strong> for each rule, which enables accountability to a<br />

very specific extent.<br />

Many firewalls support the ability to selectively decide what informati<strong>on</strong> to log. If a firewall receives a<br />

series of similar packets from the same locati<strong>on</strong>, it may decide not to log any additi<strong>on</strong>al packets after the<br />

first <strong>on</strong>e. Although this is a valuable feature, c<strong>on</strong>sider the c<strong>on</strong>sequences: each packet that is dropped and<br />

not logged is potential evidence of malicious intent. The principle of logging, a fundamental aspect of<br />

accountability, is discussed in detail in Secti<strong>on</strong> 9.1.<br />

As with OSs and other security-enforcing elements, a firewall requires updates. This includes updating<br />

firmware for hardware and router-based firewalls. Specific instructi<strong>on</strong>s <strong>on</strong> how to update a firewall are<br />

found in the manufacturer’s documentati<strong>on</strong>. Administrators should check for firewall updates frequently.<br />

8-8

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

Saved successfully!

Ooh no, something went wrong!