Toralf F?rster <toralf.foers...@gmx.de> 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-setScott 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
