eBPF-based SYN Flood Detector
This tool implements a Proof-of-Concept SYN Flood detector based on eBPF, aiming to identify the source IP addresses of an ongoing SYN Flood attack on the protected system.
Detection Mechanism
The normal TCP handshake is composed of three packets:
- A SYN packet from the client that initaites the handshake.
- A SYN-ACK packet from the server that communicates to the client that the server is willing to accept the connection. Before sending this packet the server creates an entry in the TCP backlog queue to store information about the halof-open connection.
- An ACK packets from the client that completes the handshake. Once this packet is received the server removes the entry from the baclock queue and creates and entry in the connections table.
The SYN Flood attack operates by initiating a large number of handshakes without completing them with the last ACK packet. This causes the backlog queue of the server to fill up and prevents other legitimate TCP connection from being accepted. Modern systems implement the SYN Cookies mechanism to mitigate this attack, removing the use of the backlog queue and allowing the server to keep handling new handshakes even under attack. This mechanism however has a computational overhead and a SYN Flood attack can still cause a shortage of resources on the server if the number of packets sent is high enough.
This detection tool targets a scenario with SYN Cookies enabled, in which the server keeps responding to new handshakes with SYN-ACK packets. The tool identifies incomplete handshakes as those handshakes composed by the first two packets (SYN and SYN-ACK) that are not completed by a given timeout. These incomplete handhsakes are a sign of possible attack. If the number of incomplete handshakes generated by a single source address exceeds a given threshold over a given monitoring time the address is identified as (potentially) malicious.
Architecture
Two eBPF programs are attached to the ingress and egress TC hooks of monitored network interfaces and store information about incoming (client to server) TCP handshakes in a hash map. The map contains one entry for every pending handshake (identified by the TCP 4-tuple) and stores the initiation timestamp (timestamp of reception of the first SYN packet) and a boolean value telling wether the SYN-ACK packet has already been sent by the server. Once an handshake is completed (last ACK received) the corresponding entry is removed from the map.
In user space a Python script periodically (every handshake timeout) scans the pending handshakes map and identifies the incomplete ones (now - handshake.begin_time > timeout). Incomplete handshakes are removed from the map and a counter is increased for the source IP address. If this counter exceeds a threshold the address is added to the malicious list.
Requirements
- BPF Compiler Collection (BCC) to handle eBPF programs.
- The Polycube framework in case the XDP mitigation feature is needed.
Usage
The tool must be executed with root privileges and can monitor multiple interfaces. To monitor interfaces enp1s0f0 and enp1s0f1 run the command:
sudo ./detector.py enp1s0f0 enp1s0f1
The tool start monitoring the interfaces and prints a log with the number of malicious addresses detected such as the following:
[INFO] [1601554007.359749] Monitoring interfaces, hit CTRL+C to stop
[INFO] [1601554017.369871] Checking handshakes
[INFO] [1601554017.371053] No new potentially malicious source addresses detected. Total 0
[INFO] [1601554027.369855] Checking handshakes
[INFO] [1601554027.370821] Detected 1000 new potentially malicious source addresses. Total 1000
[INFO] [1601554037.369849] Checking handshakes
[INFO] [1601554037.370811] No new potentially malicious source addresses detected. Total 1000
^C[INFO] [1601554039.522658] Removing filters from devices
Two actions (specified by the -a option) can be applied to detected addresses:
printprint the list of detected addresses.mitigateuse the Polycube DDoS Mitigator service to block packets from detected addresses at the XDP level. The Polycube daemon must be running when the tool is started:sudo polycubed -d
To achieve better performance please use the batch branch of the project (Kernel >= 5.6 is required)