On 11/10/2022 2:38 AM, Scott Bennett
wrote:
Toralf F?rster wrote:
On 11/8/22 10:57, Chris wrote:
The main reason is that a simple SYN flood can quickly fill up your
conntrack table and then legitimate packets are quietly dropped and you
won't see any problems thinking everything is perfect with your server
unless you dig into your system logs.
Hhm, my system log doesn't show any problems, maybe due to (or
regardless of?):
CONFIG_SYN_COOKIES=y
?
On FreeBSD 12.3 I use pf and have gone back to using synproxy on the
"pass in" statements for the ORPort and DirPort, but I doubt it has actually
made any difference
The quote about SYN Flood is
actually from my post which went only to toralf and wasn't
displayed on the group. My bad. To explain further, I didn't
say the current attack includes SYN floods, what I meant was
whenever we have some conntrack rules in our iptables, it's
prudent to have some rate limiting rules before it, because if
the attacker knows we rely on conntrack and intends to do some
damage, the attacker can easily flood our conntrack table with
SYN flood and then we start dropping legitimate packets
without notice. However you're correct, currently there are no
SYN floods.
because the only attacks I've seen so far were coming
via other relays and triggered tor's rejections of INTRODUCE2 cells by the
thousands. Instead, what has been very effective has been to increase the
NumCPUs count drastically.
You're correct yet again. The
number of CPUs make a huge difference. Tor automatically
detects up to 16 CPUs if you have them. Anything above that,
Tor can't see. I've never tried adding it to my torrc though,
it might see more if you tell it to look for them.
On my relays which are run on
VMs, I simply added more CPUs to the VM and somewhere around
10 CPUs seemed to be the magic number when all the warning
messages disappeared. They are currently happily running on
12.
On a non-hyperthreaded quad-core CPU I now have
it set as "NumCPUs 20".
OK I'm confused now, Are you
saying that it's possible to tell Tor to use non existent CPUs
and it actually works? That would be really cool. Is it
because Tor assigns multiple worker threads to the same CPU?
Each worker thread uses almost no CPU time, but
haveing enough of them waiting to grab an onionskin off the queue instantly
seems to stop all messages about cells, onionskins, or connections being
dropped.
During an attack I often saw all workers in top(1) screen updates with
"NumCPUs 16", so I increased to 20 for the next restart, but I hadn't gotten
any of the aforementioned error/warn messages at 16. Unfortunately, I have
yet to see what happens at 20 because before the next restart Comcast made
a change that blocks me from running a relay. :-( I intend to find out very
soon whether I can afford to switch to their business network right away, so
that I might resume running my relay or will have to wait until things happen
next summer that should free up some of my limited income first.
Nevertheless, I updated the Readme to explain my point of view [1] [2].
[1] https://github.com/toralf/torutils#block-ddos-traffic
[2] https://github.com/toralf/torutils#rule-set
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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
