The problem is: Thats not scaleable.
This is the “normal” state of one of my servers:
Total: 429711 TCP: 492099 (estab 401695, closed 63371, orphaned 10702, timewait 63140)
Transport Total IP IPv6 RAW 0 0 0 UDP 447 437 10 TCP 428728 400433 28295 INET 429175 400870 28305 FRAG 0 0 0
The idea to be proactive is fantastic and I am sure it is also best practice but not doable with the hardware I have. Well, I could invest a few ten thousand in new hardware or the same amount in a 100Gig firewall etc …. but right now with the stock market crashing I am broke as fuck.
And even if I were not broke, we are talking about really really high amounts of money.
On 22. Feb 2021, at 15:27, Toralf Förster toralf.foerster@gmx.de wrote:
The following 3 statements
# Make sure NEW incoming tcp connections are SYN packets; otherwise we need to drop them. $IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# DDoS $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood --set $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood --update --seconds 60 --hitcount 10 -j DROP
seems to work and to help here ata fast Tor relay. CPU went down from 109% to 95%. There're 500 connections less than before for a Tor fast relay.
The /proc/net/xt_recent/synflood is quickly filled. Unfortunately I cannot change the "ip_list_tot" of "xt_recent" b/c I do use a non-modular kernel. Does anybody knows a circumvention?
Are there any objections against this approach?
Toralf _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays