- tor-relays - lists.torproject.org

Re: [tor-relays] Advice on dealing with ISP's response to DMCA takedownnotice.
by tor＠t-3.net 30 Oct '13

30 Oct '13

Reply to the email, say that you found a misconfiguration in your Tor daemon which could have accounted for this problem and you've repaired it, and hopefully this problem is resolved for the future. Put the below as your exit policy in torrc, and I'd stop/start the service to be sure it grabbed it. Using the below exit policy, we've had our exit node running for a couple months or so doing pretty good bandwidth, and not had a single warez-related complaint. Seen some complaints about SQL injection attacks but perhaps those will annoy your ISP less. ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews etc ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy reject *:* On Thursday 24/10/2013 at 9:11 pm, Christopher Jones wrote: > > I’ve been running an exit relay for about 3 days and, sure enough, > some BitTorrent bugger caused sh3lls.net to send me a DMCA nastygram: > >> >> We have got the following complain, please remove all illegal torrents >> immediately from your server: >> >> Evidentiary Information >> Title: Suits (TV) >> Infringement Source: BitTorrent >> Initial Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Recent >> Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Infringing Filename: >> Suits Season 3 Episode 6 (The Other Time) (HDTV x264)-ASAP (1GBps >> SeedBox).mp4 URL if applicable: >> Infringing File size: 364405400 >> Infringers IP Address: 64.32.14.34 >> Bay ID: 7fbb4256bfca558d5a809b9f6536b5fd5e4e782d|364405400 >> Port ID: 33788 > > I followed through with the templates provided by the Tor Project as a > response to the DMCA takedown notification. A day later, the ISP sent > me this: > >> >> Dear Christopher >> Whether you run Tor or not, we even told you in past, it's your >> responsibility to stop all abuse >> If Tor is causing it, stop the program Tor on your server, if we get >> another complain we will have to suspend/terminate your services >> >> tor always always gets lots and lots of abuse and complains >> >> Update us within 24 hours >> >> Thanks > > I was never provided with the full text of the original DMCA > complaint, so I was unable to respond. Furthermore, I was never > “even told…in the past” that I had to stop all abuse caused by > Tor. Tor is not singled out in the ToS or AUP. And I was certainly > never told anything in the past about abuse and Tor specifically. As I > said, first warning. Then there’s the “tor always always gets lots > and lots of abuse and complains [sic]”. Which is kind of bizarre, > because their position on tor seems a bit cagey. Does the claim about > lots of abuse mean they won’t allow exit nodes? Or is that just a > “hint” that I’d be better off not trying to run it? > > And this is an ISP I picked from the good list. > > Suggestions are welcome. I’m running with the default exit node > policy, which should block most of the abuse-laden ports. > BitTorrent’s a little harder to deal with. I’ve no qualms working > with the ISP to mitigate their concerns, but I’m not sensing their > returning the same spirit of cooperation. > > .cpj_______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

3 2

Filtering TOR Non-exit Relay - Just Curious
by Nelson 29 Oct '13

29 Oct '13

