11.5 PROTECTION AGAINST DENIAL OF SERVICE

Team-Fly

In Chapter 3, we introduced and briefly discussed the TCP SYN flooding attack. In this attack, a number of TCP SYN messages are sent to a server to flood its backlog queue. Unfortunately, this attack is always possible and protection against it requires some major modifications in TCP and the way TCP connections are established (e.g., the use of SYN cookies). These modifications will take some time to be specified, standardized, implemented, and deployed. When they become available, it is strongly recommended to install them on all systems as soon as possible.

In the meantime, there are ad hoc solutions offered by some firewall vendors. For example, CheckPoint Software Technologies, Ltd., offers a tool called SYNDefender for its FireWall-1 customers. In fact, the SYNDefender provides two different solutions for the problem of protecting internal systems against TCP SYN flooding attacks: SYNDefender Relay and SYNDefender Gateway.

The SYNDefender Relay protects an internal system by making sure that a three-way TCP connection establishment handshake with an external host is completed (i.e., the connection is valid) before an initial SYN message is sent to the internal system. More specifically, the SYNDefender Relay that resides on the firewall and receives a SYN message from an external system returns a SYN-ACK message to that system. The external system must then finish the connection establishment with an ACK message, before the SYNDefender Relay establishes a secondary TCP connection to the internal system on the external system's behalf. From then on, the SYNDefender Relay simply relays data between the two TCP connections back and forth. The corresponding message flows are illustrated on the top of Figure 11.7. Note that one of the key capabilities the SYNDefender Relay employs is the ability to translate the sequence numbers, which are now different for either connection.

click to expand
Figure 11.7: Message flows of the SYNDefender Relay and the SYNDefender Gateway.

For the resetting of SYN connection attempts to be effective against the TCP SYN flooding attack, the reset timer must be small enough to keep the internal system's backlog queue from filling up, while at the same time being big enough to allow users coming over slow links to connect. The SYNDefender Gateway solution surmounts this problem by making sure that an ACK message is sent in immediate response to the internal system's SYN-ACK message. When the internal system receives the ACK message, the connection is moved out of the backlog queue and becomes an open connection. Again, the SYNDefender Gateway resides on the firewall. Whenever it receives a SYN message from an external system, it simply forwards the message to the internal system. The internal system, in turn, sends back a SYN-ACK message that the SYNDefender Gateway forwards to the external system. In addition, the SYNDefender Gateway returns an ACK message to the internal system to establish the connection. If a proper ACK message from the external system is received within a certain time frame, the destined connection is established and the SYNDefender Gateway simply relays data back and forth. If, however, the SYNDefender Gateway does not receive a proper ACK message from the external system, it closes the connection by sending an RST message to the internal system. The message flows of the SYNDefender Gateway are illustrated at the bottom of Figure 11.7.

The main advantage of the SYNDefender Relay is that the internal system will not receive any invalid connection establishment request. If the host has limited memory or often reaches an overloaded state, then the SYNDefender Relay's filtering of invalid connection establishment requests might be advantageous in the event of an attack. Users making connections to an internal system may, however, experience a slightly longer connection setup time, which is not the case with the SYNDefender Gateway solution.

Team-Fly