Re: [tor-talk] [bad-relays] relays in spamhaus DROP list

[grarpamp <grarpamp@xxxxxxxxx>]

Regarding blocking at scale of exits to various services...

  http://www.spamhaus.org/drop/
  http://www.spamhaus.org/faq/section/DROP%20FAQ
  http://www.spamhaus.org/sbl/
  http://www.spamhaus.org/faq/section/Spamhaus%20SBL
  http://www.spamhaus.org/sbl/query/SBL216916
  http://www.spamhaus.org/sbl/query/SBL202964
  https://globe.torproject.org/#/search/query=46.29.248


> But I think this means that relay traffic between the relays listed in DROP
> and providers hidden services (and general Tor nodes, and the dirauth
> server) will be dropped. What does Tor do in that case? Establish a
> different circuit?

The user's app gets a TCP close or reset or stack times out.
There might be an option someday for that, but there's already
a 'new identity' button to do it manually.

>> > I do NOT think the question is:
>> >    Is it OK for spammers to run a Tor relay?
>>
>> Tor is one process. Whatever else is running is another process.
>> I don't think tor's in a position or has desire to dictate other processes.
>>
>> > I think the question is:
>> >    Is it OK for someone to run a relay from IP space from which any
>> >    traffic exiting is likely to be blocked by many routers on the
>> >    internet?
>>
>> Seems a bit of a mixed question of utility vs bad-relays@ malicious
>> sort of thing. The tor-relays@ list, and the metrics of tor, bwauths,
>> etc tends to help with utility and nonsense configuration issues.
>>

>>> whipped up a quick python script(attached) that grabs the DROP list and
>>> compares it with the relay list and that turned up a two more, here's the

>> > I think a good first step would be to setup something like his script
>> > in a cronjob/nagios check/etc and have it alert when relays are using these
>> > IP ranges. Then a human could look at them and decide what to do. It may be
>> > enough to block a few, or maybe it turns into wack-a-mole, who knows.
>>
>> I'd do two things...
>> 1) As you and he suggested... get a handle on how many relays are
>> on which lists and why. See RBL removal DontBlockMe doc here...
>>
>> https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe
>>
>> 2) But not assume that they have no utility just because
>> they can't use provider. A better guage of that would be
>> to setup accounts on all the mail providers and exitmap
>> mail from all exits through all of them into a testbin at tpo.

Over half the exits support modern SUBMISSION, msmtp.sf.net
would easily test this (with fetchmail or mpop testing pulls)...

wc -l /tmp/25 /tmp/465 /tmp/587
      40 /tmp/25
     532 /tmp/465
     522 /tmp/587
sort /tmp/25 /tmp/465 /tmp/587 | uniq | wc -l
     547

>> If both provider and some overriding number of other
>> mail providers on the net were blocking tor exits
>> then perhaps some action could be taken in the
>> same way as if a particular exit had a port open
>> in their torrc but was blocking it in their packet filter,
>> or it was being blocked by their upstream, both
>> causing lack of utility.
>
> Well it's not just email, the DROP is intended to be used by ISPs and
> backbone providers. Maybe such an availability check should be even more
> generic.

It's worth looking into. I'd guess the percent of exits actually
affected would be quite low. Tier-n backbones don't subscribe
to such things, and last hop ISP's are too small to effect much.
Ie: Many exits and their users would repeatedly notice and report
that some /etc/service was being globally blocked in front of their
exits, mark the hoster (end ISP) on the goodbadisp wiki, etc.
I'm not aware of such quantity of reports. It could also be
that exits are testing their own exit's view first, and moving to
another hoster without reporting if their view sucks before
their exit has time to be used by users.

>> I don't mean they are consciously blocking exits,
>> but that choice is being made to subscribe
>> to a potentially blocky blocklist service.

>> Another option is to import the blocklists
>> into local configs after parsing out exit relays
>> via tordns queries.

> Or reject mail from those relays with a different message like "please use
> the tor hidden service instead".

Other than the web page docs an in-protocol message is a
good notification place too.

Let's see if whoever on tor-talk wants to pick this up as something
to be tested for as a project, then consider what the results mean.
Perhaps for any given "service / app" there will be a certain global
level of utility, less than which exits might then be recommended to
try to resolve it, relocate, or deconfigure that service in torrc.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk