U,koo On Jun 6, 2015 5:00 AM, tor-relays-request@lists.torproject.org wrote:
Send tor-relays mailing list submissions to tor-relays@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@lists.torproject.org
You can reach the person managing the list at tor-relays-owner@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:
- Re: Updating tor to get fix for #15083? (Elliott Jin) (AlexK (Tor lists))
- Re: Keeping an exit node off of blacklists due to botnet activity. (tor@t-3.net)
- BWAUTH weightings too volatile. . ."twitchy" (starlight.2015q2@binnacle.cx)
Message: 1 Date: Fri, 05 Jun 2015 14:32:05 +0200 From: "AlexK (Tor lists)" tor-relays@kalex.nl To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Updating tor to get fix for #15083? (Elliott Jin) Message-ID: 557196C5.7000103@kalex.nl Content-Type: text/plain; charset=windows-1252
tor-relays-request@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@t-3.net To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Keeping an exit node off of blacklists due to botnet activity. Message-ID: 5571a254.4b95.8816c700.4c72f93d@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
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@binnacle.cx To: tor-relays@lists.torproject.org Subject: [tor-relays] BWAUTH weightings too volatile. . ."twitchy" Message-ID: 6.2.5.6.2.20150606020527.04dbce00@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/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1...
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
End of tor-relays Digest, Vol 53, Issue 12
tor-relays@lists.torproject.org
-
Victor Victoe