Tor Exit Relay have the ability to filter traffic by allowing the operator make choices based on personal preferences for personal, legal (ex: country of origin) and for other reasons. Non-exit Relays do not have the ability to set "Relay Policies" (torcc??), and why would they, considering that all this traffic is encrypted anyway, as I understand it, and one would not ever know what type of traffic it is, or its origin, based on the bandwidth graph. I checked my smoothwall firewall logs it does not seem to show the traffic flowing on my relay, I guess this would be obvious because it's Tor traffic; unless I'm not filtering the logs correctly. Running a Tor relay seems straightforward and one could just fire-it-up and easily contribute to the network. But my curiosity gets the best of me. I was looking to add additional URL Filter rules for my smoothwall as a more centralized way of controlling what gets to the LAN for my users. While checking for additional blocklists I came upon P2P rules and I started to compare the new blocklists with my old ones and then I stumbled upon PeerBlock which has been around for a while. On Windows 7, PeerBlock seemed to provide two things I was looking to test on a TOR Relay: 1. Real Time Traffic Logging (ip's and ports logged) 2. The ability to filter traffic. Apparently I am able to do both with PeerBlock, although I'm sure there are more suitable and capable tools available out there that do this, but I'm not aware of or have used any of these tools. In peerblock I can create new custom lists and completely block specific ip ranges (ex: warez, torrents etc.), and I am able to see what traffic is allowed or blocked based on policies created. 1. What problems, if any, arise from using peerblock and Tor together? 2. Why do we not have the ability to at least set our own policy for the type of traffic on a relay just like an Exit Relay?

6 9

"stable" flag voting differences
by starlight.2013q4＠binnacle.cx 28 Oct '13

28 Oct '13

I observed an interesting behavior in the authority votes regarding relay stability and am curious if anyone can comment. Have a new relay, about ten days old. Relay is marked Fast Guard Running Stable Valid One 10 minute network outage three days ago and then a 68 minute outage one day ago for repair. Overall about 4680 seconds down over the last week, and if one uses a 646220 second timeframe per this post https://lists.torproject.org/pipermail/tor-relays/2013-July/002255.html It works out to about 99.27% uptime, which seems within the 98% threshold quoted in the posting. What was interesting was that Faravahar gabelmoo maatuska tor26 urras all immediately removed the "stable" flag when the relay came back online after maintenance, while dannenberg moria1 left the stable flag in place. The two remaining authorities dizum turtles have never set the stable flag due to heavy link congestion between AS286/AS3265 for 'dizum' and congestion within AS6461 for 'turtles'. Then exactly 24-hours after the end of the outage the five naysayers turned the stable flag back on. Mainly a point of curiosity, but I'd guess from this that the first five authorities listed above are using a much shorter window for evaluating stability while the second two are using the seven-day window. I couldn't find per-authority logging of this category of information so it's hard to know. Perhaps it's relevant that the node was removed from the consensus directory briefly immediately after the outage ended. Finally it is interesting that 'dizum' and 'turtles' have set the "guard" flag even though they consider the relay unstable. This is a recent development. Earlier the two impaired-path authorities had the guard flag set off.

2 2

Traceroute measurement from Tor relays
by Karsten Loesing 28 Oct '13

28 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Tor relay operators, We could use your help in a pilot project to improve Tor security. As you may be aware, the anonymity of a connection over Tor is vulnerable to an adversary who can observe it in enough places along its route. For example, traffic that crosses the same country as it enters and leaves the Tor network can potentially be deanonymized by an authority in that country who can monitor all network communication. Researchers have been working to figure out how Tor traffic gets routed over the Internet [0-3], but determining routes with high confidence has been difficult. That's where you come in. To figure out where traffic travels from your relay, we'd like you to run a bunch of "traceroutes" - network measurements that show the paths traffic takes. This is a one-time experiment for now, but, depending on what we find out, regularly making such measurements may become a part of Tor itself. We have already gotten some results thanks to Linus Nordberg of DFRI and Moritz Bartl of torservers.net, and now it's time to ask all relay operators to help. We would like to start this right away. We have written some shell scripts to automate most of the process. The easiest way for you to get them is with git, using the following commands: git clone https://bitbucket.org/anupam_das/traceroute-from-tor-relays git checkout f253f768d14e3368e4fe4de9895acd2715a19412 You can also just download the files directly by visiting [4]. Detailed instructions for setting up and running the experiment are in the README. Basically the experiment does traceroutes to three groups: all "routable IP prefixes", all Tor relays, and then all /24 subnets. These kinds of measurements are not uncommon, and they will not be done at a high rate. By default the scripts will periodically move the results to our server [5] via SSH, although you can keep the results around and/or not send them automatically if you wish (see the README). The traceroute data recorded is not sensitive or private at all. We plan to make the code and data public, following Tor's practice of open cooperation with the research community [6]. The measurements will work best if you have the "scamper" tool from the Cooperative Association for Internet Data Analysis (CAIDA) installed (see the README for installation instructions). This is a standard and open-source tool that handles the many modern complexities of Internet routing measurement. If you are not able to run scamper, the script will also work with the more-common but less-accurate and slower "traceroute" utility. We do not currently have support for Windows relays. The output will take up around 500KB (110MB if you disable automatic removal after upload) disk space if you use scamper; on the other hand if you use "traceroute" utility each output will be around 4MB (1GB with automatic removal after upload disabled). * *Depending on whether you run scamper or traceroute the total time required varies but results for traceroutes to "routable IP prefixes" and all Tor relays should finish within one week (possibly earlier). We would like to request relay operators to upload those results once finished.* * This experiment is in collaboration with several researchers, but the leads are Anupam Das, a Ph.D. student at the University of Illinois at Urbana-Champaign, and his advisor Nikita Borisov. Based on a review of the scripts of commit f253f768d14e3368e4fe4de9895acd2715a19412, we believe that they operate as described above. Please do read through them yourself, and let us know if you have any questions or concerns. And also feel free to contact any of us for help or with suggestions. Because of you, Tor is the "king" of anonymous communication. With your help, we will keep improving to face the new challenges to privacy and freedom online. Thank you, Karsten Loesing <karsten(a)torproject.org> Anupam Das <das17(a)illinois.edu> Nikita Borisov <nikita(a)illinois.edu> [0] "Protecting anonymity in the presence of autonomous system and internet exchange level adversaries" by Joshua Juen. Master's Thesis, UIUC. 2012. <https://www.ideals.illinois.edu/handle/2142/34363> [1] "Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries" by Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul Syverson. ACM CCS 2013. <http://freehaven.net/anonbib/cache/ccs2013-usersrouted.pdf> [2] "AS-awareness in Tor path selection" by Matthew Edman and Paul F. Syverson. ACM CCS 2009. <http://freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf> [3] "Sampled Traffic Analysis by Internet-Exchange-Level Adversaries" by Steven J. Murdoch and Piotr Zieliński. PETS 2007. <http://freehaven.net/anonbib/cache/murdoch-pet2007.pdf> [4] https://bitbucket.org/anupam_das/traceroute-from-tor-relays/downloads [5] ttat-control.iti.illinois.edu [6] https://metrics.torproject.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSZ+aXAAoJEMIuYwomKaxNouoH/AyS9oUXuilXH5Wat4l41OGy Zdx8I4VOIox4MPpEEvgulzxJUg5+XvEcMwECwe9/fiIw1M0RAALzicme8xGbG5c7 6OndBNqtTg2dN+4SXC90bMPHtaTS7KiNxkvq4h3z5EqFg38Nymwm2xA7dsEIE7Mh T/k7wch/uE++wWKFXpa8MNKUCC+RpIWUdx00F717F8av/fLlhFuwmjKiMqqNDH5D ntLn2i67Tqe17hOJxVNgPJuf7MDfsTgMTGVCClSWtn95EDrL6WMh2RIteUt+Gb94 3KxS7uIqzyXIN2BhcZ+kk55g7LAWmL+AMKGyGsa88+j8c782hVzRSoL9ii+EZ0U= =ygb9 -----END PGP SIGNATURE-----

8 9

minimum ram
by I 28 Oct '13

28 Oct '13

4 10

Thanks for the advice on handling DMCA complaints.
by Christopher Jones 27 Oct '13

27 Oct '13

Hey all, I just wanted to thank the list members for giving me some great advice on working with my ISP to deal with the DMCA nastygrams. I restricted my exit policy to allow most legitimate TCP services and block the rest, which should hopefully disincentivize those damn P2P users from picking my relay as an exit in most cases. Does the Tor project run a database to track abuse complaints? Could be useful in terms of uncovering who the largest pains in the ass are (mine was from Irdeto on behalf on NBC Universal), as well as organizing targeted campaigns to put pressure on companies like Irdeto to at least perform some due diligence and not send out DMCA originating from exit relays. If not, maybe I’ll start working on a project to do so if there isn’t something else like it elsewhere. On another note, I discovered I prefer running Tor on FreeBSD over Linux. Ran CentOS for a bit, but somehow encrypting /tmp blew it up and the NOC had to re-install the OS. I went with FreeBSD instead and dig it immensely. Pf is much less of a headache than IPTables — I actually got port forwarding from 80 to 9091 and 43 to 9090 working. Administration is more straightforward. I like the clear separation of the base system from additional software added from ports. Compiling ports, while more time consuming, is a delight compared to some of the binary package management issues I’ve had in the past with Linux. FreeBSD also appears to manage memory more efficiently. I run Linux as a desktop OS, but for a server OS, FreeBSD has won me over with its simplicity, less convoluted security (no SELinux — yes I know you can turn it off, but I’m the masochist who leaves it on), better support for chroot jails. Just my opinion. One more question and I’ll probably feel stupid after reading the answers, but does “RelayBandwidthRate” apply separately to rx and tx rates or the combined throughput of them both? The server I run has an unmetered 100Mb/s connection. I’ve got RelayBandwidthRate set to 5MB and RelayBandwidthBurst set to 10MB. 12.5MB/s being the theoretical max, if I bumped up my bandwidth rate to, say, 8, would my relay overload the NIC or would it continue to behave? My server specs are as follows: FreeBSD 9.2 Dual Core Atom D2500 4GB RAM 2TB SATA drive (encrypted swap and /tmp) 100Mbit unmetered traffic 5 usable IPv4 addresses At last check, I had 1140 TCP connections according to lsof and vnstat is showing throughputs of 13-18Mbit/s rx and 14-19Mbit/s tx. Tor CPU usage is about 22-27% according to top. Does this look reasonable or should I tweak some things like max connections? Thanks, Chris

4 3

TCP: drop open request
by mett 26 Oct '13

26 Oct '13

Hi! Since yesterday, the kern.log of the relay I'm running is flooded with "TCP: drop open request from". I first thought it was a kind of DDOS on our servers but it seems to be related to Tor (When I stop Tor, kernel doesn't complain anymore). Does somebody have an idea of why this is happening and what to do to mitigate it? Thanks a lot.

