- tor-relays - lists.torproject.org

DMCA letters
by jvoss＠altsci.com 13 Mar '13

13 Mar '13

Hi all, I've been running a Tor exit node on my new server for 16 days. Today I received my second automated DMCA infringement notice from HBO. I sent them the boilerplate you see at the bottom of the message both times. My colo provider Hurricane Electric understands Tor, which is awesome. I don't think it'll be an issue, so I'm happy with this. I'm wondering if anyone receives a large number of DMCA infringement notices and whether there was a resolution. It would certainly make my life a little bit more difficult to send more than one of these per week. When I got my first letter I was pushing 5 Mbps (megabits) and now I'm pushing 9 Mbps. I've set the RelayBandwidthRate to 5120 KB which should give a max rate of 41 Mbps. If infringement notices increases linearly with traffic, this could become an issue. I'm happy to share the infringement notices if anyone is interested. I followed a few of the tips from https://blog.torproject.org/running-exit-node , I got a separate IP address and I reduced the exit policy. I plan to update the reverse dns. I don't feel like reducing the exit policy does anything because BitTorrent was designed to run on any high port. Also, reducing the exit policy blocks researchers who are doing port scans and header grabbing over Tor. That's a point of contention for me because I know legitimate researchers use Tor for that purpose. Does anyone have any data or anecdotes on how exit policy affects malicious use of Tor vs legitimate use of Tor? Btw, my server is 216.218.134.12. I'm running a patched version of tor 0.2.3.25 which fixes a few bugs I found in buffer events. See https://trac.torproject.org/projects/tor/ticket/7788 for more info. Uptime is now 6 days, 13 days without a crash. Thanks, Javantea ------------------- Dear Andrew Martin: The IP address in question is a Tor exit node. https://www.torproject.org/overview.html There is little we can do to trace this matter further. As can be seen from the overview page, the Tor network is designed to make tracing of users impossible. The Tor network is run by some 2500 volunteers who use the free software provided by the Tor Project to run Tor routers. Client connections are routed through multiple relays, and are multiplexed together on the connections between relays. The system does not record logs of client connections or previous hops. This is because the Tor network is a censorship resistance, privacy, and anonymity system used by whistle blowers, journalists, Chinese dissidents skirting the Great Firewall, abuse victims, stalker targets, the US military, and law enforcement, just to name a few. See https://www.torproject.org/about/torusers.html.en for more info. Unfortunately, some people misuse the network. However, compared to the rate of legitimate use (the IP address in question processes approximately 11 megabits of traffic per second), abuse complaints are rare. https://www.torproject.org/docs/faq-abuse.html.en This is the second e-mail from you that I am replying to. The only thing that has changed is that I have increased the bandwidth to 9 megabits per second. If you have further questions, feel free to contact me at ------------ Sincerely, -----------

5 6

Local problem or Authority problem?
by Steve Snyder 12 Mar '13

12 Mar '13

