|W O R K S H O P|
Firewall & Load-Balancer: Perfect Union?
February 7, 2000
By Gregory Yerxa
At The Internet Security Conference recently, we participated in a panel discussion on the merits of load-balancing in the enterprise and the security issues involved. The audience's barrage of questions and wealth of configuration scenarios made it apparent that load-balancing has grown from a simple scalability solution to a core requirement for high-availability Web sites. With this growth has emerged a new urgency for security features, such as SSH, SSL and SecureSNMP.
Not surprisingly, many audience members asked the panel about integrating firewall services with load-balancers. The panel's response was decisive: Integrating a firewall appliance into a load-balancer or vice versa creates more problems than it solves. Combining the specialized functionality of both products--not to mention trying to create a single point of failure--is difficult. Segmenting the processes allows for additional fine-tuning of performance parameters and configuration problems. With much depending on Web-site availability and performance, Web and network administrators should rely on two separate entities.
We look at basic configuration scenarios involving a distributed Web site, as well as how incorporating a firewall or security tool can affect design choices and configuration. These scenarios show variations on firewall placement relative to the location of the load-balancers and real servers, which are the end Web servers servicing Web requests.
Semiotics of High Availability
There is no standard in wide use for communicating state information from one load-balancer to another. Some load-balancing vendors have started work on other communication protocols, such as the Network Element Control Protocol. NECP is extensible, so it can be used in a distributed environment and may be used with firewalls. With heavyweight support from Alteon WebSystems, F5 Networks, Network Appliance, Novell and RadWare, among others, NECP could mature into the de facto communication protocol for all load-balancing implementations (see "Leveraging the Network Element Control Protocol," page 86). NECP presents an interesting opportunity for collaboration between product spaces. If firewalls, Web caches, load-balancers and real servers communicate proactively, failures can be avoided or circumvented more quickly.
First Line of Defense?
The former option is easier to configure but renders the system more open to attack. A load-balancer in front of the firewall is the first line of defense. It is more susceptible to DOS (denial-of-service) attacks and compromises via telnet and SNMP than any mature firewall solution. Only a few load-balancers have built-in anti-DOS-attack measures, such as IP filtering and SYN-attack detection. A load-balancing solution should not play a central role in any security posture.
Making matters worse, distributed load-balancing sites have an even greater concern: Distributed sites use proprietary communication protocols, as well as traditional DNS services, between locations. These protocols are used to communicate site load and availability, as well as redirect incoming traffic. If an attacker can see these protocols, he or she can reverse-engineer them and use them to construct a DOS attack by making the entire site seem out of service or overloaded. Fortunately, a few load-balancing vendors employ some level of security beyond their already obscure distributed protocols. F5 Networks leverages an encrypted protocol, called iQuery, that uses the Blowfish algorithm and a 56-bit exportable grade key. RadWare uses a proprietary checksum similar to a digital signature, and also is developing a method to encrypt the entire protocol.
Your firewall configuration could become more complicated as you add and remove services from your load-balancer configuration. Adding a Web site or real server to your load-balancer could entail adding security policies to your firewall. With real servers in the DMZ, you also need to configure the firewall to permit proprietary server protocols from the load-balancer to the real servers. Between the more-susceptible load-balancing configuration and the necessary additional firewall policies, most network administrators will opt to place the load-balancer outside of the firewall in the DMZ.
|PAGE: 1 I 2 I 3 I NEXT PAGE|