<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 11/10/2022 2:38 AM, Scott Bennett
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:202211100738.2AA7cw7d026293@sdf.org">
<pre class="moz-quote-pre" wrap="">Toralf F?rster <a class="moz-txt-link-rfc2396E" href="mailto:toralf.foerster@gmx.de"><toralf.foerster@gmx.de></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 11/8/22 10:57, Chris wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Hhm, my system log doesn't show any problems, maybe due to (or
regardless of?):
CONFIG_SYN_COOKIES=y
?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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 </pre>
</blockquote>
<p><font size="-1"><font face="Arial">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.</font></font><font size="-1"><font face="Arial"> </font></font><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:202211100738.2AA7cw7d026293@sdf.org">
<pre class="moz-quote-pre" wrap="">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. </pre>
</blockquote>
<p><font size="-1"><font face="Arial">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.</font></font></p>
<p><font size="-1"><font face="Arial">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.</font></font></p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:202211100738.2AA7cw7d026293@sdf.org">
<pre class="moz-quote-pre" wrap="">On a non-hyperthreaded quad-core CPU I now have
it set as "NumCPUs 20". </pre>
</blockquote>
<p><font size="-1"><font face="Arial">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?<br>
</font></font></p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:202211100738.2AA7cw7d026293@sdf.org">
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Nevertheless, I updated the Readme to explain my point of view [1] [2].
[1] <a class="moz-txt-link-freetext" href="https://github.com/toralf/torutils#block-ddos-traffic">https://github.com/toralf/torutils#block-ddos-traffic</a>
[2] <a class="moz-txt-link-freetext" href="https://github.com/toralf/torutils#rule-set">https://github.com/toralf/torutils#rule-set</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a>
</pre>
</blockquote>
</body>
</html>