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.foerster@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