Successive Multiple Connections
FIGURE 1-42Successive Events — Successive Multiple Connections page
Action — Select the appropriate tracking option.
To configure when the tracking option specified under Action will be taken, click Advanced to display the Advanced Configuration window (FIGURE 1-38 on page 54).
SYN Attacks and SYNDefender
The TCP Three-Way Handshake
TCP (Transport Control Protocol) is a connection-oriented, reliable transport protocol. Two participating hosts must first establish a connection by a three-way handshake between them. TCP assigns sequence numbers to every byte in every segment and acknowledges all data bytes received from the other end.
Successive Multiple Connections
For example, if host A wants to establish a connection with host B, A begins by sending a SYN packet (a TCP packet with the SYN bit set) to B. B replies with a SYN/ACK packet (a TCP packet with the SYN and ACK bits set). A completes the three-way hand-shake with a TCP ACK packet.
FIGURE 1-43TCP SYN handshake
When B receives the SYN packet, it allocates substantial memory for the new connection. If there were no limit to the number of connections, a busy host would quickly exhaust all of its memory trying to process TCP connections. However, there is usually a small upper limit to the number of concurrent TCP connection requests (“backlog queue”) a given application can have running on the host.
There is an upper limit for each server program (depending on the configuration) of outstanding unacknowledged (un-ACK’d) connection requests. When the backlog queue limit is reached, an attempt to establish another connection will fail until one of the backlogged connection either becomes established (SYN/ACK packet is ACK’d), is reset (a RST packet is received) or times out.
How the Attack Works
A client initiates a TCP connection by a request with the SYN flag set in the TCP header. Normally the server replies with a SYN/ACK identified by the source IP address in the IP header. The client then sends an ACK to the server (FIGURE 1-43 on page 59) and data exchange begins.
When the source IP address is spoofed (changed) to that of an unreachable host, the targeted TCP cannot complete the three-way hand-shake and will keep trying until it times out. This is the basis for the SYN flood attack.
The attacking host (Z) sends a small number (less than 10 is sufficient) of SYN requests to the target TCP port (for example, the Web server). The attacking host also spoofs the source IP address as that of another (Z’), currently unreachable host. The process is depicted in FIGURE 1-44. Internet
A
SYN SYN/ACK ACKB
SYN Attacks and SYNDefender
FIGURE 1-44SYN Attack
The source IP address (Z’) must be unreachable because the attacker does not want any host to receive the SYN/ACKs from the target TCP, which would elicit a RST from that host (an RST packet is issued when the receiving host does not know what to do with a packet) and thus foil the attack (FIGURE 1-45).
FIGURE 1-45The SYN Attack unsuccessful, because Z’ is reachable
Instead, until the SYN requests time out, A will not accept any connection requests. If the attacks were, for example, against A’s Web server, then that Web server will be inaccessible for some two minutes as a result of an attack that lasted less than one second.
Internet
These packets are sent by Z but "spoofed" so that they seem to come from
Z' - an IP address unreachable A replies to Z'
Z
Z'
Z'
Z'
Z'
Z'
Z'
Z'
Z'
Z'
SYN SYN SYN SYN SYN SYN SYN SYN/ACK SYN/ACKA
2
1
Internet A replies to Z' Z Z' Z' Z' Z' Z' Z' Z' Z' Z' Z' Z' SYN SYN SYN SYN SYN SYN SYN RST RST SYN/ACK SYN/ACK A These packets are sent by Z but "spoofed" so that they seem to come fromZ' - a IP address reachable 1 2 Z' resets the connection and
the attack is unsuccesful
Successive Multiple Connections
VPN-1/FireWall-1 SYNDefender
Check Point’s SYNDefender provides three different approaches for defending against a SYN flooding attack:
• SYN Gateway (supported only for pre-NG VPN/FireWall Modules) • Passive SYN Gateway
• SYN Relay (not supported for pre-NG VPN/FireWall Modules)
All these solutions are integrated into the VPN/FireWall Module, which intercepts all packets before they are observed by the operating system and performs Stateful Inspection on these packets. The system administrator can choose which of the solutions is best suited to a particular environment.
SYN Gateway
In order for the resetting of SYN connection attempts to be effective against the SYN flooding attack, the reset timer must be short enough to keep A’s backlog queue from filling up, while at the same time long enough to enable users coming over slow links to connect. The SYN Gateway solution counters the attack by ensuring that an ACK packet is sent in immediate response to A’s SYN/ACK packet.
When A receives the ACK packet, the connection is moved out of the backlog queue and becomes an open connection on A. Internet servers can typically handle hundreds or thousands of open connections, so the SYN flooding attack is no more effective in creating a denial of service condition than a hacker trying to establish an excessive number of valid connections to the server. The backlog queue is effectively kept clear and it is possible to wait longer before resetting connections which have not been completed.
SYN Attacks and SYNDefender
FIGURE 1-46SYN Gateway
1 VPN-1/FireWall-1 intercepts a SYN packet going to host A and records the event in an INPSPECT state table.
2 VPN-1/FireWall-1 lets the SYN packet continue on to A.
3 VPN-1/FireWall-1 intercept A’s SYN/ACK reply to Z and correlates with the corresponding SYN packet sent by Z.
4 VPN-1/FireWall-1 lets the SYN/ACK continue on its way to Z.
5 VPN-1/FireWall-1 sends an ACK packet to A, which moves the connection out of A’s backlog queue.
6 At this point, one of two things will happen, depending on whether the connection attempt is valid.
a If Z’s connection attempt is valid, then VPN-1/FireWall-1 will receive an ACK from Z which it will pass on to A.
A ignores this second redundant ACK since the three-way handshake has already been completed.
b If Z’s IP address does not exist, then no ACK packet will return from Z to A and the reset timer will expire. At this point, VPN-1/FireWall-1 resets the connection.
The effectiveness of the SYN Gateway solution is based on quickly moving connection attempts out of the backlog queue. SYN flood connection attempts then fail to fill up
Internet
Z
SYN SYN ACK ACK RST ACK SYN/ACK SYN/ACKA
5
4
6a
6b
3
2
1
FireWalled Gateway No ACK receivedSuccessive Multiple Connections
Passive SYN Gateway
Passive SYN Gateway is similar to SYN Gateway, except that VPN-1/FireWall-1 does not simulate Z’s ACK packet to A, and instead waits for Z’s ACK before passing it on to A.
The unacknowledged connection remains in A’s backlog queue, but times out after VPN-1/FireWall-1’s timeout period, which is much shorter than the backlog queue’s timeout period.
FIGURE 1-47 depicts Passive SYN Gateway.
FIGURE 1-47Passive SYN Gateway
SYN Relay
The SYN flooding attack sends SYN packets with the source addresses of unreachable hosts which will not reply to SYN/ACK packets. SYN Relay counters the attack by making sure that the three way handshake is completed (that is, that the connection is a valid one) before sending a SYN packet to the connection’s destination (A). SYN Relay is a high-performance kernel-level process which acts as a relay mechanism at the connection level. FIGURE 1-48 depicts SYN Relay.
SYN SYN ACK RST ACK SYN/ACK
4
SYN/ACK5a
5b
3
2
1
No ACK received InternetZ
A
FireWalled GatewaySYN Attacks and SYNDefender
FIGURE 1-48SYN Relay
1 VPN-1/FireWall-1 intercepts a SYN packet going to host A.
2 VPN-1/FireWall-1 does not pass the SYN packet to A, but rather acts on A’s behalf and replies with a SYN/ACK packet to Z.
3 If an ACK packet is received from Z, then ...
• VPN-1/FireWall-1 sends a SYN packet to A.
• A replies with a SYN/ACK packet.
• VPN-1/FireWall-1 replies with an ACK packet.
At this point the connection from Z to A is established and VPN-1/FireWall-1 is able to begin passing packets between Z and A. SYNDefender correctly translates the connection sequence numbers, which are now different for each half of the connection.
If VPN-1/FireWall-1 does not receive a packet for several seconds during any of the above steps, or if it receives a RST when an ACK or SYN/ACK are expected, it terminates the connection immediately.
Note that if Z contacts an unavailable server on A, it will first connect and then get a RST, which is not normal but harmless.