- tor-relays - lists.torproject.org

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

05 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 05 Dec '17

05 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

Save the date! Thursday, Dec 07 - Tor Meetup in NYC
by isabela＠riseup.net 04 Dec '17

04 Dec '17

Hello community! We are sending this 'save the date' note to let you know that on Thursday December 7th on the 20th floor of 150 Broadway in the LMHQ shared meeting space at 6:45 PM. There are a lot of folks from the community in NYC so we thought it would be cool to have some time share skills, learn new things, and be a place for new folks who want to get involve to come and meet folks. For this first one we will be talking about our community of relay operators. You can read more at this blog post: https://blog.torproject.org/explore-tor-new-york-city-new-meetup-starting-d… So if you are in the area, come and join us! cheers, Isabela

3 2

Please disregard 'excessive bounce' notice
by Damian Johnson 01 Dec '17

01 Dec '17

Hi all. Everyone with a gmail account not a notice that their subscription was suspended due to excessive bounces. You can ignore this notice, no action is needed on your part. I'm not entirely sure of the root cause but something similar happened a few years back with another list too. I've disabled automated bounce processing and re-enabled everyone's subscription. Cheers! -Damian

1 0

do the 800+ UbuntuCore relays constitute a Sybil attack?
by starlight.2017q4＠binnacle.cx 01 Dec '17

01 Dec '17

The population of these has been climbing for more than a week and no-one has commented, which seems odd. No contact provided. https://atlas.torproject.org/#search/UbuntuCore

4 4

Tor security releases coming tomorrow
by Nick Mathewson 30 Nov '17

30 Nov '17

I'm sending this message to announce that we will be releasing new stable and versions of Tor tomorrow, to fix 5 security bugs. I apologise for the short notice; we've had to move up our intended release date in order to try to match with release deadlines for downstream projects. We have classified 3 of these bugs as Medium and 2 as High, per draft security process at https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Securit… . The most serious bugs are a pair of denial-of-service issues, which we treat as high security because of the possibility of escalating them for traffic-analysis purposes. Note that only the following series are supported, and only they will receive updates: 0.2.5, 0.2.8, 0.2.9, 0.3.0, 0.3.1, and 0.3.2. 0.2.8 and 0.3.0 will become unsupported in January; 0.2.5 will become unsupported in May. best wishes, -- Nick

1 0

Screening DNS
by Dr Gerard Bulger 29 Nov '17

29 Nov '17

The DNS 9.9.9.9 https://www.theregister.co.uk/2017/11/20/quad9_secure_private_dns_resolver/ At least is not blocking my exit node IP, simply because it is TOR! Nice. So far. Gerry

6 7