>Are there any objections against this approach? A hard limit of 9 might be a little too low - then again, a legit, unmodified tor binary would hold it's TCP connection established for as long as needed - so maybe this will block some of the attacks, but it's very basic - I'd try to go with a smart firewall that learns from previous attacks, as in detecting and establishing attack patterns, and then blocking new attempts instantly.
Unfortunately, such things are far from inexpensive. I hope that this is enough to at least save your node from going from no-problems-at-all to unusable - make sure syncookies are enabled as well, which isn't the case on some distributions by default. - William 2021-02-22 14:27 GMT, Toralf Förster <toralf.foers...@gmx.de>: > 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 > _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
