- tor-relays - lists.torproject.org

Re: [tor-relays] Qualities of a good relay (Sean Saito)
by Magnus Hedemark 25 Jun '15

25 Jun '15

These ideas are quite good. I think it would be interesting for a partner organization like the EFF maybe to gamify Tor relay best practices by issuing Mozilla type merit badges [ http://openbadges.org/ ] to relay operators. Setting it up is not free, volunteer time is not free, but it's a way to recognize volunteers in meaningful ways that does not require sending out tee shirts around the world. Importantly, badges should also be revoked if a relay operator is found to be behaving in less than meritorious ways. This is easily done. [ https://github.com/mozilla/openbadges-backpack/wiki/Revoking-Issued-Badges ] Magnus : E0B7C731568AC72AE848EDE91F857A3FED19ED0B @Magnus919 Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. -------- Original Message -------- Subject: Re: [tor-relays] Qualities of a good relay (Sean Saito) Time (GMT): Jun 25 2015 15:12:17 From: moritz(a)torservers.net To: tor-relays(a)lists.torproject.org Hi Sean, On 06/24/2015 03:07 AM, saitosean(a)ymail.com wrote: > Besides the obvious requirements of a good relay (e.g. speed, > geo-diversity, constant uptime), what qualities make a relay valuable to > the Tor network and its users? George posted some ideas a while ago: https://lists.torproject.org/pipermail/tor-dev/2014-July/007181.html I also remember another list of "diversity criteria" that someone posted, but I can't remember who or in which thread. -- Moritz Bartl https://www.torservers.net/ _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Let's talk incentives: addressing the social questions
by Ori Shimony 25 Jun '15

25 Jun '15

Hi All, I am an undergraduate researcher at the University of Virginia looking into the Tor Incentives Problem. I recently started running an exit-relay and plan on finding effective ways of encouraging others to do so as well! As a student of Computer Science and Anthropology, I am prioritizing both the technical and social angles of Tor's ecosystem in my approach to this problem. Thus far, many of the unanswered social questions regarding motivation and Tor have barred progress in efforts to scale the relay community. It is my objective to move this issue forward by conducting systematic research on the human-systems underlying Tor while developing proposals grounded in these socio-technical realities. One idea I’ve had is to discuss these issues and potential approaches one-on-one with some of the individuals currently operating relays. I think it would be really helpful to hear your ideas, questions, and personal insights on relay-volunteering and its future. If you are interested please email me at os7hf(a)virginia.edu with dates/times that would be convenient for a Skype or phone call. For general questions, comments, concerns, etc. feel free to respond on the mailing list as well. Thanks, Ori

1 0

Ports 465 and 587 vanished from reduced exit policy?
by Mike Perry 25 Jun '15

25 Jun '15

It appears that some years ago someone quietly removed port 465 and 587 from the reduced exit policy at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy without an explanation. I've added them back in, since these ports should only be used for user-authenticated SMTP, and not spam. Has anyone experienced any abuse from these ports that involved non-authenticated mail/spam? Otherwise, it seems that exit operators who were using the reduced exit policy should consider updating their polices to include these ports. -- Mike Perry

4 3

Re: [tor-relays] Qualities of a good relay (Sean Saito)
by saitosean＠ymail.com 25 Jun '15

25 Jun '15

Wow, thank you all for the suggestions! Hope to implement these soon. Would definitely appreciate more ideas too. Sean

4 4

Fwd: [Site5 #TZZN-12908]: DMCA Complaint: mybox.ganton.ca
by Bruce Ganton 25 Jun '15

25 Jun '15

Any advice on how to handle the following?? bg -------- Forwarded Message -------- Subject: [Site5 #TZZN-12908]: DMCA Complaint: mybox.ganton.ca Date: Wed, 24 Jun 2015 21:29:24 +0000 From: Site5 Level 2 Support <support(a)site5.com> To: bganton(a)tanglewood-cottage.ca <bganton(a)tanglewood-cottage.ca> <http://mandrillapp.com/track/click/14822339/www.site5.com?p=eyJzIjoiR3hNYjd…> [TZZN-12908]: DMCA Complaint: mybox.ganton.ca Carl Carl's Bio <http://mandrillapp.com/track/click/14822339/www.site5.com?p=eyJzIjoiUmlOVEd…> Tell us how we are doing: Good <http://mandrillapp.com/track/click/14822339/survey.site5.com?p=eyJzIjoiVWla…> Bad <http://mandrillapp.com/track/click/14822339/survey.site5.com?p=eyJzIjoiSG9R…> Greetings, Thank you for contacting Site5! Your inquiry has been assigned a ticket number (available in the subject of this email). Please include this string in the subject line of all future correspondence about this issue (or you can simply reply to this message with the ticket ID in the subject). We look forward to assisting you. If there is anything else we can do for you, please don't hesitate to let us know! Best Regards, The Site5 Support Team ------------ Hello Bruce, We are writing to you in connection with the below-pasted e-mail from the third party claimant specified therein (the Claimant) regarding certain materials contained in the specified web site mybox.ganton.ca that are infringing upon the Claimants intellectual property rights (the Infringing Materials). ***NOTE TO WORLD WIDE WEB HOSTING, LLC: PLEASE FORWARD THIS ENTIRE NOTICE TO ACCOUNT HOLDER OF IP ADDRESS 108.174.157.60 at 2015-06-23 00:39:23 North American Eastern Time*** June 23, 2015 Re: Notice of Unauthorized Use of Copyrights Owned by Two Out of Ten Productions Inc, Case #: U145963094 CEG TEK International ("CEG") represents Two Out of Ten Productions Inc, who owns all right, title and interest, including copyrights, in and to the work listed below (hereinafter the "Work"). (Some individuals may find certain words in titles of works to be offensive. CEG apologizes in advance if this is the case.) This notice is intended solely for the primary World Wide Web Hosting, LLC service account holder. Someone using this account has engaged in the unauthorized copying and/or distribution of the Work listed below. Evidence: Work Title: Odd Thomas Copyright Owner: Two Out of Ten Productions Inc Unauthorized File Name: Odd.Thomas.BRRip.XviD.AC3-WAR Unauthorized Hash: 69081b805ad400ef03f93f327a361d3d22176c48 Unauthorized File Size: 1486277285 bytes Unauthorized Protocol: BitTorrent Timestamp: 2015-06-23 00:39:23 North American Eastern Time Unauthorized IP Address: 108.174.157.60 Unauthorized Port: 50142 The following files were included in the unauthorized copying and/or distribution: File 1: Odd.Thomas.BRRip.XviD.AC3-WAR/wthomas.avi CEG TEK International ("CEG") hereby notifies you that unauthorized copying and/or distribution of Two Out of Ten Productions Inc's Work listed above is a violation of the U.S. Copyright Act, 17 U.S.C. 106. In this regard, request is hereby made that you and all persons using this account immediately and permanently cease and desist from unauthorized copying and/or distribution of the Work. CEG informs you that you may be held liable for monetary damages, including court costs and/or attorney fees if a lawsuit is commenced against you for unauthorized copying and/or distribution of the Work listed above. You have until Thursday, July 23, 2015 to access the settlement offer and settle online. To access the settlement offer, please visit https://www.copyrightsettlements.com/ and enter Case #: U145963094 and Password: usp7k. To access the settlement offer directly, please visit https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Information: Direct Settlement Link: https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Website: https://www.copyrightsettlements.com/ Case #: U145963094 Password: usp7k If you fail to respond or settle within the prescribed time period, the above matter may be referred to attorneys representing the Work's owner for legal action. At that point the original settlement offer will no longer be an option, and the settlement amount will increase significantly. Nothing contained or omitted from this correspondence is, or shall be deemed to be either a full statement of the facts or applicable law, an admission of any fact, or waiver or limitation of any of the Two Out of Ten Productions Inc's rights or remedies, all of which are specifically retained and reserved. The information in this notice is accurate. CEG has a good faith belief that use of the material in the manner complained of herein is not authorized by the copyright owner, its agent, or by operation of law. CEG and the undersigned declare under penalty of perjury, that CEG is authorized to act on behalf of Two Out of Ten Productions Inc. Sincerely, Ira M. Siegel, Esq. Legal Counsel CEG TEK International 8484 Wilshire Boulevard, Suite 515 Beverly Hills, CA 90211 Toll Free: 877-526-7974 Email: support(a)cegtek.com Website: www.copyrightsettlements.com - ----Start ACNS XML U145963094 https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Open Normal CEG TEK International Ira M. Siegel, Esq. CEG TEK International, 8484 Wilshire Boulevard, Suite 515, Beverly Hills, CA 90211 877-526-7974 support(a)cegtek.com World Wide Web Hosting, LLC United States abuse(a)worldwidewebhosting.com 2015-06-23T04:39:23Z 108.174.157.60 50142 P2P 1 2015-06-23T04:39:23Z Odd Thomas Odd.Thomas.BRRip.XviD.AC3-WAR 1486277285 Movie 69081b805ad400ef03f93f327a361d3d22176c48 DMCA Odd Thomas true true 5 June 23, 2015 Re: Notice of Unauthorized Use of Copyrights Owned by Two Out of Ten Productions Inc, Case #: U145963094 CEG TEK International ("CEG") represents Two Out of Ten Productions Inc, who owns all right, title and interest, including copyrights, in and to the work listed below (hereinafter the "Work"). (Some individuals may find certain words in titles of works to be offensive. CEG apologizes in advance if this is the case.) This notice is intended solely for the primary World Wide Web Hosting, LLC service account holder. Someone using this account has engaged in the unauthorized copying and/or distribution of the Work listed below. Evidence: Work Title: Odd Thomas Copyright Owner: Two Out of Ten Productions Inc Unauthorized File Name: Odd.Thomas.BRRip.XviD.AC3-WAR Unauthorized Hash: 69081b805ad400ef03f93f327a361d3d22176c48 Unauthorized File Size: 1486277285 bytes Unauthorized Protocol: BitTorrent Timestamp: 2015-06-23 00:39:23 North American Eastern Time Unauthorized IP Address: 108.174.157.60 Unauthorized Port: 50142 The following files were included in the unauthorized copying and/or distribution: File 1: Odd.Thomas.BRRip.XviD.AC3-WAR/wthomas.avi CEG TEK International ("CEG") hereby notifies you that unauthorized copying and/or distribution of Two Out of Ten Productions Inc's Work listed above is a violation of the U.S. Copyright Act, 17 U.S.C. 106. In this regard, request is hereby made that you and all persons using this account immediately and permanently cease and desist from unauthorized copying and/or distribution of the Work. CEG informs you that you may be held liable for monetary damages, including court costs and/or attorney fees if a lawsuit is commenced against you for unauthorized copying and/or distribution of the Work listed above. You have until Thursday, July 23, 2015 to access the settlement offer and settle online. To access the settlement offer, please visit https://www.copyrightsettlements.com/ and enter Case #: U145963094 and Password: usp7k. To access the settlement offer directly, please visit https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Information: Direct Settlement Link: https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Website: https://www.copyrightsettlements.com/ Case #: U145963094 Password: usp7k If you fail to respond or settle within the prescribed time period, the above matter may be referred to attorneys representing the Work's owner for legal action. At that point the original settlement offer will no longer be an option, and the settlement amount will increase significantly. Nothing contained or omitted from this correspondence is, or shall be deemed to be either a full statement of the facts or applicable law, an admission of any fact, or waiver or limitation of any of the Two Out of Ten Productions Inc's rights or remedies, all of which are specifically retained and reserved. The information in this notice is accurate. CEG has a good faith belief that use of the material in the manner complained of herein is not authorized by the copyright owner, its agent, or by operation of law. CEG and the undersigned declare under penalty of perjury, that CEG is authorized to act on behalf of Two Out of Ten Productions Inc. Sincerely, Ira M. Siegel, Esq. Legal Counsel CEG TEK International 8484 Wilshire Boulevard, Suite 515 Beverly Hills, CA 90211 Toll Free: 877-526-7974 Email: support(a)cegtek.com Website: www.copyrightsettlements.com]]> - ----End ACNS XML This is an automated email. If you have questions or concerns, please visit us at http://www.copyrightsettlements.com/contact_us.html. Replies sent to dmca(a)cegtek.com are not read. Please review the following complaint and follow up with us to let us know the steps you intend to take to resolve this. Failure to follow up within that time may lead to suspension of your account.Please note that under the Digital Millennium Copyright Act, you have the right to file a counter-notice claiming that either (a) that the Claimant is wrong and that the Infringing Material is lawfully posted on the Web Site or (b) that the Infringing Material has been misidentified. You can use this online form at http://support.scribd.com/entries/22993-DMCA-counter-notification-template which is an editable template containing all the required elements for counter-notification which you can send back to us. Thanks, Carl B. Abuse Administrator, Site5.com Ticket Details =================== Ticket ID: TZZN-12908 Department: Level 2 Support Status: Awaiting Customer Reply Backstage Login <http://mandrillapp.com/track/click/14822339/backstage.site5.com?p=eyJzIjoiV…> | Service Notices <http://mandrillapp.com/track/click/14822339/forums.site5.com?p=eyJzIjoiOG95…> | Support Center <http://mandrillapp.com/track/click/14822339/www.site5.com?p=eyJzIjoiR3JhX3N…> | Knowledge Base <http://mandrillapp.com/track/click/14822339/kb.site5.com?p=eyJzIjoiNk1ITGJJ…>

3 2

Re: [tor-relays] Fwd: [Site5 #TZZN-12908]: DMCA Complaint: mybox.ganton.ca
by tqr2813d376cjozqap1l＠tutanota.com 24 Jun '15

24 Jun '15

Send back a reply using this template: https://www.torproject.org/eff/tor-dmca-response.html

1 0

A bridge too far
by jchase 24 Jun '15

24 Jun '15

Hello, Can anybody help me figure out why my bridge has stopped showing the flags fast, running and stable? Especially stable, I would love to get that flag back. I run two bridges, on two different Rasp Pi's, the one with a globe fingerprint of B08284109C72C81ACF5866A17A4CC64CE3E16499 . The other with a globe fingerprint of 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . The first bridge runs with obfs 3 & 4 on a Pi 2. It seems I lost the stable flag around the time I got obfs 4 up and running. The second bridge runs only with obfs 3 on an older Pi. I've read that the stable flag is quite handy. Any ideas about how I can get it back? Greetings, J Chase

3 2

exit to youtu.be via germany gema
by tor-server-creator＠use.startmail.com 24 Jun '15

24 Jun '15

german exit for https://youtu.be/ is breaking functionality due to disunity between google and gema. since years now. anyhow german exits shouldnt block youtube ip's, now should they?

3 3

Problems with second/third relay
by TORnet Zone 24 Jun '15

24 Jun '15

Really need some help here, just cannot find the answer. I've been running 2 middle relays for a year now, from a home/business IP, one DSL and the other cable. Only problems were brief and IP induced all has served the system well. I recently attempted to add a 3rd relay on the same cable feed as one of my others, but there is no way the ORport will connect. I have DMZ'd the static address, forwarded the ports, changed the ports - the ORport just will not open. And yes I realize diversity is tightened, but I'm trying to help all I can on my budget. First - CAN there be two relays on the same dynamic address (different port numbers) ? How? Do I need some form of DNS service to help? Relay 1 is Linux 3.2.0-86 and Tor 0.2.6.9. Relay 2 is Linux 3.16.0-30 and Tor 0.2.6.9. The DMZ'd relay worked until I had to forward 9001 to the 2nd, then it quit. Uptime was normally 40 - 50 days until a kernel update, or something major. Both are old laptops on battery backups that never have power down. Router is an Archer C7, latest firmware. -Gumby

4 4

Raspberry Pi - Relay Setup
by Tor Zilla 24 Jun '15

24 Jun '15

Hello All, I just bought a Raspberry Pi.. Wanted to setup as a Tor non exit relay. I have read so many instructions online on how to set it up but i am facing issues with opening ports. I am using a NetGear Router and require your inputs with the same. Also is static IP mandatory for setting up a relay? Thanks, TorZilla11

7 9

Re: [tor-relays] Qualities of a good relay (Sean Saito)
by teor 24 Jun '15

24 Jun '15

> Date: Wed, 24 Jun 2015 01:07:28 +0000 > From: <saitosean(a)ymail.com> > > I?m currently working with Dr. Virgil Griffith on Roster, a tor project that aims to reward relay operators with good relays. > > Right now we are brainstorming how to measure/quantify a good relay. > > Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users? Autonomous System diversity, and similarly, IP-netblock diversity Operator diversity (ContactInfo, MyFamily) Operating System diversity, perhaps (most of the Tor network is Linux, including BSDs/OS X and others avoids a monoculture, but Windows is considered less secure) teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by teor 23 Jun '15

23 Jun '15

> Date: Tue, 23 Jun 2015 13:09:07 +0200 > From: Fabian Keil <freebsd-listen(a)fabiankeil.de> > > nusenu <nusenu(a)openmailbox.org> wrote: > >>> … >>> Did you test with custom flags like "--+Log ${tor_loglevel} file >>> ${tor_logfile}"? >> >> This should read "--Log" no? > > While I prefer using neither "--Log" nor "--+Log", the latter > is valid syntax and used in the real world: > https://svnweb.freebsd.org/ports/head/security/tor-devel/files/tor.in?view=… > > … >> - From tor's man page: >>> Other options can be specified on the command-line in the format >>> "--option value", in the format "option value", or in a >>> configuration file. > > Looks like the man page is incomplete. See the next section, "THE CONFIGURATION FILE FORMAT" > By default, an option on the command line overrides an option found in > the configuration file, and an option in a configuration file overrides > one in the defaults file. > > This rule is simple for options that take a single value, but it can > become complicated for options that are allowed to occur more than > once: if you specify four SOCKSPorts in your configuration file, and > one more SOCKSPort on the command line, the option on the command line > will replace all of the SOCKSPorts in the configuration file. If this > isn't what you want, prefix the option name with a plus sign, and it > will be appended to the previous set of options instead. > > Alternatively, you might want to remove every instance of an option in > the configuration file, and not replace it at all: you might want to > say on the command line that you want no SOCKSPorts at all. To do that, > prefix the option name with a forward slash. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by nusenu 23 Jun '15

23 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Did this reply make the intentions clearer? > >> Yes, thanks. Though my first inclination would be to tell users >> "don't use rc.d if you've got the ansible role configured", I >> suppose it can't hurt to make it foolproof. I'll test your patch >> in different scenarios, and, if it works, commit it. Thank you! -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViTfhAAoJEFv7XvVCELh0164P/2ORfHYYdh2MbihJP/3yrKoK JuvgHLcRmYHob7s8vFAzdg8KqpriyNGuWCGY1b5ameXNFpy5slwGP0wmTFIe8qIA pfHVO1Oo1r4vFpMq5PEjHZloBLBnjxwDbcuC2D+b4f8YeOMjSeB4Rf6yXWF2EXju 3cEsUb5UguQ6YAcFItlW8Es/XijHp5Ad1e2DUXpl/te8FH7VxoK41ctILP4zs0kM ykPWgq7j5V0/OQS4BOe71i85S37sssejTFyPLV6kTdDUN1zLZKiUZljkgktfjAwm uMGp3FGnVWL0mN6KmK0OM1DesbRsIv0yMU/FIUyaL0vOnh/vgDt/o2seBKo7Evsy Po6w/J5X27M3gsFG5HtNuyrONssndvSsVwNQvpXf2vTiz342fulRnptCjvtNz+iI CGfpJ6i2VHH7ZMY0ZDYIfBrgZDa/HdzlZU9gk4hmORJOpol4jMjqDu44K7RW8PLo hHTqa/gWBKZsOwSpXDjsQyMYCFGvxcCXdqDOa1KNJa4zw/pZur52b7fv0s8/+Lky u19lBODZO/7br1Sg4fwmMjLVUbkQtIwtmBdbRWP6zqEByFEt/LJSt93RXs2rMtX0 IVKWCvh3+G04nZkv0AbF/YeMKe9ABp1pbP7I3M+X0wOdKzpPsBLjjUYxaOpZnhqn 7wJDlcBTqVQ86e1lavlD =WeYu -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by nusenu 23 Jun '15

23 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Pascal, thanks for the fast reply. I think there is a slight misunderstanding. >> rc.subr(8) does not have multi-instance support, and it will most >> likely stay that way. Correct, and I'm _not_ trying to add that in any way to rc.subr or to your rc script. > What you're trying to do is going against that design >> decision, so I suggest you simply don't use the rc.d subsystem >> if configured for multiple instances. Even if I'm not using it at all, your rc script will kill unrelated tor instances, this is not limited to an ansible environment. The goal is only to be able to have your tor package + the ansible role on the same system without the rc script from the package interfering with unrelated tor instances created via ansible. >> I mean: As soon as you have more than one tor instance running, >> you'll have to implement a way to start/stop/restart/reload all >> of them individually anyway That is already done. Did this reply make the intentions clearer? After all the proposed fix should not generate any new problem or effort for your package, or does it? thanks! -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViTOUAAoJEFv7XvVCELh0wVUP/1PX+HjEUvDTlg8mKZzCwy4Q pXbSQpqEyuXDLbAYvN2GOnL0Vd8jSH5NxpuRFHnevdEC0/vdAbRRAJRbQwXSneYk 60XCVCLW8IFsNwDNjzDf1oXkcQFIkPQW7uoyFWxn7Km/JITtRIrpmpfdMYQ1ievM DBIEFZZWg1/Oa2NsxYPc1NQHdFoxbRLEwmRT8bZCHuPjB+pULTjZyuCpTcO4xcmt peE5SeE74X4oakrHqjLdoF0Vmcak1NNpulvV/Q/GMhqzucAbnvzoUrEHNn5ffxhC s+dd5kkrOwN61E3vg+1JxdWSK2Bh6Equ8DgIhW4pNOlenmGLQwL8HeuQ6hAJafCt rPAdEP9RtKIB+uj0KvZtngUhlkonnHeu/NGX6wSfwgL1S8SjSBCRCVPWDKs+Bkdx PM4VGBHw9USdXbBPrKvMpvDKxoX5wNJOBArTdz3UfJh+sow5tD0i/+Oq8bVK0s4u cu9TNHH+/SdriGNcwaOTKYdJ3tCQke2ACYREYrVdM6iaBKlhMhEy2oWWa/05Cp+S k5GCdsUWP/ppDK+OGHbxQ5h9xAxjNgF8myh32uMS8e0arG2X8ibnFd+1QYg+pL5s tUby7RMu0p6LsVYL7G0s1nWpaANFn8qcSdIT5AAdEOtCSl1pR973OeMh4xGoYa4+ awnwja7uPHk6DnjPY1yZ =JcuP -----END PGP SIGNATURE-----

1 0

OR port no longer reachable
by Patrick Derwael 22 Jun '15

22 Jun '15

Guys, I've been running a relay since many months without issue (Tor 0.2.6.9 on CentOS 6 fully patched) Since a few weeks, my OR port is no longer reachable without apparent reason (Dirport remains reachable on port 9030) [warn] Your server (xx.xx.xx.xx:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Nothing changed on my network nor on the config... Both Dir & OR port are open and routed properly (Nmap checked from the Net) Selinux & firewalling are disabled, nothing but localhost in /etc/hosts... I'm kinda puzzled... Could you tell me where I should investigate further? Thanks!

1 0

Messages
by Adrian Soh 21 Jun '15

21 Jun '15

Is there a way to send out messages that all tor relays will display to other circuits? Or any mailing system where I could send out to lists and boards?

1 0

Re: [tor-relays] Tor relay is restarting every minute
by teor 20 Jun '15

20 Jun '15

> Date: Fri, 19 Jun 2015 06:42:59 -0500 > From: Michael <mctor(a)biographiks.com> > Jun 19 06:10:34.000 [warn] The communication stream of managed proxy > '/usr/local/bin/obfsproxy' is 'closed'. Most probably the managed > proxy stopped running. This might be a bug of the managed proxy, a bug > of Tor, or a misconfiguration. Please enable logging on your managed > proxy and check the logs for errors. Please provide the obfsproxy logs. You might also find that the tor debug-level logs around the time of the interrupt are useful. > Jun 19 06:11:43.958 [warn] OpenSSL version from headers does not match > the version we're running with. If you get weird crashes, that might > be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running > with 1000106f: OpenSSL 1.0.1f 6 Jan 2014). > Jun 19 06:11:43.958 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) > running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib > 1.2.8. Please run tor with the OpenSSL version it was compiled with, and see if that makes a difference. > Jun 19 06:10:28.722 [notice] We were compiled with headers from > version 2.0.19-stable of Libevent, but we're using a Libevent library > that says it's version 2.0.21-stable. Please try using the same Libevent version tor was compiled with, and seeing if that makes a difference. You might also want to consider the following: tor is shutting down because it's receiving an interrupt signal. Which interrupt is it receiving? What is sending the interrupt signal to tor? Potential options are cron, a memory or server watchdog process, a rogue process, or perhaps a hardware fault. obfsproxy isn't running. Why does the obfsproxy process not start up/not keep running/shut down? Did you do anything else to your server around the time of the move? Upgrade software? Drop it? (I only ask because a hardware fault can trigger certain kinds of interrupts.) Does AT&T block certain types of connections? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

BWAUTH weightings too volatile. . ."twitchy"
by starlight.2015q2＠binnacle.cx 19 Jun '15

19 Jun '15

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/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF… 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.

1 2

Tor relay is restarting every minute
by Michael 19 Jun '15

19 Jun '15

My Tor relay interrupts and restarts every minute (without my involvement), so it isn't usable by anyone. Nothing new in my obfsproxy log. My relay was running fine until I moved and changed to a new ISP (AT&T). Jun 19 06:10:28.717 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8. Jun 19 06:10:28.717 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jun 19 06:10:28.717 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jun 19 06:10:28.717 [notice] Read configuration file "/etc/tor/torrc". Jun 19 06:10:28.722 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand. Jun 19 06:10:28.722 [notice] We were compiled with headers from version 2.0.19-stable of Libevent, but we're using a Libevent library that says it's version 2.0.21-stable. Jun 19 06:10:28.722 [notice] Opening Control listener on 127.0.0.1:9051 Jun 19 06:10:28.723 [notice] Opening Control listener on /var/run/tor/control Jun 19 06:10:28.723 [notice] Opening OR listener on 0.0.0.0:9001 Jun 19 06:10:28.723 [notice] Opening Extended OR listener on 127.0.0.1:0 Jun 19 06:10:28.723 [notice] Extended OR listener listening on port 55831. Jun 19 06:10:28.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Jun 19 06:10:28.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Jun 19 06:10:28.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Jun 19 06:10:29.000 [notice] Your Tor server's identity key fingerprint is [REDACTED] Jun 19 06:10:29.000 [notice] Your Tor bridge's hashed identity key fingerprint is [REDACTED] Jun 19 06:10:29.000 [notice] Bootstrapped 0%: Starting Jun 19 06:10:33.000 [notice] Bootstrapped 80%: Connecting to the Tor network Jun 19 06:10:34.000 [warn] The communication stream of managed proxy '/usr/local/bin/obfsproxy' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. Jun 19 06:10:34.000 [notice] Failed to terminate process with PID '13164' ('Success'). Jun 19 06:10:34.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Jun 19 06:10:35.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Jun 19 06:10:36.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jun 19 06:10:36.000 [notice] Bootstrapped 100%: Done Jun 19 06:11:13.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Jun 19 06:11:43.000 [notice] Clean shutdown finished. Exiting. Jun 19 06:11:43.000 [notice] Tor 0.2.6.9 (git-145b2587d1269af4) opening log file. Jun 19 06:11:43.958 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running with 1000106f: OpenSSL 1.0.1f 6 Jan 2014). Jun 19 06:11:43.958 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.

1 0

Installing Tor-ramdisk
by eldorado 17 Jun '15

17 Jun '15

Installing Tor-ramdisk I have question about installing Tor-ramdisk on Dedicated server in hetzner datacenter. I want install iso file without using USB and DVD . i followed this link[1] . My iso file is in my VPS that LARA could access to iso via SAMBA/CIFS . LARA shows me the iso file attached but after running KVM and press F11 the boot menu have my hard disks not "PepperC Virtual Disc 1 0.01" in boot menu . How i can mount Tor-ramdisk with KVM . i don't want pay € 21.01 for using USB stick/DVD . [1] http://wiki.hetzner.de/index.php/LARA/en

1 0

Questions about GUI monitor
by nks nks 17 Jun '15

17 Jun '15

Dear Sir/Madam: My system is Debian 32bit, Tor non-exit bridge. 1. For Debian, is there any pure Tor service monitoring and analyzing software for the local machine (not the entire Tor network), with/without a GUI ? 2. Does "Vidalia" really end developing? May I ask why? May I install the "Vidalia" which is still could be found in the Debian apt system? 3. https://www.torproject.org/projects/projects.html.en "orlib" the link is dead. 4. About "Tor2web", are there any clearer figures and docs which could explain the security differences between "Tor" and "Tow2web" ? Especially for the client. Thank you.

4 4

Exit relay is apparently being used to attack other servers
by trillium 16 Jun '15

16 Jun '15

Hello, I’m running an exit relay (fingerprint: 5793CB9E1F5BAD3D5DA6C4158E16067D80CD8A2E) on a Linode VPS right now, and so far they’ve been really fantastic with dealing with a couple of DMCA notices that were sent to them. However, in the last week, I received notice from them that my server is attacking multiple sites around the web. Their suggestion was to go through my logs and remove the offending user, which is obviously unhelpful advice as I don’t keep any logs on my relay’s users. I’d like to keep running the exit relay, but I’m not really sure how to best go about mitigating these sorts of threats and don’t want Linode to shut down the entire server. Any suggestions are very much welcomed. Thanks, trillium

6 6

Encryption in French servers
by Javi 15 Jun '15

15 Jun '15

I know in France it's illegal to encrypt data so if I run a tor relay in a French server I would have any problem? Thanks.

2 1

Re: [tor-relays] Exit relay is apparently being used to attack other servers
by spiros_spiros＠freemail.gr 13 Jun '15

13 Jun '15

Hi Trillium, It is always sad when Tor is used to hack/DoS/compromise servers. As operator of an Exit Node unfortunately you will see as well as the DMCA notice the hacking/abuse/spamming/botnet alerts from some service provider, also you will get notification that the node is added to this blacklist and that spammer list. My advice is to work very closely with your Exit Node datacentre and make them know that you respond quickly to abuse emails (even the annoying automatic ones) with polite message to tell them you have a Tor Exit and cannot provide details of traffic source or realistically block individual user or IP. If the datacentre is friendly you will hopefully not be shut down or account closed. If you get paranoid about one particular provider, or they harass you with email threats/notifications you could use iptables or ipfw to block individual host, or close the port to the Exit Node in your torrc. It would be better to explain situation if you are in contact with them and go from there. In my experience when I email complaining party to explain I run Tor relays I almost never get a response but sometimes they just block the Exit Node IP on their firewall which is fine. If really paranoid, consider moving to provider that does not require scan of government ID or passport, pay with BitCoin if possible, don't provide real house address and don't log in to server from your home IP. As others have written before me, Linode is not great for Tor friendliness. S On 13 Jun 2015, at 19:03, trillium <trillium(a)riseup.net> wrote: Hello, I’m running an exit relay (fingerprint: 5793CB9E1F5BAD3D5DA6C4158E16067D80CD8A2E) on a Linode VPS right now, and so far they’ve been really fantastic with dealing with a couple of DMCA notices that were sent to them. However, in the last week, I received notice from them that my server is attacking multiple sites around the web. Their suggestion was to go through my logs and remove the offending user, which is obviously unhelpful advice as I don’t keep any logs on my relay’s users. I’d like to keep running the exit relay, but I’m not really sure how to best go about mitigating these sorts of threats and don’t want Linode to shut down the entire server. Any suggestions are very much welcomed. Thanks, trillium _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Recommendation: Upgrade your OpenSSL! (Nick Mathewson)
by teor 12 Jun '15

12 Jun '15

> Date: Thu, 11 Jun 2015 14:30:35 -0400 > From: Nick Mathewson <nickm(a)torproject.org> > > Hi, relay operators! > > There have been a series of new openssl releases today: 0.9.8zg, > 1.0.0s, 1.0.1n, and 1.0.2b. > > They fix a set of security issues described in this announcement: > https://www.openssl.org/news/secadv_20150611.txt > > Since some of these issues could allow a remote denial-of-service > attack, I would suggest that everybody should upgrade as OpenSSL > packages become available for your operating systems. If you build > OpenSSL from source, now's a good time to rebuild. You probably don't > need to run in circles freaking out, or anything -- just upgrade when > you can. > > Also, if you can possibly avoid it, it would be a good idea to stop > using the OpenSSL 0.9.8 series entirely. It's old and crufty and is > missing many security improvements in later versions. OpenSSL 0.9.8 > will not be supported in Tor 0.2.7.2-alpha or later. Please also note that OpenSSL versions 0.9.8 and 1.0.0 are becoming unsupported at the end of 2015: "As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html) support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade." See the second-last section in https://www.openssl.org/news/secadv_20150611.txt teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Recommendation: Upgrade your OpenSSL!
by Nick Mathewson 11 Jun '15

11 Jun '15

Hi, relay operators! There have been a series of new openssl releases today: 0.9.8zg, 1.0.0s, 1.0.1n, and 1.0.2b. They fix a set of security issues described in this announcement: https://www.openssl.org/news/secadv_20150611.txt Since some of these issues could allow a remote denial-of-service attack, I would suggest that everybody should upgrade as OpenSSL packages become available for your operating systems. If you build OpenSSL from source, now's a good time to rebuild. You probably don't need to run in circles freaking out, or anything -- just upgrade when you can. Also, if you can possibly avoid it, it would be a good idea to stop using the OpenSSL 0.9.8 series entirely. It's old and crufty and is missing many security improvements in later versions. OpenSSL 0.9.8 will not be supported in Tor 0.2.7.2-alpha or later. best wishes, and many thanks! -- Nick Mathewson

1 0

Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
by starlight.2015q2＠binnacle.cx 10 Jun '15

10 Jun '15

>Mon Jun 8 05:25:55 UTC 2015 >> UBSAN seems expensive and doesn't seem >> it would run other than test, but >> I didn't work on it long and am not >> 100% certain. Was trying ASAN extra >> stack checking at the time, which may >> have been the culprit. > >As I said in my previous email, if you're >running releases before 0.2.6.6 (2015), >Tor won't run under UBSAN due to issues >that have been fixed in subsequent >releases. Had a need to run ASAN+UBSAN and it works perfectly fine for me with version 0.2.4.27. Required a minor patch to convert a single common variable 'incoming_queue' to extern. Performance hit was not as bad as I thought from the earlier try, but bad enough that I limited the instrumented modules to only what's necessary.

1 0

Incorrect IP Address change reported
by Pascal Terjan 10 Jun '15

10 Jun '15

I got my IP address reported as changed to some Deutsche Telekom IP twice in a few minutes by 154.35.175.225 yesterday This IP is "Faravahar" according to https://trac.torproject.org/projects/tor/ticket/14487 Jun 09 12:21:50.000 [notice] Our IP Address has changed from 149.18.2.82 to 91.5.121.93; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:21:51.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:21:54.000 [notice] Performing bandwidth self-test...done. Jun 09 12:22:51.000 [notice] Our IP Address has changed from 91.5.121.93 to 149.18.2.82; rebuilding descriptor (source: 86.59.21.38). Jun 09 12:22:51.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:22:51.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jun 09 12:23:52.000 [notice] Our IP Address has changed from 149.18.2.82 to 91.5.121.93; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:23:52.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:24:10.000 [notice] Our IP Address has changed from 91.5.121.93 to 149.18.2.82; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:24:10.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:25:00.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.

2 1

Cheap exit-friedly VPS provider
by Alexey Nayden 10 Jun '15

10 Jun '15

Hello everybody, A couple of months ago I decided to run a Tor exit relay. I contacted several VPS and dedicated providers and ended up using PulseServers, because they offered unmetered fast channel for ~$13/month and were Tor-friendly. Only after installing and configuring the relay I realized their IPs are from OVH AS and they are OVH resellers. I understand OVH AS'es already dominate the network and should be avoided if possible, so I have 2 questions: 1. Is there a comparable alternative? 100 Mbit/s unmetered (or 20+ TB of traffic) for less than $20/month. I imagine cheap OpenVZ virts can't handle even 100 Mbit/s anyway, so I'm not looking for top performance, but I want something that can do at least 50 Mbit/s 24/7. 2. If one decided to use OVH AS, are VPS that OVH sells directly good enough? They have virts as cheap as 2.99/month with at least 10Tb at 100Mbit/s (http://www.ovh.com/us/vps/vps-classic.xml) Thanks! -- Alexey Naiden

7 7

Re: [tor-relays] Cheap exit-friedly VPS provider
by spiros_spiros＠freemail.gr 09 Jun '15

09 Jun '15

I have an exit on Wedos since April and so far things have been well. I receive the usual abuse/hacking/nastiness complaint and respond politely within 72 hour. The only issue is on Atlas the exit doesn't yet have exit flag, but I am assuming this is down to bwauth issue etc etc. Will happily recommend. S On 9 Jun 2015, at 17:28, Andrej Manduch <amanduch(a)gmail.com> wrote: Hi Alexey-san, I'm running tor exit relay on VPS from amerinoc and they didn't seems to have problem with that. I mentioned that when I asked them to change abuse e-mail for ip-address and they were ok with that. However I would definitly recommend you to take look at this list: https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs I also heard that https://hosting.wedos.com/en/ are very tor friendly and they're really cheap (about 100 bucks/year). On 06/09/2015 11:43 AM, Stephen R Guglielmo wrote: On Mon, 8 Jun 2015 22:35:28 -0700 Alexey Nayden <alexey.nayden(a)gmail.com> wrote: Hello everybody, A couple of months ago I decided to run a Tor exit relay. I contacted several VPS and dedicated providers and ended up using PulseServers, because they offered unmetered fast channel for ~$13/month and were Tor-friendly. Only after installing and configuring the relay I realized their IPs are from OVH AS and they are OVH resellers. I understand OVH AS'es already dominate the network and should be avoided if possible, so I have 2 questions: 1. Is there a comparable alternative? 100 Mbit/s unmetered (or 20+ TB of traffic) for less than $20/month. I imagine cheap OpenVZ virts can't handle even 100 Mbit/s anyway, so I'm not looking for top performance, but I want something that can do at least 50 Mbit/s 24/7. 2. If one decided to use OVH AS, are VPS that OVH sells directly good enough? They have virts as cheap as 2.99/month with at least 10Tb at 100Mbit/s (http://www.ovh.com/us/vps/vps-classic.xml) I can't say for exits, but I use the OVH Classic VPS ($2.99/mo) to run one of my relays. It's not an exit node. I let them know about it and paid a year in advance. No problems whatsoever with them thus far. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Improving Node Connection Testing
by starlight.2015q2＠binnacle.cx 09 Jun '15

09 Jun '15

>Mostly, latency and packet loss in nodes >will negatively impact Tor's usability. . . Was reading this thread and thought of potentially useful and perhaps not overly difficult BWauth enhancement--perhaps worth considering as part of ongoing efforts to rework the BWauth scripts. When measuring a node, a BWauth could spawn a 'tcpdump -w' PCAP capture of the specific test connection traffic and SIGTERM it when that's finished. Then run some tool or another to analyze the connection for SACKs and/or other indications of the quality of the relay and path. Here's one example: https://github.com/lennart-schulte/tcpdump-analyzer Alternately, such a mechanism could rely on a continuous 'tcpdump' running with a large circular buffer and a script or program could follow the test connections and spit out a statistical summary for completed ones to a text log that would then be consumed by the BWauth scripts. If the idea has potential, someone could perform a casual passive 'tcpdump' of test traffic and examine a few connections.

1 0

(n00b) Exit node question
by Hong, Yongmin 08 Jun '15

08 Jun '15

Hello, it's my first time running an exit. (Well, I'm n00b in running a relay too :p) I think I followed the guidelines correctly to be an exit (with some modification from reduced exit policy on trac), but atlas and globe reports that my exitpolicy is "reject *:*". My configuration is at [1]. Please tell me what's wrong here. Thanks! [1]: https://phabricator.wikimedia.org/P740 -- Revi https://www.revi.pe.kr -- Sent from Android --

3 5

Re: [tor-relays] tor-relays Digest, Vol 53, Issue 12
by Victor Victoe 08 Jun '15

08 Jun '15

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

1 0

Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
by teor 08 Jun '15

08 Jun '15

> Date: Sat, 06 Jun 2015 14:37:01 -0400 > From: starlight.2015q2(a)binnacle.cx > > At 04:12 6/7/2015 +1000, teor wrote: > >Please let me know how you go - the 0.2.6.x > >series should also be relatively ASAN > >and UBSAN clean, as Tor has been tested > >with them since late 2014. > > I've run 0.2.4.x and 0.2.5.x with ASAN > live in production with no problems > when the relay had less bandwidth. > Performance hit is something like > 30% extra CPU. Also had it on > libssl.so and libevent.so, but > was too expensive to run on > libcrypto.so. > > UBSAN seems expense and doesn't seem > it would run other than test, but > I didn't work on it long and am not > 100% certain. Was trying ASAN extra > stack checking at the time, which may > have been the culprit. As I said in my previous email, if you're running releases before 0.2.6.6 (2015), Tor won't run under UBSAN due to issues that have been fixed in subsequent releases. If you're running on architectures other than x86_64, Tor won't run under UBSAN due to a known issue in the donna C code. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

avira exits as24875
by tor-server-creator＠use.startmail.com 07 Jun '15

07 Jun '15

hey seems like avira is joining us running 24 exits through as24875. seems to be about double the size of mozillas relays. Yay!

3 3

Help with my first relay.
by janarkopunk＠riseup.net 07 Jun '15

07 Jun '15

Hi, i want to check if the relay has a good configuration. Also i have another question, why the speed of the relay is so slow, i have a VPS with a connection of 100mb/s, the relay is new. This is torrc: ORPort 443 Exitpolicy reject *:* Nickname Freedom4Anarchists ContactInfo nomail@... RelayBandwidthRate 85 MB RelayBandwidthBurst 90 MB DisableDebuggerAttachment 0 Thanks to all :)

2 1

False exit abuse from server4you
by Dr. Who 07 Jun '15

07 Jun '15

Fun fact of the week, I got this abuse email on friday: "Dear Customer, we've detected that you're running a TOR Exit Node on your machine. Please understand, that we cannot tolerate such a service on our infrastructure. Please ensure, that this service is disabled as soon as possible. Best Regards Your Intergenia Abuse Team" followed by over 6000 IPv4 numbers including one of my relay server. First I find it a privacy violation for those other users who might run any form of tor beeing found on an abuse email to me. It should have listed only my own IP number. Secondly I think they should be able to differate between exit and relay servers. I'm eager to hear their response on Monday. Either they keep relays running or I quit, monthly payment is a good idea in that case. Just letting you know...

4 4

Bridge Usage and Setup
by Tom Ritter 07 Jun '15

07 Jun '15

Earlier this month I set up an obfs3/obfs4 bridge that (as far as I can tell) has never been used. Is this normal? My bridge is at https://atlas.torproject.org/#details/C184F644B9D39B26647779282003ACAF59E80… During this exercise I ran across a few pain points for setting up a bridge. Maybe I completely ignored some existing resource for this, but the bottom of https://www.torproject.org/docs/bridges is out of date, BridgeDB doesn't have a link anywhere, and trac's search isn't that good but I couldn't find anything on that either. 1) Setup I followed https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md to set up the obfs3/obfs4 As good as this is, it would be great if it included a minimal and complete torrc for an obfs4 bridge, and perhaps also for an obfs3/obfs4 bridge and an IPv6 setup. My torrc is SocksPort 0 ControlPort 9051 HashedControlPassword ... CookieAuthentication 1 ORPort 9001 ORPort [<public ipv6 addr>]:9001 BridgeRelay 1 ExtORPort auto ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy ServerTransportListenAddr obfs3 [::]:80 ServerTransportListenAddr obfs4 [::]:443 2) Testing How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB? netstat seems to say that things are good. The tcp6 connections on 80 and 443 also apply to ipv4 though; right? $ netstat -lpn tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN 479/tor tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 479/tor tcp 0 0 127.0.0.1:55346 0.0.0.0:* LISTEN 479/tor tcp6 0 0 :::443 :::* LISTEN 480/obfs4proxy tcp6 0 0 <public ipv6 addr> :::* LISTEN 479/tor tcp6 0 0 :::80 :::* LISTEN 480/obfs4proxy I can put my bridge line into TBB and try and use it for obfs4; seems to work. But actually finding that bridge line wasn't straightforward (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the fields, right?) And it doesn't help for obfs3. Some external validation would be nice. 3) Usage Can do I figure out if my bridge is being used? I've identified the following: $ cat /var/lib/tor/stats/bridge-stats bridge-stats-end 2015-05-31 18:58:43 (86400 s) bridge-ips bridge-ip-versions v4=0,v6=0 bridge-ip-transports $ zgrep unique /var/log/tor/* (a bunch of lines of "0 unique clients") Atlas graphs, showing virtually no traffic I feel like #2 might be addressed by Weather (if it was working), but all of these might be a good subject for a wiki page on how to run a bridge, if my understanding of everything is correct. -tom

8 9

Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
by teor 06 Jun '15

06 Jun '15

> Date: Sat, 06 Jun 2015 02:43:09 -0400 > From: starlight.2015q2(a)binnacle.cx > > … > 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. > … Good timing! Tor 0.2.7.1-alpha on x86_64 is currently Address Sanitizer and Undefined Behavior Sanitizer clean. I've just submitted a branch with instructions for building, running, and testing Tor with ASAN and UBSAN. https://trac.torproject.org/projects/tor/ticket/15817#comment:8 The following known issues exist: Two of the tests deliberately invoke undefined / illegal behavior, the instructions provide a blacklist file and an environmental variable to exempt them from ASAN/UBSAN. Architectures without (x86?) 64-bit assembler use donna C code that left-shifts 1 bits into and past the sign bit of signed integers. Until https://trac.torproject.org/projects/tor/ticket/13538 is resolved, this particular file can be exempted from UBSAN. Please let me know how you go - the 0.2.6.x series should also be relatively ASAN and UBSAN clean, as Tor has been tested with them since late 2014. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

Updating tor to get fix for #15083?
by Elliott Jin 06 Jun '15

06 Jun '15

Hello, Over the last few days, my relay (D28D32015D9723E6C50827BFD9D19200901E19D1) has been going down quite often. When I checked the logs, I saw this message: tor_assertion_failed_(): Bug: ../src/or/buffers.c:2627: assert_buf_ok: > Assertion ch->data < &ch->mem[0]+ch->memlen failed; aborting. It looks like this issue has already been observed and addressed: https://trac.torproject.org/projects/tor/ticket/15083 However, when I tried to update tor, I got the message "tor is already the newest version". I have two questions for this list: - 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? Thanks! -Elliott -- Anonymous Feedback <http://www.admonymous.com/eyjin>

2 2

Re: [tor-relays] Keeping an exit node off of blacklists due to botnet activity.
by tor＠t-3.net 05 Jun '15

05 Jun '15

> 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.

1 0

Re: [tor-relays] Updating tor to get fix for #15083? (Elliott Jin)
by AlexK (Tor lists) 05 Jun '15

05 Jun '15

tor-relays-request(a)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

1 0

How to use our own TOR relay as entry node for local network hosts
by Tor User 04 Jun '15

04 Jun '15

Hello, We have been operating a moderately successful public tor relay for a while now. Having read about how TOR works back a couple of years ago, I was more or less sold on the idea that if traffic originating on your local network uses your own TOR relay as the first hop (entry node), then by the time your traffic has left your tor relay, people in the middle can't tell the difference between traffic originating from your network and other (relayed) traffic passing through your TOR relay. I also understand that this still doesn't protect you from an exit node being able to see your traffic (and why you should use HTTPS with a high-quality cipher if it's really important), and that there are other ways your traffic can be analyzed -- but all in all, I would rather our TOR traffic enter the TOR network through a relay I *KNOW* I can trust (mine!) than leave it to chance. We have polipo running on our public TOR relay, configured to accept traffic from our local subnets. We've basically followed the info in this TOR doco: https://trac.torproject.org/projects/tor/wiki/doc/CentralizedTorServer The TOR browser bundle appears to function correctly, ie, it is able to start up, open circuits, etc. and we get the expected Congratulations! page opening a new browser window. But when clicking the green onion to show the circuit of relays handling the browser's connection, our relay is never the first hop. I'm using TBB 5.01a on one particular system, and for an example, it shows this for the circuit: - This browser - Austria (aa.bb.cc.dd) - Germany (ee.ff.gg.hh) - Guatemala (ii.jj.kk.ll) - Internet I have tried defining an EntryNodes statement with the $fingerprint of our TOR relay and setting StrictNodes 1 in the TBB's torrc file, but it can't ever establish a circuit when I try this. We get messages like this logged on the browser's tor: 05/20/2015 04:21:20.700 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. 05/20/2015 04:21:20.700 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. 05/20/2015 04:21:20.900 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150 05/20/2015 04:21:20.900 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 05/20/2015 04:21:20.900 [NOTICE] Closing old Socks listener on 127.0.0.1:9150 05/20/2015 04:21:21.700 [NOTICE] Delaying directory fetches: DisableNetwork is set. Is it possible to define your desired entry node via IP address and port, or some other way that does not require a successful directory connection/circuit first? (so it can find the relay by its fingerprint)? It seems like a chicken vs. egg problem... Or what about defining a directory for the client to use by its IP/port? We are operating a public directory as well. I can't find any info about this or other approaches anywhere. So I always end up removing the EntryNodes and StrictNodes statement from TBB's torrc file, leaving only the HTTPSProxy aa.bb.cc.dd:<polipo-listen-port> statement in there with the DataDirectory, GeoIPFile, and GeoIPv6File statements. It gets the TBB's on our network to the local polipo proxy, which in turn forwards the traffic to our public TOR relay. TBB works fine, but I don't think our TOR relay is the one getting to see our traffic with the original source address with this setup. It is definitely possible, likely even, that I am misunderstanding parts of how this is supposed to work or how a central TOR relay/proxy is supposed to be configured. But it doesn't seem to me that proxying our local network's TBB clients' traffic through the polipo instance on our public TOR relay means that our TOR traffic is being "anonymized" as to where it originated from before it gets to the first node in the circuit - or we would be seeing our TOR relay as the first hop when we look at the circuit in "the green onion button". If I'm wrong about this, that's great - I'd love to see some documentation to explain it better if you have any links handy. But if I'm right, how can I configure our TBB clients to actually MAKE them use our TOR proxy as their entry node? Thanks, Tor User

3 5

Relay traffic triggering snort ftp rules
by Paul Pearce 04 Jun '15

04 Jun '15

Hey everyone, I've encountered tor relay traffic over port 21 is triggering some (overly aggressive?) snort rules. Our ISP recently sent us a slew of snort warnings that were triggered by our obfsproxies creating circuits with tor relays that run on port 21 (I've confirmed this). The warnings are of the form: ftp_pp: Telnet command on FTP command channel [**] [Classification: Generic Protocol Command Decode] [Priority: 3] ftp_pp: FTP response length overflow [**] [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} ftp_pp: Evasive Telnet command on FTP command channel [**] [Classification: Potentially Bad Traffic] [Priority: 2] (Lawl.) They described the quantity as "overwhelming." I have no idea if this rule is enabled by default or configurable in some way. I am not familiar with snort. Has anyone ever encountered this before? If encrypted relay traffic to port 21 does indeed trigger these widely distributed warnings, it might be a good idea for "best practices" to suggest avoiding relays on this port. Thanks.

1 0

non exit relay shows up as exit in arm connections
by Maximilian Kaul 04 Jun '15

04 Jun '15

Hi, I just set up my first relay and as I'm living in Germany it needs to be a non exit relay :-( However in arm -> connections it shows up as "exit" in the last column. >From my configuration /etc/tor/torrc ExitPolicy reject *:* This is also confirmed by the head row of arm which contains the entry exit policy: reject *:* So the only thing that confuses me is the arm connections view. Is this a bug or do I simply misunderstand the tool? I googled for this but I only found another unanswered question. The relays fingerprint is 1FF50B543DC87A6F0D1F3B44BDCCAF39B07C91AC And globe.torproject.org says that it is not a exit relay but the information there is old (I changed the ORPort and DirPort listing several hours ago). Sorry for the noise but I really want to be sure. Thanks

3 4

Keeping an exit node off of blacklists due to botnet activity.
by Julian Plamann 04 Jun '15

04 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 -----BEGIN PGP SIGNATURE----- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVcKatCRB9wOTqlogdgwAAgdYP/268o2gs1nSKVcNKQfJR gnKQyBsduy2DZCGlSCnEmj4JJ0E9jiOsh+aBrZBknnbbwYPtwMBuctHTblXD czQAy5DxMNUE+E9wofLQJHLUe3W43hueKGuKzVjBnnSgxKhsUS+7dH1q4dLt KHzYdxUqQQYmmX4P9uY43/6tWeratdUF7w93cevatRpDbULMTb0j09+aeUyE MfU2i3KK6CZXIij6oo2pndwrglHywcasFwXpmEN058SYrHlB/4QDQBl7xgyU eELb71jxmz+vwZOyfEyj10ffwVtT/TcYKi5wOT1viDqQV9orNmlu8UOvu3xE 47zsb8M1Bt8JU19AsKmJNVS3YLH+2J5ertyi2mFM2PpSRIAQ6NzGA/zd/+Qr MJ7pilIBpozauf/iqiZH3UFDU5UUSezqR62fSkUDuTNaSIV5Inz0gWJnqK8w ZUMLM5xovCvWg/SqrZo0Qbry2AxOZ/l5zyhW4Jn2uioOoP+Z763FP04LcRm9 gVqfvVDNHyaAvdgKR8PSPXi2PrnNb0uEKDZLea76deWN8f2DBgfqp5hRAUOf Mk2BD9Fk30F1RC0QH0DLm/hsgTnxDEyq+XDtD6LJiGkfiHtwPkye6pH+Qf3K ZuonkypZqdfccY68lb2hMkLW7N/hsOf4hjUVQri/TL8V6eUMoEw0OAZLzhtZ gv2S =HitE -----END PGP SIGNATURE-----

1 0

amount of unmeasured relays continuously rising since 2 weeks
by nusenu 02 Jun '15

02 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor BW Authories, we'd like to bring the following issue to your attention. Since the last two weeks the amount of unmeasured relays is steadily rising [1]. unmeasured relays on 2015-05-01: 387 unmeasured relays today: 1087 (and growing) Graph showing the last 5 months: https://trac.torproject.org/projects/tor/attachment/ticket/13450/unmeasured… Data: https://trac.torproject.org/projects/tor/attachment/ticket/13450/2015-01-01… Would be great if you had some time to look into this: https://trac.torproject.org/projects/tor/ticket/13450 (follow ups should probably go to trac) ..so bw doesn't go wasted. A contributed but unused relay doesn't make relay ops happy. thanks! [1] https://lists.torproject.org/pipermail/tor-relays/2015-May/006946.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVVP8PAAoJEFv7XvVCELh03bwP/1NQi99IweePw+o/Mj4nWieE yRLDmTt2J8IeJXp8tMQPcqJIZSEzSOW7u7J9o7McNR+n2lm2Mx9x9IMKQPCX6CFh /v5JJ2/aZyfu7JnkTLr7sNKw6DqkAODnKHbyALuc20zsc1oQmu56VZpY6orwC3RG n4qhbXxyD7+TXCv5iZF5CZsnlrVojHevK6tKkivOem/qMVSwshFHCUSnYVi/YK+R CcLIGllT5fx8msYEWDnnTdIBi9PoIl2gO7SE4Y3TKEpkFhGeU8FEsGmIV9LQi8O1 XcaIeU2BVup4PJMDBSgtB9BlSuKGQAq1ICiVx3OnVUVPleTYsFATFUQxW83irfu9 o8Q3ns3srj3tmtLHE0LA9c2gCuE4NiWA++t72sCc+tiqCy9+X4f5BKsqsem7bT5o 89PfZijjuR4ZI3531e+PCjZDokNY9Gx7lCjIlnrGDeGKSIPqPz9N53bYYIXB+d4r uKDeRaRjv3iz/yKjXFYSra3p70HcQmx+CM4aws035LSCTLg/zFyARXb+hf8/NeKn JzXaVoURRiRX3gzeyiznQ7EVNXTyQmr1ppGJVZAXhtfAuiCrqS5JsPJ8BTzxcylI hZBkcwyQzkV3cCeBFMABQFy3AtQ2SZSOuLzS1vyH1oAHPPWd5K1bgHcSMvOqIEPh LspnH0QSv8ICnU1uhbTZ =rNB9 -----END PGP SIGNATURE-----

14 33

Updated: Running Tor When OS X Boots
by teor 02 Jun '15

02 Jun '15

I've recently updated the OS X launchd instructions for OS X Yosemite: https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot <https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot> They were starting to show their age - they were originally written in 2011, and were based on Vidalia, tor 0.2.2, and OS X 10.6 or 10.7. If you're running Tor on OS X, please try these instructions, fix any mistakes, and add missing steps. In particular, we've moved away from Vidalia to nyx (arm), so the nyx sections could do with some more detail. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] Improving Node Connection Testing
by teor 02 Jun '15

02 Jun '15

> > Date: Tue, 02 Jun 2015 11:58:25 -0400 > From: 12xBTM <12xbtm(a)gmail.com> > > This is a little write-up on the quality of data connections involving > nodes, and some thoughts on that. So, as of today, the quality of nodes > is determined by their bandwidth, uptime, and not being malicious. There > are two major missing factors from this, and I wanted to bounce some > ideas around: Latency and Packet Loss. These are fairly simple tests > that can be performed on nodes, albeit, it would increase the resource > load on the bwauths. However, nodes with high latency or packet loss > should be identified, and nodes should be measured with these two > important factors. > > High latency will increase the delay of the circuit, but will not appear > in the consesus at all. A node can have enormous latency and hamper that > circuit without anyone knowing. The same could be said for a node that > drops a lot of packets, or drops a lot of packets at a certain time of > day (peak usage). Do the bwauths only measure the time to transmit the data, or do they include the time to connect as well? Including the time to connect would be a measure of latency, particularly for smaller file transfers. Are the bwauths only using one size of file transfer to measure bandwidth? Using a small and large size would allow measurement of mostly-latency and mostly-throughput with the current infrastructure. Since, as far as I know, Tor connections are in-order delivery, dropping packets will cause retransmits, and back up (parts of) the transmission. This will reduce the bandwidth as a side-effect. This reduction in bandwidth is currently measured by the bwauths - but, as you say, it isn't a direct measurement. In future, it would be great to have separate statistics for latency and packet loss - but this is perhaps a job for something more like Ooniprobe? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

3 2

IPv6 slows BW?
by torelay 02 Jun '15

02 Jun '15

I have two relays that I set up last night to test. They're at the same datacenter, same spec server, and configured identically. The only difference is one is set up for IPv6 and the other isn't. With IPv6 BW is at: 75kB/s Without IPv6 BW is: 110kB/s Is this normal behavior or has anyone else experienced this loss of bandwidth? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

2 1