Network Computing

Upcoming Events

Are you caught between a desire for the benefits of the cloud and concerns about security and control? Then you should attend this insight-packed webinar to learn how private data networking technologies like MPLS IP-VPNs can address your concerns and allow you to safely and intelligently reap the savings, agility and other benefits associated with cloud computing.

Join us to hear top industry experts discuss the private data network technologies that are best suited for enterprise cloud access requirements. You won't want to miss this opportunity to learn how your organization can best mitigate risk while reaping the full potential benefits of the cloud.

Register Now!


	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 Constructing a Web site with a high-availability (HA) architecture involves more than a few spare Web servers. The primary goals are to provide lightning-fast failover to other functioning systems and to maintain a Web presence to new consumers and clients. Secondary goals include maintaining TCP and HTTP session state and user data to prevent Web sessions from becoming unproductive. Through the use of load-balancing and HA solutions, Web administrators have accomplished these goals. The hitch is that the solutions are almost entirely proprietary, leading to new difficulties at every turn. 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? Of course, a load-balancer--or any real servers that are being load-balanced--should not sit on the trusted network segment. Susceptible to attacks, a real server on the trusted network can render your trusted network vulnerable in no time. The only acceptable alternatives are to place the load-balancer in front of the firewall or to place it in the DMZ. 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

Research and Reports