Firewall > TCP Settings
440
SonicOS Enhanced 4.0 Administrator Guide
A SYN Flood attack is considered to be in progress if the number of unanswered SYN/ACK
packets sent by the SonicWALL (half-opened TCP connections) exceeds the threshold set in
the “Flood rate until attack logged (unanswered SYN/ACK packets per second)” field. The
default value for the field is 20, the minimum is 5, and the maximum is 999,999.
Understanding a TCP Handshake
A typical TCP handshake (simplified) begins with an initiator sending a TCP SYN packet with
a 32-bit sequence (SEQi) number. The responder then sends a SYN/ACK packet
acknowledging the received sequence by sending an ACK equal to SEQi+1 and a random, 32-
bit sequence number (SEQr). The responder also maintains state awaiting an ACK from the
initiator. The initiator’s ACK packet should contain the next sequence (SEQi+1) along with an
acknowledgment of the sequence it received from the responder (by sending an ACK equal to
SEQr+1). The exchange looks as follows:
1. Initiator -> SYN (SEQi=0001234567, ACKi=0) -> Responder
2. Initiator <- SYN/ACK (SEQr=3987654321, ACKr=0001234568) <- Responder
3. Initiator -> ACK (SEQi=0001234568, ACKi=3987654322) -> Responder
Because the responder has to maintain state on all half-opened TCP connections, it is possible
for memory depletion to occur if SYNs come in faster than they can be processed or cleared by
the responder. A half-opened TCP connection did not transition to an established state through
the completion of the three-way handshake. When the SonicWALL is between the initiator and
the responder, it effectively becomes the responder, brokering, or proxying, the TCP
connection to the actual responder (private host) it is protecting.
SYN Flood Protection Methods
The following sections detail some SYN Flood protection methods.
SYN Flood Protection Using Stateless Cookies
The method of SYN flood protection employed starting with SonicOS Enhanced uses stateless
SYN Cookies, which increase reliability of SYN Flood detection, and also improves overall
resource utilization on the SonicWALL. With stateless SYN Cookies, the SonicWALL does not
have to maintain state on half-opened connections. Instead, it uses a cryptographic calculation
(rather than randomness) to arrive at SEQr.
Layer-Specific SYN Flood Protection Methods
SonicOS Enhanced provides several protections against SYN Floods generated from two
different environments: trusted (internal) or untrusted (external) networks. Attacks from
untrusted WAN networks usually occur on one or more servers protected by the firewall.
Attacks from the trusted LAN networks occur as a result of a virus infection inside one or more
of the trusted networks, generating attacks on one or more local or remote hosts.
To provide a firewall defense to both attack scenarios, SonicOS Enhanced provides two
separate SYN Flood protection mechanisms on two different layers. Each gathers and displays
SYN Flood statistics and generates log messages for significant SYN Flood events.
• SYN Proxy (Layer 3) – This mechanism shields servers inside the trusted network from
WAN-based SYN flood attacks, using a SYN Proxy implementation to verify the WAN
clients before forwarding their connection requests to the protected server. You can enable
SYN Proxy only on WAN interfaces.