[tor-relays] tor-relays Digest, Vol 53, Issue 12
Victor Victoe
achievecard1960 at gmail.com
Mon Jun 8 06:37:50 UTC 2015
U,koo
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
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 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
> Jin)
> 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
> check:
>
> https://www.torproject.org/download/download-unix.html.en
>
> 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
> tor-0.2.6.8-tor.1.rh6_6.x86_64
>
> Good luck!
> Alex
>
>
>
> ------------------------------
>
> 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
> now
> > that I'm having difficulty keeping off of the
> http://cbl.abuseat.org/
> > blacklist and have been informed of this listing by the VPS
> provider.
> > The relay is running with a reduced exit policy -- and additionally
> I've
> > blocked common mail ports, etc via IPFW so I know that no spam is
> > actually being sent out of the relay. Still, various botnets
> connections
> > are connecting to abuseat.org botnet sinkholes via port 80
> > Command&Control connection attempts. I'm at a loss at how to stop
> this
> > 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
> traffic
> > out and they seem to be generally happy with that explanation, but
> a
> > 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 85.159.211.119 # Cryptolocker
> ExitPolicy reject 212.71.250.4 # Cryptolocker
> ExitPolicy reject 54.83.43.69 # Cryptolocker
> ExitPolicy reject 192.42.116.41 # Cryptolocker
> ExitPolicy reject 192.42.119.41 # Cryptolocker
> ExitPolicy reject 198.98.103.253 # Cryptolocker
> ExitPolicy reject 208.64.121.161 # Cryptolocker
> ExitPolicy reject 142.0.36.234 # Cryptolocker
> ExitPolicy reject 173.193.197.194 # 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: <6.2.5.6.2.20150606020527.04dbce00 at flumedata.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I'm back to complain further about
> erratic bandwidth authority behavior,
> previously
>
> [tor-relays] BWauth kookiness
> https://lists.torproject.org/pipermail/tor-relays/2015-May/007039.html
>
> 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.
>
>
> https://atlas.torproject.org/#details/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2
>
> 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
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> ------------------------------
>
> End of tor-relays Digest, Vol 53, Issue 12
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150607/80bafe4c/attachment-0001.html>
More information about the tor-relays
mailing list