tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays