Re: [tor-relays] DoS attacks on multiple relays

[null <null@xxxxxxxxxxxx>]

@ x9p:

> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort
> | egrep -v '      1 |      2 |      3 '
>
> with this information in hand, double the max of it (mine was 10
> connections from 188.214.30.0/24):
>
>      10 188.214.30
>
> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
> --connlimit-mask 24 -j REJECT --reject-with tcp-reset

Thank you! This was extremely helpful.

In our case we found a handful of IPs that had *thousands* of
concurrent connections on several of our relays. The offending IPs
were not in the consensus. After restarting the Tor service, these
suspect connections come back rapidly, again across several of our
relays. Since our relays are all in the same declared family, it is
very difficult to see how this traffic is legitimate. If it's valid
Tor clients, they are behaving very strangely, and in either case we
need to limit their impact. As such we've implemented connlimits by
/24 as suggested (with a much higher limit to err on the side of not
rejecting valid traffic). We can already see that this has improved
our situation.


@ Scott Bennett:

>      What you are seeing is most likely the same phenomenon brought up on
> this list repeatedly over at least the last decade or so.  That phenomenon
> is providing HSDir service, or perhaps a rendez-vous point, for a popular
> hidden service.

> If you don't like it, you can set
>
> HidServDirectoryV2      0

Thanks for your reply. The data suggests this was not the case (this
time). Some of these relays have been up almost a year with the same
configuration, often with the HSDir flag. The recent issues just
started occurring, and happened across several relays during the same
timeframe.

Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule
it out. However it appears that option is deprecated (on 0.3.1.9).
Enabling it causes this in the log:

  [WARN] Skipping obsolete configuration option 'HidServDirectoryV2'

It's also no longer listed in the Tor manual
(https://www.torproject.org/docs/tor-manual.html.en). It looks like we
might be able to achieve the same effect with something like this
instead:

  MinUptimeHidServDirectoryV2 52 weeks

Anyone have any info on why HidServDirectoryV2 is consider obsolete?
Is using MinUptimeHidServDirectoryV2 instead going to achieve the same
effect?


>> We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks
>> like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor:
>>
>>   elif [ "$system_max" -gt "40000" ] ; then
>>     MAX_FILEDESCRIPTORS=16384
>>
>> Surely that is high enough for normal service?
>
>      If by normal you mean "low traffic", then yes, it's probably enough.
> However, that's really not very high in a general sense.


Why does the default /etc/init.d/tor (from the Debian/Ubuntu pkg) cap
MAX_FILEDESCRIPTORS at 16384 then? We have it set to 64000 otherwise.
Obviously we could comment out these lines, but it seems odd the
default config tries to cap it at 16384 if that's too low for a high
traffic relay.

Thanks everyone for your replies!
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays