U,koo On Jun 6, 2015 5:00 AM, <[email protected]> wrote:
> Send tor-relays mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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. ([email protected]) > 3. BWAUTH weightings too volatile. . ."twitchy" > ([email protected]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 05 Jun 2015 14:32:05 +0200 > From: "AlexK (Tor lists)" <[email protected]> > To: [email protected] > Subject: Re: [tor-relays] Updating tor to get fix for #15083? (Elliott > Jin) > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > [email protected] 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: [email protected] > To: <[email protected]> > Subject: Re: [tor-relays] Keeping an exit node off of blacklists due > to botnet activity. > Message-ID: <[email protected]> > 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: [email protected] > To: [email protected] > Subject: [tor-relays] BWAUTH weightings too volatile. . ."twitchy" > Message-ID: <[email protected]> > 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ------------------------------ > > End of tor-relays Digest, Vol 53, Issue 12 > ****************************************** >
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
