[tor-relays] syn flood iptables rule

[William Kane]

>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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>