Monitoring SYNPROXY - hilbix/netdata GitHub Wiki
Linux Anti-DDoS
SYNPROXY is a TCP SYN packets proxy. It can be used to protect any TCP server (like a web server) from SYN floods and similar DDos attacks.
SYNPROXY is a netfilter module, in the Linux kernel (since version 3.12). It is optimized to handle millions of packets per second utilizing all CPUs available without any concurrency locking between the connections.
The net effect of this, is that the real servers will not notice any change during the attack. The valid TCP connections will pass through and served, while the attack will be stopped at the firewall.
To use SYNPROXY on your firewall, please follow our setup guides:
Real-time monitoring of Linux Anti-DDoS
netdata is able to monitor in real-time (per second updates) the operation of the Linux Anti-DDoS protection.
It visualizes 4 charts:
- TCP SYN Packets received on ports operated by SYNPROXY
- TCP Cookies (valid, invalid, retransmits)
- Connections Reopened
- Entries used
Example image:
See Linux Anti-DDoS in action at: netdata demo site (with SYNPROXY enabled) (but read the note below).
A note for DDoS testers
Since I posted this, a few folks tried to run DDoS against http://netdata.firehol.org.
Well, guys this site is not a test bed for DDoS. Don't do this. You are just wasting bandwidth!
Also, please try to understand what you are doing. SYNPROXY is about spoofed packets. Making a large set of POSTs or instructing exploited wordpress installations to attack the demo site, is not a DDoS that SYNPROXY can detect.
Next, http://netdata.firehol.org is behind cloudflare.com, so even if you manage to make a spoofed IPs attack, you will actually attack cloudflare.com. Do not expect to see the traffic cloudflare detected as spoofed on the netdata demo site (you are reaching the demo site, through cloudflare proxies). You can see a real attack on the demo site, only if you attack its real IP (but, you guessed it - it only accepts requests from cloudflare.com). The demo site is just a demo for netdata, not a demo for DDoS.
And finally, thank you for exposing the IPs and hostnames of the exploited wordpress installations and the IPs of the hosts you manage to instruct them make so many POST requests to us.
Evidence of the attacks:
- Attack from wordpress installations
- ngnix log with the exploited wordpress installations used today
- IPs of the exploited wordpress installations used today
- Attack using a large set of POST requests
You actually stressed netdata a bit. What saved the server from your attack was QoS. I had the bandwidth limited to 50Mbps, so your attacks could not bring the server to its limits. Now, I lowered it even more.
This is what happened with the POSTs:
And this is what happened with the wordpress attack:
Now our nginx configuration includes these:
if ($http_user_agent ~* "WordPress") {
return 403;
}
if ($request_method !~ ^(GET|HEAD|OPTIONS)$ ) {
return 403;
}
include firehol_webserver.conf;
include netdata-attacks.conf;
firehol_webserver is this IP Blacklist and netdata-attacks are the IPs given in the evidence above.
So, you are just blacklisted.
Other IP lists, matching the attackers IPs: