[tor-relays] DoS attacks on multiple relays

Thu Dec 7 08:56:39 UTC 2017

teor <teor2345 at gmail.com> wrote:
>
> > On 6 Dec 2017, at 19:13, Scott Bennett <bennett at sdf.org> wrote:
> > 
> > null <null at omuravpn.com> wrote:
> > 
> >> @ x9p:
> >> 
> >>> [stuff deleted  --SB]
> >>> 
> >> 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
> > 
> >     But it could be legitimate.  As has been discussed here previously,
> > they may be connections from a relay that actually is in the consensus,
> > but either a) uses an OutboundBindAddress or b) is on a LAN that has
> > multiple connections to the Internet.
>
> Relays try very hard to have at most one connection to each other relay.

     Good.  That tendency must have improved a lot over the years, then.

> (And only two relays are allowed in the consensus per IPv4 address.)

     Yes.

> Clients try to make one connection to one or two guards.

     Or however many are specified in torrc.  Sometimes one needs, say, three
to five guards for better capacity or lower latency or better reliability.
>
> So it's far more likely to be a collection of Tor clients in a network with
> only a few public IPv4 addresses. (There are entire countries and large
> networks that only have a few allocated IPv4 addresses.)

     An excellent point.  Thank you.
>
> Or, it might be a bug in Tor, a misconfiguration, or a denial of service
> attack. We'd like to know more, so we can find out and fix it.
>
     If it's a LAN with many users and few external IPv4 addresses (or,
perhaps, even IPv6 addresses if NATed to the outside via only a few), then
there really is nothing to fix.

> > (Snip)
> >     A script similar to the one used to reveal and make available the
> > otherwise unidentified source IP addresses of exits could be run by the
> > project to gather the hidden addresses of currently running relays, and
> > a list of such addresses could be made available on a compromise basis,
> > e.g., by having a relay at the project that would serve those lists only
> > over tunneled directory connections *from relays*, were it not for obstinacy.
> > Such a list could then be included into our packet filters' "free pass"
> > lists without putting the list up on the project's web site like the exit
> > list is.
>
> Outbound addresses aren't secret, because they are used for connections.

     Roger has claimed here that some of them are indeed secret in the sense
that their owners do *not* want them to be published, one possible reason for
which being that they do not want their relays blocked successfully by
governments, e.g., China, Iran.  (How hiding the source address of a published
relay would evade the Great Firewall escapes me somehow, except perhaps for
hidden services based inside China that might be reached via those hidden
source addresses.  Given that most source addresses of relays *are* published,
the chances of getting a circuit into China seem rather slim anyway.)  I guess
tor project members are not all in agreement over such matters.
>
> Anyone is free to volunteer to create and maintain a list of outbound
> relay addresses. It is technically feasible: it requires a few thousand Tor
> connections per day, one via each relay, to a relay that reports the

     Ideally, per hour, but that is why it should only be done by one site.
Note that Exit relays might be skippable because their outbound addresses
are already identified by one site, namely, the tor project, and published.
IOW, only entry/middle and non-Exit exit nodes need be tested, which would
shrink the list by several hundred to a thousand or so.

> remote address of each inbound relay connection.
>
> It just needs to be done safely, in a way that doesn't collect client
> addresses, and avoids attaching a timestamp or order to relay connections.

     Why would client addresses ever be involved?  What would be gathered
are the addresses from which *relays* connect to other relays (N.B. *not* to
destinations).  The only timestamps that I see might be relevant would be
the starting and ending times for each script run, so that an administrator's
own script(s) for incorporating those addresses into his "free pass" list
might easily discern out-of-date script output files from current script
output files.
>
> > A torrc option to fetch the list whenever updates were available
> > could default to not fetching the list, so relays whose operators who do
> > not use packet filter defenses would not automatically fetch the hidden
> > address list of non-exit relays.
>
> If someone created a list, and showed that it had value to other relay
> operators, then it might gain support, and be supported by Tor,
> just like other features have:
>
> There is an exit_addresses field for relays in Onionoo and Relay Search
> that gives the outbound exit addresses of every exit (when they differ
> from the relay address). It gathers addresses using exitmap. (Rather
> than relays self-reporting, which is unreliable.)

     Right.
>
> There is also a torrc option that has the side effect of making every
> address on the machine public, even unused addresses, because it
> blocks them in the exit policy. (ExitPolicyRejectLocalInterfaces, off by
> default.)
>
> Here's how someone could work on this feature:
>
> Create a scanner, publish a list, and show that it has value.

     Because such a list would include addresses whose owners might not be
pleased about those addresses being published (see above), such a list
should *not* be published, but perhaps could be sent to someone in the tor
project.  Better still, the generating script could be sent to someone in
the tor project to enable the project to run the script, rather than
encouraging many relay operators all to duplicate the network load of
running it.

> Or start with a proposal, ask for advice, then create the scanner.
>
> Try for something independent of Tor, like exitmap, because it will
> be more accurate. (Tor doesn't always know what its outbound address
> is.)

     Like I wrote before, a script would do it, although an actual program
could also do it.  Execution speed is probably not relevant because the
orders-of-magnitude larger delays will come from circuit construction times,
which consist primarily of network delays and delays caused by other relays.
     After putting it off for many years, I'm now going through a small book
on python.  Aside from a couple of very annoying misfeatures I've run across
so far, it looks to be a fairly straightforward language to learn to write.
Then I'll need to study the tor project's stem library documentation before
writing the script, which I doubt will need to be very complex.  The output,
after all, should only be a list of otherwise unpublished IP addresses from
which connections from relays may arrive at any other relay.  No other
information need be included, other than possibly the aforementioned file
generation timestamps (similar to consensus document timestamps, though
perhaps less frequent).
>
> And try to have list downloads rely on existing Tor features, like onion
> services. They'll be faster to deploy that way.

     AFAIK, tor has no such feature.  If a relay is to download nothing more
than a file of IP addresses, which feature are you suggesting will do that
upon demand by a relay (and only an identified relay)?  Yes, a relay can ask
for a directory download (and so can a client).  Yes, a relay can ask for a
directory update download (and so can a client).  Yes, a relay can ask for
ExtraInfo document downloads.  How does a relay ask to download a kind of
file that doesn't yet exist?  Is there already some undocumented, generic
feature that a identified relay (but nothing else) can ask a directory mirror
or authority to "give me your latest version of file x"?
     If you mean that the downloading process could be spun off to a worker
thread, then yes, of course, it should be, but the actual implementation in
tor would be up to the tor developers, not to me.
>
> Here's a description of the proposal process:
>
> https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt
>
> >> 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.
> >> 
> >     And it will likely get you roundly denounced by tor project members
> > and certain other individuals on this list. :-(
>
> I sketched a proposal like this in another thread just a few days ago.
> I'm happy to work with others to include inbound or outbound connection
> limits in the draft proposal. (My initial proposal had outbound circuit and
> stream limits.)
>
> > You will also see your
> > Fast and HSDir flags come and go at random, depending upon how many
> > authorities creating testing circuits to reach and test your node(s)
> > go through a node that used a hidden outbound address as the source
> > address that fails your filter to connect to your node.
>
> If you set the connection limit at or above 512 connections per /24, it will
> be impossible for well-behaved consensus relays to go above the limit:
>
> 2 relays per IPv4 * 256 IPv4 addresses per /24 = 512 connections

     Apparently, the aforementioned effort to limit each relay pair to a
single connection does not apply to hidden service connections, as can be
readily seen on a Fast HSDir relay when bursts of connections occur.  There
is also little to prevent many thousands of clients from connecting
simultaneously.  A number of high-capacity relay operators have mentioned
here in the past that they have had to increase their OS's fd limit to a
value far greater than its default in order to prevent relay death under
the heavy connection loads typical of such relays.  My relay is a relatively
low-capacity relay, yet when it has the Fast flag, and especially with an
additional HSDir flag, it often has several thousand connections at any
given time.
>
> Or you could check how many relays are in the most popular /24, and use
> that to work out a limit.
>
> > (Snip)
>
> >> @ Scott Bennett:
> >> 
> >>> (Snip)
> >> 
> >> 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
> > 
> >     Sigh.  My apologies.  You are indeed correct on this matter.  It had
> > slipped my mind that tor no longer is distributed with a man page.
>
> Tor source is distributed with an asciidoc man page.

     But not a UNIX/LINUX man page, either as *roff source or plain, ASCII
text.  If it doesn't have a file that works with the man command, then it
does not have a man page, by definition.
>
> It might not be on your system because the packager left it out, or left
> out asciidoc as a build dependency.

     Thanks for the info.  I'll try to check into that.  asciidoc is in
the build dependency list if either the DOCUMENTATION or the MANPAGES
configuration option for the port is selected.  The MANPAGES option is on
by default in the port's Makefile, yet no man page gets installed as nearly
as I can see.


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