- tor-relays - lists.torproject.org

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