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

[Scott Bennett <bennett@xxxxxxx>]

Roger Dingledine <arma@xxxxxxx> wrote:

> On Sun, Jun 04, 2017 at 07:14:06PM -0500, Scott Bennett wrote:
> >      Which versions are the Running votes coming from versus the non-Running?
>
> You can see the votes at
> https://www.seul.org/~arma/moria1-v3-status-votes

     Very interesting indeed.  The only two Running votes are from tor26 and
maatuska, which are the only Authority relays running 0.3.0.7.  All the other
authorities are running 0.2.9.9, 0.2.9.10, or 0.3.0.7-dev. (!)  I'm not quite
sure what to make of that, except that it appears that 0.3.0.7 is compatible
with itself.
>
> >      I have a few commands in a crontab entry that extract relay IP addresses
> > from the most recently received consensus, sort them, and load them into a
> > table in pf.  They run every 15 minutes.  Anything coming from the addresses
> > in the table is immediately passed.  Anything not passed gets checked against
> > a much larger table of probers, attempted intruders, etc. and is blocked if it
> > matches a table entry.
>
> Well heck. Sounds like we have a winner here.

     How so?  If all traffic from the relay addresses is passed?  I suppose
I should have mentioned, because I use pf, that the rules use the "quick" flag:

pass in quick on nfe0 proto tcp from <TorRelays> to nfe0 port 32323 flags S/SA label "ORPort from relays"
pass in quick on nfe0 proto tcp from <TorRelays> to nfe0 port 32326 flags S/SA label "DirPort from relays"
block drop in quick on nfe0 from <Crackers> to any
pass in quick on nfe0 proto tcp from any to nfe0 port 32323 flags S/SA label "ORPort from others"
pass in quick on nfe0 proto tcp from any to nfe0 port 32326 flags S/SA label "DirPort from others"

IOW, the rules act in a normal, logical sequence, rather than in the reversed
order, remaindered way that is pf's standard method of operation.  (I haven't
the foggiest idea why the OpenBSD folks designed pf that way.)
     Note that TorRelays is the table generated by the crontab job, and
Crackers is the table of offending addresses that I block.  By passing all
relay traffic first, it never hits the third rule.  The fourth and fifth
rules let all traffic from non-offending clients through, as well as any
traffic from new relays that do not appear in the most recently downloaded
consensus or in the Crackers table.
>
> Turn off your weird censorship infrastructure, confirm that things

     I must strenuously object.  First, I am not a government, thus I have
no censorship powers.  Second, all computer operators/sysadmins have the
right to defend their systems.  If you think that blocking attackers is
weird, then I suggest that that is your issue, not mine.

> start working after a while, and now you have something to debug. :)

     As I noted before, my setup has been working for many years without
problems.  It is only with the change to 0.3.0.7 from 0.3.0.6 that the problem
in question has appeared.  Convince me that that is irrelevant, please.


                                  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