This is the 2nd time I've seen the message below in the last few days. Is this a local problem, or is this Authority server having network problems? --------------------- Mar 12 16:13:57.000 [warn] Received http status code 504 ("Gateway Time-out") from server '154.35.32.5:80' while fetching consensus directory. Mar 12 16:13:57.000 [warn] Received http status code 504 ("Gateway Time-out") from server '154.35.32.5:80' while fetching "/tor/server/d/04074EB96250570D79D54ABF8BCCB5D78DCAF288+04A4D41B424AEDA92907E8FD2D3E62150EDF6C2B+05FD952570E17B917395B0A1B85BE3A9D0B2CDFB+063AD80363C90979C3BF86B7059A418C5FD5FEE3+087D53B75320FCB0CA6C3410F1772A75A1BCCD1C+08BE6F4FDAED1B19ED764696DC1BE56B738228E0+09579C2014F3B0419E98E78F2A25D8DD6C96B2E2+0999BB98E0F66C0B888530E3F2E5212DDDF0C6DE+09B0FA1C28671CB104AFC9EDD65239084E407BA0+09BDCC19AD5AB4C3926F7A68F283746871D4D56F+0AB6B62AE4772EE2965DFDAFB8130ECE9CD36884+0C03BE2409199A5D144FE71C88978393DDD421BB+0C2F936E8C2612AAC08C01A0351CE38879E9BDDC+0C7CC03C29DCA1A5F1B52B960EEC9626D174B58E+0D36F472EBFAE10CB177AACC6A119BE3F9DCE08C+0D43FC4BC3A709B0466C824B66685B735CA0238D+0D92EF510A781FC282D09E4AD59BA0C549C38CB5+0DE1BBE15B66DEDDA4BA26CCB81243CA5D5B4361+0E68E2980775EC1A4DCF243B300CD10B667D727E+0EC893270D60852719EA61437365D4E04B58DFF0+0FCF73CC589E66B0A61F5243E98EE181556E58DA+1383AED682BA066E90AB4A129313F8CB74083009+138AC265F2027B064686E061B9BE95B4375F1EDD+14AD0D65F7B8CAB4D1244A81A94435D72C405ED2+163A20C60F5B3852DC4AE997B1AC684167597DA1+176D2F97C6D94847812BA237E5E8FCBC1C06DE23+1775169594A4FC2E0BFF2DC3A72B1250E48AF967+1925372A11574505E657E5FBA91790F1E199E9A7+1A81CCF4DA2D1083C486502D7A1531E0FDA9A976+1A8FFED1415988D7F150DB934B142D367A91F1D4+1AA4EF44F5A1530A7EBF7FCF58F9B9F73B8C8CBD+1AC92989A40613D367D4FBC938260743F735D006+1B047A3E77D42D6F90AC70AD9087C87273608874+1BD1A901C208924FF723449204C1B739253CFC88+1C88BA75E091BA0AD0586F4496563A8108EF0AFD+1D9BD53B703F5B74D35FEFE90A7AAB877C9811C3+1DDB372BA6ED786C00A0A544FC6111388039E208+2007140616A3236E274F96794033B8100FD483E2+210AA9E1A6A081FD73E2ABFB53B58484CFD86854+215DFFBB03D9B0273E54A5312A8D0CC8790FBEBF+2188A991565919B0A93FC008D7F7CA3B88226CD0+21A3880C02DD2F329975A672A378BCF456900D68+21CF5A07F11BD114FDD83A1A9D84011CDEB4B553+22CDC2869521DAB7B894EAB61C22CBD4F91EBFEA+247120DAD42F112C75EA31B08305AEA1B8030C29+24D23ACAA3B84B6FAE1C8C3C6397C8FA72311960+2569B8E88056D46BD791D3EF828669659A37E0C9+262FA174601FDCDB024BED3040929F21BDC36D48+27FEE7C12A2F2CED4FB4BFD8B453740CC14CBE0A+2AF5996140CB3C40ADD81C1C56734EEAB12EE967+2E94AE3BD0CE4F5DFE7779D5358B0B87825B8637+2E95EC620F01E26C120D8097176C4E2A39873F44+2EC372E877F32770625386C46AA1C0A325B23B2C+2FB82F9DB850312DF102F15C904B9DD6D01273B7+3104BEF38E684D052EB5358B0DB8A0221A1D7E2D+3214DEC5847CB9662F76AD2A73F35AD5EB8ADAC5+327371CEF85B0358A179EDBC6305601F3E1A617F+3282DD9CA468BCD87EF104A947FC087BE8457CD4+32AA787CB8185DBB1B371DC3A055C9D54EE263AF+334C9E6D243E607D7F309F6D49EA617D18CBA4AC+33DF5016BA97AA6B00F30C753A9DC2A6B8046F93+3444C8C526C39133A91F519C07476BF40F422330+34D3650408E276D0204EB8711B083432AB5F2736+3521734E1923619DBB92E43FBA1454995BD9BFA2+35624B39BC583AFD70F21C4E4F16E316D83898C2+366E6CB7854E6FB47411484CCF16316967C8BB68+372B550402CF1CAE0EB53CF03B036619521F5401+37BCE27DA528E4B5ECB639EF38768415981376B8+3990219DEFB3E6991ACE408A1D44CBCD226673D1+3D0E6313BEF11C56B4A1703716EACB2D2BFAF170+3D38952385BD797A7E42AE98889BBA39334CE883+3D480580359358750F66AFE84E187AE789380880+3D9F982ECAEE4FA35D4A963BECFB7F3E7B6659C8+40193F0DF2D4041C421455C079272038F9BC3DAC+40BBB8FB6F665C87D9297D67BB053BE388611A09+40DF0911958AEC11481AFE923D0EEA2B7A8EC7DF+419E7503347EA5CD467BB8383565AEC08722A417+41EF33A6492F7563978A369A23F8753F9AE18DB3+42049023A0ADD501B4426F851AC96CE184DC53BD+42F6AA4DF5B2DF4E0C694E7E8D44F07AE0273983+434CE452D749AB0ECB3328F1173EA5C5D9563F28+43AF557F22152E4868AFCBC637F67E3D28502CE5+44FFB205642C55639AB23C33B342B7B4BA52A40F+4547E5892491161DA48E3A85F387F414453D767F+458D39FAFA9D37E137D810E42FC3E3FCA73D1DD1+45B341C87E3765EC668F3F79FEAA775FFAB0FB72+46146B22376DD4CF48EFE695360D4E04C6B27A5F+4672A76E50B62C6ECB36374904BD2E27D58E0F34+473631BF990138E4F0F9DBC6F92A291346F403C6+49067AB9F33B3A813055D1F06C4196AA01952F1F+496341B3CF1F500BF3544EB4D4B4C65A96A663D0+4B03C837FBE98892ABFBD8F88A87DD253F8CBCE3+4D66AEA3A987CB19F6F1A416369FE52DD90C5B97+4D9705EB0D8539C6DB31FB683ADABEAA8B50237C+4DA6EF73ED368372F0639D030408506B7F1874FE+4E825DC538DA34966EA64712E6B7DD84613FD238.z". I'll try again soon.

3 2

ORPort NoListen
by Sina Eetezadi 11 Mar '13

11 Mar '13

Hi! I want to have port 443 advertised but listen on port 9001. My router then forwards 443->9001 to the machine tor is running on. It works with this: ORport 433 ORListenAddress 0.0.0.0:9001 However I thought this is deprecated and I rather use: ORport 443 NoListen ORPort 0.0.0.0:9001 NoAdvertise The latter however does not seem to work. Arm for example still errors "binding failed" and I see no incoming connections. Is this a bug? Thanks. SE

2 4

relay exposed?
by eliaz 09 Mar '13

09 Mar '13

So, some hours ago I noticed a circuit on the network map consisting of a relay in my own country, another one 11,000 km away, and - surprise - my own bridge relay. Can this be so? I thought that bridges, though published, are anonymous. My TBB configuration seems fine, it's what I've used in previous implementations. The only difference I've written into torrc for this run is SocksPort auto. The bandwidth rates seeming way higher than should be allotted to my bridge (10485760 & 5242880, rather than the 196608 & 98304 of previous runs), I checked my bandwidth-limit setting and found that I had inadvertently chosen > 1.5 Mpbs instead of 1.5 Mpbs (but as I'd noted to myself previously, the higher setting doesn't seem to matter, except maybe to improve performance a bit). The relays_ published output is as usual (not that I'd be likely to recognize anything amiss in that report). One other thing that may be pertinent and which I've wanted to ask about for a long time is this: I occasionally for convenience run my open browser from the same vista machine on which I'm running the TBB at the same time. Is this bad practice, and could it have been the reason that the bridge nickname showed in the network map? - eli gpg: 0xE498E90D

1 0

DynDNS and TOR bridge
by Sina Eetezadi 06 Mar '13

06 Mar '13

Hi, I have a bridge running and since my ISP is changing my IP at least daily, I thought it might be a good idea to set my DynDNS in the torrc file. Is it a good idea? How do I set that? Thank you. Sina

5 8

Recommended specifications for 1Gbps exit
by Matt Joyce 05 Mar '13

05 Mar '13

I am wondering if anyone with experience in this area could advise me some on recommended specifications for a 1Gbps exit I think my latest once needs a package upgrade to handle it, currently seems stuck at around 100Mbps worth of traffic. Currently it has access to 3 v cores @1.33Ghz and 1GB of RAM and I think the latter might be becoming the limit instead now I had thought it was the CPU when it had just the one core but that alone hasn't helped. I am not entirely sure if tor is infact using the other cores though watching with top it is sitting at 100 or a fraction over like 104% or so. MaxCPU's is set in torrc to 4 as the OS sees 4 virtual cores but is capped to 300% by the hypervisor perhaps it should be set to 3 not sure if there is any benefit in setting to 4 I have limited experience with virtual servers but unfortunately a fully dedicated server for tor is financially out of my budget at the moment. Also, just to confirm while I'm aware it's very possible that the limitation could be bandwidth given it shares with the other VPS'es on the host I don't believe that was the case, I pulled a backup from there to another server of mine on a different AS and continent and it transferred at 250Mbps while tor was running at 100Mbps the entire time, so unless the contention is over the download which seems less likely for a server I think we should be able to get a good 300Mbps of exit capacity out of this possibly more. So can anyone can advise on recommended CPU, RAM have to consider budget but will try and meet them, also if there are any settings I should check in torrc?

5 9

[ANNOUNCE] check_tor.py: a Nagios check for Tor relays
by Jérémy Bobbio 26 Feb '13

26 Feb '13

Hi! I hereby announce the first release of check_tor.py. It is meant to be used with Nagios (or a similar tool with a compatible interface) in order to check if a bridge, entry node, middle node or exit node is working as intended. check_tor.py is a Python script that relies on Stem [1] to control a dedicated Tor instance in order to perform its checks. For more documentation, please refer to the README at: <http://anonscm.debian.org/gitweb/?p=users/lunar/check_tor.git;a=blob;f=READ…> Download through Git: $ git clone git://anonscm.debian.org/users/lunar/check_tor.git $ cd check_tor && git tag -v 0.1 Browse using gitweb at: <http://anonscm.debian.org/gitweb/?p=users/lunar/check_tor.git> check_tor.py is licensed under GPLv3+. Contributions are highly welcome. [1] https://stem.readthedocs.org/ -- Jérémy Bobbio .''`. lunar(a)debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-

2 2

Google Groups Exit Policy Reject?
by Jonathan Baker-Bates 25 Feb '13

25 Feb '13

Hi All, I've been forwarded a request to block Google Groups IPs due to some abuse or various usenet groups. Is anyone else rejecting from these IPs, and should I do the same? Thanks, Jonathan

4 5

US Investigators seem to learn
by Moritz Bartl 22 Feb '13

22 Feb '13

Hi, I thought I would let you know: Our US hoster is regularly contacted by law enforcement about our exits there. Some agents ask if the traffic pattern is balanced, ie. if the same amount of traffic enters and leaves the box. I always argue that this is a good indicator for Tor traffic, and that it is bad to mix Tor traffic with other traffic for that exact reason. -- Moritz Bartl https://www.torservers.net/

7 9

Problems with Debian package and low ports
by Chris Baines 14 Feb '13

14 Feb '13

I am having some problems with tor (version 0.2.3.25-1), I get warnings when it resumes form hibernation: Feb 11 00:00:00.000 [warn] Could not bind to 0.0.0.0:80: Permission denied Feb 11 00:00:00.000 [notice] Opening OR listener on 0.0.0.0:443 Can anyone help?

11 11