At the end of the chapter, we discuss a case study that implements FWLB in a network with multiple secure segments using Cisco's module-based load balancer for the Catalyst 6500 (Cat6500), the Content Switching Module (CSM). Details of the CSM and Catalyst 6500 configurations are included together with an explanation of various key commands.
Reasons for and Benefits of FWLB
In today's data centers, the security of the network, servers and application is a key concern. Together with VPN concentrators, Secure Socket Layer (SSL) offload devices, and intrusion detection devices, firewalls are a vital component of secure data center infrastructures. Firewalls are used not just to protect against malicious or unauthorized access from the public segment but also across multiple demilitarized zones (DMZ) and server segments. When a firewall accepts a packet from one segment, it sends the packet through to the other segment. A firewall can modify a packet before passing it through or can send it through unaltered. When a firewall rejects a packet, it usually drops the packet and logs the dropped packet as an event. After a session is established and a flow of packets begins, a firewall can monitor each packet in the flow or allow the flow to continue unmonitored, depending on the policies configured on that firewall.
There are several motivations behind load-balancing firewalls, the key ones being scalability, redundancy, and manageability.
Scalability
Firewalls are physical devices that exist between network segments, typically in a routed design. They perform stateful inspection of sessions going through them from one segment to the other. Firewalls block or permit sessions based on configured security policies and rules. A firewall has limited resources in terms of link speed, memory, and processor power. These factors determine the capacity and capability of the device in terms of session scalability and raw packet-switching performance.
FWLB is necessary when multiple parallel firewalls are deployed to overcome performance limitations in terms of throughput, session rate, and session capacity. FWLB allows you to scale firewall protection by distributing traffic across multiple firewalls on a per-connection basis. In a load-balanced solution, all packets between a pair of IP addresses for a particular session, in either direction, traverse the same firewall. The firewall then allows or denies transmission of individual packets across its interfaces.
Redundancy
One of the primary reasons for FWLB is high availability of the secure path provided by the firewall. Typical firewalls, like Cisco Private Internet Exchange (PIX) firewall, do provide redundancy capability in active/backup fashion. In these scenarios, one firewall is functional and active while the other is in silent mode. Both the firewalls share an interface IP address, thus enabling continuance of traffic flow in case of a device failure.
FWLB takes the firewall redundancy to the next level by load balancing traffic to a group of active and functional firewalls. A firewall failure is detected within seconds by the load balancer, which takes that specific firewall out of rotation. As long as a single firewall within the load-balanced group is functional, the secure path stays connected.
Manageability
Firewall rule and policy changes have always been a difficult task that requires careful planning and change window allocation. This is because a firewall provides security between the public and secure segment, and an improper change can completely block user access or create a bypass of security. The same difficulty also applies to a firewall software upgrade.
FWLB solves this problem and enables easy management of the devices. Since the firewalls are being load balanced in a group, an individual firewall can be taken out of rotation for management purposes. This ensures that the user traffic is not interrupted by firewall changes.
Firewalls can be taken out of rotation by removing them from the firewall farm configured on the CSM or by blocking the probe sent by the CSM. By blocking or dropping the probe packets, the firewall is taken out of rotation dynamically by the CSM.
Types of Firewalls
As we discussed before, firewalls are physical devices that enforce security policies between network segments. There are several types of firewalls, namely:
- Packet-based firewalls
- Application-based firewalls
- Application gateway or proxy firewalls
- Layer 2 or stealth firewalls
Packet-Based Firewalls
Packet-based firewalls are first-generation devices that enforce policies on per-packet bases. They do not have any concept of session and have no application layer understanding. A simple form of packet-based firewall is an access control list (ACL) on a router. The ACL blocks or permits IP packets based on source or destination IP addresses or both. There are more complex ACLs available now on routers that can provide stateful inspection.
Load balancing of packet-based firewalls is simple because session state is not maintained on a firewall, so potentially the same TCP connection can be load balanced on a per-packet basis across multiple firewalls. In other words, asymmetric flows are allowed in this environment.
Figure 5-1 shows an example of load–balancing packet-based firewalls. Since these firewalls are stateless, a TCP SYN for a particular connection can go through the first firewall while the TCP SYN ACK from the server to the client goes through the the second firewall.
Figure 5-1
Load-Balancing, Packet-Based Firewalls
Application-Based Firewalls
Application-based firewalls that are commonly available now can provide stateful inspection of sessions along with network address translation (NAT) functionality. The PIX and Firewall Services Module (FWSM) on the Catalyst 650000 are application-based firewalls. Similar to hardware-based load balancers, application-based firewalls install permitted session information in hardware memory. These firewalls do not allow any packets through them other than those that belong to the inspected and installed sessions in the firewall.
Load balancing of application-based firewalls is complex, as it requires a particular user session to be sent through the same firewall. In other words, if a client TCP SYN is sent through firewall A to reach the server, the TCP SYN ACK from the server to the client should go through firewall A also. Path symmetry needs to be maintained, and this is typically done by using a source or destination address. A hash of the source and destination address is calculated to maintain the symmetry for the client TCP SYN and server TCP SYN ACK response. We will discuss this further in the case study.
Figure 5-2 shows an example of load balancing application-based stateful firewalls. Notice that a particular TCP connection needs to go through the same firewall in this case.
Figure 5-2
Load-Balancing Application-Based Firewalls
Application Gateway or Proxy Firewalls
Application gateway–based firewalls provide stateful inspection of sessions. They are not only session aware, but are also familiar with the application protocols that create sessions; for example, HTTP, SMTP, and FTP. The application-level gateway does more than just filter packets and sessions. It acts as a gateway between the protected network and the Internet. As a gateway, it does not allow any packets to travel directly between the Internet and the protected network.
Application gateway firewalls proxy all user requests and fetch the data by initiating a new connection to the end server. The end server sees the request coming from the firewall's IP address. The firewall splices the client-side and server-side TCP connection such that the client gets the data from the end server without the Internet-based end server having knowledge of the client's IP address. This functionality looks similar to NAT but is really above and beyond because the firewall is not just hiding the internal client's IP address; it is also implementing application-based security policies.
Application gateway firewalls can be implemented transparently, but most are implemented in a proxy fashion. This is why they are also referred to as proxy firewalls.
Load-balancing proxy firewalls require the load balancing of sessions from the internal network to the Internet only. From the Internet to the internal network, packets always make it to the correct firewall, as the destination IP is the firewall's physical IP. Thus, dynamic symmetry of sessions is ensured.
Figure 5-3 shows an example of load-balancing proxy firewalls. Notice, in this case, the firewall proxies the client requests and then sets up a separate connection to the end server. In this case, a client/server session is load balanced through the same firewall. The firewall proxies the client connection and issues a connection to the Internet server. The client sends the initial request to a VIP on the load balancer, and the request is translated to the firewall IP on VLAN 3.
Figure 5-3
Load-Balancing Proxy Firewalls
Layer 2 or Stealth Firewalls
Layer 2 or stealth firewalls are also known as "bump on the wire" firewalls. These firewalls do not have any IP addresses, and they simply bridge traffic between two segments or VLANs. Both segments or VLANs share the same IP subnet and broadcast domain. In other words, these are undetectable Layer 2 devices that can perform Layer 2 forwarding together with packet and session inspection.
Load balancing stealth firewalls is fairly complex but is supported by the Cisco CSM module. For load-balancing stealth firewalls, the firewalls are connected to unique VLANs on either side—that is, the public or private side. The public-side VLANs connect to a particular CSM pair, and the private or internal VLANs connect to another CSM pair. The firewall bridges traffic between the private and public VLANs. That means, even though they are different VLANs, they are the same broadcast domains. CSMs are configured with alias IP addresses on all VLANs, and they balance traffic across the firewalls by forwarding packets to the remote CSM's alias IP addresses. In other words, the firewall server farm consists of the alias IP addresses on the remote CSM pairs. A stealth firewall is configured so that all traffic moving in both directions across that VLAN moves through the firewall.
Figure 5-4 shows an example of load balancing Layer 2 or stealth firewalls. Notice each Layer 2 firewall exists on a separate VLAN pair and subnet. A VLAN pair (for example, VLAN 2 and VLAN 12) is used to merge a broadcast domain, servicing subnet 10.1.2.0/24.
Figure 5-4
Load-Balancing Stealth Firewalls
Case Study: Firewall Load Balancing
Now that you understand the different types of firewalls and the motivations behind FWLB, you can learn how to deploy a fairly complex FWLB solution over multiple secure segments. When deploying FWLB, it's critical to learn about the applications flows that would be load balanced to the firewall, whether they are outbound to the Internet or inbound to the DMZ. Applications that require multiple connections, also called buddy connections, such as FTP, need to be considered and accounted for in the design. For these applications, you need to ensure that both the connections belonging to the same user session go through the same firewall.
In this case study, we will examine a specific customer deployment where CSM is used to load balance firewalls with three secure segments, namely an INET, a DMZ, and a LAN segment. The idea behind the following case study is to understand not only the concepts but the implementation details. To fully understand the sample deployment, we will look at:
- Server and application requirements
- Security requirements
- Infrastructure requirements
- Design options
- Test and verification
Server and Application Requirements
Server and application requirements for this case study are defined as follows:
- The servers should be directly managed in the DMZ from management stations in the LAN segment.
- Servers should also be able to initiate sessions for application software patches and driver upgrades.
- The number of servers in the DMZ is about 300.
- The primary application that is being load balanced in the DMZ is HTTP and HTTPS based.
- Persistence is needed for the HTTPS-based application.
- TCP-based probes are OK.
- Direct access to the DMZ servers from the LAN is made using long-lived flows a minimum of three hours of idle timeout.
- FTP is used between LAN and DMZ segment servers.
Security Requirements
The security requirements for this case study are as follows:
- The main requirement is to load balance flows to the firewalls from all the three segments.
- It is critical that each network path through the firewall be verified before sending connections over it; that is, a LAN's user traffic should only be sent toward the DMZ over a firewall that has its DMZ segment interface functional.
- FTP and other applications with multiconnections should be sent across the same firewall.
- High availability is critical.
- Firewalls do not share state tables; that is, each firewall is unaware of the session states of the other firewalls.
Source: http://docphy.com/technology/computers/software/chapter-5-firewall-load-balancing.html
No comments:
Post a Comment