Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] abuse control for Tor exit nodes

Tom Ritter tom at ritter.vg
Fri Jun 28 08:34:58 PDT 2013


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?

-tom



More information about the liberationtech mailing list