HTTP/HTTPS

HTTP HTTPS

Much of web security is dependent on the application. Different web servers have different methods of hardening, as highlighted in Chapter 5. This section presents several possible network designs to support web traffic. Because of HTTP's dependence on application security, web security (from the network) is basically about limiting your exposure and gaining visibility of potential attacks. These designs get a bit more complicated when you introduce caching, load balancing, and SSL offload. These technologies are discussed in Chapter 11, "Supporting-Technology Design Considerations."

Simple Web Design

For a basic web server with static content, the design is very straightforward. A single web server off of a public service segment (third interface) on the firewall suffices. The firewall can be configured to allow only TCP 80 traffic into the web server, and, as discussed in Chapter 7, "Network Security Platform Options and Best Deployment Practices," the firewall can block any outbound traffic from the web server.

Two-Tier Web Design

Once you start providing dynamic content and processing input from a user, you are going to have web applications (Common Gateway Interface [CGI] scripts and so on) and probably a database server. The two-tier design separates these functions into two different servers or groups of servers: the web server, which displays the content to the user, and the application/database server, which processes user input and generates the content. By separating the two functions, you make it more difficult for the attacker to get at the applications and database, which is where real damage can result.

The only device that can communicate with the application/database server is the web server. This means an attacker first must compromise the web server or perhaps the firewall to communicate directly with the application server. Although it is possible to put both servers on the same segment, this defeats much of the benefit of segmenting them. If they are on the same segment and an attacker compromises the first server, there is nothing stopping the attacker from attacking the second server directly without passing back through the firewall. Private VLANs can't help here because the systems must talk with one another. The best option is to put the servers on separate interfaces of the firewall. This way, traffic from the compromised web server must pass through the firewall again. This at least limits the attack vectors. This design is shown in Figure 8-7.

Figure 8-7. Two-Tier Web Design

The firewall access control policies to implement this design are as follows. Only the HTTP-related portions of the ACL are shown. In this filtering, it is assumed that some of the dynamic content will be pushed to the web server and some will be pulled from the application server by the web server. Depending on your application architecture, these pushes and pulls can be over another protocol besides HTTP. HTTP (TCP 80) is assumed in these examples. As with the other configurations in this chapter, stateful filtering, which handles the return traffic, is assumed.

Inbound on the inside interface:

!Deny web requests to the application server
access-list 101 deny tcp any host 192.0.3.12 eq 80
!Permit all other web requests
access-list 101 permit tcp 10.8.0.0 0.0.255.255 any eq 80
access-list 101 permit tcp 10.8.0.0 0.0.255.255 any eq 443

Inbound on the outside interface:

!Permit outside hosts to talk http/ssl to the web server
access-list 102 permit tcp any host 192.0.2.53 eq 80
access-list 102 permit tcp any host 192.0.2.53 eq 443
!Deny any other web traffic
access-list 102 deny tcp any any eq 80
access-list 102 deny tcp any any eq 443

Inbound on the perimeter 1 (P1) interface:

!Permit requests to the application server
access-list 103 permit tcp host 192.0.2.53 host 192.0.3.12 eq 80
!Deny any other web request
access-list 103 deny tcp any any eq 80
access-list 102 deny tcp any any eq 443

Inbound on the perimeter 2 (P2) interface:

!Permit content push to the web server
access-list 104 permit tcp host 192.0.3.12 host 192.0.2.53 eq 80
!Deny any other web request
access-list 104 deny tcp any any eq 80
access-list 102 deny tcp any any eq 443

 

Three-Tier Web Design

Once your organization gets serious about e-commerce, you should probably think about a dedicated three-tier design to accommodate the security requirements of the sensitive data that is entrusted to you by your customers. This design basically separates the application and database servers, which were combined on a single platform in the two-tier design. Many financial organizations adopt a three-tier design, as do businesses with large e-commerce presences.

This design generally is separate from the corporate Internet access for employees and general applications such as mail. This separation is shown in Figures 6-24 and 6-25 from Chapter 6, "General Design Considerations." Remember also that this design affords certain flooding attack mitigation benefits, as shown in Figure 6-26 and discussed in the e-commerce-specific filtering section in Chapter 6. Although it is possible to implement a three-tier design with three firewalls as shown in Figure 8-8, using two firewalls as shown in Figure 8-9 is less expensive and loses almost no security benefit.

Figure 8-8. Three-Tier Web Design (Three Firewalls)

Figure 8-9. Three-Tier Web Design (Two Firewalls)

The firewall access control policies to implement this design are as follows. Only the HTTP-related portions of the ACL are shown. Content push and device management are not included here. Depending on your application architecture, the communication between web and applications and applications and database could be over any number of protocols. TCP 80 is assumed in these examples, as is stateful filtering.

Inbound on the FW-1 outside interface:

!Permit outside hosts to talk HTTP/SSL to the web server
access-list 101 permit tcp any host 192.0.2.53 eq 80
access-list 101 permit tcp any host 192.0.2.53 eq 443
!Deny any other web traffic
access-list 101 deny tcp any any eq 80
access-list 101 deny tcp any any eq 443

Inbound on the FW-1 perimeter interface:

!Permit web server to make requests of the apps server
access-list 102 permit tcp host 192.0.2.53 host 192.0.3.12 eq 80
!Deny any web traffic
access-list 102 deny tcp any any eq 80
access-list 102 deny tcp any any eq 443

Inbound on the FW-1 inside interface:

!Deny any web request (the apps server will only be responding to requests
!from the web server, since the firewall is stateful, this is automatically
!allowed where appropriate)
access-list 103 deny tcp any any eq 80
access-list 103 deny tcp any any eq 443

Inbound on the FW-2 outside interface:

!Permit apps server to make requests of the DB server
access-list 101 permit tcp host 192.0.3.12 host 192.0.4.8 eq 80
!Deny any web request
access-list 101 deny tcp any any eq 80
access-list 101 deny tcp any any eq 443

Inbound on the FW-2 perimeter interface:

!Deny any web request (the DB server will only be responding to requests
!from the apps server, since the firewall is stateful, this is automatically
!allowed where appropriate)
access-list 102 deny tcp any any eq 80
access-list 102 deny tcp any any eq 443

Inbound on the FW-2 inside interface:

!Deny any web request (the only traffic which should be allowed from the
!inside network is management and content push traffic. The method of doing
!this is variable and is discussed in Part 4 of this book)
access-list 103 deny tcp any any eq 80
access-list 103 deny tcp any any eq 443