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