Re: [tor-relays] Advice on dealing with ISP's response to DMCA takedownnotice.
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 *: # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *: # distinct ExitPolicy accept *:1 # 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
[tor-relays] Thanks for the advice on handling DMCA complaints.
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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Thanks for the advice on handling DMCA complaints.
Christopher Jones: 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. Not the Tor project itself, but have a loot at Chilling Effects: https://www.chillingeffects.org/. It was founded by Wendy Seltzer who is also on the board of directors of The Tor Project. Chilling Effects would probably welcome your help. :) -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Thanks for the advice on handling DMCA complaints.
On Fri, Oct 25, 2013 at 11:03:27AM -0400, Christopher Jones wrote: 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. If you want to go even more conservative, you could allow just 80 and 443. It would still be useful to many people, and be even less likely to draw dmca complaints. Something to consider for the future if you need another step in the negotiation. 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. Lunar's pointer to Chilling Effects is a good one. But see also this mail from the distant past: https://lists.torproject.org/pipermail/tor-talk/2005-October/016301.html You see, if somebody sends you a DMCA takedown knowing that it doesn't apply to you, then *they're* breaking the law. So in theory you could notify them that you've got safe harbor under DMCA 512(a) and would they kindly stop harrassing you, and then when they send the next letter you can countersue. Somebody should do this someday, but it will be an involved and messy process. On the plus side, some large universities have successfully used this approach (or more precisely, the threat of using it) to stop the bigger DMCA bullies from wasting their time. On the minus side, you as a customer of your ISP don't get to make this decision, at least not by yourself, because your main problem is the policy of your ISP, not any actual laws. 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? Tor counts bytes separately in each direction. So 5Mbytes means 5mbytes reading and 5mbytes writing. So you are currently limiting your relay to a long-term average of 40mbps. 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? There isn't any functionality currently to limit how many connections your relay will use/accept. You need to be able to have a connection open to every other relay, and to the exit destinations that users ask for (if your exit policy allows it), and to clients if they pick you for their first hop. Refusing to do any of those connections degrades service (and in the relay-to-relay connection case, it potentially messes with anonymity in complex ways too, since the Tor network is no longer a clique topology). Fortunately, sockets are basically free on a real OS. The main challenge comes up in cheap VPS systems where they artificially limit system resources to make it hard for you to do anything with your VPS. --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TCP: drop open request
On Fri, 25 Oct 2013 01:13:57 -0400 grarpamp grarp...@gmail.com wrote: On Fri, Oct 25, 2013 at 12:10 AM, Roger Dingledine a...@mit.edu wrote: On Fri, Oct 25, 2013 at 12:43:42PM +0900, mett wrote: 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). if you're in BSD-land. It's a Linux message. Feed it to a search engine and you'll find several things to try depending on what the cause is. It shuts off either because Tor is attracting the syn's or the overall count is lower with Tor off, you'll have to tcpdump to see. Look into syn cookies, packet filter rules, and stack tuning. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Thanks a lot for both answers. Actually, I recently changed my IP from dynamic to static(a week ago), and at the same time I changed the settings regarding syn cookies and spoofed IP's source address verification, so it might have been related. I'll definitely tcdump my connection to check deeper. By the way, the system is debian-squeeze on a P4(linux kernel 2.6 serie, 2.4CPU for 512RAM), that I use as a multipurpose router/server. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
