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