3 3

Re: [tor-relays] [tor-talk] A new check
by grarpamp 25 Oct '13

25 Oct '13

>> > > We're considering launching a new check, >> > > >> > > It'd be appreciated if you could take a moment to look for false negatives, >> > > and let us know. >> > >> > I found 15 relays where check2 told me that I'm not using Tor. >> >> Very good idea! :) Did you also run the same test against >> check.torproject.org? Keep in mind that while it may be frustrating to some users config tests to find that they are temporarily using a false negative exit... this 'multihoming' could, and should in fact, be considered a feature since it keeps some exits out of the reach of anti-tor blocklists that simply parse all the IP's out of the descriptor set. Similar to how obfs and other design features keep Tor out of the reach of anti-tor entities, making an anti to do a little work to be an anti is a good thing. Thus having a good number of false negatives around can allow you to reach places you couldn't otherwise reach due to that type of blocking. That may cause philosophical stress to some places that indiscriminantly [1] block Tor IP's by default, but also keep in mind that Tor is dual use and such a policy is rather blind to that by definition... as would be indiscriminantly blocking all coffee shop IP's by default. So if the point of 'looking for false negatives' is to do something, like attempt to convince the operators to not multihome... the better thing to do would be to add regular false negative tests to the backend of the check service so that these exits come up positive therein. [1] Within a day ago I posted a link to a slashdot discussion of one particular instance of this.

1 0

Advice on dealing with ISP's response to DMCA takedown notice.
by Christopher Jones 25 Oct '13

25 Oct '13

I’ve been running an exit relay for about 3 days and, sure enough, some BitTorrent bugger caused sh3lls.net to send me a DMCA nastygram: > We have got the following complain, please remove all illegal torrents immediately from your server: > > Evidentiary Information > Title: Suits (TV) > Infringement Source: BitTorrent > Initial Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Recent Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Infringing Filename: Suits Season 3 Episode 6 (The Other Time) (HDTV x264)-ASAP (1GBps SeedBox).mp4 URL if applicable: > Infringing File size: 364405400 > Infringers IP Address: 64.32.14.34 > Bay ID: 7fbb4256bfca558d5a809b9f6536b5fd5e4e782d|364405400 > Port ID: 33788 I followed through with the templates provided by the Tor Project as a response to the DMCA takedown notification. A day later, the ISP sent me this: > Dear Christopher > Whether you run Tor or not, we even told you in past, it's your responsibility to stop all abuse > If Tor is causing it, stop the program Tor on your server, if we get another complain we will have to suspend/terminate your services > > tor always always gets lots and lots of abuse and complains > > Update us within 24 hours > > Thanks I was never provided with the full text of the original DMCA complaint, so I was unable to respond. Furthermore, I was never “even told…in the past” that I had to stop all abuse caused by Tor. Tor is not singled out in the ToS or AUP. And I was certainly never told anything in the past about abuse and Tor specifically. As I said, first warning. Then there’s the “tor always always gets lots and lots of abuse and complains [sic]”. Which is kind of bizarre, because their position on tor seems a bit cagey. Does the claim about lots of abuse mean they won’t allow exit nodes? Or is that just a “hint” that I’d be better off not trying to run it? And this is an ISP I picked from the good list. Suggestions are welcome. I’m running with the default exit node policy, which should block most of the abuse-laden ports. BitTorrent’s a little harder to deal with. I’ve no qualms working with the ISP to mitigate their concerns, but I’m not sensing their returning the same spirit of cooperation. .cpj

3 2

Re: [tor-relays] Traceroute measurement from Tor relays
by Jesse Victors 25 Oct '13

25 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > That's where you come in. To figure out where traffic travels from > your relay, we'd like you to run a bunch of "traceroutes" - network > measurements that show the paths traffic takes. This is a one-time > experiment for now, but, depending on what we find out, regularly > making such measurements may become a part of Tor itself. We have > already gotten some results thanks to Linus Nordberg of DFRI and > Moritz Bartl of > torservers.net, and now it's time to ask all relay operators to help. > We would like to start this right away. How much bandwidth will this be taking up, and roughly how much will be uploaded/downloaded? I've cloned the repo, but I'm nervous about running this if it's going to be a significant bandwidth hog for a whole week. As Aaron said in Issue 39, it looks like it's going to be a lot of IPs and a large amount of packets. Also, ISPs may not take kindly to all these scans. What's the word on that? Has anyone run this tool, and what's their opinion? I'd be happy to help, but I'd like to know the full details of the various resources this tool will be consuming. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSacyDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAhy4IAJ0OSiPjqFTq8bqyU+nXZX7R 6TgA1nmU3Q2tEc6CVBf+/eBpddyAmAG5SZ8/vXKGrUB2VtujaW/VMZ/9zaEMql2B KKGcPcYAy0wQUcJPFZEw0TMuRS5dVV+bEmUXEYh3DhfECVfsGMy8b1mP0UuxW9MN 8UQFiDbzT04lGo2vNOpFGk2DuH+WVHzDj1/Nqv249iobPQWqvebJtFbTnoWrt7m/ cAO3kJtSq43RJSQcImXqwOKDdnTLI5/7FSlP/0Mw5N7ROBMUVfA9/80mRY3VcxtX u6EHP8ZE0JPBOf6WAnwjJU1DBay9EUtHuPpYu1jO9pfuWDrPINyR7NgSg+wEWIQ= =yDvu -----END PGP SIGNATURE-----

1 0

Cheap non exit relay recommendation
by Christian Dietrich 24 Oct '13

24 Oct '13

I hope this is allowed, to due the fact that this is advertising. Currently i'm running two tor relays on a single dedicated server, pushing 404 mbit/s atm. (000000000000myTOR1 & 000000000000myTOR2) I will cancel it at beginning of november due to the fact that i miss tor relay multi core support and i plan to support other projects instead. Anyway, i can recommend my current hoster for non exit tor nodes, you will get: HP ML310e G8 Server (/w iLO4) Intel XEON E3-1230v2 (4x 3,3 GHz /w HT) 16 GB DDR3 ECC 2x 1 TB SATA RAID1 Disks 1000mbit unmetered traffic (pushed ~100 TB so far, no problems) 1 IPv4 Adress (5,-€ per additional) / /64 IPv6 for 69,99€ (currently ~96 USD) hXXp://goo.gl/pXkb78 Germany based. I think this is currently the best deal for non exit relays.

3 2

Port for obfsproxy
by GDR! 23 Oct '13

23 Oct '13

Hello, I'm new here, running a relay for the past year. I'm looking to implement obfsproxy running on port 80 and emulating HTTP traffic. The official manual says I should add this line to torrc: ServerTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed However, it runs on a random port (30000+) which kind of defeats the whole purpose of running an obfuscated bridge. I also haven't seen a way to force faking HTTP traffic. The manual page is very terse and doesn't explain how to do any of this. How do I configure obfsproxy to look like a HTTP server? -- Zapisz moj nowy prywatny adres email: gdr(a)gdr.name Teraz na wlasnym serwerze. Zawsze czysto - zawsze sucho - zawsze pewnie. Klucz PGP to nadal 4ED3D2B7

7 13

Re: [tor-relays] My Relay speed has dropped nearly to zero - Why?
by Jesse Victors 22 Oct '13

22 Oct '13

On 10/19/2013 06:00 AM, tor-relays-request(a)lists.torproject.org wrote: > Message: 3 > Date: Sat, 19 Oct 2013 00:55:42 -0400 > From: Torop <torop(a)optonline.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] My Relay speed has dropped nearly to zero - > Why? > Message-ID: <526210CE.80409(a)optonline.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/18/2013 11:46 PM, David Carlson wrote: >> > On October 8 something caused my non-exit relay speed to drop from >> > around 50 KB to less than 10 KB according to Atlas graphs. I have >> > checked with my ISP and run speed tests that verify my upload speed to >> > be .96 Mb and download to be over 3 Mb, as they have been for years. I >> > am running Tor 0.2.4.17-rc on Windows 7 and my consensus weight has >> > dropped to 26. What could have caused this? >> > > Same here. See the below and do the math on how much data I was and am > now pushing per 24 hours, as well as open circuits. > > > Oct 07 09:04:41.242 uptime 15 days 22:00 hours, 791 circuits open. > I've sent 55.41 GB and received 57.06 GB. > Oct 08 09:04:41.237 uptime 16 days 22:00 hours, 1255 circuits open. I've > sent 63.95 GB and received 65.80 GB. > > Oct 17 23:04:41.236 uptime 26 days 12:00 hours, 87 circuits open. > I've sent 90.08 GB and received 92.16 GB. > Oct 18 23:04:41.259 uptime 27 days 12:00 hours, 87 circuits open. > I've sent 91.85 GB and received 93.96 GB. I've been seeing the same. My bandwidth limit is around 3 MB/sec, but it's been consistently at 400-600 KB/sec. I don't think it started that early for me though, not sure though. I was going to blame it on psad, but I can't see any evidence of that. The fact that all three of us experience this is interesting. Jesse V.

5 7

Relay security, re: local network
by Joe 22 Oct '13

22 Oct '13

Hi, I'm planning to run a Tor relay on a spare computer at home. Security is a concern, and not only regarding the machine running the relay but also my other computers. Are there any (theoretical or otherwise) known attacks a person can perform on a running Tor relay to take remote control of it, and assuming the said person could pull that off, is it possible to extend this control to the other computers behind the same router? I am aware of possible DDOS attacks and other risks related to running an exit, but i am comfortable in taking these chances in my environment. I would run the relay on a yet-undecided-Linux distro, possibly Mint Debian or some flavor of Ubuntu which i am more familiar with, and use full-disk encryption with strong passwords. Are there any risks to my other computers worth consideration? Thanks.

