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
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
On 2/22/21 7:29 PM, William Kane wrote:
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 -
Hhm, I'm really under the impression that even 5 or 4 should be enough. If a client connects more often than every 15 seconds to its guard or a relay opens a conenction for more often than 4x per minute to another relay - then they are modified, or ?
-- Toralf
Then they are modified, or ?
You don't know that, and Tor has code to defend against such attacks, both limiting concurrent requests, creating too many circuits and putting a threshold on connect() aka TCP SYN packets, the latter though only being available on 0.4.6.1-alpha or later.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40253
I'd advise against such firewall rules and let tor handle it.
- William
On 24/02/2021, Toralf Förster toralf.foerster@gmx.de wrote:
On 2/22/21 7:29 PM, William Kane wrote:
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 -
Hhm, I'm really under the impression that even 5 or 4 should be enough. If a client connects more often than every 15 seconds to its guard or a relay opens a conenction for more often than 4x per minute to another relay - then they are modified, or ?
-- Toralf _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 22/02/2021 14:27, Toralf Förster wrote:
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?
Have you tried adding "xt_recent.ip_list_tot=<number>" to your kernel command line? That formula works for most module parameters when their module is built-in, I think.
Stephen
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
On 2/22/21 3:27 PM, Toralf Förster wrote:
# 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
just for the record:
In the emanwhile I do think that this idea was BS.
The reason is that if an advisory spoofs the sender address then this eventually blocks the (spoofed) sender address thereby.
-- Toralf
On 30.03.2021 19:46, Toralf Förster wrote:
On 2/22/21 3:27 PM, Toralf Förster wrote:
# 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
just for the record:
In the emanwhile I do think that this idea was BS.
The reason is that if an advisory spoofs the sender address then this eventually blocks the (spoofed) sender address thereby.
DDoS SYN flood attack are unfortunately very different and hard to defend against.
I recently found something: SYNPROXY https://www.redhat.com/en/blog/mitigate-tcp-syn-flood-attacks-red-hat-enterp...
https://hakin9.org/syn-flood-attacks-how-to-protect-article/ at the bottom: # iptables -t mangle -I PREROUTING -p tcp -m tcp --dport 80 -m state --state NEW -m tcpmss ! --mss 536:65535 -j DROP
Does anyone know the community services of Team Cymru? Is that really free? That might be something for people with their own ASN like nifty. https://team-cymru.com/community-services/utrs/
Hi,
DDoS SYN flood attack are unfortunately very different and hard to defend against.
What?
Not really if you understand the TCP protocol, it's just a bunch of TCP connections (can't really call them connections yet since they are still stuck in the synchronize state) overflowing the tcp queue.
Turning on syncookies is usually enough to deal with basic SYN flood variants though that functionality comes with it's own set of drawbacks.
net.ipv4.tcp_syncookies = 1
- William
On 01/04/2021, lists@for-privacy.net lists@for-privacy.net wrote:
On 30.03.2021 19:46, Toralf Förster wrote:
On 2/22/21 3:27 PM, Toralf Förster wrote:
# 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
just for the record:
In the emanwhile I do think that this idea was BS.
The reason is that if an advisory spoofs the sender address then this eventually blocks the (spoofed) sender address thereby.
DDoS SYN flood attack are unfortunately very different and hard to defend against.
I recently found something: SYNPROXY https://www.redhat.com/en/blog/mitigate-tcp-syn-flood-attacks-red-hat-enterp...
https://hakin9.org/syn-flood-attacks-how-to-protect-article/ at the bottom: # iptables -t mangle -I PREROUTING -p tcp -m tcp --dport 80 -m state --state NEW -m tcpmss ! --mss 536:65535 -j DROP
Does anyone know the community services of Team Cymru? Is that really free? That might be something for people with their own ASN like nifty. https://team-cymru.com/community-services/utrs/
-- ╰_╯ Ciao Marco!
Debian GNU/Linux
It's free software and it gives you freedom! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
lists＠for-privacy.net -
niftybunny -
Stephen Mollett -
Toralf Förster -
William Kane