[liberationtech] abuse control for Tor exit nodes

[Mike Perry]

Tom Ritter:
> On 27 June 2013 05:07, Rich Kulawiec <rsk at gsp.org> wrote:
> > [ Okay, so I have a long-winded response to this.  It's possible that
> > eventually I'll wander somewhere near a point. ;-) ]
> > ...
> > ...
> > My suggestion (and this is based on many other kinds of operations
> > since I've never run a Tor exit node) is to do what everyone should
> > do for every operation: use a bidirectional default-deny firewall.
> > Then punch holes in it as necessary to permit desired traffic.  Use netflows
> > to detect and squash things like brute-force attacks.  (In other
> > words, if you observe a serious spike in outbound ssh connection attempts,
> > then someone is using your node, and possibly others, to conduct an ssh
> > brute-force attack.  Rate-limit it.  Or just block it for a while.)
> > Another highly useful technique is rate-limiting based on passive
> > OS fingerprinting of the source: one application is to provide
> > severely limited SMTP bandwidth to anything fingerprinting as Windows.
> > Another is to use the Team Cymru bogon list.  And still another is
> > to use the Spamhaus DROP list, since nothing good can happen by permitting
> > traffic to/from those network ranges.
> >
> > The "pf" firewall in various BSD distributions is a good choice
> > for implementing all this.  It also has the useful feature of being
> > rather resource-frugal: it's quite impressive how an old/slow box
> > running it can gracefully handle large traffic volumes.
> 
> 
> This is a very well written argument, thank you.  I'd love to see more
> discussion around the ethics of "Should I" or "Shouldn't I" put in
> (non-logging) abuse filtering on exit nodes.  Someone can always
> disguise abuse.  An intelligent DoS attack on an SSL website couldn't
> be detected by an exit node operator.  But, just as moving SSH off
> port 22 really honest-to-god does eliminate 99% of the crap you'd get
> otherwise, maybe there are similar cheap wins to be had on Exit Nodes.
>  While there are legitimate reasons to send sqlmap through Tor, I'm
> currently thinking if you actually want to test something,
> legitimately, through Tor, using sqlmap - you should be prepared to
> deal with exit blocking.  Exit blocking that could eliminate 50%, 80%,
> 95% of the crap.  I'd love to see people debate this back and forth
> more and tease out arguments for and against.
> 
> On the practical side of things, a couple questions.
> Blacklisting connects *to* the spamhaus list, and other known spammers
> (as an exit operator) would really only shut down control channels,
> no?.  Similarly, if you're an entry node, you could block connections
> *from*... but if spammers on the spamhaus blocklist were actually
> using Tor... well, they wouldn't *be on the blocklist*.  I could
> always be wrong, but I don't see this making big wins.
> 
> Shutting down SSH brute forcing would be cool.  I've joked with my
> friends "There are so many interesting thing in the world, and I have
> no little time to learn them all.  I have to prioritize. So I decided
> to skip iptables and use a wrapper (shorewall)."    Do you have, or
> know of, any simple writeups for doing that, or some of the more
> complicated suggestions?

This argument comes up every so often on tor-relays.

Censorship filters, IDS systems, and rate limiting firewalls don't
belong on Tor exits anymore than they belong on the core routers of the
Internet. They belong on the leaves. Censor yourself, not others.

Imagine what would happen if the core routers of the Internet "detected"
"abuse" with even 99% accuracy (1% false positive rate). The Internet
would cease to function, due to the base rate fallacy and the relative
infrequency of actual abuse:
https://en.wikipedia.org/wiki/Base_rate_fallacy

The same math applies to Tor exits.

-- 
Mike Perry