<p>U,koo</p>
<div class="gmail_quote">On Jun 6, 2015 5:00 AM,  <<a href="mailto:tor-relays-request@lists.torproject.org">tor-relays-request@lists.torproject.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send tor-relays mailing list submissions to<br>
        <a href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:tor-relays-request@lists.torproject.org">tor-relays-request@lists.torproject.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:tor-relays-owner@lists.torproject.org">tor-relays-owner@lists.torproject.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of tor-relays digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Updating tor to get fix for #15083? (Elliott Jin)<br>
      (AlexK (Tor lists))<br>
   2. Re: Keeping an exit node off of blacklists due to botnet<br>
      activity. (<a href="mailto:tor@t-3.net">tor@t-3.net</a>)<br>
   3. BWAUTH weightings too volatile. . ."twitchy"<br>
      (<a href="mailto:starlight.2015q2@binnacle.cx">starlight.2015q2@binnacle.cx</a>)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 05 Jun 2015 14:32:05 +0200<br>
From: "AlexK (Tor lists)" <<a href="mailto:tor-relays@kalex.nl">tor-relays@kalex.nl</a>><br>
To: <a href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a><br>
Subject: Re: [tor-relays] Updating tor to get fix for #15083? (Elliott<br>
        Jin)<br>
Message-ID: <<a href="mailto:557196C5.7000103@kalex.nl">557196C5.7000103@kalex.nl</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
<a href="mailto:tor-relays-request@lists.torproject.org">tor-relays-request@lists.torproject.org</a> schreef op 05/06/15 om 14:00:<br>
<br>
> Updating tor to get fix for #15083? (Elliott Jin)<br>
><br>
>   - Is Tor 0.2.5.10 (git-43a5f3d91e726291) actually the newest stable<br>
>     version, or did I mess something up when trying to update tor?<br>
>   - Would it be a good idea to upgrade to an experimental version?<br>
<br>
Assuming you're running 'standalone' on *Nix, this is a good place to check:<br>
<br>
<a href="https://www.torproject.org/download/download-unix.html.en" target="_blank">https://www.torproject.org/download/download-unix.html.en</a><br>
<br>
Here you'll find the latest source (stable/unstable) and the latest<br>
packages for several *Nixes, including simple install instructions.<br>
<br>
Latest and greatest is 0.2.6.8, even if you rely on your package<br>
manager's updates this is what you should have, e.g. on my relay:<br>
<br>
$rpm -qa tor<br>
tor-0.2.6.8-tor.1.rh6_6.x86_64<br>
<br>
Good luck!<br>
Alex<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 05 Jun 2015 09:21:24 -0400<br>
From: <a href="mailto:tor@t-3.net">tor@t-3.net</a><br>
To: <<a href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a>><br>
Subject: Re: [tor-relays] Keeping an exit node off of blacklists due<br>
        to      botnet activity.<br>
Message-ID: <<a href="mailto:5571a254.4b95.8816c700.4c72f93d@t-3.net">5571a254.4b95.8816c700.4c72f93d@t-3.net</a>><br>
Content-Type: text/plain; charset=us-ascii; format=flowed<br>
<br>
<br>
 > I have a fairly high bandwidth exit node running for about a month<br>
now<br>
 > that I'm having difficulty keeping off of the<br>
<a href="http://cbl.abuseat.org/" target="_blank">http://cbl.abuseat.org/</a><br>
 > blacklist and have been informed of this listing by the VPS<br>
provider.<br>
 > The relay is running with a reduced exit policy -- and additionally<br>
I've<br>
 > blocked common mail ports, etc via IPFW so I know that no spam is<br>
 > actually being sent out of the relay. Still, various botnets<br>
connections<br>
 > are connecting to <a href="http://abuseat.org" target="_blank">abuseat.org</a> botnet sinkholes via port 80<br>
 > Command&Control connection attempts. I'm at a loss at how to stop<br>
this<br>
 > or somehow detect and filter botnet traffic.<br>
 ><br>
 > I've informed the VPS provider that I'm on top of it and have the<br>
 > machine configured to not actually allow this sort of malicious<br>
traffic<br>
 > out and they seem to be generally happy with that explanation, but<br>
a<br>
 > better solution if one exists would be appreciated.<br>
 ><br>
 > Thanks,<br>
 ><br>
 > Julian Plamann<br>
 ><br>
 > julian (at) <a href="http://amity.be" target="_blank">amity.be</a><br>
 > GPG: 0x96881D83<br>
<br>
Don't know if this will help, but maybe:<br>
<br>
ExitPolicy reject 85.159.211.119   # Cryptolocker<br>
ExitPolicy reject 212.71.250.4     # Cryptolocker<br>
ExitPolicy reject 54.83.43.69      # Cryptolocker<br>
ExitPolicy reject 192.42.116.41    # Cryptolocker<br>
ExitPolicy reject 192.42.119.41    # Cryptolocker<br>
ExitPolicy reject 198.98.103.253   # Cryptolocker<br>
ExitPolicy reject 208.64.121.161   # Cryptolocker<br>
ExitPolicy reject 142.0.36.234     # Cryptolocker<br>
ExitPolicy reject 173.193.197.194  # Cryptolocker<br>
<br>
In general, I see complaints about abuse from the exit relays we run<br>
due to someone using Tor to try to exploit remote web server scripts<br>
and databases and the like. I don't think there's anything that can be<br>
done about it? I would say that it's just part of what you get coming<br>
out out of Tor exit nodes.<br>
<br>
If anyone else has any better advice feel free to correct me but, I<br>
think it might be accurate to explain to the upstream that Tor exits<br>
will generate certain kinds of abuse complaints as part of normal<br>
operation. They open proxy web-related ports out, and some people<br>
abuse Tor for web hacking types of activity.<br>
<br>
I would say that it is normal for Tor exits to live permanently on<br>
certain kinds of blacklists. They do not need to be on the spam email<br>
related ones (reject *:25 and other email ports),  but they will land<br>
on other types of blacklists, and I don't think it can be helped.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 06 Jun 2015 02:43:09 -0400<br>
From: <a href="mailto:starlight.2015q2@binnacle.cx">starlight.2015q2@binnacle.cx</a><br>
To: <a href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a><br>
Subject: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"<br>
Message-ID: <<a href="mailto:6.2.5.6.2.20150606020527.04dbce00@flumedata.com">6.2.5.6.2.20150606020527.04dbce00@flumedata.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
I'm back to complain further about<br>
erratic bandwidth authority behavior,<br>
previously<br>
<br>
[tor-relays] BWauth kookiness<br>
<a href="https://lists.torproject.org/pipermail/tor-relays/2015-May/007039.html" target="_blank">https://lists.torproject.org/pipermail/tor-relays/2015-May/007039.html</a><br>
<br>
Allowing that BWauths are in a bit of flux,<br>
with tor26 replaced by maatuska and<br>
moria1 dropping the GuardFraction<br>
calculation, the bandwidth calculations<br>
evidence wildly erratic swings.<br>
<br>
Specifically my relay, which is perfectly<br>
stable, reliable, fast (9.375 Mbyte/sec)<br>
has been assigned a jaggedly random<br>
series of consensus weights.<br>
<br>
<a href="https://atlas.torproject.org/#details/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2" target="_blank">https://atlas.torproject.org/#details/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2</a><br>
<br>
earlier, fairly sane<br>
<br>
*gabelmoo  Bandwidth=7701 Measured=9960<br>
 tor26     Bandwidth=7701 Measured=9340<br>
 moria1    Bandwidth=7701 Measured=18000 GuardFraction=66<br>
 longclaw  Bandwidth=7701 Measured=12800<br>
<br>
later, bit high, nutty<br>
<br>
 gablemoo Bandwidth=9375 Measured=17100<br>
 moria1   Bandwidth=9375 Measured=77900 GuardFraction=75<br>
*longclaw Bandwidth=9375 Measured=23000<br>
<br>
now, sane but undervalued<br>
<br>
 gablemoo Bandwidth=8925 Measured=14900<br>
 maatuska Bandwidth=8925 Measured=17200<br>
 moria1   Bandwidth=8925 Measured=5330<br>
*longclaw Bandwidth=8925 Measured=7440<br>
<br>
moria1 here is downright schizophrenic<br>
but other BWauths regularly double<br>
and halve the bandwidth value they<br>
assign.  Graph shows it a more vividly.<br>
<br>
What the graphs and numbers do not show is<br>
that the effective difference between<br>
the consensus values of ~7000 and ~23000<br>
is staggering.  At the low end<br>
of this range the relay shows roughly<br>
2500 active circuits and a average<br>
load factor of about 20% of actual<br>
bandwidth, while an assignment of 23000<br>
results in almost 8000 circuits<br>
and a load factor of more like 50%<br>
(both per Blutemagie.de).<br>
<br>
My point is that BWauths should not<br>
be arbitrarily flipping stable, well<br>
run relays from the top to the bottom<br>
of this steeply sloped sweet-spot of<br>
the weighting curve.  Perhaps the<br>
sweet-spot range has moved over the<br>
last couple of years as the price of<br>
bandwidth has dropped and faster<br>
connections become more prevalent,<br>
and this has been overlooked in<br>
the algorithm.<br>
<br>
Regardless, it seems BWauth measurement<br>
should be more nuanced in this<br>
particular range, such that relays are<br>
not slammed constantly between "rather<br>
popular" and a "bit boring" irrespective<br>
of their actual available capacity.<br>
<br>
One reason this vexes is that I<br>
would like to see how well the relay<br>
runs with Address Sanitizer active.<br>
ASAN provides obvious benefits<br>
w/r/t security, but entails a<br>
performance trade-off.  With the<br>
BWauths throwing darts, eyes closed,<br>
when choosing weighting, it's<br>
impossible to gauge the performance<br>
impact of various adjustments.<br>
<br>
In the bigger picture view, erratic<br>
BWauth weighting can't be adding<br>
clarity to the performance,<br>
capacity and utilization situation.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
<br>
<br>
------------------------------<br>
<br>
End of tor-relays Digest, Vol 53, Issue 12<br>
******************************************<br>
</blockquote></div>