- tor-relays - lists.torproject.org

Tor 0.3.0.x end-of-life date in one week (2018-02-01)
by nusenu 25 Jan '18

25 Jan '18

This is a quick reminder that in one week, Tor 0.3.0.x will reach its end of life date (2018-02-01). >300 relays are still running that major version. https://nusenu.github.io/OrNetStats/#major-versions list of affected relays: https://atlas.torproject.org/#search/version:0.3.0.%20running:true https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Consider enabling auto-updates to keep your relays safe https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#AutomaticSoftwa… -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

nyx no connections shown
by TorGate 23 Jan '18

23 Jan '18

Hi, i have 2 new relais running and have also installed nyx. When i go to the page 2 in nyx is there no connection. But my network show me over 4000 tor connections . What is the issue with nyx on my torservers ? TorGate torgate(at)linux-hus.dk

5 16

kelihos infection
by scar 22 Jan '18

22 Jan '18

Hello fellow relay operators, I have received word from my ISP that they detected malicious traffic from my account. I'm running the exit node "cave" with reduced exit policy, https://atlas.torproject.org/#details/3875c9c843d33762fa733bcaf128f26a10bc7… The information received from my ISP was: infection => 'kelihos', subtype => 'kelihos.e', port => '52935', asn => '209', family => 'kelihos', sourceSummary => 'Drone Report' Typically they will also provide an IP address related to the infection, which is usually a sinkhole. The solution is to block the IP in my exit policy. However no IP was provided in this report and there is not one available, since my ISP is just relaying information they receive from a 3rd party detection agency. Furthermore, the port mentioned, 52935, is not allowed in my exit policy, so I'm guessing that port is somewhere else... Any ideas about this "infection" and how we could prevent it from using our exit nodes? Thanks

2 1

Become a Fallback Directory Mirror
by teor 22 Jan '18

22 Jan '18

Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. If your relay is on the current list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. Q: What about the current relay DDoS? We don't think the DDoS will have much impact on the fallback list. If your relay is affected, please: * make sure it has enough available file descriptors, and * set MaxMemInQueues to the amount of RAM you have available per tor instance (or maybe a few hundred MB less). We're also working on some code changes. See [5] for more details. [1]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [2]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc [3]: https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist [4]: https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_… [5]: https://lists.torproject.org/pipermail/tor-relays/2017-December/013881.html -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

15 26

connlimit: better to use "DROP" or "REJECT --reject-with tcp-reset"?
by tor 22 Jan '18

22 Jan '18

For relay operators using iptables connlimit to mitigate DoS attacks (or increased load from new clients), is it better for the Tor network to use "DROP" rules, or should we use something like "REJECT --reject-with tcp-reset"?

4 11

hidden service performance
by Igor Mitrofanov 21 Jan '18

21 Jan '18

I'd like to call out the apparent hidden service performance slowdown: https://metrics.torproject.org/torperf.html?start=2017-04-23&end=2018-01-21… I hope the dev team is looking into it. Thanks, Igor

3 2

updateFallbackDirs.py issues
by Toralf Förster 21 Jan '18

21 Jan '18

I do wonder why $> scripts/maint/updateFallbackDirs.py check_existing tells $> WARNING::1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA not a candidate: changed address/port recently (2017-10-22 07:00:00) But 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA didn't changed it address/port since end of 2016. What I did is to establish a 2nd Tor relay at the same hardware at 2 different ports in automn last year: D11D11877769B9E617537B4B46BFB92B443DE33D (to verify if the combined bandwidth/weight of both would be equal to the one of the former single relay at the same IP). And I played a little bit with its configuration values. What comes in addition into my mind is that at every reboot I do run first "certbot" to check for a renewed LetsEncrypt certificate. And shortly (1 or 2 minutes) after it finished both Tor instances are started. -- Toralf PGP C4EACDDE 0076E94E

2 6

Onionoo bandwidth recording stopped?
by Ralph Wetzel 21 Jan '18

21 Jan '18

3 5

Question about downtime
by Conrad Rockenhaus 21 Jan '18

21 Jan '18

Hello, Note - to others that have sent me emails about a proposed project, I will respond, I’m sorry I just got caught up in a huge emergency project. Anyway, I had a quick question, on the relay side I run ConradsOVHRelay01 (Relay) and ConradsOVHRelay02 (Exit). They’re running on CentOS, so I have to manually install the latest version of tor to keep up with the security updates. I am considering migrating to Ubuntu or Debian to make the update process simpler. To avoid downtime, would it be better to spin up two more boxes and migrate or would bringing them down for maintenance be acceptable? I would like to avoid downtime personally, as they’re stable, fast relays. I’m just looking for thoughts and ideas. Thanks, Conrad

3 2

Increased cpu usage
by r1610091651 20 Jan '18

20 Jan '18

Hi AFter upgrade from 3.1.9 to 3.2.9, I've noticed that the cpu usage doubled for same throughput / conditions. Is anyone else seeing that too? Regards

6 5