- tor-relays - lists.torproject.org

Re: [tor-relays] Become a Fallback Directory Mirror
by Dennis Emory Hannon 22 Dec '17

22 Dec '17

Tim, 5E56738E7F97AA81DEEF59AF28494293DFBFCCDF Thanks, Hostmaster@: Mr. Dennis Emory Hannon BackplaneDNS.org / Backplane LLC Phone: +1 (716) 348-0064 Linkedin: http://linkedin.com/in/dennis-hannon-52236019/

1 0

IPv6 Issue with Relay
by Conrad Rockenhaus 22 Dec '17

22 Dec '17

Hello, One of the relays that I brought online yesterday, ConradsAWSExit (Hash 1B47E33F9D422CC97BD2DDA1F082BFF2FC58E79A) is showing up on Atlas that the IPv6 OR is unreachable. The other relay is working just fine with IPv6. I’ve confirmed that the following entries are in torrc: ORPort 9001 ORPort [2600:1f14:ede:d601:e107:1a4b:ba3:803]:9001 IPv6Exit 1 Just to confirm, here’s the output from ifconfig, that is the IP: inet6 2600:1f14:ede:d601:e107:1a4b:ba3:803 prefixlen 64 scopeid 0x0<global> I have confirmed that all of the applicable Security Group rules are configured correctly: Custom TCP Rule TCP 9001 0.0.0.0/0 ORPort Custom TCP Rule TCP 9001 ::/0 ORPort Custom TCP Rule TCP 9030 0.0.0.0/0 DIRPort Custom TCP Rule TCP 9030 ::/0 DIRPort Plus, I have confirmed with a telnet -6 to port 9001 from both my house and my servers at OVH in Canada that I’m able to connect to port 9001 via the IPv6 address on this node. So, my question is…what could I be missing here that is causing atlas to say that IPv6 is unreachable? I’ve been looking into this through the day and would like to kind of close it out, got a bunch of emails to catch up on hehe :D, so any input would be appreciated. Thanks, Conrad

3 5

Ongoing DDoS on the Network - Status
by David Goulet 21 Dec '17

21 Dec '17

Hi everyone! I'm David and I'm part of the core development team in Tor. A few minutes ago I just sent this to the tor-project@ mailing list about the DDoS the network is currently under: https://lists.torproject.org/pipermail/tor-project/2017-December/001604.html There is not much more to say about this right now but I wanted to thanks everyone here for running a relay, this situation is not pleasant for anyone especially for relay operators for which you need to deal with this attack (and extra bonus point during the holidays for some...). Second, everyone who provided information, took the time to dig in this problem and sent their findings on this list was a HUGE help to us so again, thank you very much for this. We will update everyone as soon as possible on the status of the tor releases that hopefully will contain fixes that should help mitigate this DDoS. Cheers! David -- aFJe0kbRB1zZXgwFQIvBG0Skn3xAsDGxVQsAiguKjY8=

2 3

restarting tor service after AccountingMax has been reached
by Fabian A. Santiago 21 Dec '17

21 Dec '17

I'm noticing that if i attempt to restart tor AFTER AccountingMax has been reached (meaning it's currently hibernating), tor itself fails to start. if i increase AccountingMax in torrc, then it restarts just fine. normal? -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

3 8

Guard node suddenly sending twice what it receives
by Logforme 20 Dec '17

20 Dec '17

My little guard node (855BC2DABE24C861CD887DB9B2E950424B49FC34) have suddenly started to behave strangely. iftop (my "bandwidth monitor"), shows twice as much sent traffic as received traffic. The traffic seems to be distributed to a lot of ip addresses. No ip address stands out as receiving very much traffic: https://imgur.com/a/dAUzc Given the last few days of DDoS attacks (my node is still targeted by those) I naturally assume this is another attack. First it is lots of connections (mitigated with connection limits) Then it is massive amounts of memory per circuit (MaxMemInQueues fixes that) And now this. Could this be a third attack vector or am I seeing something "normal" (though I often check my bandwidth and I've never seen this before). My node recently got the HSDir flag after the last crash. Could the network be starved for HSDir machines and this is what I'm seeing? Being a linux noob I don't know how to figure out exactly what kind of traffic this is. Suggestions gratefully accepted.

2 3

botnet? abusing/attacking guard nodes
by starlight.2017q4＠binnacle.cx 20 Dec '17

20 Dec '17

