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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS offers the most benefits with the least amount of risk for most organizations. The DMZ allows access to the resources located within it to both internal and external users. There are a wide variety of DMZ configurations, each with its own strengths and weaknesses. Creating a DMZ involves placing a firewall between an organization’s border router and its internal network, and creating a new network segment that can only be reached through the DMZ device. The Web server is placed on the new segment, along with other network infrastructure components and servers that need to be externally accessible. In some configurations, the border router itself may act as a basic firewall. Figure 8-1 illustrates an example of this simple DMZ using a router with access control lists (ACL) to restrict certain types of network traffic to and from the DMZ. Figure 8-1. Simple Single-Firewall DMZ A single-firewall DMZ is a low-cost approach because the organization needs only to add a single firewall and use its existing border router to provide protection to the DMZ. It is usually appropriate only for small organizations that face a minimal threat. The basic weakness in the approach is that although the router is able to protect against most network attacks, it is not “aware” of the Web server application layer protocols (e.g., HTTP) and thus cannot protect against application layer attacks aimed at the Web server. A superior approach is to add a second firewall between the Internet and the DMZ, as shown in Figure 8-2. Figure 8-2. Two-Firewall DMZ 8-2
GUIDELINES ON SECURING PUBLIC WEB SERVERS A two-firewall DMZ configuration improves protection over a router-firewall DMZ because the dedicated firewalls can have more complex and powerful security rule sets. In addition, because a dedicated firewall is often able to analyze incoming and outgoing HTTP traffic, it can detect and defend against application layer attacks aimed at the Web server. Depending on the rule sets of the firewalls and the level of traffic the DMZ receives, this type of DMZ may result in some performance degradation. For organizations that desire the security of the two-firewall DMZ but do not have the resources to purchase two firewalls, another option exists called the “service leg” DMZ. In this configuration, a firewall is constructed with three (or more) network interfaces. One network interface attaches to the border router, another interface attaches to the internal network, and a third network interface connects to the DMZ (see Figure 8-3). Figure 8-3. Service Leg DMZ This configuration subjects the firewall to an increased risk of service degradation during a DoS attack aimed at the DMZ. In the standard single-firewall DMZ network configuration discussed above, a DoS attack against the Web server generally affects only the Web server. In a service-leg DMZ network configuration, the firewall bears the brunt of any DoS attack because it must examine any network traffic before the traffic reaches the Web server (or any other DMZ or internal network resource) [<strong>NIST</strong>02a]. However, it is increasingly likely that a DoS attack will take the form of a DDoS attack and consume all of the incoming network bandwidth and related devices (e.g., Internet border routers) before ever reaching a DMZ firewall. The advantages of a DMZ from a security standpoint are as follows: The Web server may be better protected, and network traffic to and from the Web server can be monitored. Compromise of the Web server does not directly threaten the internal production network. Greater control can be provided over the security of the Web server because traffic to and from the Web server can be controlled. The DMZ network configuration can be optimized to support and protect the Web servers. 8-3
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: GUIDELINES ON SECURING PUBLIC WEB S
Page 87: GUIDELINES ON SECURING PUBLIC WEB S
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?