- tor-relays - lists.torproject.org

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