Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[Scott Bennett <bennett@xxxxxxx>]

Roman Mamedov <rm@xxxxxxxxxxx> wrote:

Hi Roman!
> On Thu, 08 Jun 2017 09:43:00 -0500
> Scott Bennett <bennett@xxxxxxx> wrote:
>
> >      As noted more than once previously, the pf rules *pass* all traffic
> > from relay addresses *first*, so that traffic has already gone on to tor
> > before the block list is applied.
>
> There are most likely some relays which use a different IP for outgoing
> connections than what is listed in the consensus, due to multiple IPs or
> provider multihoming. Your scheme does not seem to account for that, so those
> connections may fail. In effect you will be leaving the Tor network
> permanently semi-broken by running a relay while employing such filtering.

     You're right.  I recall spending a lot of time trying to find a way to
get those addresses, so that I could include them in the TorRelays table or
some other arrangement to let their traffic through.  Unfortunately, tor
doesn't publish them anywhere that I could find nor did anything else back
at the time I set these rules and tables up.  However, I figured most relays
probably have only a single WAN interface, so the rules would probably cause
few failures.  Also, clients don't give up after something like that, but
rather continue to try more circuits, so the end user may experience a short
delay, but won't actually go unserved in such cases.
     Consider another case.  Users have often complained that running a tor
relay results in their IP addresses being blocked by all manner of services
around the Internet.  The providers of those services say they have suffered
attacks originating from tor relays.  The project's response was to create
an automatically, frequently updated list of IP addresses of exit relays and
make that list available for download by anyone wishing to block traffic from
tor exits, while allowing traffic from all other relays.  That list of
addresses suffers the same problem of not including alternative IP addresses
for those relays.  Even worse, troublesome connections from those alternative
addresses *can* be traced back, in some cases, to the exit relay.  Once those
services have identified the offending traffic as coming from a machine they
had been promised by the tor project would be in the downloadable list of
exit relay addresses, they may decide that they had been deceived by the tor
project, which could lead to many bad things in the future.
>
> In any case I don't think there is any reasonable threat scenario against which
> you must protect by not just allowing all connections from anywhere to
> ORPort/DirPort of a Tor relay.
>
     That is something that each system administrator has to determine for
the system(s) under his care.  My determination for my system apparently
differs from your evaluation of your situation.
     What originally prompted me to look into using a packet filter to block
traffic from identifiable sources of trouble was the frequency of attacks on
my system.  It was so intense at times that even the kernel was complaining
in console messages that it was limiting RSTs to 200/s.  These messages were
happening so fast that syslogd was reducing them in most cases with messages
like "last line repeated 1353 times" (not an exact quotation, but I'm sure
you've seen syslogd's message flood response before).  At first, setting

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1

seemed to take care of the problem.  However, after a couple of years, the
messages resumed.  China, Malaysia, Nigeria, and a few other countries were
being especially persistent and aggravating in the frequency of their attacks.
(Just in case, I've since added "net.inet.sctp.blackhole=2" to the above list.)
     Although providing a tor relay and directory is currently the only thing
my system offers to benefit other people, I decided that, if I ever chose
to offer other services, I would want to deny those services to the offending
parties, too, which is why those block rules apply to all ports on my system
and not only to tor's ports.  The pass rules apply to traffic destined to
tor's ports.


                                  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
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays