- tor-relays - lists.torproject.org

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

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

exit relay
by Evangelos Meintasis 15 Dec '17

15 Dec '17

Hello to all, I got this warning : [warn] Tor is running as an exit relay. If you did not want this behavior, please set the ExitRelay option to 0. But in /etc/tor/torrc file, I can not locate an y EXITRELAY option. Should I just type it without comments there with the 0 flag? Thank you! Vagelis. Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland.

5 4

someone is livestreaming a bad exit
by tor 15 Dec '17

15 Dec '17

https://www.twitch.tv/sp00k13z https://twitter.com/notdan/status/941116413070270465

4 3

Alleged Family Members / Stable flag "issues"
by Stijn Jonker 15 Dec '17

15 Dec '17

Hi all, For a little short of a year I'm running Relay SJC01 (328E54981C6DDD7D89B89E418724A4A7881E3192), there was some unnoticed outage of the relay which caused a couple days of downtime. This was at the end of Nov, oddly enough I don't seem to get back the "Stable" flag. In searches I found some conflicting answers, it's either 7 days of uptime, a median of seven days of the entire uptime and/or the advice to check https://consensus-health.torproject.org/consensus-health-2017-12-14-18-00.h… What I don't understand is the differences in the output of the concensus: - The concensus nodes that don't have IPv6 (assumed from "KnownFlags" from top of page. (longclaw, dizum, moria1 and faravahar) list my relay with Stable/Guard. - The concensus nodes that do assign the "ReachableIPv6" flag, don't have my relay listed with those flags. To test the IPv6 function, I took an VM outside of my network and ran Tor with "UseBridges" only allowing via iptables IPv6 out to my relay as entry node, and it the relay is/was functioning on IPv6. Now happy to wait an other week/month etc for the stable flag. It doesn't add value to me, but I'm more curious why the flag doesn't return. The same with the Alleged Family Member, I had an relay / exit with a reduced exit policy ($F8333E028E952840C1B93DAEE20880F75B90A68A) but that has been gone for quite some weeks (months) as it was taken down by the hoster. Now all info I can find is that when the relay doesn't announce this anymore one can expect it to be gone after some days/weeks. But in this case it's not going away. If there are actions on my side happy to take them, but I can't find the "right thing" to do here. Thanks! -- Yours Sincerely / Met Vriendelijke groet, Stijn Jonker

3 5

Dir address none
by Fabian A. Santiago 14 Dec '17

14 Dec '17

I'm checking my Tor relay on atlas and the dir address is listed as 'none'. I have dirport set in my torrc file to just a number with no other flags. I can hit the HTML page in my browser. I did just stand up my relay less than 24 hours ago. Anything I'm missing? Thanks. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

2 5

Removed x bytes by killing y circuits
by Felix 14 Dec '17

14 Dec '17

Hi everybody Can someone explain the following tor log entry: Removed 528 bytes by killing 385780 circuits; 0 circuits remain alive. (it's the nicest one, see below) Memory stays at 3 - 4 GB before and after. Only tor restart gets rid of the memory. We love to remove 528 bytes. Tor log becomes 370 MB within 18 hours. ---- Tor 0.3.2.6-alpha (git-87012d076ef58bb9) MaxMemInQueues 2 GB ---- We receive some of these: Dec 14 00:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 3:00 hours, with 508694 circuits open. Dec 14 00:30:08.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:09.000 [notice] Removed 13344 bytes by killing 594572 circuits; 0 circuits remain alive. Also killed 3 non-linked directory connections. Dec 14 01:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 4:00 hours, with 67530 circuits open. Dec 14 02:07:16.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 02:07:17.000 [notice] Removed 206448 bytes by killing 484352 circuits; 0 circuits remain alive. Also killed 2 non-linked directory connections. Dec 14 03:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 6:00 hours, with 379182 circuits open. Dec 14 03:13:17.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 03:13:17.000 [notice] Removed 528 bytes by killing 385780 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 05:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 8:00 hours, with 303958 circuits open. Dec 14 05:15:17.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 05:15:18.000 [notice] Removed 528 bytes by killing 317854 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. and lots of: Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 221 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 297 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 395 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 468 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 509 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. -- Thanks and cheers, Felix

2 2

Re: [tor-relays] Issues with faravahar?
by Sina Rabbani 12 Dec '17

12 Dec '17

Dear Tor Relay Operators, Faravahar had some hardware issues last night, while I was on an airplane without internet access. It took me a few hours to respond and I apologize for the delay. Please note that redundancy is built into the network, and I am committed to operating this system with very high availability. A maintenance window to replace the hardware will be announced soon, this system has been running since 2012 and it's time to upgrade. All the best, Sina "Be the change that you wish to see in the world." - Mahatma Gandhi ----- On Dec 12, 2017, at 5:38 PM, teor teor2345(a)gmail.com wrote: > On 13 Dec 2017, at 08:17, tor <tor(a)anondroid.com> wrote: > >>> this time though I ran Wireshark while started tor, and it appears tor is >>> transmitting encrypted info over port 80. >> >>> Surely tor shouldn't be transmitting unencrypted messages? >> >> I'm not an expert on the protocol but you may just be looking at responses from >> the proxy in front of Faravahar? > > Tor's directory documents are public, and signed, and they only contain > public keys. So it's entirely safe to transmit them unencrypted. > > T > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Issues with faravahar?
by r1610091651 12 Dec '17

12 Dec '17

Hi I'm seeing regular issues with faravahar in logs lately. Is somebody working on this? Logs: Dec 12 10:32:56.000 [warn] HTTP status 502 ("Bad Gateway") was unexpected while uploading descriptor to server '154.35.175.225:80'. Possibly the server is misconfigured? Dec 12 10:33:56.000 [warn] Received http status code 502 ("Bad Gateway") from server '154.35.175.225:80' while fetching "/tor/server/d/706E3C29265BD073DF77DC457A3CD8B1BC16C6E6+E223A1B036E3F7315DCADE32F6A4428F15148987.z". I'll try again soon. Thanks

8 8

DoS attacks on multiple relays
by null 12 Dec '17

12 Dec '17

Hi, We're experiencing what looks like a DoS attack on multiple relays in our family: https://atlas.torproject.org/#search/family:CBEAE10CBBB86C51059246B2EF92EB2… The relays are currently running Tor 0.3.1.9 on Linux kernel 4.4.0 (although when the problem started the relays were running Tor 0.3.1.8). The attack knocked 3 of 6 relays offline overnight. By the time we looked at logs, the Tor service had stopped and this was the last line in the log: "Tor[xyz]: Failing because we have 16351 connections already. Please read doc/TUNING for guidance." The attack is still ongoing. When it's happening, the number of connections rises very rapidly, until the attack succeeds in stopping the service. $ ss -s Total: 15855 (kernel 0) TCP: 24520 (estab 23969, closed 305, orphaned 31, synrecv 0, timewait 261/0), ports 0 Transport Total IP IPv6 * 0 - - RAW 0 0 0 UDP 8 4 4 TCP 24215 24213 2 INET 24223 24217 6 FRAG 0 0 0 ... and only a few seconds later: $ ss -s Total: 12120 (kernel 0) TCP: 27389 (estab 20026, closed 1906, orphaned 45, synrecv 0, timewait 1587/0), ports 0 Transport Total IP IPv6 * 0 - - RAW 0 0 0 UDP 8 4 4 TCP 25483 25481 2 INET 25491 25485 6 FRAG 0 0 0 That's obviously much larger than the normal number of connections, more than we've ever seen, and seems like more connections than would be needed for a relay. We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor: elif [ "$system_max" -gt "40000" ] ; then MAX_FILEDESCRIPTORS=16384 Surely that is high enough for normal service? We haven't started looking into where the traffic is coming from or other characteristics. We are wondering if: 1) this is a known attack, 2) if other operators are experiencing it, 3) if there are any ideas for mitigating it, and 4) if any additional information would be helpful. Thanks.

7 11

Action relays on 188.214.30.0/24 subnet
by x9p 12 Dec '17

12 Dec '17

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. cheers. x9p

2 3

UbuntuCore stats update
by Chad MILLER 11 Dec '17

11 Dec '17

Hi all. I generate* the packages that make up those UbuntuCore relays and bridges you hear about some time in here. I intended it to be a low-friction way normal joes can help Tor. There have been a good number of volunteers. The automatic-update system of Snap means the security update of a few days ago gives some population info through download stats. About 2200+ machines updated to last week's release. Almost all are amd64, though a few percent are i386 or armhf. I don't know of any arm64 yet. They're mostly desktops and servers. I see several new downloads every day. Judging from the new Atlas, about 800 are have checked in to try to join the consensus, and a little more than 100 are active at any time. Some working details: The package has a kill-switch so that it no longer starts after a few months of staleness (if I'm ever hit by a bus). At first launch, Tor creates a key and the last two bits of the key determines the role of the instance, with a 1/4 chance of becoming a obfs4 bridge. The default bandwidth limit is a modest 4 megabits per second. Also by default, it tries to punch holes in NAT to make itself available for incoming connections, but I don't have a lot of confidence that is often successful. I remain on this list and am always happy to answer questions or suggestions. * http://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/files -- Chad Miller chad.org gpg:a806deac30420066

4 5

Weird issue caused downtime of my relay
by Aneesh Dogra 11 Dec '17

11 Dec '17

