- tor-relays - lists.torproject.org

Storing ed25519_master_id_secret_key[_encrypted] on a smartcard?
by telekobold 04 Mar '23

04 Mar '23

Dear fellow relay operators, currently, I'm operating a Tor relay (Middle/Guard) and a Tor Bridge. Offline keys [1],[2] are a good way to secure a Tor relay, but I'm wondering if there is a standard way or something like a hacking guide how to store your ed25519_master_id_secret_key[_encrypted] on a smartcard or hardware token like a Nitrokey or Yubikey? This would even be more secure than storing it on a "normal" USB device. Unfortunately I have not found much about this on the internet. Kind regards telekobold [1] https://support.torproject.org/relay-operators/offline-ed25519/ [2] https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/Offl…

1 1

RFC: does a private exit would work?
by Toralf Förster 04 Mar '23

04 Mar '23

tl;dr; restricted access + usage of an exit longer: An exit is sooner or later abused. A reduced exit policy does not prevent that. What about setup a tor exit relay with 'PublishServerDescriptor = 0' ? Having an access line like for bridges would restrict the access. An alternative could be a port knockig + iptables solution. Objections and comments are welcome. -- Toralf

5 5

Preferred range for ephemeral ports
by binarynoise 03 Mar '23

03 Mar '23

Hello everyone, I just set up a snowflake proxy on my pi at home. Unfortunately I can only forward 255 ports to my pi (at once, or is there a way to trick my Fritz!box into allowing more?). Which is the preferred range for -ephemeral-ports-range when it needs to be restricted to allow the most users to connect? Is 60000:60250 ok? Greetings binarynoise

2 1

removing tor versions from "recommended versions" before they reach EOL
by nusenu 01 Mar '23

01 Mar '23

Hi, the tor 0.4.5.x end of live versions are still on the recommended versions list: https://consensus-health.torproject.org/#recommendedversions > consensus client-versions 0.4.5.6, 0.4.5.7, 0.4.5.8, 0.4.5.9, 0.4.5.10, 0.4.5.11, 0.4.5.12, 0.4.5.14, 0.4.5.15, 0.4.5.16, 0.4.7.7, 0.4.7.8, 0.4.7.10, 0.4.7.11, 0.4.7.12, 0.4.7.13 > server-versions 0.4.5.6, 0.4.5.7, 0.4.5.8, 0.4.5.9, 0.4.5.10, 0.4.5.11, 0.4.5.12, 0.4.5.14, 0.4.5.15, 0.4.5.16, 0.4.7.7, 0.4.7.8, 0.4.7.10, 0.4.7.11, 0.4.7.12, 0.4.7.13 it would probably be better to stop recommending tor versions a month before they reach their eol date so relay operators get to see a log entry and have some time to react. kind regards, nusenu -- https://nusenu.github.io

2 1

relay configuration not allowing optimal performance
by Relayer 26 Feb '23

26 Feb '23

I'm running a tor relay on some older hardware that I didn't want to discard when I could still put it so good use. Some details of the box are: -- CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz -- RAM: 4GB -- ARCH: x86_64 -- HDD: 250GB -- OS: Ubuntu 22.04.1 I originally configured a single Tor instance IPv4 to run as a relay only (not as an exit, nor hosting a hidden service). I am also using the iptables rules from https://github.com/Enkidu-6/tor-ddos to minimize DDOS overhead (please advise if there are alternatives or additions to this). My original config seemed ok until I started seeing my CPU and RAM maxing out consistently so I throttled back with the following in my torrc: RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) MaxAdvertisedBandwidth 1 MB My RAM usage now is only about 50% or marginally less of my total available. Here's how the metrics look lately: https://metrics.torproject.org/rs.html#details/38939B45237BA84941C74836349C… As you can see, the throughput rated dropped in half (that's when the graph drops on 2023-02-09). However, the volume continued to decline. Additionally, I'm unclear why my Middle Probability and Consensus Weight have both dropped to near 0%. Are those, in fact, where I want them? I'm monitoring with nyx and see I get some traffic through with no apparent errors or warnings. I am NOT seeing the CPU spikes any longer but I don't think I'm giving the most with my hardware. Questions: 1.) Is my tor service now misconfigured and not utilizing my hardware as best it could? 2.) Should my Consensus Weight and/or Middle Probability be higher? 3.) Should I consider running two tor instances? Nyx log snippet: 07:59:32 [NOTICE] Heartbeat: DoS mitigation since startup: 7 circuits killed with too many cells, 591 circuits rejected, 2 marked addresses, 0 marked addresses for max queue, 0 same address concurrent │ connections rejected, 0 connections rejected, 0 single hop clients refused, 19166 INTRODUCE2 rejected. [1 duplicate hidden] │ 07:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 57982 v4 │ connections; initiated 116266 and received 356623 v5 connections. │ 07:59:32 [NOTICE] Circuit handshake stats since last time: 3/3 TAP, 44849/44849 NTor. [1 duplicate hidden] │ 07:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 194128391 (server descriptor fetch); 7140 (server descriptor upload); 17539422 (consensus network-status fetch); 1794 (authority cert │ fetch); 2111765 (microdescriptor fetch) │ 07:59:32 [NOTICE] Heartbeat: Tor's uptime is 10 days 23:58 hours, with 179 circuits open. I've sent 34.83 GB and received 35.63 GB. I've received 444762 connections on IPv4 and 0 on IPv6. I've made │ 254336 connections with IPv4 and 0 with IPv6. [1 duplicate hidden] │ 01:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 56651 v4 │ connections; initiated 114326 and received 347071 v5 connections. │ 01:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 189431170 (server descriptor fetch); 7140 (server descriptor upload); 17131743 (consensus network-status fetch); 1794 (authority cert │ fetch); 2068377 (microdescriptor fetch) Thanks. Relayer1974

2 1

Re: [tor-relays] Frantech (was Re: Confusing bridge signs)
by Jeff Teitel 26 Feb '23

26 Feb '23

On Fri, Feb 24, 2023 at 12:10 AM Marco wrote: > Yes, Frantech should actually be avoided. But in Miami there are few Tor > relays. A SLICE 512 for $2.00/m or $20.00/y is sufficient for a bridge. > https://buyvm.net/kvm-dedicated-server-slices/ Why should Frantech be avoided? Jeff Teitel

2 1

Questions about Tor consensus weight & swag
by shruub 19 Feb '23

19 Feb '23

Hello, so my relay regulary gets overloaded, for what I can only assume is an hardware issue, (which I can't upgrade rn) since I already applied the tor anti ddos scripts. It seems to be able to recover, however with a lower Consensus Weight. I also (stupidly) tried to have a cron restarting my tor daemon daily which also resulted in the latter. So I wonder, if there is any way to have a relay run more stable and I suppose with a somewhat higher consensus weight (I can only asssume making some further changes in advertising bandwidth etc. My second question(s) is/are concerning the tor swag (I hope that's allowed to ask here). Firstly, what is the actual Speed requirement? In the tor ecosystem, every unit is MBs, and only on the swag site its KBs. But if my calculations are correct, 500KBs = 500000Bs = 0.5MBs which doesn't really make sence, imo(but I probably misscalculated somewhere). Secondly, does running mean it's uptime (aka Last Restarted) or the Time it was first seen? Sorry for the wall of text for not much information, and thanks a lot in advance for your replies! Best, shruub

4 5

disable moderation on tor-relays again?
by nusenu 15 Feb '23

15 Feb '23

Hi, can we try to disable moderation on this list again and see how it goes? If it gets out of hand you can always move back to a moderated mode or a mode where the first email of a sender is moderated. kind regards, nusenu -- https://nusenu.github.io

4 4

Use OutboundBindAddress on multi-instance tor servers
by nusenu 13 Feb '23

13 Feb '23

Hi, to reduce the risk that your multi-instance tor relay setup triggers false-positive filter thresholds on other relays, I recommend you make use of the OutboundBindAddress (or OutboundBindAddressOR) option and set it to the same IP as in the ORPort line. This will ensure that the outbound source IP will be the same when connecting to relays. The man page is not clear what tor's default without that setting is but I guess that would leave it to the OS to pick the source IP and that could result in all your tor's using the same source IP. relayor users are covered by default, no further action required. https://github.com/nusenu/ansible-relayor/blob/2bc62d62f85b62c51a38d9caa893… kind regards, nusenu -- https://nusenu.github.io

4 5

publish current AuthDirMaxServersPerAddr limit?
by nusenu 13 Feb '23

13 Feb '23

Hi, would it be possible to publish the currently enforced value of AuthDirMaxServersPerAddr on some tpo website? Maybe consensus-health.tpo? kind regards, nusenu -- https://nusenu.github.io

3 2

HowTo use relayor's Prometheus Integration (relayor v23.1.0)
by nusenu 12 Feb '23

12 Feb '23

Hi, relayor v23.1.0 is released. It comes with: * a minor security fix that needs manual intervention * support for more than 2 relays per IP * a major simplification for users of the prometheus integration. * removal of the tor_dedicatedExitIP feature. relayor now implements conf.d support for prometheus. This includes a few backward incompatible changes. Full Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v23.1.0 With the release I also published this guide that should help users get started with relayor's prometheus integration: https://github.com/nusenu/ansible-relayor/discussions/239 kind regards, nusenu

1 0

Questions about 4 Relays per IP and the ddos mitigation scripts
by Chris Enkidu-6 08 Feb '23

08 Feb '23

Hello Everyone, Before I make changes to [my scripts](https://github.com/Enkidu-6/tor-ddos), I need to understand a few things and any help is much appreciated. - First, Does an Exit relay with zero Guard probability and zero middle relay probability need to initiate circuits with a Guard or middle relay and assuming it fails, would that affect my relay, relaying traffic to that Exit node as a part of my own circuit? To clarify the question, I have 2 Established connections to two Or Ports of an exit relay, the relay has no connections to me, Does that break anything? - I have a few Exit relays as permanent residents in my block list, not because I want them to be there but because, no matter how many times I remove them, day or night, they'll be back in seconds for making too many concurrent attempts. I'm assuming this is due to the fact that Exits are being used to attack other relays but I may be wrong which is why I need someone to clarify this for me and hence another reason for question one. - Each relay has Established connections to many other relays and if they're guard they will also have many connections to regular users and their Tor browsers until they have enough traffic to reach their MaxAdvertisedBandwidth. Obviously we don't Establish connections to all 6300 relays out there. So if we do not allow each IP more than two connections and they need 4, They'll have two from us and they'll move on to another relay and get the other two and get the job done and we will reach our Max Bandwidth anyway by accepting traffic from other relays. Diversity of relays as opposed to concentration of some relays. Am I correct in my assumption that this will have little to no effect on the health of the Tor network as a whole? Thanks for reading, I'm not going to make this longer than it is already.

5 8

tor relay shows offline @ tor relay search while running
by theyarewatching＠disroot.org 03 Feb '23

03 Feb '23

Good day, My relay shows offline on the Relay Search page but according to NYX the relay is always running. I am running two relays on on Proxmox through my home network. Please inform me of what info/logs you may need to help diagnose this. Thank you for your time and help. TAW

2 1

Ensure servers with >2 relays per IP do not get hit by rate limiting firewalls (by other relays)
by mail＠nothingtohide.nl 03 Feb '23

03 Feb '23

Hi Tor operators, Some of us took/will take advantage of the increase in allowed Tor relays per IPv4 address[1] to reduce costs for running Tor relays. This change will result in more relays sharing the same source IP address than before, which means other relays using rate limits on their ORPorts might need to make sure they do not unintentionally block relay to relay connectivity. Many relay operators deploy TCP SYN rate limiting packet filters theses days due to the ongoing DDoS issues. With the increase in Tor relays per IPv4 address, there might be more (new) connection coming from the same source IP. If you have strict TCP SYN rate limits per source IP, please ensure that this change does not result in blacklisting relay to relay traffic. You could for example whitelist relay IP addresses or have less strict rate limits for them. Thanks for reading, https://applied-privacy.net https://nothingtohide.nl [1] https://gitlab.torproject.org/tpo/core/tor/-/issues/40744

1 0

4 relays per IP address are allowed from now (Feb 2023) on
by Georg Koppen 02 Feb '23

02 Feb '23

Hello everyone! You might recall that Tor is restricting the possible amount of Tor relays per IP address to 2, mainly for Sybil prevention reasons.[1] Given that Tor on the relay side at least is not multithreaded yet (and will likely not be for the near and medium future) that's wasting a lot of useful resources as many servers can easily handle more than 2 relays. Additionally, IPv4 addresses are scarce/expensive. I have good news for you, though. Thanks to a push by our relay operator community we raised that limit to 4 with the help of the directory authorities (by having set `AuthDirMaxServersPerAddr 4` on a majority of them) and, depending on how that experiment goes, consider raising it even to 8. Thus from now one should be able to run 4 relays per IP address. We are looking very much forward to seeing a bunch of additional relays entering the network and making it stronger. :) For more details, information and discussion see: tor#40744.[2] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/109-no… [2] https://gitlab.torproject.org/tpo/core/tor/-/issues/40744

1 0

(Save the date) Tor Relay Operators Meetup - 2023-01-28 @ 19UTC
by gus 02 Feb '23

02 Feb '23

Dear relay operators, Save the date: our next Tor relay operator meetup will happen on January 28 at 19:00 UTC! We're drafting the agenda here: - pad: https://pad.riseup.net/p/tor-relay-op-meetup-j28-keep - onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… Feel free to add topics and/or questions. Room Link - https://tor.meet.coop/gus-og0-x74-dzn cheers, Gus -- The Tor Project Community Team Lead

2 2

Relays at universities campaign
by Eldalië 02 Feb '23

02 Feb '23

Hello everyone. At last Saturday's Tor Relay Operators Meetup, ongoing work on a "relays at universities" campaign was announced. I am interested in it as I may be able to help a little, so I'd like to receive any news, but I don't remember any message about it on tor-relays(a)lists.torproject.org list, and I see that tor-relays-universities(a)lists.torproject.org hasn't received any message at all since the only one from 2021. Is there a way to keep up with the campaign project already or it's being worked on by a "closed group"? Thanks, Eldalië -- Eldalië My private key is attached. Please, use it and provide me yours!

2 1

relayor v23.0.0 is released
by nusenu 28 Jan '23

28 Jan '23

Hi, relayor v23.0.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… This release comes with some great new prometheus integration features (some labels that tor does not provide out of the box). I'll follow up with a post that gives a general introduction on how to use relayor's prometheus integration soon. Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v23.0.0 Note: If you used relayor's prometheus support in previous relayor releases, make sure to set the tor_prometheus_scrape_file variable after upgrading to v23.0.0 and before running ansible-playbook with v23.0.0 for the first time. See the README for an example value. kind regards, nusenu -- https://nusenu.github.io

1 0

Tor Relay Operators Meetup Jan 28
by George 27 Jan '23

27 Jan '23

Tomorrow is the next Tor relay operator meetup will happen on January 28 at 19:00 UTC! We're drafting the agenda here: - pad: https://pad.riseup.net/p/tor-relay-op-meetup-j28-keep - onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… Feel free to add topics and/or questions. Room Link - https://tor.meet.coop/gus-og0-x74-dzn g

1 0

Proposal: increase max number of relays per IP
by mail＠nothingtohide.nl 23 Jan '23

23 Jan '23

Hello! Running a high bandwidth Tor server requires a lot of IPv4 addresses, while IPv4 addresses are becoming quite scarce and very expensive. For this reason we started the process to get the current limit of two relays per IPv4 address increased to reduce the cost of running high bandwidth Tor servers. You can find our proposal on Tor's Gitlab: https://gitlab.torproject.org/tpo/core/tor/-/issues/40744. If you would like to support this proposal, let us know and we add your domain/nick to the issue :). This topic will also be on the agenda of the Tor Relay Operator Meetup on 2023-01-28 19:00 UTC: https://lists.torproject.org/pipermail/tor-relays/2023-January/020973.html. See you there! - https://applied-privacy.net/ https://artikel10.org/ https://nothingtohide.nl/

1 0

bridge going down
by Anonforpeace 21 Jan '23

21 Jan '23

Hello: I have recently built a Tor Bridge (nickname is h4ck3rspace) and when it first went up, it was up to about two weeks and then it went down. So I brought it up again and ever since, it routinely goes down every 1 to 3 nights, between 8p and 10p EST. I've never seen this type of behavior before. Is there a way to know why it keeps going down so often, and subsequently how to prevent it? My area doesn't suffer from power outages and each time I restart Tor I wait to make sure it says that it is visible externally and that it will be published. Any help is greatly appreciated. Thank you Sent with [Proton Mail](https://proton.me/) secure email.

1 0

backports obfs4proxy unsigned
by tor 15 Jan '23

15 Jan '23

the backport of obfs4proxy seems to be unsigned I needed to use: deb [trusted=yes] http://deb.debian.org/debian bullseye-backports main

2 1

obfs4proxy ubuntu jammy arm64
by tor 14 Jan '23

14 Jan '23

Hello I'm running ubuntu, jammy, arm64. When I run: machine@user_1:~$ sudo apt-get install obfs4proxy Reading package lists... Done Building dependency tree... Done Reading state information... Done obfs4proxy is already the newest version (0.0.13-1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Where do I get version 14? -m On Fri, Jan 13, 2023 at 7:00 AM <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. obfs4proxy on arm64 (tor) > 2. Re: obfs4proxy on arm64 (meskio) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Jan 2023 18:11:40 -0500 > From: tor <tor(a)kevinandmatt.com> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] obfs4proxy on arm64 > Message-ID: > <CAE8TgqTFidzSHmS+u2h5OBfwaS2xaK_tqc3ddh6jcm4= > OdgRLA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi > Where do I find the updated version of obfs4proxy for arm64? > -m > > On Wed, Jan 11, 2023 at 7:00 AM <tor-relays-request(a)lists.torproject.org> > wrote: > > > Send tor-relays mailing list submissions to > > tor-relays(a)lists.torproject.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > or, via email, send a message with subject or body 'help' to > > tor-relays-request(a)lists.torproject.org > > > > You can reach the person managing the list at > > tor-relays-owner(a)lists.torproject.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of tor-relays digest..." > > > > > > Today's Topics: > > > > 1. Re: security update for obfs4proxy (meskio) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 10 Jan 2023 19:51:49 +0100 > > From: meskio <meskio(a)torproject.org> > > To: tor-relays <tor-relays(a)lists.torproject.org> > > Subject: Re: [tor-relays] security update for obfs4proxy > > Message-ID: <167337670907.1540.14665065923373201554@localhost> > > Content-Type: text/plain; charset="utf-8" > > > > We have made public the details of the distinguishability bugs that were > > affecting obfs4: > > https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/91 > > > > > https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs… > > > > Most bridges are already upgraded, thank you all bridge operators for the > > work > > here. > > > > Quoting meskio (2022-10-14 11:28:44) > > > Hello, > > > > > > The latest version of obfs4proxy (0.0.14) comes with an important > > security fix. > > > If you are running a obfs4 Tor bridge please upgrade as soon as > possible. > > > > > > If you use debian you can find the Debian package in stable-backports: > > > https://packages.debian.org/stable-backports/obfs4proxy > > > > > > If you use docker you'll find the latest version in docker hub: > > > https://hub.docker.com/r/thetorproject/obfs4-bridge/ > > > > > > Or you can find the source code in the upstream repository: > > > https://gitlab.com/yawning/obfs4 > > > > > > If you need help upgrading your relay, please use this mailing list or > > the Tor > > > Forum: > > > https://forum.torproject.net/c/support/relay-operator/17 > > > > > > We appreciate a lot your effort and time! > > > > > > Thank you > > > > -- > > meskio | https://meskio.net/ > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > My contact info: https://meskio.net/crypto.txt > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Nos vamos a Croatan. > >

3 4

obfs4proxy on arm64
by tor 13 Jan '23

13 Jan '23

Hi Where do I find the updated version of obfs4proxy for arm64? -m On Wed, Jan 11, 2023 at 7:00 AM <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: security update for obfs4proxy (meskio) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 10 Jan 2023 19:51:49 +0100 > From: meskio <meskio(a)torproject.org> > To: tor-relays <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] security update for obfs4proxy > Message-ID: <167337670907.1540.14665065923373201554@localhost> > Content-Type: text/plain; charset="utf-8" > > We have made public the details of the distinguishability bugs that were > affecting obfs4: > https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/91 > > https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs… > > Most bridges are already upgraded, thank you all bridge operators for the > work > here. > > Quoting meskio (2022-10-14 11:28:44) > > Hello, > > > > The latest version of obfs4proxy (0.0.14) comes with an important > security fix. > > If you are running a obfs4 Tor bridge please upgrade as soon as possible. > > > > If you use debian you can find the Debian package in stable-backports: > > https://packages.debian.org/stable-backports/obfs4proxy > > > > If you use docker you'll find the latest version in docker hub: > > https://hub.docker.com/r/thetorproject/obfs4-bridge/ > > > > Or you can find the source code in the upstream repository: > > https://gitlab.com/yawning/obfs4 > > > > If you need help upgrading your relay, please use this mailing list or > the Tor > > Forum: > > https://forum.torproject.net/c/support/relay-operator/17 > > > > We appreciate a lot your effort and time! > > > > Thank you > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan. >

2 1

security update for obfs4proxy
by meskio 10 Jan '23

10 Jan '23

Hello, The latest version of obfs4proxy (0.0.14) comes with an important security fix. If you are running a obfs4 Tor bridge please upgrade as soon as possible. If you use debian you can find the Debian package in stable-backports: https://packages.debian.org/stable-backports/obfs4proxy If you use docker you'll find the latest version in docker hub: https://hub.docker.com/r/thetorproject/obfs4-bridge/ Or you can find the source code in the upstream repository: https://gitlab.com/yawning/obfs4 If you need help upgrading your relay, please use this mailing list or the Tor Forum: https://forum.torproject.net/c/support/relay-operator/17 We appreciate a lot your effort and time! Thank you -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

4 12

Netcraft spam
by jvoisin 10 Jan '23

10 Jan '23

Hello everyone, at Nos-Oignons[1], we're getting spammed, not only on abuse(a)nos-oignons.net, but also on our contact email, and so is our hoster and its upstream but Netcraft[2]. Of course, we started by diligently answering the emails, but now it does feel like a waste of everybody's time. We told them we're hosting tor nodes, and that there is little we can do to prevent morons from abusing the network and using our relays for bad things™, but the netcraft spam keeps coming, annoying everyone. Is this something other operators have seen too or are we alone? If so, is there anything that can be done to make them understand what's going on? Than,s 1. https://nos-oignons.net 2. https://www.netcraft.com/cybercrime/countermeasures/ -- Julien (jvoisin) Voisin GPG: 04D041E8171901CC dustri.org

4 3

I think I'm available 24/7
by fastliftednloud 09 Jan '23

09 Jan '23

I apologize for my newbie-ness. I'm game to do my part and operate a relay, something simple for a technologically simple guy, like a guard or middle relay. I'm about ready to try and install for operation on my windows PC. The resources say that if you want to operate a relay on windows you need to be available 24/7. I think I am, could someone confirm this for me please. I live where I work, I run a family farm so I work outside but I rarely leave the property and I can clock in and out as I see fit. This leads me to believe I'm G2G but I want to make sure of this before I start working on a relay install only to waste my time. Thanks for any useful info and while I'm here, sup people? I'm the new guy.

2 1

Short heads up (was: Re: Another attempt against Tor DDoS)
by Frank Steinborn 09 Jan '23

09 Jan '23

Hi friends, I made some smaller tweaks over the last few hours which should especially help relays on nearly OOM or thrashing situations (making use of Zswap + MGLRU if available). The rules themselves are just the same, so no changes there. Merry christmas, Frank ------- Original Message ------- On Sunday, December 4th, 2022 at 11:25 PM, Frank Steinborn <steinex(a)nognu.de> wrote: > > > Hi, > > I want to show you my anti DDoS solution for my relays (aswell ;-). It works without ipset, but with a mix of the recent and hashlimit iptables modules. > > What is does: > * If one IP address tries to make 7 SYN connection attempts per second, they are locked out for 300 seconds. If they try another connection in that timeframe, the timer is reset and they are locked out for another 300 seconds. > * Threre are no more SYNs allowed if 4 connections are already in use to the ORPort. > > It works very well for me. Other solutons are far more aggressive but I feel my solution works perfectly against the attacks, even if they are not that aggresive. > > On top of that, I feel its more easy to implement into ones existing firewall solution. > > You can find the repo here: https://github.com/steinex/tor-ddos > > Feel free to give it a shot and feedback would be much appreciated! > > Greetings, > steinex

3 2

IPv6 Tor authority is down?
by shruub 09 Jan '23

09 Jan '23

Hello, so to also enable IPv6 on my relay I followed the post-install article which said that one should ping all IPv6 authorities with the following command: "ping6 -c2 2001:858:2:2:aabb:0:563b:1526 && ping6 -c2 2620:13:4000:6000::1000:118 && ping6 -c2 2001:67c:289c::9 && ping6 -c2 2001:678:558:1000::244 && ping6 -c2 2607:8500:154::3 && ping6 -c2 2001:638:a000:4140::ffff:189 && echo OK.". This generally works fine except for 2607:8500:154::3, and further testing with an online tool confirms that the ping does not succeed. So I now wonder if I can simply ignore that and enable IPv6, or if this isn't recommended (and probably also what I could do in this case). Thanks a lot. -- Best, shruub

2 2

Closing tor-relays-fr mailing list
by Chre 07 Jan '23

07 Jan '23

Hi all here, Many of us, French relay operators and Tor volunteers, thought it would be useful to restart the tor-relays-fr list, to discuss Tor relays in French. Having lost access to the original list created in 2012, we asked The Tor Project to create a new one. Arma was kind enough to respond, and despite his questions about the relevance of such a list, agreed to play along. This new tor-relays list was created on 9/22/2020. Thank you Tor Project! https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays-fr But... after over two years of existence, this list is clearly not very active. Probably because most people running Tor relays are fluent enough in English to discuss directly on... tor-relays. So we announce the closing of this list at the end of this year 2022, and we invite interested people to use on tor-relays (in English) ! It's here: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays https://forum.torproject.net/c/support/relay-operator/17 And it's still possible to ask questions in French on the official Tor project forum: https://forum.torproject.net/c/in-your-language/19 Good luck to everyone, and keep supporting the Tor project! Issue running here: https://gitlab.torproject.org/tpo/community/team/-/issues/63 <3 -- Chre

1 0

Bridge distribution mechanism thoughts
by a tor op 06 Jan '23

06 Jan '23

I have a few questions, I have two obfs4 bridges updated with sw, one old since a few years and the other very new. The older one I now notice all of a sudden have gotten distribution mechanisms 'none'. It had 'moat' earlier, what would make it change like this? It usually has between 50-100 users according to metrics page. The new bridge should be somewhat not/little used for some time according to lifecycle info on relays found online. I do however wonder if I should expect to see some users after 16 days? Another wonder about the new bridge is yet again distribution mechanism, it has 'email', is that really much used? Generally speaking I want my time and money to get the most use possible of course. How much use does the 'telegram' mechanism get? Maybe someone can give some comments before I (possibly) change it manually on either of those bridges. A tor op

1 0

cannot keep my bridge up
by Anonforpeace 02 Jan '23

02 Jan '23

Hello: I hope you can help me. I'm having trouble keeping my bridge up. Ports are forwarded. Running latest version of Tor. I had it running for at least roughly 7 to 10 days and then it went down and keeping it up is trouble. I even setup dynamic dns on my router using no-ip.com to see if that would help and still no. I've pasted logs from this morning here. Any help is appreciated. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF tor[17727]: Dec 20 08:55:16.929 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:34445 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: We compiled with OpenSSL 30000020: OpenSSL 3.0.2 15 Mar 2022 and we are running with OpenSSL 30000020: 3.0.2. These two versions should be binary compatible. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Tor 0.4.7.12 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.35 as libc. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Read configuration file "/etc/tor/torrc". Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Based on detected system memory, MaxMemInQueues is set to 2849 MB. You can override this by setting MaxMemInQueues by hand. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Socks listener on 127.0.0.1:9050 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Socks listener connection (ready) on 127.0.0.1:9050 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening OR listener on 0.0.0.0:443 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened OR listener connection (ready) on 0.0.0.0:443 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Extended OR listener on 127.0.0.1:0 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Extended OR listener listening on port 34445. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Extended OR listener connection (ready) on 127.0.0.1:34445 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF kernel: [137278.310446] audit: type=1400 audit(1671544516.974:36): apparmor="DENIED" operation="open" profile="system_tor" name="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" pid=17728 comm="obfs4proxy" requested_mask="r" denied_mask="r" fsuid=128 ouid=0 Dec 20 08:55:17 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Parsing GEOIP IPv4 file /usr/share/tor/geoip. Dec 20 08:55:17 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Dec 20 08:55:17 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your Tor server's identity key fingerprint is 'h4ck3rspace 93695FBD832C2A29A2DE719CC82B29F06C0B4E09' Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your Tor bridge's hashed identity key fingerprint is 'h4ck3rspace 709E7C37DFE418F6A28B3F0352787606B51A66C6' Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your Tor server's identity key ed25519 fingerprint is 'h4ck3rspace WpmTmQmwNU2PXhaGrwguLXwxiPL3g/4hHuXZRZxZli0' Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: You can check the status of your bridge relay at https://bridges.torproject.org/status?id=709E7C37DFE418F6A28B3F0352787606B5… Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 0% (starting): Starting Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Starting with guard context "default" Dec 20 08:55:26 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Signaled readiness to systemd Dec 20 08:55:26 mxh-HP-Compaq-Pro-6300-SFF systemd[1]: Started Anonymizing overlay network for TCP. Dec 20 08:55:26 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Registered server transport 'obfs4' at '[::]:52812' Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 5% (conn): Connecting to a relay Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Socks listener on /run/tor/socks Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Socks listener connection (ready) on /run/tor/socks Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Control listener on /run/tor/control Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Control listener connection (ready) on /run/tor/control Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Unable to find IPv4 address for ORPort 443. You might want to specify IPv6Only to it or set an explicit address or set Address. Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 10% (conn_done): Connected to a relay Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 14% (handshake): Handshaking with a relay Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 15% (handshake_done): Handshake with a relay done Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: External address seen and suggested by a directory authority: 100.38.62.232 Dec 20 08:55:28 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 100% (done): Done Dec 20 08:56:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Now checking whether IPv4 ORPort 100.38.62.232:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF CRON[17784]: (root) CMD (timeshift --check --scripted) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF crontab[17820]: (root) LIST (root) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF crontab[17821]: (root) LIST (root) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF systemd[1]: run-timeshift-17784-backup.mount: Deactivated successfully. Dec 20 09:15:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your server has not managed to confirm reachability for its ORPort(s) at 100.38.62.232:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Dec 20 09:17:01 mxh-HP-Compaq-Pro-6300-SFF CRON[18262]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Sent with [Proton Mail](https://proton.me/) secure email.

4 5

Tor process sporadically gets hung on cloud server
by Keifer Bly 19 Dec '22

19 Dec '22

Hi, So I have been being careful to keep tor as well as Debian up to date, however, both my middle relay "udeserveprivacy" and my bridge "gbridge", running on two different cloud services (OVH and Google Cloud respectively), the tor process gets hung and the relay become unreachable. Upon checking the tor log file I cannot find anything suspicious, so this is a possible bug in tor I am reporting. I am wondering why this would happen and not be recorded in the tor log file? Thanks all. -Keifer

1 0

Setting a relay as an HSDirectory?
by code9n＠pm.me 19 Dec '22

19 Dec '22

Hi all, Thanks for the last answers, it's all running nicely now. Now I want to set the relay to act as a Hidden Services Directory as well and reading the torrc file I'm not sure how to do it. Do I just uncomment the lines 10 and 11 of the extract below? Or just line 10? Or lines 10, 11, 13,14 and 15? Or just some combination of them? 1 ############### This section is just for location-hidden services ### 2 3 ## Once you have configured a hidden service, you can look at the 4 ## contents of the file ".../hidden_service/hostname" for the address 5 ## to tell people. 6 ## 7 ## HiddenServicePort x y:z says to redirect requests on port x to the 8 ## address y:z. 9 10 #HiddenServiceDir /var/lib/tor/hidden_service/ 11 #HiddenServicePort 80 127.0.0.1:80 12 13 #HiddenServiceDir /var/lib/tor/other_hidden_service/ 14 #HiddenServicePort 80 127.0.0.1:8015 #HiddenServicePort 22 127.0.0.1:22 I have uncommented line 10 as, looking at other relays in relay search, relays that have the HSDir flag (mostly) do not seem to have any DirPorts open but so far my relay does not have the HSDir flag itself. Although the torrc file hasn't been reset for very long, yet. Thanks for any advice, Pete

2 1

How to reduce tor CPU load on a single bridge?
by David Fifield 19 Dec '22

19 Dec '22

The main Snowflake bridge (https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6…) is starting to become overloaded, because of a recent substantial increase in users. I think the host has sufficient CPU and memory headroom, and pluggable transport process (that receies WebSocket connections and forwards them to tor) is scaling across multiple cores. But the tor process is constantly using 100% of one CPU core, and I suspect that the tor process has become a bottleneck. Here are issues about a recent CPU upgrade on the bridge, and observations about the proportion of CPU used by different processes: https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… I have the impression that tor cannot use more than one CPU core—is that correct? If so, what can be done to permit a bridge to scale beyond 1×100% CPU? We can fairly easily scale the Snowflake-specific components around the tor process, but ultimately, a tor client process expects to connect to a bridge having a certain fingerprint, and that is the part I don't know how to easily scale. * Surely it's not possible to run multiple instances of tor with the same fingerprint? Or is it? Does the answer change if all instances are on the same IP address? If the OR ports are never used? * OnionBalance does not help with this, correct? * Are there configuration options we could set to increase parallelism? * Is migrating to a host with better single-core performance the only immediate option for scaling the tor process? Separate from the topic of scaling a single bridge, here is a past issue with thoughts on scaling beyond one bridge. it looks as though there are not ways to do it that do not require changes to the way tor handles its Bridge lines. https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… * Using multiple snowflake Bridge lines does not work well, despite that we could arrange to have the Snowflake proxy connect the user to the expected bridge, because tor will try to connect to all of them, not choose one at random. * Removing the fingerprint from the snowflake Bridge line in Tor Browser would permit the Snowflake proxies to round-robin clients over several bridges, but then the first hop would be unauthenticated (at the Tor layer). It would be nice if it were possible to specify a small set of permitted bridge fingerprints.

7 57

Status of Bug #7349 - Obfsbridges should be able to "disable" their ORPort?
by Gary C. New 17 Dec '22

17 Dec '22

All: What is the status of Bug #7349 - Obfsbridges should be able to "disable" their ORPort? https://bugs.torproject.org/tpo/core/tor/7349 I recently setup a loadbalanced OBFS4 bridge and would prefer not to expose the ORPort to the World. I've noticed that some of the tasks to make this possible have been implemented, but it isn't clear whether everything needed is in place as I receive a bridge/relay down status on metrics.torproject.org when the ORPort isn't exposed to the World. Thank you for your assistance. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)

2 2

New relay questions
by code9n＠pm.me 15 Dec '22

15 Dec '22

Hi Relay Operators, I am trying to run a non exit relay for the first time and have some questions: FYI, I have 2 virtual CPU s and 1.256 GB RAM with ‘unlimited’ bandwidth on a rented VPS running Debian 11. The logs report success and the Relay Search shows my relay (Nickname: code9nRelay) running but the advertised bandwidth is 0 B/s. It’s been running for 13 hours or so and I see a new relay that has been running for 1 hour has an advertised bandwidth of 12MiB/s. I did set the bandwidth to 100KB/s, then 200KB/s but now it’s just set to run the defaults. Ie Nothing is set. I had my email address as my first contact then my GPG fingerprint as a second contact but the fingerprint is displayed not the email. Now I have it all on one line with the email address first. Which brings me to my main question; when I run systemctl restart tor@default shouldn’t the new settings in the torrc file be used from that point on? Because they don’t seem to be. I have run it after making the changes above and the old settings are still shown on the Relay Search page. Ie 0KB/s and my GPG fingerprint showing as my email address. If this restart doesn’t reset the torrc then what does? Or is it just a matter of waiting for the new info to be taken up? Any one have any thoughts or advice, please? Pete Here are the recent logs: Dec 14 20:05:31.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 10 circuits open. I've sent 188.82 MB and received 168.28 MB. I've received 14629 connections on IPv4 and 1847 on IPv6. I've made 171 connections with IPv4 and 8 with IPv6. Dec 14 20:05:31.000 [notice] While not bootstrapping, fetched this many bytes: 3951317 (server descriptor fetch); 944 (server descriptor upload); 358850 (consensus network-status fetch); 49621 (microdescriptor fetch) Dec 14 20:05:31.000 [notice] Average packaged cell fullness: 95.570%. TLS write overhead: 16% Dec 14 20:05:31.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 37259/37259 NTor. Dec 14 20:05:31.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 0 v4 connections; initiated 60 and received 16368 v5 connections. Dec 14 20:05:31.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Dec 15 02:05:31.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 3 circuits open. I've sent 375.23 MB and received 326.98 MB. I've received 32711 connections on IPv4 and 3289 on IPv6. I've made 306 connections with IPv4 and 14 with IPv6. Dec 15 02:05:31.000 [notice] While not bootstrapping, fetched this many bytes: 8221506 (server descriptor fetch); 944 (server descriptor upload); 766467 (consensus network-status fetch); 80676 (microdescriptor fetch) Dec 15 02:05:31.000 [notice] Average packaged cell fullness: 94.792%. TLS write overhead: 18% Dec 15 02:05:31.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 37813/37813 NTor. Dec 15 02:05:31.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 0 v4 connections; initiated 88 and received 35765 v5 connections. Dec 15 02:05:31.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Dec 15 02:31:35.000 [notice] Performing bandwidth self-test...done. ……………………………………...

3 2

Multiple ServerTransportListenAddr OBFS2|3|4 Configuration
by Gary C. New 15 Dec '22

15 Dec '22

All: I noticed that the obfs2, obfs3, and obfs4 transport names seem to be hardcoded into tor. I have been able to configure the torrc to register each of the transports for multiple ServerTransportListenAddr: # cat torrc ORPort xxx.xxx.xxx.xxx:443 NoListen ORPort 192.168.0.31:9001 NoAdvertise SocksPort 9050 SocksPort 192.168.0.31:9050 ControlPort 9051 HTTPTunnelPort 9080 HTTPTunnelPort 192.168.0.31:9080 ExtORPort 192.168.0.31:auto BridgeRelay 1 BridgeDistribution moat ServerTransportPlugin obfs2 exec /opt/bin/obfs4proxy -enableLogging ServerTransportListenAddr obfs2 192.168.0.31:3102 ServerTransportOptions obfs2 iat-mode=2 ServerTransportPlugin obfs3 exec /opt/bin/obfs4proxy -enableLogging ServerTransportListenAddr obfs3 192.168.0.31:3103 ServerTransportOptions obfs3 iat-mode=2 ServerTransportPlugin obfs4 exec /opt/bin/obfs4proxy -enableLogging ServerTransportListenAddr obfs4 192.168.0.31:3104 ServerTransportOptions obfs4 iat-mode=2 DirCache 1 ExitRelay 0 # grep -i obfs ./torlog 2022/12/14 00:39:07 [NOTICE]: obfs4proxy-0.0.14 - launched Dec 13 17:41:48.000 [notice] Registered server transport 'obfs2' at '192.168.0.31:3102' Dec 13 17:41:48.000 [notice] Registered server transport 'obfs3' at '192.168.0.31:3103' Dec 13 17:41:48.000 [notice] Registered server transport 'obfs4' at '192.168.0.31:3104' # netstat -anp | grep obfs4proxy tcp 0 0 192.168.0.31:3102 0.0.0.0:* LISTEN 30185/obfs4proxy tcp 0 0 192.168.0.31:3103 0.0.0.0:* LISTEN 30185/obfs4proxy tcp 0 0 192.168.0.31:3104 0.0.0.0:* LISTEN 30185/obfs4proxy My question is whether the respective obfs2|3|4 transport names force the corresponding protocol? If so... Are there any ServerTransportOptions that can force the obfs4 protocol on the legacy obfs2|3 transports? Also... It wasn't clear in the manual whether obfs4proxy -enableLogging takes an optional path/file? I appreciate any knowledge on the subjects. Respectfully, Gary

2 2

Are HTTPTunnelPort and SocksPort Disabled in Bridge Mode?
by Gary C. New 14 Dec '22

14 Dec '22

All: Are HTTPTunnelPort and SocksPort Disabled in Bridge Mode (BridgeRelay 1)? Recently, I migrated over to Bridge Relays and discovered I can no longer client connect over 9080 (HTTPTunnelPort) or 9050 (SocksPort). I've confirmed that listeners are still binding to 9080 and 9050, but I can no longer client connect over them. However, I am able to successfully client connect over the new ServerTransportListenAddr and Port. Is it possible to use HTTPTunnelPort and SocksPort in Bridge Mode (BridgeRelay 1)? Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)

1 1

Re: [tor-relays] inet_csk_bind_conflict
by Gary C. New 10 Dec '22

10 Dec '22

On Saturday, December 10, 2022, 7:23:28 AM PST, David Fifield <david(a)bamsoftware.com> wrote: On Sat, Dec 10, 2022 at 09:59:14AM +0100, Anders Trier Olesen wrote: >> IP_BIND_ADDRESS_NO_PORT did not fix your somewhat similar problem in your >> Haproxy setup, because all the connections are to the same dst tuple <ip, port> >> (i.e 127.0.0.1:ExtORPort). >> The connect() system call is looking for a unique 5-tuple <protocol, srcip, >> srcport, dstip, dstport>. In the Haproxy setup, the only free variable is >> srcport <tcp, 127.0.0.1, srcport, 127.0.0.1, ExtORPort>, so toggling >> IP_BIND_ADDRESS_NO_PORT makes no difference. > No—that is what I thought too, at first, but experimentally it is not > the case. Removing the IP_BIND_ADDRESS_NO_PORT option from Haproxy and > *doing nothing else* is sufficient to resolve the problem. Haproxy ends > up binding to the same address it would have bound to with > IP_BIND_ADDRESS_NO_PORT, and there are the same number of 5-tuples to > the same endpoints, but the EADDRNOTAVAIL errors stop. It is > counterintuitive and unexpected, which why I took the trouble to write > it up. > As I wrote at #40201, there are divergent code paths for connect in the > kernel when the port is already bound versus when it is not bound. It's > not as simple as filling in blanks in a 5-tuple in otherwise identical > code paths. > Anyway, it is not true that all connections go to the same (IP, port). > (There would be no need to use a load balancer if that were the case.) > At the time, we were running 12 tor processes with 12 different > ExtORPorts (each ExtORPort on a different IP address, even: 127.0.3.1, > 127.0.3.2, etc.). We started to have EADDRNOTAVAIL problems at around > 3000 connections per ExtORPort, which is far too few to have exhausted > the 5-tuple space. Please check the discussion at #40201 again, because > I documented this detail there. > I urge you to run an experient yourself, if these observations are not > what you expect. I was surprised, as well. I wonder if IP_BIND_ADDRESS_NO_PORT is better implemented in Nginx? https://www.nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus/ Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)

1 0

upcoming directory authority changes
by Roger Dingledine 08 Dec '22

08 Dec '22

Hello fellow relay operators, Later today (Tuesday) we plan to do a synchronized shift where we make two configuration changes on the directory authorities. The goal will be to make these changes while maintaining the right threshold of signatures so relays and users still get a safe network status consensus that they trust. For background, Tor uses a threshold consensus design, where as long as a majority of directory authorities are behaving properly, all users get the same accurate view of the Tor network. You can learn more about the design in the bottom half of https://support.torproject.org/about/key-management/. Specifically, we plan to make these changes: (1) Temporarily remove Faravahar from the set of directory authorities, until Sina finds a new good home for it. We weren't all comfortable with its previous hosting location inside Team Cymru's network (see the bottom of https://blog.torproject.org/role-tor-project-board-conflicts-interest/ for more details), so to be extra safe we are making it no longer participate in the consensus process until it is reborn in its future home. You can read more about Sina and why we are excited to keep him involved in the Tor community at https://blog.torproject.org/volunteer-spotlight-sina-rabbani-helps-activist…. (2) Rotate to fresh identity keys for moria1, the directory authority that I run. In early November 2022 there was a remote break-in to the computer running moria1. Based on the evidence and the type of attack, I believe it was a standard automated attack -- that is, I think they weren't targeting the directory authority and also they never realized it *was* a directory authority. But to be extra safe, we decided to rotate to a fresh set of keys. I was also in the middle of a planned move to better hardware, so overall it was good timing for a fresh new start. I should note that for both moria1 and Faravahar, we have no evidence of any misuse of their keys. But more importantly, the threshold consensus design keeps Tor users safe *even if* we are underestimating what happened. Tor users and relays demand a consensus signed by a majority of the directory authorities, and right now that's five out of eight. Tor's security/privacy/anonymity properties remained safe before, during, and after these changes. Some closing thoughts and details: * We actually already removed Faravahar in the Tor git repository and in the Tor release 0.4.7.11 (which came out Nov 10 and has been in Tor Browser since Nov 22), so modern clients and relays are already demanding signatures from five authorities that aren't Faravahar. The change we'll do today is to make the other directory authorities stop incorporating its vote and signature into the consensus. Doing these changes at different times opened the window for surprising but harmless log warnings like https://bugs.torproject.org/tpo/core/tor/40725. We could see similar issues with the new moria1 key, and if so they should go away once there's a new release with the new key and you have upgraded. * In my opinion there is a good argument for every directory authority making fresh keys every few years anyway, especially in a world with sophisticated attackers who might try to obtain keys and not leave any traces. So for example when we bring Faravahar back I think it should be with entirely new keys. * Secure consensus designs have become much better in the past decade, in large part from all the Bitcoin enthusiasm. Our current design was always intended to be a placeholder until we got something better. And our friends in the PETS research community have been exploring edge cases where evil directory authorities can create mischief even when they're slightly less than a full majority. So while we're triaging the usual fires and priorities, we shouldn't forget about improving the directory design. * Directory authority keys already have a notion of an offline long-term identity with shorter-lifetime online keys that expire periodically, with the goal of limiting the future impact of a compromise. But it seems like this role separation never quite matches up well to the security issues that arise in practice, whereas it definitely adds complexity both to the design and to operation. This piece of the design could use some new ideas. * Lastly, the directory authority operator community is a community too, and the security of the Tor network relies on social trust and cooperation between these fine people. We used to have directory authority operator meetups in person at security conferences and at Tor dev meetings, to maintain the social and community connections. Covid put a stop to that along with so many other things, and we should work to bring it back. We could start by encouraging directory authority operators to participate in the monthly virtual relay operator meetups. Thanks for reading all the way to the end / hope this level of detail helps, --Roger

3 3

Re: [tor-relays] Tor DDoS Mitigation iptables scripts update. Version 4.0.1
by Chris 05 Dec '22

05 Dec '22

Hi Andres, Not at all. That's how I'm running my own relays. Just run the **combined.sh** on each individual VM and you'll be fine. As for the ORPort, yes, I agree. There are ways to read the torrc file and set the ORPort automatically. I will incorporate that into the scripts in future versions. My original intention was to put something simple together with minimum complexity that anyone with little or no expertise can understand and modify if necessary without breaking the code. I've also set up a [Discussion Board](https://github.com/Enkidu-6/tor-ddos/discussions) for the repository on github in case you have any questions, suggestions or simply need further help. On 12/1/2022 11:57 AM, Anders Trier Olesen wrote: > Hi Chris > > We run all the 12 dotsrc relays on a single host with many IP > addresses. Would we need to change anything? > > Btw, you can make the scripts find the all the OR ports by running > something like ‘ss -pl | grep tor’. > > - Anders > > tor. 1. dec. 2022 kl. 09.02 skrev Chris <tor(a)wcbsecurity.com > <mailto:tor@wcbsecurity.com>>: > > Background: > > A set of bash scripts used to apply iptables rules to fight the > current > DDoS attacks. They require no dependencies to install except > iptable/nftables which all Linux flavors already have and require no > particular expertise. The issue was discussed here: > > [issue > 40093](https://gitlab.torproject.org/tpo/community/support/-/issues/40093) > > Change log: > > Some modifications due to a change in the nature of the attacks. > > - Re ordered rules for more efficiency and reducing the load > - Removed the hashlimit rule as it puts more load on the system > with not > much overall benefit as the attackers have adapted to it and it > reduces > the size of the block list. > - Reduce the number of allowed concurrent connections to 2 if > you're not > a relay. > - Use of remove.sh cron script at regular intervals (optional) > will give > relays a chance to create up to 4 connections if they need to. > ******- Created a new cron file **refresh-authorities.sh** to refresh > your allow-list with the most up to date IP addresses for the > authorities and snowflake. Should be run daily. > - Removed an unnecessary line in the update files. > - Modified Readme.MD file to reflect new changes. > > The new modifications have been tested for two weeks now and the > systems > are running smoothly with no ill effect. > > You can read more and download here: > > [Enkidu-6 tor-ddos on Github](https://github.com/Enkidu-6/tor-ddos) > > To avoid occasional NTor drops a minimum NumCPUs 16 in torrc is > recommended. > > P.S. > The NumCPUs option is unfortunately poorly documented. It really has > nothing to do with the number of CPUs you have. It's about the > number of > worker threads Tor will create to deal with decryption of > onionskins. So > you can have two CPUs and still set NumCPUs to 16. > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > <mailto:tor-relays@lists.torproject.org> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 2

Another attempt against Tor DDoS
by Frank Steinborn 04 Dec '22

04 Dec '22

Hi, I want to show you my anti DDoS solution for my relays (aswell ;-). It works without ipset, but with a mix of the recent and hashlimit iptables modules. What is does: * If one IP address tries to make 7 SYN connection attempts per second, they are locked out for 300 seconds. If they try another connection in that timeframe, the timer is reset and they are locked out for another 300 seconds. * Threre are no more SYNs allowed if 4 connections are already in use to the ORPort. It works *very* well for me. Other solutons are far more aggressive but I feel my solution works perfectly against the attacks, even if they are not that aggresive. On top of that, I feel its more easy to implement into ones existing firewall solution. You can find the repo here: https://github.com/steinex/tor-ddos Feel free to give it a shot and feedback would be much appreciated! Greetings, steinex

1 0

relayor v22.0.0-rc is released
by nusenu 03 Dec '22

03 Dec '22

Hi, relayor v22.0.0-rc is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes since relayor v21.2.0-rc: * MetricsPort support improvements: * generate nginx reverse server config for remote prometheus scraping on the relay (we do not install nginx) * generate htpasswd file for HTTP basic auth of MetricsPort on the relay * debian/ubuntu: support new alpha repos (branch name is no longer included in the repo name). * FreeBSD 12.3 is supported kind regards, nusenu -- https://nusenu.github.io

2 4

Difficulties testing my bridge
by binarynoise 02 Dec '22

02 Dec '22

Hello everyone, I run a bridge and as I was doing maintenance on my server, I wanted to check whether my bridge works and whether the bandwidth is really as low as advertised in the relay search (it's not, maybe because no-one uses it, as it's on reserved distribution). So I started my tor-browser, opened htop locally and on the server and started browsing. Everything went smoothly, but something was odd: I did not see any traffic on my server (that idles most of the time, so I should see my bridges traffic). Checked connection-info: no bridge there. Went to settings, checked the bridge settings: yes, I had entered by bridge-line. Odd. Continued to the tor logs: oh, bridge-line didn't parse. Interesting. (I put in the server's identity key ed25519 fingerprint instead of the not-ed25519 one and put my bridges name somewhere there too). Ok, but why doesn't it tell me? Why is there no big "Couldn't connect to your configured bridges"- warning after hitting the connect-to-tor-button? Anyway, does some tool exist, where you enter your bridge's information or run it on the server, that tells you if the recommended versions of tor + dependencies are installed and actually used? That would make the task of keeping the bridge healthy easier. Greetings binarynoise

3 4

Tor DDoS Mitigation iptables scripts update. Version 4.0.1
by Chris 30 Nov '22

30 Nov '22

Background: A set of bash scripts used to apply iptables rules to fight the current DDoS attacks. They require no dependencies to install except iptable/nftables which all Linux flavors already have and require no particular expertise. The issue was discussed here: [issue 40093](https://gitlab.torproject.org/tpo/community/support/-/issues/40093) Change log: Some modifications due to a change in the nature of the attacks. - Re ordered rules for more efficiency and reducing the load - Removed the hashlimit rule as it puts more load on the system with not much overall benefit as the attackers have adapted to it and it reduces the size of the block list. - Reduce the number of allowed concurrent connections to 2 if you're not a relay. - Use of remove.sh cron script at regular intervals (optional) will give relays a chance to create up to 4 connections if they need to. ******- Created a new cron file **refresh-authorities.sh** to refresh your allow-list with the most up to date IP addresses for the authorities and snowflake. Should be run daily. - Removed an unnecessary line in the update files. - Modified Readme.MD file to reflect new changes. The new modifications have been tested for two weeks now and the systems are running smoothly with no ill effect. You can read more and download here: [Enkidu-6 tor-ddos on Github](https://github.com/Enkidu-6/tor-ddos) To avoid occasional NTor drops a minimum NumCPUs 16 in torrc is recommended. P.S. The NumCPUs option is unfortunately poorly documented. It really has nothing to do with the number of CPUs you have. It's about the number of worker threads Tor will create to deal with decryption of onionskins. So you can have two CPUs and still set NumCPUs to 16.

1 0

Considering running a relay on AWS Free tier
by Keifer Bly 29 Nov '22

29 Nov '22

Hi, So I don't know if I will do it, but I am considering setting up a tor middle relay on AWS free tier. I have been asking their support tem regarding how much traffic one can push and remain free tier, their response was: If your microservice application is using an RDS or Amazon DynamoDB Accelerator (DAX) database, the Lambda-to-database traffic will be free if it’s in the same region, including if VPC peering is used. Traffic to databases in a different region will incur a regional transfer fee of $0.09 per GB for both the Lambda and database egress traffic. Ingress traffic is free for both.\" I am wondering does anyone else run tor middle relays on AWS free tier, and what is the best torrc configuration to use for keeping the inbound and outbound traffic in free tier in case I do go fourth with this? Thanks. --Keifer

2 1

Next Tor relay operator - November 19th at 19.00 UTC
by gus 23 Nov '22

23 Nov '22

Dear relay operators, The next Tor relay operator meetup will happen on Saturday, November 19th at 19.00 UTC. ## Where BigBlueButton: https://tor.meet.coop/gus-og0-x74-dzn ## Agenda (WIP) - Announcements - State of DoS attack - Q&A - Next Tor Relay Operator Meetup Meeting pad: - https://pad.riseup.net/p/tor-relay-op-meetup-n19-keep - http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… Everyone is free to bring up additional questions or topics at the meeting itself. ## Registration No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

1 1

Re: [tor-relays] preventing DDoS is more than just network filtering
by Toralf Förster 15 Nov '22

15 Nov '22

On 11/8/22 10:57, Chris wrote: > The main reason is that a simple SYN flood can quickly fill up your > conntrack table and then legitimate packets are quietly dropped and you > won't see any problems thinking everything is perfect with your server > unless you dig into your system logs. Hhm, my system log doesn't show any problems, maybe due to (or regardless of?): CONFIG_SYN_COOKIES=y ? Nevertheless, I updated the Readme to explain my point of view [1] [2]. [1] https://github.com/toralf/torutils#block-ddos-traffic [2] https://github.com/toralf/torutils#rule-set -- Toralf

3 3

Tor Relay on Gandi.net
by protectmyonion 14 Nov '22

14 Nov '22

mailto:tor-relays@lists.torproject.org I was wondering if anyone had experience running a Tor relay on Gandi. According to [good-bad-isps](https://community.torproject.org/relay/community-resources/g…, Gandi supports all relays. However, I contacted support asking them their policy on Tor and if their policy was the same for all Tor relays. Their response was basically 'You can install any software you want, but its use is subject to French law and our terms of service. If a complaint is received, the Abuse department will take appropriate action and notify you.'. This was pretty vague and kind of seemed like they didn't know what Tor was. I responded and tried to explain what Tor was using most of what was in the Common Boilerplate template. I explained that there were things that I could do to reduce potential abuse, like limiting the exit policy, but that there was always still potential for abuse. The next response came from the Abuse department and basically said 'Any illegal activity on your IP will result in your server being shutdown.'. Based on this, it seems like Gandi is not a good ISP for Tor exits, but likely fine for all other relays. What's a little confusing is that according to Tor metrics, Gandi currently has Tor exits. It is only 2, but nevertheless, they exist. [France](https://metrics.torproject.org/rs.html#search/as:AS203476) location has 2 exits, but [Luxembourg](https://metrics.torproject.org/rs.html#search/as:AS29169) has none. I'm not sure if [good-bad-isps](https://community.torproject.org/relay/community-resources/g… should be updated, given there's conflicting information, but I figured I'd ask if anyone had personal experience with Gandi. Thanks.

3 2