Filter
Top Products
Firewall Settings > Flood Protection
738
SonicOS 5.8.1 Administrator Guide
Each watchlist entry contains a value called a hit count. The hit count value increments when
the device receives the an initial SYN packet from a corresponding device. The hit count
decrements when the TCP three-way handshake completes. The hit count for any particular
device generally equals the number of half-open connections pending since the last time the
device reset the hit count. The device default for resetting a hit count is once a second.
The thresholds for logging, SYN Proxy, and SYN Blacklisting are all compared to the hit count
values when determining if a log message or state change is necessary. When a SYN Flood
attack occurs, the number of pending half-open connections from the device forwarding the
attacking packets increases substantially because of the spoofed connection attempts. When
you set the attack thresholds correctly, normal traffic flow produces few attack warnings, but
the same thresholds detect and deflect attacks before they result in serious network
degradation.
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.
Configuring Layer 3 SYN Flood Protection
To configure SYN Flood Protection features, go to the Layer 3 SYN Flood Protection - SYN
Proxy portion of the Firewall Settings > Flood Protection window that appears as shown in
the following figure.