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@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays