- tor-relays - lists.torproject.org

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

How long to delist from atlas?
by Fabian A. Santiago 18 Dec '17

18 Dec '17

Hello, I stood up a second Tor relay on an isp who's tos I didn't read carefully and they booted me. That's fine, my mistake. I had a vps and they only allow Tor on dedicated hosts. So I stood it up again on another known good vps provider and gave it the same Nick as the prior attempt. Now both are listed in atlas, same Nick, but one being offline. Is this ok and how long until the offline one is removed from the atlas listing? Thanks. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

2 2

#34C3 Tor Assembly
by Artikel 5 e.V. 18 Dec '17

18 Dec '17

Hello, when I looked around in the wiki for this years Chaos Communication Congress in Leipzig (Germany) I found that there is not much happening around Tor. So I took the liberty to register a small assembly [1] for Tor involved people to meet, discuss, hack or just sit and relax. This assembly will be in the Hall for "Rights & Freedoms" [2], I am not yet sure where this Hall is, but you'll find it. ;-) If all works fine I should have a DECT phone during the congress (6677), you can also reach my on various channels, one being Twitter [4], I am on the board of Artikel 5 e.V. [3] a non profit running some small relays (and exits) and looking to run more exits. (Looking for hosters preferably in Germany / EU ;-) The idea was more or less "there is no Tor assembly, but I would like to have one", the solution was to register one. I will take care of the basic stuff that has to be organized, would be very happy to get support from anyone and also looking forward to any ideas and questions. This assembly is open to anyone who is interested in Tor or actively supporting it, it is not meant to be a "Artikel 5 e.V." assembly, I just used the organization to register the assembly [5]. Things that we need: - Some Tor related decoration, so if you have anything that we can use there just bring it along and set it up in our space. - If anyone wants to hand out Tor related information/sticker/flyer please feel free to do so, but check what is accepted at the congress. I hope to see some of you guys at the #34C3 in Leipzig. Regards utzer [1] https://events.ccc.de/congress/2017/wiki/index.php/Static:Assemblies [2] https://events.ccc.de/congress/2017/wiki/index.php/Cluster:Rights_%26_Freed… [3] https://www.artikel5ev.de/ [4] https://twitter.com/utzer (holds a bit more information) [5] https://events.ccc.de/congress/2017/wiki/index.php/Assembly:Tor

8 11

Failing: 4063 Connection error
by Kurt Besig 17 Dec '17

17 Dec '17

Where can I set the connection limit higher or is this a result of max bandwidth allowed? This relay was up for over a year with no issues, however since updating the Tor version it's been problematic at best. Thanks. Linux version 2.6.32-042stab125.5 (root(a)kbuild-rh6-x64.eng.sw.ru) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Tue Oct 17 12:48:22 MSK 2017 Tor version 0.3.1.9 :Failing because we have 4063 connections already. Please read doc/TUNING for guidance. [over 16000001 similar message(s) suppressed in last 21600 seconds]

2 1

Failing because we have 4063 connections already // Number of file descriptors
by Ralph Seichter 15 Dec '17

15 Dec '17

Since a couple of days ago, one of my relay nodes keeps logging messages like this: Tor[3534]: Failing because we have 4063 connections already. Please read doc/TUNING for guidance. [over 16000001 similar message(s) suppressed in last 21600 seconds] I found https://trac.torproject.org/projects/tor/ticket/16929 and an older mailing list thread (and doc/TUNING) that suggest increasing the maximum number of open file descriptors. I now use # /etc/security/limits.conf * - nofile 65535 to raise 'nofile' from 1024 to 65535, which does not seem to make any difference (the logged error message does not change). My relay uses Gentoo Linux kernel version 4.14.5 and Tor 0.3.2.6 alpha. I also tried older versions of the kernel and Tor 0.3.1.9, in several combinations, without success. I also other relays running just fine with the default number of file descriptors (1024). As I mentioned, the problems started a few days ago, around the time I upgraded from Gentoo system profile default/linux/amd64/13.0 to default/linux/amd64/17.0, rebuilding many system packages in the process. Unfortunately I cannot tell what exactly changed. Since the profile upgrade was deliberate and I cannot roll back, I wonder if I can overcome Tor's problems via configuration options only? -Ralph

3 6

Is your IPv6 relay not Running?
by teor 15 Dec '17

15 Dec '17

Hi, Since October 2017, a majority of directory authorities check relay IPv6 ORPorts. If your relay is configured with an IPv6 ORPort: ORPort [IPv6]:Port and it is not reachable over IPv6, it will be excluded from the consensus. This can happen if the address is wrong, or the IPv6 routing is wrong. If your relay isn't in the consensus, it will log warnings. Or, you can check Relay Search at: https://atlas.torproject.org If your relay is not Running, you can check the votes for your relay here: https://consensus-health.torproject.org/consensus-health.html If all the authorities don't vote for your relay, it has a tor or IPv4 problem. If a few do vote Running, it probably has an IPv6 problem. (If you want to be sure, check which authorities support ReachableIPv6 in the consensus health Known Flags table.) If you have an IPv6 problem, check the address, and check the routing. Here's what I do to check IPv6 on my relays when I set them up: From the relay: ping6 ipv6.google.com From another IPv6 machine: ping6 ipv6.google.com ping6 (the relay's IPv6 address) telnet (the relay's IPv6 ORPort) We're working on having better support for IPv6 across Relay Search and consensus health. T

4 8