Guard relay here appears to have come under steadily increasing abuse over the last several months. Belive the two previous threads relate to the same issue: Failing because we have 4063 connections already // Number of file descriptors DoS attacks are real Several times a day a large burst of circuit extends are attempted resulting in log flooding with [Warning] assign_to_cpuworker failed. Ignoring. where the above indicates a circuit-launch failed due to a full circuit request queue. Presently the guard runs on an old system lacking AES-NI, and the operation is expansive rather than trivial. Originally thought the events were very brief, but after reducing MaxClientCircuitsPending from a larger value to the default it appears they last between five and ten minutes. The abuser also contrives to create huge circuit queues, which resulted in an OOM kill of the daemon a couple of days back. Lowered MaxMemInQueues to 1G, set vm.overcommit_memory=2 with vm.overcommit_ratio=X (X such that /proc/meminfo:CommitLimit is comfortably less than physical memory) and now instead of a dameon take-out see [Warning] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Removed 1060505952 bytes by killing 1 circuits; 19k circuits remain alive. Also killed 0 non- linked directory connections. As you can see the one circuit was consuming all of MaxMemInQueues. And today this showed up in the middle of a "assign_to_cpuworker failed" blast: [Warning] Failing because we have Y connections already. . . Digging into the source, the message indicates ENOMEM/ENOBUFS was returned from an attempt to create a socket. Socket max on the system is much higher than Y so kernel memory exhaustion is the cause. Implication is a burst of client connections associated with the events, but haven't verified that. An old server was dusted off after a hardware fail and the machine is a bit underpowered, but certainly up to the load that corresponds with the connection speed and assigned consensus weight. AFAICT normal Tor clients experience acceptable performance. The less-than-blazing current hardware illuminates the abuse/attack incidents and inspired the writing of this post.

11 16

Image asset in Tor readme html
by Fabian A. Santiago 20 Dec '17

20 Dec '17

Can the Tor service not serve up a locally referenced PNG file in the readme HTML file used for dirportfrontpage? Mine keeps showing as a broken link. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

3 3

[OrNetRadar] Contact: "dalesolutions2016 at yahoo dot com" (6)
by nusenu 19 Dec '17

19 Dec '17

Hello dalesolutions2016, thank you for adding tor relays to the network! To ensure tor users do not use your relays in multiple positions in a tor circuit (which is not safe), please set the "MyFamily" value in your torrc files. You can find out more about that configuration here: https://www.torproject.org/docs/tor-manual.html.en#MyFamily kind regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_ ornetradar(a)riseup.net: > 2017-12-18 > > | Up | Ext | JoinTime | IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamMembers | > |------+-------+------------+----------------+---------------------------------+------+-------+--------+-------+-----------+---------------+---------------| > | 1 | 1 | 10:01:27 | 93.188.164.86 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | Quahog | 1 | > | 0 | 0 | 10:54:31 | 93.188.161.36 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | 1stAmmendment | 1 | > | 1 | 0 | 12:14:36 | 93.188.161.36 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | 1stAmmendment | 1 | > | 1 | 0 | 12:15:57 | 93.188.161.109 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | MisterPink | 1 | > | 1 | 0 | 12:18:32 | 153.92.209.187 | Hostinger International Limited | gb | 9001 | 0 | Linux | 0.2.5.16 | NCC1701D | 1 | > | 1 | 0 | 12:20:15 | 156.67.220.154 | Hostinger International Limited | cy | 9001 | 0 | Linux | 0.2.5.16 | Montauk | 1 | > > https://nusenu.github.io/OrNetRadar/2017/12/18/a3 > > > > --- > To unsubscribe: <mailto:ornetradar-unsubscribe@lists.riseup.net> > List help: <https://riseup.net/lists> >

1 0

DoS attacks are real
by tordoswitchhunter＠airmail.cc 19 Dec '17

19 Dec '17

This message might be a bit controversial as I am disclosing bunch of client IPs, but you should check incoming ORPort connections on your relay, compare those IPs with usual clients and judge for yourself. I do not believe those are real Tor clients. Those IPs have been collected today from my guard node. Most of them are from LeaseWeb and OVH. :torrelayfilter - [0:0] -A INPUT -p tcp -m tcp --dport 9001 -m connlimit --connlimit-above 4 --connlimit-mask 32 --connlimit-saddr -j torrelayfilter -A torrelayfilter -s 198.7.59.194/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 199.115.112.79/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 207.244.70.120/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.178/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.191/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 207.244.110.200/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.177/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.179/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 85.10.193.240/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 162.210.192.70/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.188/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.180/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.185/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.187/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.190/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.104/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.106/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 149.202.66.206/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.186/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.184/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.192/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.193/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.103/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.107/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.189/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 51.15.161.135/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.6/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.83.3.154/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.72.231/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.237/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 51.15.162.120/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.77.152/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.7/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 95.211.95.10/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 95.211.95.18/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.236/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 95.211.95.14/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.72.66/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.77.151/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.8/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.87/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.106.246/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.90/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.235/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.89/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.5/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.104.231/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.106.245/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.10/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.88/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.9/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.234/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.105.240/32 -p tcp -j REJECT --reject-with tcp-reset

2 1

git branch to run from?
by Andreas Krey 19 Dec '17

19 Dec '17

Hi everybody, what is the proper git branch to build and run a relay from? So far I was on release-0.2.9 and just switched to release-0.3.2, but it seems that on either what I pick up there isn't actually a recommended version. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds(a)*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800

2 1