[tor-relays] DoS attacks on multiple relays

[teor]

> On 5 Dec 2017, at 22:50, x9p <tor at x9p.org> wrote:
> 
> 
> my second and third positions are similar:
> 
>      ...

Please don't publicly share exact connection numbers and netblocks.
They can be used in combination with other information to de-anonymise users.

(For example, if an adversary knows that a guard has 5 connections from
a netblock that they can't otherwise observe, they can go and hunt down
those users.)

> On 6 Dec 2017, at 07:42, null <null at omuravpn.com> wrote:
> 
> ...
> @ 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?

No, this option only applies to directory authorities, and determines their
votes for the HSDir flag.

From the tor man page:

       MinUptimeHidServDirectoryV2 N seconds|minutes|hours|days|weeks
           Minimum uptime of a v2 hidden service directory to be accepted as
           such by authoritative directories. (Default: 25 hours)

>>> 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.

Perhaps it's the maximum allowed on some kernels or low-memory systems?
Or perhaps it's historical?

I suggest that you submit a ticket or patch to the debian bug tracker.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171206/0e374cc1/attachment.sig>