AT1: SYN Flood
Definition
Clients generate a SYN packet (64 bytes) to request a new session from a host server. As the TCP three-way communication handshake is created, the host will track and allocate each of the client’s sessions until the session is closed. In a SYN flood, a victim server receives spoofed SYN requests at a high packet rate that contain fake source IP addresses. The SYN flood overwhelms the victim server by depleting its system resources (connection table memory) normally used to store and process these incoming packets, resulting in performance degradation or a complete server shutdown. A well-crafted SYN flood often fools deep-packet inspection filtering techniques. SYN-Cookie defense can be used to defend against large-scale SYN floods but this requires all servers to support this capability.
Attack Matrix Dimensions
| Nature of IP | Handshake | Source IP Range | Packet Rate | Packet Size | Packet Content | Fragmenting | Session Rate | Session Duration | VERB Rate |
|---|---|---|---|---|---|---|---|---|---|
| Spoofed | None | Large | High | Small | -- | -- | -- | -- | -- |
Defense Fundamentals
Most SYN Floods are generated by bots spoofing a large pool of IP addresses. The basic defense against this attack would be:
-
Detection can be done by examining source IP distribution.
-
In cases where there is a high level of suspicion of a SYN Flood, the RioRey system will start dropping sample SYN to observe proper TCP SYN retransmissions.
-
Once an attack is detected, the normal defense method simply becomes dropping all new incoming SYN and only allowing retransmitted SYN to continue.
-
However, a sophisticated SYN Flood attack would generate multiple SYN with the same Source/Destination IP pairs, mimicking a good TCP retransmission. In these cases, setting Force On will help.
Configuration Settings
Click Edit to change default setting(s). When done, remember to Save before moving on to next mitigation section.
| Feature | Default Setting | Comments |
|---|---|---|
| Filter Mode | Auto (Auto/Monitor/ Force On/Off) | Auto: Algorithms are executed and packets are filtered. Monitor: Packets are viewed, counted and all algorithms are executed. No filtering of these packets will occur in Monitor mode. DDoS traffic will be identified and represented in all attack-based charts and the Zone Traffic Chart will represent zero dropped traffic. Force On: Under Auto, packets undergo two distinct phases: detection and filtering. Once an attack has been detected, filtering is executed. In Force On mode, the detection phase is skipped and all packets are automatically filtered. Due to the required resources to perform this type of filtering, Force On can only be engaged for up to 64 distinct IP addresses. You can check the number of IP addresses a device is using this mode for on the Zone Management tab under Administration->Devices. In specific cases, this mode will increase the amount of packets filtered with an increased risk of false positives. Off: No filtering or monitoring is performed. |
| Disable flood mitigation (RIOS 5.3.0 or greater) | Unchecked | When this control is checked, flood detection and mitigation is turned off. The only checks that will be performed are for excessive duplicate packets (Subtype 2) and, if enabled, SYN packets with a data payload (Subtype 3). |
| Allow packets with payload (RIOS 5.3.0 or greater) | Disabled | When enabled, SYN packets with a payload will no longer be dropped automatically. |
| Maximum duplicates (RIOS 5.4.3 or greater) | 10 | This is the maximum allowed number of duplicate SYN packets from a source IP and port to the same destination IP and port (one session) before it will be considered an attack. Turning this to 0 will disable this check. |
| Allow start with zero window (RIOS 5.6.0 or greater) | Disabled | A client opening a session is usually expected to be able to receive some amount of data immediately. The default behavior is to drop SYN packets with a window advertisement of 0. If this option is enabled, SYN packets with a window of 0 are allowed. |
| Validate ECN Flags (RIOS 8.4.0 or greater) | Disabled | Technically a wide variety of behavior is allowed for Explicit Congestion Notification (ECN). Enabling this control imposes stricter checks on SYN packets that most well behaved hosts would not send (reported as Subtype 5): - Drops ECN field = CE in the IP header - Drops if CWR = 1, ECE = 0 - Drops if CWR = 0, ECE = 1 |
Subtypes
Attack packets are classified under subtypes for better reporting. The subtype and reason the packet is labeled as invalid under its attack type can be found in the following table.
| Attack Type | Subtype | Details |
| AT1 | 1 | Spoofed Flood Attack |
| AT1 | 2 | Excessive Duplicate Packets |
| AT1 | 3 | SYN Packets with Data Payload |
| AT1 | 4 | SYN with zero window |
| AT1 | 5 | SYN Packet with invalid ECN |
| AT1 | 6 | Duplicate SYN packet matches existing session |