Method for Protecting a Firewall Load Balancer From a Denial of Service Attack

Abstract

A method for protecting firewall load balancers from a denial of service attack is provided. Packets are received by the firewall load balancer. Each packet has a source and a destination. The firewall load balancer is equipped with a connection database that can contain entries about the packets. Upon receipt of a packet, the connection database is queried to determine whether or not there is an entry for the received packet. If an entry is found in the database, the packet is forwarded to its destination. Otherwise, if the packet was received from a firewall, then a new connection entry for the packet is built and is saved to the connection database and the packet is forwarded on to its destination. If the packet does not have an entry (match) in the connection database and the packet was not received from a firewall, then the packet is forwarded to a firewall.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and its advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of the system configuration of the present invention;

FIG. 2 is a flowchart illustrating an embodiment of the method of the present invention;

FIG. 3 is a flowchart illustrating an alternate embodiment of the method of the present invention;

FIG. 4 is a flowchart illustrating an alternate embodiment of the method of the present invention;

FIG. 5 is a block diagram of a 5-tuple element of the connection database of the present invention; and

FIG. 6 is a flowchart illustrating a decision tree of the method of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention deals with the routing of messages on a network. To prevent delay, buffer overflows, or congestion, long messages are broken into shorter bit strings called packets. These packets can then be transmitted though the network as individual entities and reassembled into messages at the destination. Thus, packets have a source (the device that generated the packet) and a destination.

The configuration of the present invention is illustrated in FIG. 1. As shown in FIG. 1, an array of servers 20 are used to service requests from clients 30, 32, and 34. In general, messages in the form of one or more inbound packets are transmitted from, for example, client 30 through the wide-area network 28 to the inbound firewall load balancer 26. Depending upon the workload of the various firewalls 24 that make up the firewall bank, the inbound firewall load balancer will direct the inbound packet to one of the firewalls 24. The firewall will perform its functions and forward the inbound packet to the outbound firewall load balancer 22, which will then forward the inbound packet to one of the servers 20 for processing.

Once the request has been serviced, the response is transmitted from the server to the client as follows. The response, in the form of one or more outbound packets, is transmitted first to the outbound firewall load balancer 22. From there, the outbound packets will typically be forwarded to the same firewall 24 that serviced the packets of the inbound request. Once processed by the firewall 24, the outbound packet will be forwarded to the inbound firewall load balancer 26 and then on to the wide-area network 28 (such as the Internet) and arrives at the client machine 30.

Both firewall load balancers of the present invention have their own connection databases. Specifically, the outbound firewall load balancer 22 is in operative communication with the outbound connection databases 23 and the inbound connection database 27 is in operative communication with the inbound firewall load balancer 26. These databases are used in conjunction with the method of the present invention (described below). It should be noted that the two connection databases 23 and 27 can be consolidated into a single database. However, in doing so, one may have to breach the security provided by the firewalls 24 that protect the servers 20 because the same connection database would have to service both the outbound firewall load balancer 22 and the inbound firewall load balancer 26 which are on opposite sides of the firewall. Security would not necessarily be breached, however, if only very specific signals are sent to/from the single connection database.

While the methods of the present invention can be implemented entirely in software, it is understood by those skilled in the art that the methods of the present can be implemented in either hardware or software, or any combination thereof. For instance, the apparatus of the present invention can be logic that is encoded in media which is operable with the various processors and other subsystems of the apparatus of the present invention to implement the methods of the present invention. Similarly, application specific integrated circuits (ASICs) can be used to implement various steps of the methods of the present invention.

For purposes of this disclosure, “packets” are intended to have their normal meaning, for example, a unit of information that is transmitted in a packet switched network. Typically, each packet has a packet header within which are recorded routing information in the form of, e.g., an origin IP address and a destination IP address. A “flow” is a series of packets that are sent from one entity (such as a server) to another entity (such as a client). Finally, a “connection” designates two flows, one in each direction, between the same two entities. The connection databases 23 and 27 of the present invention record the connections made between various entities.

There are various packet destination scenarios that should be considered when using the method and apparatus of the present invention. When a packet comes to a firewall loadbalancer, it is desirable to know the direction of the packet (either to or from a firewall) and if there have been other packets for this particular flow. The connection database is queried to determine whether or not other packets for that flow have been processed previously. There are four separate scenarios that must be addressed. The various scenarios depend upon whether the packet is going to or coming from a firewall and whether or not there is a record of the flow in the connection database. These scenarios, and the action needed, are summarized in Table 1.

	TABLE 1
	Packet	Flow Recorded
	From	in Connection
	Firewall?	Database?	Action Needed
	No	No	Forward the packet to a firewall
			that is determined by a stateless
			firewall loadbalancing algorithm.
	No	Yes	Forward the packet as defined by
			the connection object in the
			connection database.
	Yes	No	Build a connection object in the
			connection database and forward
			the packet towards the destination
			IP address in the packet.
	Yes	Yes	Forward the packet as defined by
			the connection object in the
			connection database.

The scenarios of Table 1 can be illustrated more fully by the flowchart of FIG. 6. Specifically, FIG. 6 illustrates a decision tree method that is explained below. As shown in FIG. 6, the method starts at step 602. The first decision is taken at step 604, where a determination is made if the packet in question has been processed by a firewall. If so, then execution continues to step 606 where a determination is made whether the flow to which the packet is a part has been recorded in the connection database. This determination is accomplished by querying the connection database for a connection object matching various parameters contained within the packet header. If so, then the packet is forwarded as defined by the relevant connection object that was found in the connection database query, step 608, and the method is terminated at step 618.

If the packet has not been processed by a firewall (i.e., the result of step 604 is no), then execution jumps to step 612, where a determination is made if the flow to which the packet is a part has been recorded in the connection database. If so, then execution continues to step 614 where the packet is forwarded as defined by the connection object in the connection database. If not, then the packet is labeled as “stateless loadbalance” and the packet is forwarded to a firewall, step 616. Step 616 is generally taken when a packet is received from the wide-area network 28 (of FIG. 1) for the first time. In an embodiment of the present, a stateless algorithm is used to designate a particular firewall that will handle not only the packet in question, but all packets of the flow pertaining to that packet. The stateless algorithm is a load balancing algorithm that does not require the loadbalancer to store information about assigned connections. Any subsequent packets on these connections will produce the same loadbalancing result. Specifically, when the first packet (of a flow) is received from the Internet, the stateless algorithm is used for choosing the firewall that will be used for this and subsequent packets in the same flow. The stateless algorithm of the present invention bases its choice of firewall only on the information that is contained within the packet. The stateless algorithm of this embodiment of the present invention uses either 1) the source and destination IP addresses or 2) the source and destination IP addresses as well as the source and destination port numbers. It is important to note that this information is not saved or recorded. Consequently, no storage space is devoted to packets that get rejected by the firewall. Moreover, once the connection has been recorded (by creation of a connection object within the connection database), few resources are devoted to additional packets for that connection. It is these features that enable the firewall load balancers of the present invention to conserve resources and thus diminish and mitigate the effects of a denial of service (DoS) attack.