11 13

rm /var/lib/tor/keys/* before changing exit policy?
by Martin Kepplinger 21 Oct '13

21 Oct '13

Really quick not too important question. When switching a relay to become an exit node or the other way round, does it make sense to delete /var/lib/tor/keys/* beforehand and start it over this way? I was thinking, if the relay has the guard flag, it would make sense, but maybe even if it doesn't. I don't know. I'll do it I guess. thanks martin

4 4

VPS
by Eduard 21 Oct '13

21 Oct '13

I rented a VPS with 256mb ram and unmetered bandwidth. Ubuntu 12.04. Can someone please tell me how to configure it as a non-exit relay for Tor? Acess via PuTTy. Cheers, Edward Sent from my Orange Smartphone I <beatthebastards(a)inbox.com> wrote: >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

6 6

Re: [tor-relays] port 9001 udp
by zwiebel＠quantentunnel.de 20 Oct '13

20 Oct '13

2 5

Botnet issues and upgrading to 0.2.4.x
by Chris Whittleston 20 Oct '13

20 Oct '13

Hey guys, So I just started running a non-exit relay on a Raspberry Pi, and have hit a problem where it seems huge numbers of circuits are being created which overwhelms the system and can cause tor to crash. I read here ( https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients) that upgrading to 0.2.4.x might help with this, so I followed the instructions here: https://www.torproject.org/docs/debian#development And ran apt-get update, apt-get upgrade to get the latest version which turned out to be 0.2.4.11-alpha-1~wheezy+1 There seems to be a problem with this though as when the install finishes (or when I try to restart tor), I get this error: pi@torberrypi /etc/tor $ sudo /etc/init.d/tor restart /etc/init.d/tor: line 111: 9701 Illegal instruction $DAEMON $VERIFY_ARGS > /dev/null [FAIL] Checking if tor configuration is valid ... failed! /etc/init.d/tor: line 111: 972 https://www.torproject.org/docs/debian#development4 Illegal instruction $DAEMON $VERIFY_ARGS 1>&2 Tor is not starting and I'm unsure how to proceed - help appreciated! :) Chris

9 19

Relay behind VPN router
by Jochen 20 Oct '13

20 Oct '13

I have a TOR relay behind a Tomato router on an ADSL line. I activated the vpn client to route all traffic through privateinternetaccess.com. Because a TOR relay does not work behind NAT without port forwarding, I'm looking for a way how to route tor traffic directly to my internet provider. I can add static routes, but I don't now the IPs in advance. Maybe there is no problem to route outgoing traffic through the vpn tunnel, but how can I make my relay publish my WAN IP instead of the tunnel IP? My WAN IP is changing every day, so I cannot configure it as static. -- Mit besten Grüßen Jochen Fahrner

3 6

port 9001 udp
by zwiebel＠quantentunnel.de 19 Oct '13

19 Oct '13

Hi relay-tives! It's my first post here, so please can someone help me with my question Why do I have to open 9001 UDP at the DSL router firewall and not necessarily in iptables? Is it something specific on my side or does someone has an explanation? The OR service seems to work. Ok - I see nearly no traffic may-be because of my small bandwidth. See some information about my system Setup PC (P4 2GB noHDD) with USB-LAN adapter (eth2) connected to DSL router (NAT & firewall) Tails 0.20.1 on SD card with USB adapter write protected Server IP x.x.x.33 received from the DHCP DSL router Goal Run PC as OR relay non exit Run OR service Dont run DIR service DSL router setting Open DSL router firewall IP x.x.x.33 TCP 9001 for OR Open DSL router firewall IP x.x.x.33 UDP 9001 for OR <= IS THE POINT Done to tails manually each time the PC turns on (amnesia!): Root terminal (password) and "/sbin/iptables -A INPUT -i eth2 -p tcp --dport 9001 -j ACCEPT" The the only change to original tails iptables list is the added rule Done to Vidalia: relay-non-exit, nickname, email, port=9001, bandwidth limits typ 20kByte/s and max 25kByte/s The log messages tell me success and all runs for a week. Thanks front-up Zwiebel _||_ / \ / O O \ \ ____ / \\__//

2 1

Re: [tor-relays] minimum ram
by Eduard 19 Oct '13

19 Oct '13

I could say that this is true. I run a relay on my desktop, and I see that after 5-7h the ram ussage increase. Even on a 16GB system, the increase is detectable. Sent from my Orange Smartphone Moritz Bartl <moritz(a)torservers.net> wrote: >On 2013-10-19 03:50, I wrote: >> Is there any utility in the very cheap VPSs with 128mb of ram? > >I did some testing quite a while ago and found that 256MB was the >minimum amount of RAM for a relay. It works for some time with >128MB, but it then runs out of memory, and it is not very good >to have it restart all the time. > >I say "was" because currently, with more than 3 million clients >in the network, a relay might even run out of memory with 256MB >RAM. I don't have any current data on that though. > >-- >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

1 0

serious gap in 'chroot' documentation
by starlight.2013q4＠binnacle.cx 19 Oct '13

19 Oct '13

Newer versions of 'openssl' require access to /proc/sys/kernel/random and so the line /proc/sys/kernel/random /chroot_tor/proc/sys/kernel/random auto bind 0 0 must be added to the /etc/fstab file or the command mount -o bind /proc/sys/kernel/random /chroot_tor/proc/sys/kernel/random must be run from somewhere. Keep in mind that issuing the 'mount' more than once causes nested overly mounts rather than doing nothing, so the 'fstab' approach is best. Obviously the directories proc/sys/kernel/random must be created in the 'chroot' jail tree. ---------------- This problem will appear when 'tor' attempts to roll-over it's key after several days. Took significant effort of figure out what happened as 'tor' dies without comment. It appears that if 'tor' fails in the middle of a re-key operation, the node name and state is lost entirely and the relay must rebuild it's reputation from scratch with a new name. Quite vexing.

4 5

My Relay speed has dropped nearly to zero - Why?
by David Carlson 19 Oct '13

19 Oct '13

On October 8 something caused my non-exit relay speed to drop from around 50 KB to less than 10 KB according to Atlas graphs. I have checked with my ISP and run speed tests that verify my upload speed to be .96 Mb and download to be over 3 Mb, as they have been for years. I am running Tor 0.2.4.17-rc on Windows 7 and my consensus weight has dropped to 26. What could have caused this?

2 1

Re: [tor-relays] OT: Re: risk of relay exploit
by starlight＠binnacle.cx 16 Oct '13

16 Oct '13

Very sorry! I forgot to use the throwaway version of my address that bypasses the curmudgeonly filter. Please try me at starlight.2013z3(a)binnacle.cx At 02:16 10/16/2013 +0100, Geoff Down wrote: >Hello starlight, > >Your outgoing self-generated Spam Score also gets >your emails treated as spam by my email provider >(I tried to email you privately but your >mailserver doesn't accept mail from my provider at >all...). > >GD >

1 0

risk of relay exploit
by starlight＠binnacle.cx 16 Oct '13

16 Oct '13

Hello, Can anyone comment on the pros and cons of running a separate client-only 'tor' instance for local browsing while maintaining an independent instance configure as a relay? My thought is that if high-resource adversary exploits/subverts the relay code and inserts a trojan/parasite, they would be in a position to monitor unencrypted traffic on the SOCKS port. Is the probability of exploit significantly reduced for instances that do not accept relay connections? If so then keeping local browsing in a non-relay client would seem to be more secure since I understand that remote relays see only encrypted traffic. Thanks

3 3