- tor-relays - lists.torproject.org

Torservers awarded $250,000 by Digital Defenders
by Christian 16 Dec '13

16 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hej! Torservers.net has been awarded $250,000 over two years by the Digital Defenders Partnership to strengthen and improve the Tor network, the anonymity system crucial to journalists and human rights defenders using the Internet. <https://blog.torservers.net/20131213/torservers-awarded-250000-by-digital-d…> Tor is free software and an open network that helps internet users to defend against traffic analysis, a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security. It is used by hundreds of thousands of daily users worldwide to secure their online communication, avoid tracking, and circumvent censorship. Tor protects users by bouncing communications around a distributed network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location. Torservers.net provides high bandwidth infrastructure for the Tor network since 2010. We have grown to 10 volunteer-run organizations in 8 countries. Torservers.net distributes donations and grants across independent organizations of IT security professionals, and helps build a sustainable network by teaching others how to run stable Tor infrastructure. The Digital Defenders Partnership was established in 2012 to provide rapid response to threats to internet freedom. The Partnership aims at keeping the internet open and free from emerging threats, specifically in internet repressive and transitional environments. It also wants to increase and better coordinate emergency support for the internet?s critical users, such as bloggers, cyber activists, journalists and human rights defenders, whenever and wherever they are under threat. Thanks to the newly awarded grant of $250,000 over two years, participating Torservers organizations will be able to sustain at least 3 Gbit/s of exit traffic, and 2000 fast and up to date bridges. Tor bridges are required in many countries with state-level censorship. 3 Gbit/s are 949 terabytes, almost a petabyte of user data, every single month, per direction. Call for organizations To strengthen the Tor network and prevent attackers, it is crucial to spread operation across as many groups as possible. Thanks to the Digital Defenders, Torservers.net can now extend its work and help less technical organizations with the setup and maintenance of Tor services. The Institute for War & Peace Reporting (IWPR) is the first civil society organization to join the Torservers program with its Cyber Arabs group. This collaboration allows Cyber Arabs to give stable and working Tor access to activists and journalists in the Arab world. If you are part of an organization interested in supporting Tor, please contact Torservers.net. They have various options available, and are happy to teach tech staff and journalists. ?Since we started Torservers.net a few years ago, Tor finally became fast enough to be used for all Internet communications? comments Moritz Bartl, co-founder of Torservers.net. ?New people also join the Tor network every day. With the help of the Digital Defenders, we have the chance to make the network bigger, safer and more resilient to the benefit of everyone with the desires to protect their online activities from surveillance.? Contact Juris Vetra Zwiebelfreude e.V. c/o DID Dresdner Institut für Datenschutz Palaisplatz 3 D-01097 Dresden Germany Fax: +49-(0)911-30 844 667 48 Phone: +49-(0)351-212 960 19 press(a)torservers.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJSrE7/AAoJEPSKc6jBxtf31rAP/15mEwAiE8dX/+q4n4mKlomj D/eaFJMTRGazwr4J0U92n3ArxBLCAYiIQV/yIYW9R6IGqMTrHX18GSoHw8bF5Xmf BbHDZ4h7IeY2Z6lkMJBqwNejMI0zFqi6rZmIQl4sU4MeByBRtJBePrwJ1+eSn/Kt hSpxZLqTt7geY/V8D97EOjG0+gGfOtZyxCPbmz49g4NTKiI34Sg+pDpgVoqqTFsb XTY8cAn6pDYu60atDTv4F4kyhWkPBKmrkwUL4F65A8VFHu3Hgld2VxveeiZBIbYY 2gsiVz/u16CPts7RGDJdmi/sSa4xo76nKQk5QufM1sS4jahiGn07srNLdWud3NQP VUTty0Wwa8lvBrBbEPUn/Z14sXsXHS3z5WUrLQNGoi4RJxY7+JSimKYxoWz47ejv ps8vHM54McwoJzkbV9wYpOphhQ57v+Ps+l2sW7/T+s3AseP9Ji4sUFotPbeBWhxr MR905ulKYMVXasIWixiOxNsSzPgIPYufIPppMu49dWblaDGKYgkZAgGNgEqa2nl/ C8RAKIW4PwFdb513diUzuYJqHL5GiAGnU+OuPoqn7LYpnN/qmbEGyZNyoXaCp+pR rWAfzQCwL1fTNwMIrcdE3KDZ+oFNmeLZx3uUCHQ45XF4ojuYsGy1lOyhxSAZ1sb3 uWo4s9PMZOKjPOjxt/XQ =6o8b -----END PGP SIGNATURE-----

6 5

Re: [tor-relays] Help testing patch on SandyBridge/IvyBridge? Force disable use of RDRAND in OpenSSL when HardwareAccel is enabled
by coderman 14 Dec '13

14 Dec '13

correct address this time :/ Fwd: #include <std_disclaimer.h> i am not speaking for Tor devs nor Tor project - the cautious should wait for a review and merge. On Sat, Dec 14, 2013 at 6:14 AM, coderman <coderman(a)gmail.com> wrote: > this is logged as trac ticket: > https://trac.torproject.org/projects/tor/ticket/10402 > ... > help coderman test mitigation patch: > https://peertech.org/dist/tor-0.2.4.19-rdrand-disable.patch > https://peertech.org/dist/tor-0.2.5.1-rdrand-disable.patch > https://peertech.org/dist/tor-latest-rdrand-disable.patch many thanks to rl1987! the patches have been updated and verified. anyone running a relay on openssl 1.0.x with HardwareAccel 1 and seeing this line in their notices.log: "[notice] Using OpenSSL engine Intel RDRAND engine [rdrand] for RAND" should** apply the apropos patch above and let me know if it doesn't work. a successful mitigation will look like this: """ [warn] OpenSSL is using RDRAND by default. Attempting to force disable. ... [notice] Using default implementation for RAND . """ **last but not least, please do run a userspace entropy collector like haveged, dakarand, etc. also be sure you're on a recent kernel that is using RDRAND in a conservative / robust manner.[0] best regards, 0. "void extract_buf(struct entropy_store *r, __u8 *out)" https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/driver… good use of RDRAND is: 1. mixed into a hash across the pool, not XOR'd against output, 2. mix the mix back into pool (prevent backtrack attacks) 3. atomically extract portion of pool and mix 4. fold final extracted output in half for conservative operation

1 0

Understanding bandwidth rate
by Florian Lindner 11 Dec '13

11 Dec '13

Hello, I'm using tor 0.2.3.25 from Debian Wheezy, the exit policy is recject *.*, I'm not using the node myself. arm shows these actual bandwidths: Bandwidth (limit: 16 Mb/s, burst: 32 Mb/s, measured: 48.6 Kb/s): Download (13.9 Mb/sec - avg: 11.3 Mb/sec, total: 211.9 GB): Upload (16.0 Mb/sec - avg: 12.6 Mb/sec, total: 237.9 GB): This is my related config: BandwidthRate 5 MB # not set in config BandwidthBurst 10 MB # not set in config RelayBandwidthRate 2 MB # set in config RelayBandwidthBurst 4 MB # set in config I'm a bit puzzled.... Why is bandwidth limit 16 Mb/s? Why bandwidth burst 32 Mb/s? Since I'm not using the node for anything else but relaying I except the bandwidth is more or less equal the RelayBandwidth limit I set. But the averages are so much higher than either the BandwidthRate and the RelayBandwidthRate? What is my problem of understanding here? Thanks, Florian

7 8

Re: [tor-relays] Understanding bandwidth rate
by Oliver Schönefeld 10 Dec '13

10 Dec '13

actually it's Mb, which stands for megabit. since one byte is 8 bit, 2 becomes 16 and 4 becomes 32. therfoe you shoul set your config to 250 Kb (250 Kbit * 8 equals 2000 KByte equals 2 MByte) and 500 Kb (500 Kbit * 8 equals42000 KByte equals 4 MByte). kind regards, Oli Am 10.12.2013 um 13:00 schrieb tor-relays-request(a)lists.torproject.org: > 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. Understanding bandwidth rate (Florian Lindner) > 2. Re: Understanding bandwidth rate (BugZ) > 3. Re: Understanding bandwidth rate (Roman Mamedov) > > Von: Florian Lindner <mailinglists(a)xgm.de> > Betreff: [tor-relays] Understanding bandwidth rate > Datum: 10 .Dezember 2013 11:47:45 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > Hello, > > I'm using tor 0.2.3.25 from Debian Wheezy, the exit policy is recject *.*, I'm not using the node myself. > > arm shows these actual bandwidths: > > Bandwidth (limit: 16 Mb/s, burst: 32 Mb/s, measured: 48.6 Kb/s): > Download (13.9 Mb/sec - avg: 11.3 Mb/sec, total: 211.9 GB): > Upload (16.0 Mb/sec - avg: 12.6 Mb/sec, total: 237.9 GB): > > This is my related config: > > BandwidthRate 5 MB # not set in config > BandwidthBurst 10 MB # not set in config > RelayBandwidthRate 2 MB # set in config > RelayBandwidthBurst 4 MB # set in config > > I'm a bit puzzled.... > > Why is bandwidth limit 16 Mb/s? Why bandwidth burst 32 Mb/s? > > Since I'm not using the node for anything else but relaying I except the bandwidth is more or less equal the RelayBandwidth limit I set. But the averages are so much higher than either the BandwidthRate and the RelayBandwidthRate? > > What is my problem of understanding here? > > Thanks, > Florian > > > > > Von: BugZ <bugmagnet1(a)gmail.com> > Betreff: Aw: [tor-relays] Understanding bandwidth rate > Datum: 10 .Dezember 2013 12:39:00 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > B=bytes > b=bits > > therefore, > Your config setting of 2MB = 16mb > Your config setting of 4MB = 32mb > > > > On 12/10/2013 5:47 AM, Florian Lindner wrote: >> Hello, >> >> I'm using tor 0.2.3.25 from Debian Wheezy, the exit policy is recject *.*, I'm not using the node myself. >> >> arm shows these actual bandwidths: >> >> Bandwidth (limit: 16 Mb/s, burst: 32 Mb/s, measured: 48.6 Kb/s): >> Download (13.9 Mb/sec - avg: 11.3 Mb/sec, total: 211.9 GB): >> Upload (16.0 Mb/sec - avg: 12.6 Mb/sec, total: 237.9 GB): >> >> This is my related config: >> >> BandwidthRate 5 MB # not set in config >> BandwidthBurst 10 MB # not set in config >> RelayBandwidthRate 2 MB # set in config >> RelayBandwidthBurst 4 MB # set in config >> >> I'm a bit puzzled.... >> >> Why is bandwidth limit 16 Mb/s? Why bandwidth burst 32 Mb/s? >> >> Since I'm not using the node for anything else but relaying I except the bandwidth is more or less equal the RelayBandwidth limit I set. But the averages are so much higher than either the BandwidthRate and the RelayBandwidthRate? >> >> What is my problem of understanding here? >> >> Thanks, >> Florian >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > Von: Roman Mamedov <rm(a)romanrm.net> > Betreff: Aw: [tor-relays] Understanding bandwidth rate > Datum: 10 .Dezember 2013 12:50:58 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > On Tue, 10 Dec 2013 06:39:00 -0500 > BugZ <bugmagnet1(a)gmail.com> wrote: > >> Your config setting of 2MB = 16mb >> Your config setting of 4MB = 32mb > > "mb" what, millibytes? https://en.wikipedia.org/wiki/Metric_prefix > > If you're trying to teach others then at least get it right yourself... > > -- > With respect, > Roman > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Your system clock just jumped
by Jobiwan Kenobi 04 Dec '13

04 Dec '13

I've been running a relay for about months now. It runs on an 1.6 Ghz single core Atom with hyperthreading, 1GB of RAM. It's on my home connection; I advertise only 176 KB/sec. Under normal conditions, it pumps around 100KB/sec, it has around 600 connections, it uses around 20% CPU. Everything looks very healthy. Lately I have seen a couple of incidents where the number of connections suddenly goes up to over 3000, traffic increases heavily, CPU usage goes well over 150% (out of possible 200). Traffic can go up to between 500 and 1000 KB/sec for long periods of time. Sometimes it seems that my relay just can't take it anymore. In the log, the ratio of TAP handshakes goes wild, and I get clock jump warnings. My clock does not jump. This is Tor hanging while allocating memory. Today I had a really bad episode, where the box started thrashing. When it became responsive again, Tor was left in a state where it was constantly downloading about 400KB/sec more than it was uploading. Normally I have a little bit more up than down, because I'm a directory server as well. I can not explain having a lot more down than up. I can fantasize that those hangs/clock jumps ("assuming established circuits no longer work") could leave 'half' circuits. Finally I restarted my relay, (which I really don't like to do) and after a while it stabilized. At this point, my router shows a peak of almost 8000 NAT sessions. Is this normal behavior of the network (esp. the sudden increase in connections) or is this another kind of attack/probe like what we've seen in early September? Is this because this machine is just too underpowered? Should I collect/provide any diagnostics? Have others seen similar events? Thanks, -Job Nov 16 22:39:52.000 [notice] Heartbeat: Tor's uptime is 36 days 6:00 hours, with 615 circuits open. I've sent 192.16 GB and received 171.74 GB. Nov 16 22:39:52.000 [notice] Average packaged cell fullness: 87.305% Nov 16 22:39:52.000 [notice] TLS write overhead: 9% Nov 16 23:39:28.000 [notice] Circuit handshake stats since last time: 6011/6013 TAP, 35/35 NTor. Nov 17 00:39:28.000 [notice] Circuit handshake stats since last time: 12521/12521 TAP, 47/47 NTor. Nov 17 01:24:45.000 [warn] Your system clock just jumped 138 seconds forward; assuming established circuits no longer work. Nov 17 01:39:28.000 [notice] Circuit handshake stats since last time: 49689/1454481 TAP, 51/51 NTor. Nov 17 02:28:44.000 [warn] Your system clock just jumped 174 seconds forward; assuming established circuits no longer work. Nov 17 02:33:12.000 [warn] Your system clock just jumped 268 seconds forward; assuming established circuits no longer work. Nov 17 02:35:17.000 [warn] Your system clock just jumped 125 seconds forward; assuming established circuits no longer work. Nov 17 02:39:28.000 [notice] Circuit handshake stats since last time: 55822/3477278 TAP, 37/37 NTor. Nov 25 06:53:31.000 [notice] Circuit handshake stats since last time: 28194/28200 TAP, 32/32 NTor. Nov 25 07:29:57.000 [warn] Your system clock just jumped 114 seconds forward; assuming established circuits no longer work. Nov 25 07:31:58.000 [warn] Your system clock just jumped 121 seconds forward; assuming established circuits no longer work. Nov 25 07:53:31.000 [notice] Circuit handshake stats since last time: 24207/2692265 TAP, 42/42 NTor. Nov 25 08:53:31.000 [notice] Circuit handshake stats since last time: 76451/4271579 TAP, 49/49 NTor. Nov 25 09:53:31.000 [notice] Circuit handshake stats since last time: 84956/3666170 TAP, 42/42 NTor. Nov 25 10:45:15.000 [warn] Your system clock just jumped 302 seconds forward; assuming established circuits no longer work. Nov 25 11:01:59.000 [warn] Your system clock just jumped 1004 seconds forward; assuming established circuits no longer work. Nov 25 11:02:04.000 [notice] Circuit handshake stats since last time: 64816/3151447 TAP, 38/38 NTor. Nov 25 11:02:18.000 [notice] Heartbeat: Tor's uptime is 5 days 11:42 hours, with 2450 circuits open. I've sent 46.92 GB and received 46.11 GB. Nov 25 11:02:18.000 [notice] Average packaged cell fullness: 82.623% Nov 25 11:02:18.000 [notice] TLS write overhead: 8% Nov 25 11:53:31.000 [notice] Circuit handshake stats since last time: 18710/1099205 TAP, 193/202 NTor. Nov 25 13:22:03.000 [warn] Your system clock just jumped 1923 seconds forward; assuming established circuits no longer work. Nov 25 13:27:23.000 [notice] Circuit handshake stats since last time: 70795/3452514 TAP, 138/140 NTor. Nov 25 13:35:51.000 [warn] Your system clock just jumped 828 seconds forward; assuming established circuits no longer work. Nov 25 13:42:15.000 [warn] Your system clock just jumped 384 seconds forward; assuming established circuits no longer work. Nov 25 13:43:15.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Nov 25 13:43:16.000 [notice] Read configuration file "/opt/etc/tor/torrc". Nov 25 13:46:09.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Nov 25 13:46:39.000 [notice] Clean shutdown finished. Exiting.

3 3

Relay - Conflicting data (Atlas != log)
by Mark Jamsek 03 Dec '13

03 Dec '13

I am trying to run a restricted exit relay on FreeBSD 9.2-RELEASE in a jail. I tested it out a couple days ago on an old(er) box, and everything worked fine: https://atlas.torproject.org/#details/A5CA10E554124289C1B42B4CCA68F0CACFE50… Decided to get it running on a fresher rig, all appears well according to system data: $ tail notices.log Dec 02 15:49:31.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. Dec 02 15:49:34.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Dec 02 15:49:34.000 [notice] Bootstrapped 100%: Done. Dec 02 15:49:34.000 [notice] Now checking whether ORPort 110.146.133.98:9001 and DirPort 110.146.133.98:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Dec 02 15:49:40.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Dec 02 15:49:59.000 [notice] Performing bandwidth self-test...done. Dec 02 15:50:33.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Dec 02 15:50:33.000 [notice] Not advertising DirPort (Reason: AccountingMax enabled) Dec 02 15:51:50.000 [notice] Your DNS provider gave an answer for "rmus4fklislhf", which is not supposed to exist. Apparently they are hijacking DNS failures. Trying to correct for this. We've noticed 1 possibly bad address so far. Dec 02 21:49:39.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 946 kB and received 7.09 MB. $ ps -aux |grep tor USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND torrelay 86844 0.0 12.1 60532 52796 ?? IJ 3:49PM 0:33.50 tor --RunAsDaemon 1 Apart from the DNS hijacking entry(?), Tor is apparently up and running. However, according to Atlas, it is not: https://atlas.torproject.org/#details/EE16D7A4FBCF6494FEE75C856D76782295CB9… (forgot to backup tor key; hence, the different print) Not sure what to think or do. Is it advertised on Atlas as false due to this entry: [notice] Not advertising DirPort (Reason: AccountingMax enabled) Or is one of the two sources (system or Atlas) wrongly reporting? Thank you. -- 01101101 01100001 01110010 01101011

2 2

Proper bandwidth units [was: Exit nodes on Gandi]
by grarpamp 02 Dec '13

02 Dec '13

On Fri, Nov 15, 2013 at 3:47 PM, Eric van der Vlist <vdv(a)dyomedea.com> wrote: > Without bandwidth limitation that's true. OTH, I currently consume only > ~ 50 Gbits/month and the limit is 500 Gbits. Would a relay limited to > let's say 200 or 300 Gbits/month still be useful for the community? People, can we please mind using the proper units. I know Tor doesn't make it easy because Tor itself incorrectly uses Bytes. But Tor is a network application, and real network apps are measured in 'bits per second', not 'bytes transferred off disk', even if the latter is what silly hosters sell by... mostly due to their presumed need to tie in with their typical customers supposed Apache access_logs. But believe me, what hosters really care about is their upstream bill in bps rate, they're just converting that for access_log presentation to you. Your further mixing of 'giga bits per month' doesn't help *at all*. Please try to use 'bits per second' as the common denominator on this (network application) list. BTW, Gandi is historically a fairly progressive company. The right approach could have some good wins there.

10 24

Newly configured relay questions
by Conrad Rockenhaus 01 Dec '13

01 Dec '13

Hello all, I brought a new non-exit relay online: ec2bridgerocks001 D06C B145 56C1 F73A F317 B555 C279 2F7B 105C 95B4 It's been operational for 6 days now, Tor has been reporting bandwidth usage, but when I try to look for it in the TorStatus page, it's not listed. I'm operating this relay on EC2 and I've opened all the usual ports. I've also checked the Tor metric portal, can't find it there either. So, I'm wondering - is there something I missed in the configuration? The torrc is pretty much the default EC2 one. Thank you I appreciate any thoughts/assistance. Respectfully, -- Conrad Rockenhaus http://www.rockenhaus.com/ http://www.lagparty.org/~conradr/

5 6

Named flag
by Sebastian Urbach 28 Nov '13

28 Nov '13

Dear colleagues, Im a bit confused about the "named" flag. My relay is running smooth and i already received the "guard" flag but still no named flag. I also read the directory specification paper. I dont have the unnamed status nor is there another server with that name in use. Im not sure if the authority supports name binding but from what i understand the authority should support it. Maybe someone on this list is able to look into that matter ... Router Name: ParEpistemenTaksis Fingerprint: 3C82 285F AC21 71FA 5178 340A 82B0 5F21 90AB 68E9 -- Mit freundlichen Grüssen / Sincerely yours Sebsstian Urbach ----------------------------------- Religion is a symptom of irrational belief and groundless hope. ----------------------------------- Gregory House, M.D.

3 4

Huge harrassment by Irdeto and IP-Echelon, 83 mails, in 2 weeks, need your help
by julien.robin28＠free.fr 19 Nov '13

19 Nov '13

Hello everybody, My 2 exit nodes servers are ArachnideFR35 and ArachnideFR35v2, with respective observed bandwidth of approximately 100Mb/s and 30 Mb/s (12 200 KB/s and 3800 kB/s). They are momentarily down since I have decided today to put them down while I will be trying to solve this enormous Irdeto/IP-Echelon problem. I want to keep my servers alive but I realize that it will not be possible if harassment doesn't stop quickly. My ISP is just transmitting to me a huge amount of abuse complaints every day (and never makes any comment) but they are too many and the incredible patience of my ISP cannot be unlimited. And all this, despite of the fact that my reverse DNS are set, since the first day, to http://digi00277.torproxy-readme-arachnide-fr-35.fr and http://digi00433.torproxy-readme-arachnide-fr-35.fr with the Tor Exit Notice on port 80. And it is this address that appears into the Tor Relay lists. I have decided to temporarily shut down my servers today (November 13, 2013, 14:50 UTC) while I'm trying to solve this enormous Irdeto/IP-Echelon problem, and to send a mail to my ISP to tell them that I will try to fix this problem before to restart my servers. Since August 18, 2013, the two machines that I'm running as Tor Relays are full exit nodes (reject *:25, *:26, *:27, accept *:*) (before it, since May 2013, they was only Relays nodes) because I was thininking that : if there is abuse complaints, I will be able to face them. I'm not the only one in this case (accept *:*), But as I see in this mailing-list it seems that the amount of abuse complaint I'm receiving is completely abnormal. My service provider is Digicube.fr, it's a really little company that doesn't seems to be able of handle everything in time. I not sure if there was no abuse complaints before end of October, but if there was, I never seen them. I have tried everything: by mail or by the Web Interface that figures in the mails, with all these arguments: - Since 08/18/2013, 95.130.10.70 and 95.130.9.89 are dedicated high speed Tor Exit Router, they do not host or share anything, they are just international network routers with empty hard disk drives. - All reports you sent about these permanent IP Addresses (95.130.10.70 and 95.130.9.89) for several weeks are wrong: the IP Address that appears into your reports is the IP Address of the router, not the user. - These routers and his responsible are NOT infringing any copyright. Neither technically nor legally. - You got to understand that the goal of such a network is a way much fair goal than movies on the Internet. In March 2011, the Tor Project was awarded the Free Software Foundation's 2010 Award for Projects of Social Benefit on the following grounds: "Using free software, Tor has enabled roughly 36 million people around the world to experience freedom of access and expression on the Internet while keeping them in control of their privacy and anonymity. Its network has proved pivotal in dissident movements in both Iran and more recently Egypt." But for both Irdeto and IP-Echelon, they don't care, and every day, the harassment procedure continues. I think they don't read my emails, I hope they can receive them; I never had any answers from them. I told them that if there is no answer, I will not have any reason to keep watching their emails... may be I need to ask my ISP to put a spam-filter about that, but I think that such a proposal have no chance to be welcome into an abuse service ! Don't be horrified: here is, below, the list of all abuse complaints I've received from them. You will understand why I love my ISP, and why I need to quickly find a solution! The olders ones are from October, 29 2013. 1 - IP-Echelon part : notices.sony(a)ip-echelon.com : Unauthorized Distribution of the Copyrighted Motion Picture Entitled "White House Down" - Case ID 131400838 Unauthorized Distribution of the Copyrighted Motion Picture Entitled "White House Down" - Case ID 131396212 Unauthorized Distribution of the Copyrighted Motion Picture Entitled "White House Down" - Case ID 131732460 notices.warner(a)ip-echelon.com : Notice of Claimed Infringement - Case ID 130362722 Notice of Claimed Infringement - Case ID 130296727 Notice of Claimed Infringement - Case ID 130308292 Notice of Claimed Infringement - Case ID 131314345 Notice of Claimed Infringement - Case ID 131160950 Notice of Claimed Infringement - Case ID 131049815 Notice of Claimed Infringement - Case ID 131044521 Notice of Claimed Infringement - Case ID 130778319 2 - Irdeto part : activision(a)copyright-compliance.com : 290-117780660 Notice of Unauthorized Use of Activision Property 290-117744045 Notice of Unauthorized Use of Activision Property 290-117740528 Notice of Unauthorized Use of Activision Property 290-117895342 Notice of Unauthorized Use of Activision Property 290-117877594 Notice of Unauthorized Use of Activision Property 290-117854157 Notice of Unauthorized Use of Activision Property 290-117818254 Notice of Unauthorized Use of Activision Property 290-118018138 Notice of Unauthorized Use of Activision Property 290-117983726 Notice of Unauthorized Use of Activision Property 290-117965572 Notice of Unauthorized Use of Activision Property 290-117961867 Notice of Unauthorized Use of Activision Property 290-118628905 Notice of Unauthorized Use of Activision Property 290-118491174 Notice of Unauthorized Use of Activision Property 290-118453073 Notice of Unauthorized Use of Activision Property 290-118398863 Notice of Unauthorized Use of Activision Property 290-118374287 Notice of Unauthorized Use of Activision Property starz_media(a)copyright-compliance.com 314-117685560 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117684996 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117666358 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117666311 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117663952 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117653783 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117780831 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117509673 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117452028 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117258420 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117005314 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-117827226 Notice of Unauthorized Use of Starz, LLC ("Starz") Property 314-118012162 Notice of Unauthorized Use of Starz, LLC ("Starz") Property teachingcompany(a)copyright-compliance.com : 120-117780245 Unauthorized Use of The Teaching Company Limited Partnership Property paramount(a)copyright-compliance.com : 22-116418467 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-116390947 Notice of Unauthorized Use of Paramount Pictures Corporation/Dreamworks Animation SKG, Inc. Property 22-116289727 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-116462954 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-116463639 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-116468964 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117784969 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117784422 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117668962 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117637379 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117360665 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117326212 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117319457 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117260566 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117206174 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117194860 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117194189 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117174717 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117143821 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117049672 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-116899426 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-116897671 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-116892769 Notice of Unauthorized Use of Paramount Pictures Corporation/Dreamworks Animation SKG, Inc. Property 22-116887099 Notice of Unauthorized Use of Paramount Pictures Corporation/Dreamworks Animation SKG, Inc. Property 22-116847203 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117909973 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117903528 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117858364 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117857551 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117815491 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117978380 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117946018 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117933311 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117930244 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-117916165 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-118620584 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-118611592 Notice of Unauthorized Use of Paramount Pictures Corporation/Dreamworks Animation SKG, Inc. Property 22-118607311 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-118523821 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-118519781 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-118369725 Notice of Unauthorized Use of Paramount Pictures Corporation Property 22-118369726 Notice of Unauthorized Use of Paramount Pictures Corporation Property ----------------------------------------------------------------------- I wanted to die when my fingers have typed this sentence : /etc/init.d/tor stop And watching my server slowly going down... :( I understood that a solution is to put a restricted exit policy, and only enable people to browse the web and nothing else, but before to do this and become something like "quarter of an exit node" (I'm kidding but you see what I mean ^^) I want to know if the amount of abuse complaint from Irdeto and IP-Echelon are normal with a full exit policy, or if I have a chance to make them stop while keep operating full exit nodes. Thank you in advance, Arachnide needs your help ! Best regards, Julien ROBIN PS : I will be at work the entire day tomorrow, sorry if I don't answer before tomorrow evening.

6 8