The connection databases 23 and 27 can use a wide variety of database engines. The best ones for the intended purpose will have fast performance and require relatively modest storage requirements. The databases will have to have the capacity to retain the desired number of 5-tuple values. The database can optionally use the 5-tuple values as a database key for database queries. The five elements of the 5-tuple consist of, for example, a source address, a destination address, a source port number, a destination port number, and a protocol identifier. Additional values can be stored to expand the functionality of the present invention. Likewise, the 5-tuple value can be reduced for increased performance and/or increased storage capacity by eliminating some of the values like, for instance, the destination port number and the source port number (although this isn't recommended). The latter embodiment is useful for specific functions where the port numbers can be assumed with confidence, albeit with reduced flexibility. For example, standard web port numbers typically are 80 (http) for non-secure web requests mail and 443 (https) for secure web requests. A web request is an example of a “sticky” transaction. A sticky transaction is one that is opened by the client, such as, an inbound request to a server and a corresponding outbound response to the client that sent that request. Thus, in the latter example, a 2-tuple value can be used because the protocol and port numbers are presumed and only the source and destination addresses need be retained.

The structure of the 5-tuple value that is the preferred embodiment of the value of the present invention is illustrated in FIG. 5. The tuple value 500 contains a source address 502, a destination address 504, a source port 506, a destination port 508, and a protocol element 510. The 5-tuple value yields maximum utility with a minimum amount of information. Unlike the 2-tuple value mentioned previously, the 5-tuple value enables dynamic port addressing and the use of multiple protocols (e.g., TCP and UDP). The size or storage capacity of the various elements can be modified to suit the situation. It is recommended, however, that some extra space be included to accommodate future growth as addresses are expected to get longer as more and more traffic and nodes are added to the Internet and the conversion from IPv4 to IPv6 takes place.

In some embodiments of the present invention, it is necessary only to know if the packet came from a firewall before it arrived at the firewall load balancer of the present invention. In alternate embodiments, it is important to know if the packet is destined for a firewall after leaving the firewall load balancer. Consequently, in several embodiments of the present invention, checks are made to determine whether or not the packet has been processed from a firewall or is destined for a firewall. In this case, if a firewall has previously processed the packet in question, then that packet is deemed to have had a “firewall origin,” even though the device that created the packet may not be a firewall. Similarly, if a packet has a routing header such that either a firewall is its next or subsequent hop, then the packet is considered to have a “firewall destination,” even though the ultimate destination of the packet may not be a firewall.

An embodiment of the method of the present invention is summarized in FIG. 4. Referring to FIG. 4, the process starts at step 402. A packet is received by the firewall load balancer in step 404. A check is made to determine if the packet has been processed previously by one of the system's firewalls in step 406, i.e., a check is made to determine if the packet has a “firewall origin.” Note, this check applies regardless of whether or not the source of the packet originated from one of the system's own servers or from a source outside of the firewall. If the packet has not yet been serviced by a firewall, the packet is sent to a firewall in step 414. Otherwise, a second check by the firewall load balancer is made to determine whether or not an entry (5-tuple value) has been made in the firewall load balancer's connection database for the packet in step 408. If an entry for the packet has not been found in the connection database, an entry is made in the firewall load balancer's connection database in step 410. If an entry for the packet existed, or if the entry was just created (step 410), then the packet is forwarded to its destination (i.e., to the next hop or to the destination), step 412. After either step 412 or step 414, the process ends in step 416. The rationale for making the database entry only after a firewall has had a chance to process the packet is that if the firewall drops the packet (for whatever reason), the firewall load balancer would be relieved of the need to devote resources (memory and execution cycles) for the packet in the connection database. It is this relief that provides the firewall load balancer a measure of protection from a denial of service attack.

An alternative method of the present invention is illustrated in FIG. 2. Referring to FIG. 2, the process starts at step 202. A packet is received by the firewall load balancer at step 204. Thereafter, the firewall load balancer makes a check during step 206 to determine if there is an entry in the connection database for the packet. If an entry exists (i.e., the packet has been through a firewall at least once), then execution skips to step 214 and the packet is sent to its destination or to the next hop. Otherwise, step 208 is performed wherein a check is made to determine if the packet was sent from a firewall (if the packet has a firewall origin). If it has a firewall origin, then an entry is made for the packet in the firewall load balancer's connection database, step 210, and the packet is thereafter sent to its destination or to the next hop in step 214. However, if the packet was not sent from a firewall, and there is no entry in the firewall load balancer's connection database, then the packet is directed to a firewall in step 212. Execution ends in step 216 as illustrated in FIG. 2.

An alternative method of the present invention is illustrated in FIG. 3. Referring to FIG. 3, the process begins at step 302. In this case, the packet is received from a common packet filter (“CPF”) or from switching vectors in step 304. If the packet has a match in the connection database, step 306, then no further processing is needed and the packet is sent to the firewall or to the outside network in step 320. However, if the packet doesn't have a matching entry in the connection database, then a determination is made whether or not the packet is either going to, or coming from, a firewall, step 308. If the packet did not come from a firewall (meaning that the packet does not have a firewall origin) and it is not destined for a firewall, then the packet is routed normally in step 318. Otherwise, a determination is made whether the packet came from a firewall, i.e., whether the packet has a firewall origin in step 310. If the packet did not come from a firewall, then step 312 is performed where a hash or sticky is made to the firewall connection database and the packet is thereafter sent to the firewall or to the outside network in step 320. If the packet did come from a firewall, then a check is made to determine if the media access control (“MAC”) address of the firewall was resolved, step 314. If so, then a connection object is created and stored in the connection database, step 316, and the packet is sent off to the outside network, step 320. If the MAC address of the firewall was not resolved, then the packet is routed normally, step 318. In any case, execution ends in step 322.

The present invention, therefore, is well adapted to carry out the objects and attain both the ends and the advantages mentioned, as well as other benefits inherent therein. While the present invention has been depicted, described, and defined by reference to particular preferred embodiments of the invention, such references do not imply a limitation on the invention, and no such limitation is to be inferred. The invention is capable of considerable modification, alternation, alteration, and equivalents in form and/or function, as will occur to those of ordinary skill in the pertinent arts. The depicted and described preferred embodiments of the invention are exemplary only and are not exhaustive of the scope of the invention. Consequently, the invention is intended to be limited only by the spirit and scope of the appended claims, giving full cognizance to equivalents in all respects.

Claims

1. (canceled)

2. (canceled)

3. (canceled)

4. (canceled)

5. (canceled)

6. (canceled)

7. An apparatus, comprising: an outbound firewall load balancer that is operable to receive a packet and to determine whether the packet is associated with an open connection such that resources are being consumed as reflected by an entry in an outbound connection database, wherein if the entry is not present in the outbound connection database then a new entry is not recorded for the outbound firewall load balancer, and wherein the packet is forwarded to a selected one of a plurality of firewalls coupled to the outbound firewall load balancer in the case where the entry is present in the outbound connection database, the packet being received by the selected firewall and then communicated to an inbound firewall load balancer, the inbound firewall load balancer being further operable to generate a new entry for the packet once it has received it from the selected firewall, the new entry being provided in an inbound connection database such that resources for the inbound firewall load balancer are then being consumed for an open flow associated with the packet.

8. The apparatus of claim 7, wherein the selected firewall is operable to determine if the packet is associated with malicious traffic and to discard the packet such that it is not communicated to the inbound firewall load balancer in a case where the packet is associated with malicious traffic.

9. The apparatus of claim 7, wherein the outbound firewall load balancer is coupled to one or more servers that are operable to deliver content to the outbound firewall load balancer.

10. The apparatus of claim 7, wherein the inbound firewall load balancer is operable to deliver the packet to a computer that is operable to respond to the packet and that is associated with the open connection.

11. The apparatus of claim 7, wherein if the packet is not associated with an open connection, the outbound firewall load balancer is operable to select one of the firewalls to direct the packet to based on a hash algorithm.

12. The apparatus of claim 7, wherein the inbound firewall load balancer is operable to receive an additional packet from one or more computers that are coupled to the inbound firewall load balancer, the inbound firewall load balancer being coupled to an inbound connection database.

13. The apparatus of claim 12, wherein the inbound firewall load balancer is operable to access the inbound connection database in order to see if there is an open connection associated with the additional packet, and wherein if there is not an open connection for the additional packet then a new entry in the inbound connection database is not made.

14. A method for enlisting one or more end users in a network environment in which loadbalancing occurs, comprising: enlisting one or more end users in a billing plan associated with network communications;generating a bill associated with one or more of the end users, the bill being based on the billing plan; andfacilitating network communications for one or more of the end users in response to the end users being enlisted in the billing plan, whereby the network communications includes a protocol that comprises: receiving a packet at an outbound firewall load balancer;determining whether the packet is associated with an open connection such that resources are being consumed as reflected by an entry in an outbound connection database, wherein if the entry is not present in the outbound connection database then a new entry is not recorded for the outbound firewall load balancer; andforwarding the packet to a selected one of a plurality of firewalls coupled to the outbound firewall load balancer in the case where the entry is present in the outbound connection database, wherein the packet may be received by the selected firewall and then communicated to an inbound firewall load balancer, wherein the inbound firewall load balancer is operable to generate a new entry for the packet once it has received it from the selected firewall, the new entry being provided in an inbound connection database such that resources for the inbound firewall load balancer are then being consumed for an open flow associated with the packet.

15. The method of claim 14, wherein the selected firewall is operable to determine if the packet is associated with malicious traffic and to discard the packet such that it is not communicated to the inbound firewall load balancer in a case where the packet is associated with malicious traffic.

16. The method of claim 14, wherein the outbound firewall load balancer is coupled to one or more servers that are operable to deliver content to the outbound firewall load balancer.

17. The method of claim 14, wherein the inbound firewall load balancer is operable to deliver the packet to a computer that is operable to respond to the packet and that is associated with the open connection.

18. The method of claim 14, wherein if the packet is not associated with an open connection, the outbound firewall load balancer is operable to select one of the firewalls to direct the packet to based on a hash algorithm.

19. The method of claim 14, wherein the inbound firewall load balancer is operable to receive an additional packet from one or more computers that are coupled to the inbound firewall load balancer, the inbound firewall load balancer being coupled to an inbound connection database.

20. The method of claim 19, wherein the inbound firewall load balancer is operable to access the inbound connection database in order to see if there is an open connection associated with the additional packet, and wherein if there is not an open connection for the additional packet then a new entry in the inbound connection database is not made.

21. Software for communicating data, the software being embodied in a computer readable medium and comprising computer code such that when executed is operable to: receive a packet at an outbound firewall load balancer;determine whether the packet is associated with an open connection such that resources are being consumed as reflected by an entry in an outbound connection database, wherein if the entry is not present in the outbound connection database then a new entry is not recorded for the outbound firewall load balancer; andforward the packet to a selected one of a plurality of firewalls coupled to the outbound firewall load balancer in the case where the entry is present in the outbound connection database, wherein the packet may be received by the selected firewall and then communicated to an inbound firewall load balancer, wherein the inbound firewall load balancer is operable to generate a new entry for the packet once it has received it from the selected firewall, the new entry being provided in an inbound connection database such that resources for the inbound firewall load balancer are then being consumed for an open flow associated with the packet.

22. The medium of claim 21, wherein the code is operable to determine if the packet is associated with malicious traffic and to discard the packet such that it is not communicated to the inbound firewall load balancer in a case where the packet is associated with malicious traffic.

23. The medium of claim 21, wherein the outbound firewall load balancer is coupled to one or more servers that are operable to deliver content to the outbound firewall load balancer.

24. The medium of claim 21, wherein the code is operable to deliver the packet to a computer that is operable to respond to the packet and that is associated with the open connection.

25. The medium of claim 21, wherein if the packet is not associated with an open connection, the code is operable to select one of the firewalls to direct the packet to based on a hash algorithm.

26. The medium of claim 21, wherein the code is operable to receive an additional packet from one or more computers that are coupled to the inbound firewall load balancer, the inbound firewall load balancer being coupled to an inbound connection database.

27. The medium of claim 26, wherein the code is operable to access the inbound connection database in order to see if there is an open connection associated with the additional packet, and wherein if there is not an open connection for the additional packet then a new entry in the inbound connection database is not made.