Hello Everyone, I run a tor exit relay named "rippedlion". I was out for vacation past few days and saw I had a 2 day downtime. I had a look at the logs and apparently /var/lib/tor got detected to be owned as <unknown>? How do I prevent this in future? Snippet from notices.log: Dec 08 06:54:57.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending) Dec 08 06:56:25.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending) Dec 08 07:00:21.000 [warn] /var/lib/tor is not owned by this user (root, 0) but by <unknown> (112). Perhaps you are running Tor as the wrong user? Dec 08 07:00:21.000 [err] Can't create/check datadirectory /var/lib/tor Dec 08 07:00:21.000 [err] Unable to update Ed25519 keys! Exiting. PS: I am now running tor; as a low privledged user that only has access to /var/lib/tor and /var/log/tor. Thanks! -- Regardless, I hope you're well and happy - Aneesh

2 2

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

10 Dec '17

@ x9p: > # 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 Thank you! This was extremely helpful. In our case we found a handful of IPs that had *thousands* of concurrent connections on several of our relays. The offending IPs were not in the consensus. After restarting the Tor service, these suspect connections come back rapidly, again across several of our relays. Since our relays are all in the same declared family, it is very difficult to see how this traffic is legitimate. If it's valid Tor clients, they are behaving very strangely, and in either case we need to limit their impact. As such we've implemented connlimits by /24 as suggested (with a much higher limit to err on the side of not rejecting valid traffic). We can already see that this has improved our situation. @ Scott Bennett: > What you are seeing is most likely the same phenomenon brought up on > this list repeatedly over at least the last decade or so. That phenomenon > is providing HSDir service, or perhaps a rendez-vous point, for a popular > hidden service. > If you don't like it, you can set > > HidServDirectoryV2 0 Thanks for your reply. The data suggests this was not the case (this time). Some of these relays have been up almost a year with the same configuration, often with the HSDir flag. The recent issues just started occurring, and happened across several relays during the same timeframe. Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule it out. However it appears that option is deprecated (on 0.3.1.9). Enabling it causes this in the log: [WARN] Skipping obsolete configuration option 'HidServDirectoryV2' It's also no longer listed in the Tor manual (https://www.torproject.org/docs/tor-manual.html.en) It looks like we might be able to achieve the same effect with something like this instead: MinUptimeHidServDirectoryV2 52 weeks Anyone have any info on why HidServDirectoryV2 is consider obsolete? Is using MinUptimeHidServDirectoryV2 instead going to achieve the same effect? >> We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks >> like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor: >> >> elif [ "$system_max" -gt "40000" ] ; then >> MAX_FILEDESCRIPTORS=16384 >> >> Surely that is high enough for normal service? > > If by normal you mean "low traffic", then yes, it's probably enough. > However, that's really not very high in a general sense. Why does the default /etc/init.d/tor (from the Debian/Ubuntu pkg) cap MAX_FILEDESCRIPTORS at 16384 then? We have it set to 64000 otherwise. Obviously we could comment out these lines, but it seems odd the default config tries to cap it at 16384 if that's too low for a high traffic relay. Thanks everyone for your replies!

5 15

ISP is aking me to send a selfie holding my identity card
by Tanous 10 Dec '17

10 Dec '17

Hi, Im running an exit relay for 116 days. Today i received an email from my ISP saying that my account has been locked for security reasons. They asked me to send a copy of my identity card and a selfie holding it. I found that very odd and i feel uncomfortable sending that data to them. Should i give up to running my exit relay and find another ISP? By the way, i had received an abuse complaint a day before, due to Brute force attempts. Best Regards, Tanous

11 26

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

08 Dec '17

On 9 Dec 2017, at 13:24, x9p <tor(a)x9p.org> wrote: >> 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. > > Sorry, I meant EntryNodes > >> 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".) > > Would it be a better approach than firewall blocking, setting > "ExcludeNodes + StrictNodes" with the offending/suspicious fingerprints? No, this is much worse: it blocks these nodes for guard, middle, intro, and rend points. That's even more detectable than blocking middle nodes after a bridge. If you must block, only block a few guards, and only short-term. This is a hard area to get right - reducing the threat of node subsets needs more research. T

1 0

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

08 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 07 Dec '17

07 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 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

ymkeo offline
by René Ladan 28 Nov '17

28 Nov '17

Hi, due to hardware problems my node ymkeo 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D will be offline for an undetermined amount of time. René

1 1

Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
by Dhalgren Tor 26 Nov '17

26 Nov '17

>Well, it's still going on, and is pretty much ruining Libero :( . Running CentOS 6, here. > >When it's happening it can look like this: > ># netstat -n | grep -c SYN >17696 I run a fast exit and can offer some advice: 1) mitigate bug #18580 (also #21394); is a DNS denial-of-service and could be the problem. either upgrade to 0.3.2.4+ or edit resolve.conf per https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#Tuningeventdn… also check out https://arthuredelstein.net/exits/ 2) if you continue to experience excessive outbound scanning SYNs, I've found that simply enabling connection tracking helps by implicitly limiting the rate a which connections can originate. If an iptables "-m state --state ESTABLISHED,RELATED -j ACCEPT" rule exists it will turn it on or you could modprobe the module if you don't want to configure incoming connection rules. some useful sysctl.conf changes, run sysctl -p after or reboot # Tor Exit tuning. net.ipv4.ip_local_port_range = 1025 65535 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_max_tw_buckets = 4194304 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 3 net.netfilter.nf_conntrack_tcp_timeout_established = 1000 net.netfilter.nf_conntrack_checksum = 0 you might see many messages: kernel: nf_conntrack: table full, dropping packet which indicates no connection table slots were available for an outbound connection and that rate limiting is effected state of connection tracking appears in /proc/net/nf_conntrack

4 5

Re: [tor-relays] Pretty sure our exit was being synflooded
by tor＠t-3.net 26 Nov '17

26 Nov '17

I spoke too soon, it seems - the exit is struggling again, with some time spent destroyed today. As I look at what it's doing, it's clear that someone is relaying SYN packets to random ports and also random destination addresses that aren't even alive. The destination hosts and ports continually vary - it never hits multiple destinations on 1 port, and it does not hit multiple ports on 1 host. I presume it is an attack that is intended to degrade this relay's service quality, or otherwise more broadly, degrade Tor. I'm going to reject a few more trojan listen ports, it might help but it isn't a real fix. My thought btw was for Tor to rate-limit syn scanning activity between the client and the first onion router, with the function taking place in that first-hop router, not at the exit.

2 1

Re: [tor-relays] Pretty sure our exit was being synflooded
by tor＠t-3.net 26 Nov '17

26 Nov '17

Thanks for the configuration suggestions. I intentionally set the conntrack limit high, maybe that was not the best thing. I think I'll be putting it back. Removing my extra IPTables code plus adding a reject for :8888 has made the exit behave properly again. I wonder if the best possible course of action for this sort of thing would be within Tor itself. I don't know that it was a single client connection into Tor that was causing all this trouble, but maybe it was. One would think that one client should not be allowed to do something so severe with the TCP that it can single-handedly ruin a fast exit. Maybe a code change that forces a rate-limit that significantly slows down the ability of a single client to roll port scans should be considered by the devs.

2 1

Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
by tor＠t-3.net 26 Nov '17

26 Nov '17

Well, it's still going on, and is pretty much ruining Libero :( . Running CentOS 6, here. Actually, I think from what I'm seeing that it may not exactly be a synflood targeting Libero. I think Libero may be being (ab)used to do massive portscanning or similar. Image should be visible below - it's normal statistics for the 18th through say, part of the 21st, messed up 22ed - 24th and on the 24th me trying different things in an attempt to mitigate (graph is from yesterday). Look at the SYN_SENT2 maximum. When it's happening it can look like this: # netstat -n | grep -c SYN 17696 # Also one tiny part of the netstat looked like this: tcp 0 1 64.113.32.29:33354 <external IP munged>:81 SYN_SENT tcp 0 1 64.113.32.29:39659 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:44247 <external IP munged>:87 SYN_SENT tcp 0 1 64.113.32.29:42038 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:42077 <external IP munged>:83 SYN_SENT tcp 0 1 64.113.32.29:36282 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:46023 <external IP munged>:8888 SYN_SENT Port 8888 is supposedly opened up for listen by a virus.

3 3

Detecting Network Attack [re: exit synflooded]
by grarpamp 26 Nov '17

26 Nov '17

On Fri, Nov 24, 2017 at 6:23 PM, <tor(a)t-3.net> wrote: > Was anyone else's exit being synflooded yesterday and today? There could be a combined monitoring array deployed among all nodes that might start to answer these questions. And further alert on all sorts of interesting network attacks launched at Tor. Software exploits... segmentation / modulation attacks... etc. This is perimeter security 101, and Tor currently has no fence, no guard dogs, not even a janitor you can ask the next day. That's beyond bad. And big oppurtunity for new research project.

2 2

Tor Metrics issue
by Arisbe 25 Nov '17

25 Nov '17

In the immediate past I monitored both my relays and my bridges through atlas. So, now with Tor Metrics, I don't see my bridges. Am I doing something wrong or are they not in the data base? Arisbe

4 5

Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
by tor＠t-3.net 25 Nov '17

25 Nov '17

I went and added a reject for exit to port 8888 and HUPed the process. Maybe this is the fix! :)

1 0