Fighting against a large SYN Flood attack that is happening every 2 minutes repeatedly.
During attack, number of syn-rcv is between 290-550
ss -n state syn-recv sport = :80 | wc -l
CPU 100% (htop output)
Tried cloudflare firewall, not helping at all CSF in action, seems can't help
backlog increased to 16K, SYN Cookies enabled... nothing helped..
Cloudflare should terminate all connections and thus prevent these spoofed syns from arriving at your server. Appears to be a misconfiguration since this traffic is being seen at your server.
Per their documentation:
How does Cloudflare mitigate SYN Flood attacks?
Cloudflare mitigates this type of attack in part by standing between the targeted server and the SYN flood. When the initial SYN request is made, Cloudflare handles the handshake process in the cloud, withholding the connection with the targeted server until the TCP handshake is complete. This strategy takes the resource cost of maintaining the connections with the bogus SYN packets off the targeted server and places it on Cloudflare’s Anycast network. Learn more about how Cloudflare's DDoS Protection works.
Source: Cloudflare - SYN Flood Attack
From the same source (Cloudflare - SYN Flood Attack), mitigation techniques include:
Increasing Backlog queue
Each operating system on a targeted device has a certain number of half-open connections that it will allow. One response to high volumes of SYN packets is to increase the maximum number of possible half-open connections the operating system will allow. In order to successfully increase the maximum backlog, the system must reserve additional memory resources to deal with all the new requests. If the system does not have enough memory to be able to handle the increased backlog queue size, system performance will be negatively impacted, but that still may be better than denial-of-service.
Recycling the Oldest Half-Open TCP connection
Another mitigation strategy involves overwriting the oldest half-open connection once the backlog has been filled. This strategy requires that the legitimate connections can be fully established in less time than the backlog can be filled with malicious SYN packets. This particular defense fails when the attack volume is increased, or if the backlog size is too small to be practical.
SYN cookies
This strategy involves the creation of a cookie by the server. In order to avoid the risk of dropping connections when the backlog has been filled, the server responds to each connection request with a SYN-ACK packet but then drops the SYN request from the backlog, removing the request from memory and leaving the port open and ready to make a new connection. If the connection is a legitimate request, and a final ACK packet is sent from the client machine back to the server, the server will then reconstruct (with some limitations) the SYN backlog queue entry. While this mitigation effort does lose some information about the TCP connection, it is better than allowing denial-of-service to occur to legitimate users as a result of an attack.
You need to check if the attack is using spoof addresses or not, if you can identify the ip address then drop them on a firewall/iptables or whatever you have. if the address are spoofed then you will need to use rate limiting, max tcp syns allowed and so on. If you cannot stop it then contact to your ISP.
