December 2017 - tor-relays - lists.torproject.org

Re: [tor-relays] DoS attacks on multiple relays
by teor 09 Dec '17

09 Dec '17

> On 9 Dec 2017, at 03:35, x9p <tor(a)x9p.org> wrote: > > Hidden Service operators, and private guards operators protecting yours > Hidden Services, if you believe it is better safe than sorry, I strongly > advise on blocking the above IP addresses in your firewall, while they are > not pulled out of the network. There's no evidence these guards are malicious. They might just be run by an operator who doesn't know to set ContactInfo and MyFamily. (And MyFamily is irrelevant for relays in a /16, anyway.) We are working on vanguards in 0.3.3 to address onion service guard discovery issues like this. That way, we change the entire network so onion services are safer. Changing just a few makes them stick out. By "private guards" do you mean "bridges"? That would be a very bad idea: it would make the bridge and its onion services stand out within minutes or hours on the network, because each circuit gets a different middle node, and the nodes would not be evenly distributed. If you block a guards on an onion service, it will look different, but that might be unnoticeable for a few months. (More precisely, it's safe in proportion the guard rotation period, divided by the number of related onion services blocking those guards, divided by the consensus weight fraction of blocked guards. We don't expect that people will do this calculation themselves, which is why we say "don't do that".) But we really don't recommend people block guards or set EntryNodes on an onion service. It's quite risky long-term. T

2 1

Re: [tor-relays] Action relays on 188.214.30.0/24 subnet
by teor 08 Dec '17

08 Dec '17

> On 6 Dec 2017, at 15:14, x9p <tor(a)x9p.org> wrote: > > > Shouldn't an action be taken against such relays? > > https://atlas.torproject.org/#search/188.214.30 > > They are clearly being run by the same entity/person, probably in an > automated fashion, don't have family set, and are using the same > datacenter. Clients don't choose relays in the same /16 in the same circuit. So I don't think this is a danger to users. We would like to write a polite email saying: "thanks for helping Tor, please add a family to your config". But since they haven't provided contact details, we can't do that. T -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

3 3

companies and organizations running relays
by Alison Macrina 08 Dec '17

08 Dec '17

Hi all, Phoul and I are working on a blog post/guide to encourage more relay operators. The post will include technical and legal information for relay operators, but also things that are in more of a "social" category, like information for starting a relay operators group on a college campus. In that section, we want to highlight a few of the companies or non-profit organizations that run relays, but we're realizing that we don't actually have an up to date list. I'm wondering if folks on this list can help me by confirming the organizations that they know of running relays. Thanks! And if you're interested in contributing to the relay operators draft we have so far, please ping me off list. Something this comprehensive can always use an extra pair of eyes. Thanks, Alison -- Alison Macrina Community Team Lead The Tor Project

12 11

So long and thanks for all the abuse complaints
by James 07 Dec '17

07 Dec '17

As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node. Prior to today I'd receive on average 1-2 complaints a month (I had a fairly strict exit policy). It saddens me that I have to shut it down, especially as it's one of very few running on BSD, but I just don't have the time to constantly respond to abuse complaints to ensure I don't get shut down by the upstream provider. If there are any devs on this list, some kind of mechanism to detect and block abuse traffic on exit would go a long way to ensuring legitimate use of the network, that is after all why people run exit nodes. It's at least why I did. Thank you to everyone else running an exit node. I hope you're able to keep yours going for a lot longer than I. James

13 23

Too many connections warning
by Logforme 07 Dec '17

07 Dec '17

I run the non-exit relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34). Today I saw a new warning in my tor log file: Dec 07 09:48:12.000 [warn] Failing because we have 32735 connections already. Please read doc/TUNING for guidance. The relay runs on an old Debian Wheezy machine. Me being a Linux noob I tried to read the doc/TUNING document (https://gitweb.torproject.org/tor.git/tree/doc/TUNING) but the only information I deemed suitable for me was "Use ulimit -n", which I ran and it reported "1024". I guess that's not of interest for this warning. Over the years I have added some stuff to my sysctl.conf file that I have picked up. Don't remember from where: # Tor net.core.rmem_max = 33554432 net.core.wmem_max = 33554432 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.tcp_wmem = 4096 65536 33554432 net.core.rmem_default = 524287 net.core.wmem_default = 524287 net.core.optmem_max = 524287 net.core.netdev_max_backlog = 300000 net.ipv4.tcp_mem = 33554432 33554432 33554432 net.ipv4.tcp_max_orphans = 300000 net.ipv4.tcp_max_syn_backlog = 300000 net.ipv4.tcp_fin_timeout = 4 vm.min_free_kbytes = 65536 net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.ip_local_port_range = 1025 65530 net.core.somaxconn = 30720 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_challenge_ack_limit = 999999999 None of the values seem to match the 32735 mentioned in the warning so I'm at a loss for what I am supposed to change. Anyone knowledgeable of these things that can give me some pointers?

4 3

Re: [tor-relays] So long and thanks for all the abuse complaints
by tor＠t-3.net 06 Dec '17

06 Dec '17

Abuse complaints are how this thing goes. With your limited exit policy, you would hardly see any complaints (relatively speaking), and what you do see would be mostly like SQL hack complaints and such. It's usually not going to be cases where someone got all the way into someone's machine, it's going to be mainly complaints about attempts. I feel like a short notification should be all you need and you're done with responses to stuff like that, such as: Hi <person>, That is the Tor exit router we host. https://www.torproject.org . Unfortunately, bad actors sometimes misuse Tor for things like this. If your attacker proves to be a serious problem, you may wish to block the entire Tor network from your device. A list of Tor exits can be seen here (and there is also an RBL somewhere): https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1 . Blocking one Tor exit such as mine won't really stop the person. Also, if I configure my node not to exit to you, the attacker won't necessarily even notice, as Tor will automatically route him through a different exit node. Regards, - < your sig > While it's true that the suggestion about blocking all of Tor isn't ideal for the internet at large, in particular as a response to stupid scans or web hack attempts that don't actually get in, there are cases where it may make sense for a server operator to do that on a single system, if only temporarily. The main points in this response are the explanations of what Tor is (via the provided link) and why it never makes sense from the attacked server's perspective for a single exit to stop exiting to it specifically. The affected server operator has the choice of ignoring the attempts, or fixing whatever vulnerability is there if one is being exploited, or blocking all of Tor. You as a single exit operator are not a part of that. There was only one time that I got a bullshit response back from someone as a result of what I'd sent, and he could be safely ignored, as he was just an idiot who thought that Tor was a bad thing. There was another guy who was ignoring my responses and emailing our abuse box repeatedly - he comes from a relatively rare mindspring.com address. If that is the one complaining about your exit, he's worthless. I configured our mail server to reject his abuse complaints outright (we own our own IP space, so, this is simpler for us than it would be for you). That mindspring.com guy also had the bright idea of emailing the networks he saw along his traceroute, thinking that we are a customer of those networks (we're not).

2 1

Re: [tor-relays] DoS attacks on multiple relays
by Aneesh Dogra 06 Dec '17

06 Dec '17

On Tue, Dec 5, 2017 at 5:04 PM, x9p <tor(a)x9p.org> wrote: > > Actually this also caught my attention on this 10 nodes from 188.214.30/24: > > https://atlas.torproject.org/#search/188.214.30 > > All from Romania, relays, ports 443/9030, good bandwidth 17-26MiB, uptime > almost identical, and no family member set. One is even named CIA :) > > Contact is set to none also. > > welcome! > > Looks scary. Interesting to see they all have high guard probabilities. :-? -- Regardless, I hope you're well and happy - Aneesh

2 1

Re: [tor-relays] DoS attacks on multiple relays
by Valter Jansons 05 Dec '17

05 Dec '17

A little relay node of a consensus around 220 checking in here. I am seeing pretty much the same as others are reporting - 11 on 188.214.30.0/24 and 10 on 217.12.223.0/24. The AS is called THC Projects SRL. They seem to provide VPS hosting among other things and ipinfo.io/AS51177 <https://ipinfo.io/AS51177#domains> reports that they host a lot of domains over there as well. Not sure how seriously one should take this, but it's interesting for sure regardless. -- 4096R/A83CE748 Valters Jansons On Tue, Dec 5, 2017 at 1:50 PM x9p <tor(a)x9p.org> wrote: > > my second and third positions are similar: > > 9 217.12.223.0/24 (family and contact info set) > 8 178.16.208.0/24 (family and contact info set, too) > > > > Interesting to see. I have similar stats. 10 connections from > > 188.214.30.0/24, second up 8 connections from 178.16.208.0/24. Thanks! > > > > On Tue, Dec 5, 2017 at 4:27 PM, x9p <tor(a)x9p.org> wrote: > > > >> > >> first measure on a good day how many connection per /24 your exit/relay > >> have, excluding these with 1 2 or just 3 connections: > >> > >> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk > >> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | > >> sort > >> | egrep -v ' 1 | 2 | 3 ' > >> > >> with this information in hand, double the max of it (mine was 10 > >> connections from 188.214.30.0/24): > >> > >> 10 188.214.30 > >> > >> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20 > >> --connlimit-mask 24 -j REJECT --reject-with tcp-reset > >> > >> cheers. > >> > >> x9p > >> > >> >> connlimit per /24. it does more good than evil. > >> > > >> > Any guidance on the specifics? Like how many concurrent connections to > >> > allow per /24? Not sure what's expected from legitimate user traffic > >> > through the relay... don't want to make things worse. > >> > _______________________________________________ > >> > tor-relays mailing list > >> > tor-relays(a)lists.torproject.org > >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > >> > >> > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > > > > > > > -- > > Regardless, I hope you're well and happy - > > Aneesh > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 1

Re: [tor-relays] DoS attacks on multiple relays
by Aneesh Dogra 05 Dec '17

05 Dec '17

Interesting to see. I have similar stats. 10 connections from 188.214.30.0/24, second up 8 connections from 178.16.208.0/24. Thanks! On Tue, Dec 5, 2017 at 4:27 PM, x9p <tor(a)x9p.org> wrote: > > first measure on a good day how many connection per /24 your exit/relay > have, excluding these with 1 2 or just 3 connections: > > # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk > -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort > | egrep -v ' 1 | 2 | 3 ' > > with this information in hand, double the max of it (mine was 10 > connections from 188.214.30.0/24): > > 10 188.214.30 > > iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20 > --connlimit-mask 24 -j REJECT --reject-with tcp-reset > > cheers. > > x9p > > >> connlimit per /24. it does more good than evil. > > > > Any guidance on the specifics? Like how many concurrent connections to > > allow per /24? Not sure what's expected from legitimate user traffic > > through the relay... don't want to make things worse. > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Regardless, I hope you're well and happy - Aneesh

2 2

Re: [tor-relays] DoS attacks on multiple relays
by null 05 Dec '17

05 Dec '17

> connlimit per /24. it does more good than evil. Any guidance on the specifics? Like how many concurrent connections to allow per /24? Not sure what's expected from legitimate user traffic through the relay... don't want to make things worse.

2 2