- tor-relays - lists.torproject.org

Re: Tor relays source IPs spoofed to mass-scan port 22?
by Carlo P. 06 Nov '24

06 Nov '24

Meanwhile 3* OVH abuse report (twice the same, once for 2nd IP), Virtarix, ServaRICA - all from the same watchdogcyberdefence folks. I have replied to all above ISPs, no suspensions so far. Just received a suspension note without ANY explanation from AvenaCloud - opened a support ticket with them... On November 5, 2024 at 5:51 PM, mick <mbm(a)rlogin.net> wrote: On Tue, 5 Nov 2024 10:32:40 +0200 "Dimitris T. via tor-relays" allegedly wrote: > another abuse report from hetzner (by the same watchdogcyberdefence) > a few hours ago. no reply from hetzner yet to previous ticket. > > this time, alleged attacked /20 subnet from watchdogcyberdefence was > firewalled since 30/10/2024, just to confirm new false abuse > reports..., and they confirmed (=their report, shows traffic from our > ip on 3/11/2024).... And I have received a new "abuse" report from Hetzner raised by the same bozos at watchdogcyberdefence, but this time purportedly aimed at FTP port 21. I've told Hetzner they are welcome to monitor traffic coming out of my node to reassure themselves that this is nonsense. Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net --------------------------------------------------------------------- _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email

1 0

Raspberry Pi 4
by Keifer Bly 05 Nov '24

05 Nov '24

Hi, So I am wondering, is a Raspberry Pi 4 a recommended device to run a tor relay on? In terms of traffic load, etc? Thanks. --Keifer

6 7

Please check if your relay has fallen out of the consensus
by Roger Dingledine 02 Nov '24

02 Nov '24

Hi folks! We're hunting down a mystery where two of our big university relays are having troubles reaching the Tor directory authorities: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/86 Can you check to see if your relay is in a similar situation? In particular, the situation to look for is "Tor process is still running fine from your perspective, but, relay-search (https://atlas.torproject.org/) says you are no longer running." If your relay is in this situation, the next step is to check your Tor logs, try to rule out other issues like firewall rules on your side, and then (if you're able) to start exploring traceroutes to the directory authority IP addresses vs other addresses. If you need more direct help, we can help you debug or answer other questions on #tor-relays on IRC. Thanks, --Roger

5 7

"When you pay peanuts, you get monkeys"
by mick 02 Nov '24

02 Nov '24

Hi there. I found the title of the above blog post highly ironic. I run a Tor relay (middle and guard node). You appear to be sending automated "abuse" reports to other ISPS as a result of what is obviously (well obvious to anyone who studies the network traffic properly) spoofed source address connections to SSH port 22 on random servers around the net. These "abuse" reports cause the ISP hosting the /real/ address of the spoofed server to do one of two things. Either they just pass the report on to the server admin for investigation, or they simply shut down the srevr in question and lock the account of the operator. In either case the perfectly innocent Tor server admin is highly inconvenienced and the bad actor(s) doing the spoofing scans get the Tor relay addresses blacklisted. This is detrimental to the health of the Tor network. Please look carefully at your automated abuse reporting system and add some intelligence to it - preferably by getting a properly skilled network administrator to look at the traffic /before/ firing off a spurious report. (Oh and BTW, SSH scanning at scale is so much part of the background noise on the 'net that I am astounded that you should pay much attention to it at all. I don't.) Best Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net ---------------------------------------------------------------------

2 2

Re: [tor-relays] Tor relays source IPs spoofed to mass-scan port 22?
by Carlo P. 31 Oct '24

31 Oct '24

Just received today two abuse tickets... On October 31, 2024 at 9:29 AM, Pierre Bourdon <delroth(a)gmail.com> wrote: On Tue, Oct 29, 2024, 03:33 Pierre Bourdon <delroth(a)gmail.com> wrote: By any chance, any other relay ops seeing the same thing, or am I just going crazy? (it does kind of sound insane...) Any speculation as to the reason for this? My own write-up and explanation (and speculation) is available at https://delroth.net/posts/spoofed-mass-scan-abuse/ as a reference. I've had a few people email me saying they had the same scare moment after getting an abuse report and they ended up finding my article, so I'd like to think it's already helped a bit! I also received an email today from Hetzner's legal team saying that they have read my article (props on them, I didn't send it to them myself!). They are monitoring the situation on their side and emphasized that they do not usually take action on this kind of reports they have recently been forwarding to Tor relay operators. So at least for others hosting relays at Hetzner I don't think it's worth worrying too much. For other hosting providers, your mileage may vary. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sent with https://mailfence.com Secure and private email

1 0

[tor-project] Reminder: mailman 3 upgrade imminent (TPA-RFC-71)
by Antoine Beaupré 30 Oct '24

30 Oct '24

Hi, As mentioned in early October, we're in the process of upgrading our main mail server, which includes upgrading to the shiny new Mailman 3 platform. We have, right now, a prototype mailman 3 server available at: https://lists-01.torproject.org/ It's hidden behind the usual "trivial" authentication (ask us on IRC if you don't remember what it is), but should otherwise work normally. I'm going to start by migrating the TPA mailing list and we'll be testing this for a couple of days, but, next week, I'll start migrating the other mailing lists (including this one!). If people want to jump in front of that train early and be part of the beta testers, then by all means I'm happy to have your mailing list be part of the early adopters. Be warned that Mailman 3 is a significant upgrade from Mailman 2. There are some great things (like unified authentication), and some less great things (like a more complex design and "shinier" web interface that might not be everyone's taste). As a reminder, we're doing this upgrade a little rushed because the main mail server is now unsupported for security upgrades. See the details of the proposal here: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-71-emerge… ... with the milestone tracking actual work issues in: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/16 (Sorry for cross-posting this, but this seems like it warrants wider distribution. As a rule of thumb, I selected mailing lists with public archives that had posts in October 2024, removing duplicates like anti-censorship-team and -alerts. I also suspect many of those mailing lists will refuse my message because I'm not subscribed, but I will have tried. :)) Phew! a. -- Antoine Beaupré torproject.org system administration _______________________________________________ tor-project mailing list tor-project(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

1 0

Re: [tor-relays] Please check if your relay has fallen out of the consensus
by denny.obreham＠a-n-o-n-y-m-e.net 29 Oct '24

29 Oct '24

As an update, once I showed the link from OONI to my ISP, they offered to move my server to another location at no charge. So the Tor server was moved from India to the UK. (Actually, I built a new one from scratch.) So I will mention here this ISP - Contabo.com - for their great customer service and understanding of what Tor represents. They have automatically and temporarily blocked my IP address - and informed me that they did - 2 or 3 times in the past because they felt it was under a DDoS attack, and I'm OK with that. At one point, communicating with their support team, one person even wrote this to me: We are glad to support your efforts in maintaining these relays, as they play a crucial role in fighting censorship and promoting internet freedom. Thank you for your ongoing trust and partnership. I initially chose them because they have few exit relays (only 12 as of today, 4 of them being mine, but there are about 100 other non-exit relays). With that kind of service, I'm wondering why they are not more popular for exit relays. Denny On 2024-10-22 15:41, tor-relays(a)queer.cat wrote: > > > On 22/10/24 12:08, denny.obreham(a)a-n-o-n-y-m-e.net wrote: >> I still haven't found a solution to my problem I stated earlier in my email with the subject "Exit relay not in consensus" https:// lists.torproject.org/pipermail/tor-relays/2024-October/021899.html <https://lists.torproject.org/pipermail/tor-relays/2024-October/021899. html> >> >> >> The most helpful answers were from Sebastian <https:// lists.torproject.org/pipermail/tor-relays/2024-October/021909.html> and George <https://lists.torproject.org/pipermail/tor-relays/2024- October/021918.html>. I contacted the ASN but never received a response. My ISP was useless as they jus t repeated "We don't block traffic." > > > Iâve gone through the original thread you shared and found an OONI result that supports the notion that your ASN (141995) is blocking Tor directory authorities. You can view the result here: > > https://explorer.ooni.org/m/20241001034902.297107_US_tor_d6973b06186ed4 3a > >> >> >> As of today, the server is still active and running. You can't find it in the metrics but it is still in the consensus <https://consensus- health.torproject.org/consensus-health.html? #7BDDE0E7607A5F49578768F44CD721793FA2D7AE>. >> >> >> I did not have much time lately and have no clue what I can do from this point forward. >> >> >> Denny >> >> >> On 2024-10-22 04:48, Roger Dingledine wrote: >> >> Hi folks! We're hunting down a mystery where two of our big university relays are having troubles reaching the Tor directory authorities: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/86 Can you check to see if your relay is in a similar situation? In particular, the situation to look for is "Tor process is still running fine from your perspective, but, relay-search (https:// atlas.torproject.org/) says you are no longer running." If your relay is in this situation, the next step is to check your Tor logs, try to rule out other issues like firewall rules on your side, and then (if you're able) to start exploring traceroutes to the directory authority IP addresses vs other addresses. If you need more direct help, we can help you debug or answer other questions on #tor-relays on IRC. Thanks, -- Roger _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi- bin/mailman/listinfo/tor-relays >> >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 1

Next Tor Relay Operator meetup - October 26th, 2024 at 1900 UTC
by gus 27 Oct '24

27 Oct '24

Dear operators, Save the date: the next Tor Relay Operator will happen Saturday, October 26th, 2024 at 19.00 UTC[1]! We're still working on the agenda for this meetup, however feel free to add your topics directly to the gitlab issue below or use the tor-relays mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/100. ## Agenda 1. Announcements 2. Network Health updates - New proposal: Framework for running Tor Network Health investigations https://gitlab.torproject.org/tpo/community/policies/-/issues/25 3. OTF relay operator survey summary/presentation 4. Osservatorio Nessuno presentation - https://osservatorionessuno.org/ 5. Questions & Answers ## How to join us Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: Saturday, October 26th, 2024 - 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. cheers, Gus [1] If you're confused about UTC and your timezone, @anarcat maintains a cool project called undertime - https://gitlab.com/anarcat/undertime -- The Tor Project Community Team Lead

3 4

DDOS mitigation with nftables
by Top 25 Oct '24

25 Oct '24

Hi all, My tor relays[1] traffic decreased a lot and I think this *might* be connected to some kind of DDOS attack. So I wanted to use this situation to set up some DDOS protection. For that I stumbled upon Enkidus tor DDOS mitigation script. [2] However, this script is made for `iptables`, not `nftables`. I use `firewalld` with `nftables` on my system, since this seems to be the new default. [3] I don't really know that much about firewalls, so this situation overwhelms me a bit. In the README of Enkidus rules it says: > Practically all linux systems come with iptables or more recently with nftables which basically does the same and more. So you won't need to install iptables. Just type iptables -V . If you see a version, you have it. The same with ipset . An ipset -v will do the job. In some rare cases you may not have ipset installed and installing it is as simple as apt-get ipset or yum install ipset or... This seems to imply that the script should work fine with `nftables` as well. This is also what Enkidu seems to state in a relevant gitlab issue: [4] > nftables interprets all the iptables rules just fine so the provided scripts will work regardless of which one you have. But it's not true! The script failed on my server, complaining that the `iptables` command couldn't be found (and no rules had been applied). So how can I apply proper DDOS protection firewall rules whilst using `nftables`? Is there some easy way to modify the script to make it work? Kind regards Top [1]: https://metrics.torproject.org/rs.html#search/toptor [2]: https://github.com/Enkidu-6/tor-ddos [3]: https://wiki.debian.org/nftables [4]: https://gitlab.torproject.org/tpo/community/support/-/issues/40093

6 8

Botnet targeting Tor relays
by anon＠kai.sx 25 Oct '24

25 Oct '24

Hello, I run several Linux root servers, spread over several providers, some of which serve as Tor relays. For a few weeks now I have been observing massive brute force attempts via SSH from hundreds of sources around the world. However, only the Tor relays are affected, the rest of the servers are not. Are other relay operators also observing something like this? Is there currently a botnet targeting Tor relays? Best, Kai.

7 7

Re: [tor-relays] Please check if your relay has fallen out of the consensus
by denny.obreham＠a-n-o-n-y-m-e.net 23 Oct '24

23 Oct '24

I still haven't found a solution to my problem I stated earlier in my email with the subject "Exit relay not in consensus" [1]https://lists.torproject.org/pipermail/tor-relays/2024-October/02189 9.html The most helpful answers were from [2]Sebastian and [3]George. I contacted the ASN but never received a response. My ISP was useless as they just repeated "We don't block traffic." As of today, the server is still active and running. You can't find it in the metrics but it is still in the [4]consensus. I did not have much time lately and have no clue what I can do from this point forward. Denny On 2024-10-22 04:48, Roger Dingledine wrote: Hi folks! We're hunting down a mystery where two of our big university relays are having troubles reaching the Tor directory authorities: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/86 Can you check to see if your relay is in a similar situation? In particular, the situation to look for is "Tor process is still running fine from your perspective, but, relay-search (https://atlas.torproject.org/) says you are no longer running." If your relay is in this situation, the next step is to check your Tor logs, try to rule out other issues like firewall rules on your side, and then (if you're able) to start exploring traceroutes to the directory authority IP addresses vs other addresses. If you need more direct help, we can help you debug or answer other questions on #tor-relays on IRC. Thanks, --Roger _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Tor-Podcast about Tor-Messaging
by lists＠for-privacy.net 20 Oct '24

20 Oct '24

On Saturday, 19 October 2024 20:17 David Adam wrote: People are crying in the Tor forum that you have to register with an (anonymous) email. Expressions are used like: Tor Project is dictatorship. And then redshit links? OPSEC please, use frontents: https://github.com/libreddit/libreddit-instances/blob/master/instances.md Onion or clearnet + > /r/Spot_On_Encryption/comments1g7ejidtormessaging_introducing_reflectors_exitrelay/ For all the other centralized cloudflared nonsense: https://github.com/mendel5/alternative-front-ends -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

Tor Relay Operator Community Health - Final report (June 2024)
by gus 18 Oct '24

18 Oct '24

Hello, I wanted to share the "Tor Relay Operator Community Health - Final Project report" (June 2024) made by Ana and Victoria. You can access the report via these links: - Main report: https://www.sr2.uk/reports/2024-TorRelayOperatorCommunityHealth.pdf - Mirror: https://gitlab.torproject.org/-/project/60/uploads/846d7d1816aee92fd2ee283b… best, Gus -- The Tor Project Community Team Lead

3 2

[proposal] Framework for running Tor Network Health investigations
by gus 16 Oct '24

16 Oct '24

Dear Tor relay operators, Inspired by the Berkeley Protocol on Digital Open Source Investigations, Network Health Team and Community Team has developed a framework for conducting Network Health investigations. This proposal provides clear guidelines for conducting ethically sensitive investigations transparently, responsibly, and in a way that upholds the trust of the Tor user base and wider internet freedom community. You can read and comment on this proposal here: https://gitlab.torproject.org/tpo/community/policies/-/issues/25 Alternatively, you can read the full text below. Gus ``` * Filename: 101-running-network-health-investigations.md * Title: Framework for running Tor Network Health investigations * Author: Gus - gus at torproject.org, GeKo - gk at torproject.org * Created: 2024-10-15 * Status: Draft ``` ## Overview This proposal outlines a framework for conducting open source investigations of Tor Network Health related events and actors that potentially harm Tor users or the Tor network, such as denial-of-service attacks or malicious relay operators. Investigations of other types of network incidents, like censorship events, are out of scope of this proposal, even though they might want to follow the framework outlined here as well. Inspired by the Berkeley Protocol on Digital Open Source Investigations [1] (hereafter: Berkeley Protocol), but adapted to the needs of the Tor Community, this proposal provides clear guidelines for conducting ethically sensitive investigations transparently, responsibly, and in a way that upholds the trust of the Tor user base and wider internet freedom community. ## Motivation It is easy to contribute to the Tor network by setting up and running relays. While this low threshold is good for growing the network it, unfortunately, makes it easy as well for malicious actors trying to harm Tor users or the network. Using publicly accessible data and open-source resources empowers the Network Health team and open-source investigators to actively protect the Tor network against such malicious actors. However, thus far there are no guidelines on how to do such investigations in an ethical, reliable and reproducible manner which might prevent volunteers from looking closer at the Tor network out of fear they might do something wrong or harm users or the Tor Project. This proposal is meant to resolve that issue, encouraging interested volunteers to stay vigilant and help protecting the Tor network and its users. At the same time, it aims at providing transparency into how we at the Tor Project use publicly available data during network health investigations ourselves, as we follow the framework developed below as well. ## Framework The framework outlined in this proposal is following the open source investigation cycle as developed in Chapter 6 of the Berkeley Protocol, concluding with a section about guidelines for reporting the findings safely to the Tor Project, so we can take action if needed. The individual stages of the investigation process will be adapted to the Tor context while following the methodological, professional, and ethical principles collected in Chapter 2 of the Berkeley Protocol. Those principles are in particular important as advancing human rights is at the core of Tor's mission. The framework below does not address any security or legal concerns that could arise from doing open source investigations into network incidents or actors. In particular, if the planned investigation might result in danger or harm (be it physical, legal, or otherwise) to yourself or a third party, we urge you to additionally consult the legal and security sections of the Berkeley Protocol first for advice and proper planning of the investigation before it starts. Finally, keep in mind that investigators must adhere to the Tor Project's [Community Policies](https://community.torproject.org/policies). For instance, investigators must respect relay operators' human rights and privacy rights conventions as described in the [evalution criteria for solution to combat malicious relays](https://community.torproject.org/policies/relays/evaluation-criteri…. ## Table of Contents 1. Searching and Monitoring 2. Preliminary assessment 3. Collection 4. Preservation 5. Verification 6. Analysis 7. Reporting ### 1. Searching and Monitoring 1.1. When searching for information and monitoring sources, investigators need to be aware of biases, both their own and those inherent in information online, which might taint the results. Developing and deploying several working hypotheses, which are guiding the search and monitoring efforts, is helping with biases but is not a panacea. Ultimately, it's crucial to be aware of potential biases involved in investigative work and countering them e.g. by broadening and diversifying search and monitoring efforts. 1.2. Besides useful external tools, like regular search engines or specialized ones (e.g., https://shodan.io/) investigators can deploy a collection of tools developed and maintained by the Tor Project to look into network anomalies and bad relay behavior. These tools can be found on the [Network Health GitLab repository](https://gitlab.torproject.org/tpo/network-health/). It is recommended to avoid rewriting tools that already exist, for example, a Tor exit scanner to spot machine-in-the-middle (MITM) attacks. Instead please contribute to the code that's actively developed. In case you're working on innovative open-source methods to detect malicious actors and publishing them could tip attackers, please contact bad-relays(a)lists.torproject.org so we can think about ways to use those methods while not giving attackers an even larger advantage in the bad relay arms race.[2] 1.3. Running scanners is important to keep the network healthy, but be mindful that this is putting strain on the network and the data you are looking for might already be available by other means. 1.4. As a public network, the Tor network already provides relay information such as relays IP addresses, ISPs, operating systems, fingerprints, Tor versions, and more. Investigators can query or consult this data as long as it does not disrupt relay operations or compromise the privacy of Tor users. Such publicly accessible network information is available via Tor Metrics and Onionoo. To learn more, refer to the Onionoo[3] and Tor Metrics sources[4] documentation. Moreover, there are tools available as well, like OrNetStats[5], that build upon those sources providing further insight into the network and its relays. 1.5. Moreover, as a transparent and open source project we provide public analyses and investigations of a lot of previous and current incidents in our [bug tracker](https://gitlab.torproject.org/tpo). Please consult that issue tracker as well to avoid duplicated work or false positives. For instance, sometimes there are some DNS resolution issues at exit nodes preventing users from reaching a website. We are aware of that as we are continuously scanning for that problem and dealing with affected exit nodes on a regular basis. 1.6. It must be acknowledged that legit investigations into malicious activities and bad relays may extend beyond using open-source data. Other methodologies and strategies for gathering information, like whistleblowing or using a relay's MetricsPort[6], are out of scope of this framework. 1.7. Finally, it is important to highlight that running modified Tor software or deploying offensive hacking techniques against relays or the Tor network which could harm users, relay operators and the Tor network itself won't be considered part of an open-source investigation under this framework. Rather, those actions will be considered a malicious activity. ### 2. Preliminary assessment 2.1. As searching and monitoring efforts lead to more and more results it is important to make a preliminary assessment of them early on to avoid over-collection. Over-collection is not just problematic because it will make the analysis process slower and more difficult: there are more results to analyze, more storage used and needed, etc. The risks of leaking information or infringing on rights to privacy of individuals are rising as well. 2.2. Similarly to the search and monitoring efforts, assessing the results through the lens of hypotheses is important as they help to focus on the evidence and avoid speculation. 2.3. During the assessment of results make sure they are relevant, reliable and safe to collect. If there is no risk of results being removed from the internet then their collection is not needed either. ### 3. Collection 3.1. Data collected close to the event under investigation may produce better results. For example, tracking IP addresses involved in a DDoS attacks might not be useful after a long period of time as the attackers' infrastructure might have been reassigned to a new customer. 3.2. As the investigation progresses and new evidence shows up, older, previously collected data might not be needed anymore. Please consider deleting it for the same reasons as stated in section 2.1. above. 3.3. Apart from collecting relevant content itself, it is important to save associated metadata as well in order for other investigators to more easily reproduce the investigation's findings and double-check used source material: URLs of the content, the time when it was accessed, source of a website in question, and anything else that helps to explain the context of the capture/collection should be stored, too. 3.4. In cases where malicious content, such as injected JavaScript, is identified during the scanning of exit nodes, it is crucial to capture and archive the website’s source code for both analysis and as evidence of a bad exit relay. ### 4. Preservation 4.1. Preserving the collected content is essential in network health investigations because the information can change, disappear, or be altered over time, making it unreliable and unusable for the investigation. To ensure the integrity of the data, network health investigators must follow preservation principles, based on archivist standards, as outlined in the Berkeley Protocol (section 6D). These principles include authenticity, availability, identity (keeping track of the origin and nature of the evidence), persistence, renderability, and understandability. 4.2. The decentralized and dynamic nature of the Tor network makes collecting and preserving public relay information a significant challenge. The network changes as relays join or leave, making historical data collection and preservation essential for investigations. For example, relay information is only available on the Tor Metrics website for one week before it is archived and removed from the relay search portal. To ensure access to historical relay information, investigators need to download relay descriptors from [CollecTor](https://metrics.torproject.org/collector.html). 4.3. Tools like archive.today and the Internet Archive (web.archive.org) are useful for capturing and publicly preserving snapshots of digital content, such as relay information, websites, social media content, and other online information that needs to be collected during an investigation. For a private archive collection, see the [ArchiveBox project](https://github.com/ArchiveBox/ArchiveBox). 4.4. When using open source tools to monitor the network, it is important to preserve the results. This includes maintaining logs with metadata such as timestamps, relay fingerprints, targeted URLs and other information like errors. Trusted services like archive.today or the Internet Archive should be used to preserve the original version of the website. 4.5. Investigators must maintain both evidentiary and working copies of collected digital content. An evidentiary copy is a preserved, unaltered version of the original evidence, used to maintain the authenticity of the original content. Working copies can be created for analysis, allowing changes in format or structure without compromising the integrity of the original data. 4.6. Investigators should regularly back up both evidentiary and working copies to secure storage systems, ensuring that data is not lost or corrupted during the investigation process. Please note that while relay descriptors are important for verification and analysis, they can be re-downloaded from the Tor Metrics website, so backing up this data is not needed. ### 5. Verification 5.1. Verification is a process to ensure the accuracy and validity of information collected during network health investigations. Verification can be done using closed and confidential sources or based exclusively on open sources. Without using a verification method, the information collected may be invalid or unreliable for detecting and removing bad relays. (Verification can be split into three key methods: source analysis, technical and investigative analysis.) 5.2. Investigators must evaluate the credibility and impartiality of the source from which the evidence originates. This includes verifying whether the output from open source tools, social media or websites are reliable. 5.3. Information should be cross-verified by consulting other sources to avoid relying on non validated, manipulated, biased or outdated data. Please be aware that some relay information displayed on the Tor Metrics website are not validated, for example, operator's contact information. 5.4. When verifying collected information, network health investigators should begin by looking for unique or distinguishing features. Such features might include groups of relays joining or leaving the network from a particular Autonomous System (AS), new relay operating in an obscure or popular AS, similarities and other patterns. These identification methods rely on searching and monitoring the Tor network activity. 5.5. While geolocation can be a useful tool in network health investigations and analysis, it is important to remember that the geolocation of Tor relays is often inaccurate. This data must be cross-verified with other IP geolocation databases to ensure reliability. 5.6. Investigators should evaluate the information collected for internal consistency during the verification process. This helps determine whether the information is consistent and coherent, and aligns with itself, ensuring its credibility on its own terms. ### 6. Analysis 6.1. Be mindful that a network health analysis might find false-positives. There are a number of possible reasons for that. Among other things: - the data from Tor Metrics isn't always reliable, and what could initially appear as an action of a malicious actor could actually be the result of a glitch in the Metrics database or other network events, like a denial-of-service attack or a major Tor version upgrade. Please double check if Tor Metrics services (Metrics website, relay-search, Onionoo, etc) status are/were healthy and accurate at the time of the incident. - properly analyzing scanning results can be tricky. During an anomaly investigation, you may discover new and intriguing censorship facts, where exit nodes seem to mess with user traffic resulting in blocked websites. Yet, the underlying problem is that they are just using [the DNS resolvers of their ISP](https://gitlab.torproject.org/tpo/network-health/team/-/issues/92) or the blocking of websites is done even further upstream. - Tor has location-biases that might impact the analysis. For instance, when investigating bandwidth related anomalies in the network or outright attacks it might just look like some relays are involved based on bandwidth scanner data. However, that might in fact be related to the still existing location-dependency of our bandwidth scanning efforts instead. 6.2. When starting the analysis keep in mind that it might be useful to translate, aggregate or reformat collected material so that it's easier to process with tools planned to be deployed. For instance, it is not uncommon to change the format of collected information to make it more easily searchable. 6.3. If any of your collected data is at risk of getting altered, lost or destroyed during an analysis it is advisable to use a working copy instead. That way it is possible to re-do the analysis with the same data later on, for instance with a different set of tools that might produce better results. See items 4.5. and 4.6. 6.4. There are many open source tools and services available to assist with your data analysis. As the Network Health Team needs to verify findings without the need to buy or purchase any product, it is important to prioritize platforms and/or products that do not require the purchase of a license to access the results. 6.5. Shifting the focus from 'who' to 'how' an anomaly or attack is happening may yield more valuable insights. In general, attackers have a _modus operandi_. Making a profile of a potential attacker, including their resources and techniques, can significantly help and support your analysis. 6.6. During the analysis investigators may be able to identify attacks such as Sybil, MITM, (distributed) denial-of-service, impersonation of relay operators, DNS poisoning, and social engineering (for example, Tor relay MyFamily evasion) attacks. A list of harmful behaviors can be found in [Criteria for rejecting bad relays](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Crite… and also on [Network Health blog posts](https://blog.torproject.org/malicious-relays-health-tor-network/). ### 7. Reporting 7.1. As said in 6.6, the canonical definition and criteria for bad relays in the Tor network are established and followed by the [Criteria for rejecting bad relays](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Crite… document. However, if you've observed a behavior that you may consider malicious and can cause harm to Tor users or to the network, but is not covered by the criteria, please file a ticket on [GitLab](https://gitlab.torproject.org/tpo/network-health/team). Make sure the ticket is confidential[7] if there is a risk of tipping off an attacker (see 7.7.). 7.2. If investigators detect relays with one of the described issues or behaviors from the Criteria for rejecting bad relays, please report them with a detailed description to our bad relays mailing list (bad-relays(a)lists.torproject.org) including: - The relay's IP address or fingerprint. The fingerprint is a forty-character hex string such as 203933ED4E55EF8A3C3518427D1A1ED6A4CC285E. - What kind of behavior did you see and when? - Any additional information we'll need to reproduce the issue. 7.3. It is better to report attacks earlier than later, as attackers might turn them on and off to avoid the risk of detection. Waiting too long before getting back to us might make it therefore harder or outright impossible to replicate your findings. 7.4. Without replicable findings, the Network Health Team is unable to reject relays. However, we'd like to hear your results nevertheless, as we might have additional information or did our own investigation already that could help reproducing them. 7.5. When reporting to us, investigators don't need to identify themselves by their legal names. Pseudonyms and anonymous tips are welcome. 7.6. Writing a blog post or a research paper about your findings is very much welcomed. However, please coordinate the disclosure part with us first, so that the risk and potential harm to our users is minimized. 7.7. Don't tip off the attacker. While much of the data on suspicious relay activity is public, putting together all the pieces of an investigation should be done discretely. Revealing publicly an investigation result could inadvertently inform the attacker, helping them to evade future detection. 7.8. Additionally in the case of bridges, investigators must be careful on not publicly revealing the bridges' IP addresses. Revealing publicly the IP addresses of bridges without consulting the Network Health Team might be considered as malicious intent. ## References [1] Berkeley Protocol on Digital Open Source Investigations (2022) - https://www.ohchr.org/en/publications/policy-and-methodological-publication… [2] [tor-talk] Why make bad-relays a closed mailing list? (2014) - https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html [3] Onionoo documentation - https://metrics.torproject.org/onionoo.html [4] Metrics sources documentation - https://metrics.torproject.org/sources.html [5] OrNetStats - https://nusenu.github.io/OrNetStats/ [6] MetricsPort - https://support.torproject.org/glossary/metrics-port/ [7] Confidential issues in GitLab - https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html -- The Tor Project Community Team Lead

1 0

Decommissioning a FallbackDir node (punki)
by Osservatorio Nessuno 09 Oct '24

09 Oct '24

Hi there, sadly after almost 6 years of good and honest service, our exit node punki[1] will be turned off. The provider is powering off the infrastructure where it is hosted, and has offered no viable alternative. We are writing this email in advance, since the node is in the FallbackDir list and embedded in Tor. The cluster will be powered off on 25th November. punki E43244684E0C924EC082B8ECC735FAF2F8CF1C45 Cheers Giulio [1] - https://metrics.torproject.org/rs.html#details/E43244684E0C924EC082B8ECC735…

3 6

Re: [tor-relays] Exit relay not in consensus
by denny.obreham＠a-n-o-n-y-m-e.net 06 Oct '24

06 Oct '24

I tried changing the exit and OR ports, I tried setting CircuitBuildTimeout to 300, and my ISP keep assuring me they don't block any port, ever. Some DirAuth still cannot connect with me. I have about 20 exit relays spread across 11 ISPs, including 4 with this ISP (each in a different country). They are all built with the same setup. This particular Tor instance has been working fine for months now. I don't understand what more I can do. Everything is OK on my side, except for an "It seems like we are not in the cached consensus." line appearing in the log once in a while. It's the DirAuth that somehow cannot reach me, apparently blocked by some proxy server in the middle. What more can I do? Do I just abandon this server and IP address because it is somehow blacklisted by I don't know who? Denny On 2024-10-03 13:06, boldsuck via tor-relays wrote: On Wednesday, 2 October 2024 21:24 Sebastian Hahn wrote: On 2. Oct 2024, at 09:05, George Hartley via tor-relays <tor-relays(a)lists.torproject.org> wrote: It could be that your provider has throttled you temporarily. I don't think so, I get that message on a dedicated 10 GbE link with little to no use except for the exit relay on it. Also, if his relay publishes it's descriptor, then why Metrics won't reflect that? It should show it as online, as you don't need IPv6 to be reachable to get the online flag. it looks like your upstream is maliciously messing with your traffic. I am noticing a distinct difference between two traces, one directly from my diraut's IPv4, another from a different host on the same network: A few years ago, Roger emailed me that he could not reach a service @ mit.edu (ASN3) via my exit. I had 2 exits at the same provider with same torrc, network config, IPtables, etc. One had "mystery null routes between Tor relays." https://gitlab.torproject.org/tpo/core/tor/-/issues/40357 I then switched to a different exit port and the problem was solved. -- â°_â¯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Exit relay not in consensus
by denny.obreham＠a-n-o-n-y-m-e.net 04 Oct '24

04 Oct '24

Before my last restart 6 hours ago you get a series of messages like these: ``` Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 81 v3 connections; initiated 0 and received 341 v4 connections; initiated 38535 and received 87986 v5 connections. 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. Heartbeat: It seems like we are not in the cached consensus. Heartbeat: Tor's uptime is 2 days 18:00 hours, with 185 circuits open. I've sent 41.52 GB and received 55.06 GB. I've received 105529 connections on IPv4 and 0 on IPv6. I've made 46384 connections with IPv4 and 0 with IPv6. While not bootstrapping, fetched this many bytes: 53988798 (server descriptor fetch); 11748 (server descriptor upload); 3201890 (consensus network-status fetch); 548826 (microdescriptor fetch) Circuit handshake stats since last time: 0/0 TAP, 2/2 NTor. ``` After my last restart I have: ``` Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Read configuration file "/etc/tor/torrc". Based on detected system memory, MaxMemInQueues is set to 4440 MB. You can override this by setting MaxMemInQueues by hand. Opening Control listener on 127.0.0.1:9051 Opened Control listener connection (ready) on 127.0.0.1:9051 Opening OR listener on 156.67.111.146:443 Opened OR listener connection (ready) on 156.67.111.146:443 [...] Bootstrapped 5% (conn): Connecting to a relay Opening Control listener on /run/tor/control Opened Control listener connection (ready) on /run/tor/control Self-testing indicates your ORPort 156.67.111.146:443 is reachable from the outside. Excellent. Publishing server descriptor. Bootstrapped 10% (conn_done): Connected to a relay Bootstrapped 14% (handshake): Handshaking with a relay Bootstrapped 15% (handshake_done): Handshake with a relay done Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Bootstrapped 95% (circuit_create): Establishing a Tor circuit Bootstrapped 100% (done): Done Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes. Performing bandwidth self-test...done. ``` I can confirm that the IPv6 address is not reachable for an unknown reason. The IPv6 address and flag have been removed from the torrc file to correct the problem and don't appear in the log at restart, as shown above. IPv6 should be completely ignored by the DirAuth. Denny On 2024-10-01 08:06, George Hartley via tor-relays wrote: Hi, looks like the DirAuth's think that your relay is unreachable, and so your descriptor isn't published, so your flags are not updated, this would explain the lack of change in flags. Port 443 on 156.67.111.146 is open for me, can't test IPv6 as I have disabled it through my modem and kernel command line. Can you attach your tor log file? You can also adjust the log verbosity of certain "domains" within Tor like so: [1]https://2019.www.torproject.org/docs/tor-manual.html.en#Log Please let us know what you find. Thanks, George On Tuesday, October 1st, 2024 at 1:40 PM, denny.obreham(a)a-n-o-n-y-m-e.net <denny.obreham(a)a-n-o-n-y-m-e.net> wrote: My exit relay which has been running for months without a problem has not been in the cached consensus for days now. https://consensus-health.torproject.org/consensus-health.html?#7BDDE 0E7607A5F49578768F44CD721793FA2D7AE After investigating, I thought the reason was that the IPv6 wasn't reachable anymore. It happened once before with another relay. Seems to be a problem with my ISP. Anyway, I just remove the ORPort IPv6 address and IPv6Exit flag from the torrc file and everything should return to normal. It has been days and it doesn't. Reloaded and restarted more than once since then. What I don't understand is that the OR IPv6 address and the ReachableIPv6 flag are still listed in the metrics. h ttps://metrics.torproject.org/rs.html#details/7BDDE0E7607A5F49578768 F44CD721793FA2D7AE Any help would be appreciated. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

5 4

turning off BridgeDB and the future of moat bridges
by meskio 03 Oct '24

03 Oct '24

Hello, tl;rd: moat bridges are not distributed anymore. Don't shut them down as they are still used but don't create new bridges with "BridgeDistribution moat". BridgeDB has being our bridge distribution system since 2007. For years we have being developed a replacement of BridgeDB[0] called rdsys[1]. And finally yesterday we replaced the last distributors missing in rdsys (email, https and moat) and turned off BridgeDB. The only visible difference is that captchas has disappeared from https://bridges.torproject.org and requesting bridges in Tor Browser gives you a static captcha and doesn't even verify if the answer is correct (until we have the time to update TB to don't request the captcha[2]. The mayor difference for bridge operators is that we don't distribute "moat" bridges anymore. We have merged circumvention settings and moat and now is one distributor handing over "settings" bridges. For now we are going to keep the existing "moat" bridges assigned to "moat" and don't distribute them, so users that have one of those bridges can keep using them without risk of censors finding it. New bridges will not be assigned automatically the moat distributor, only existing bridges or bridges with "BridgeDistribution moat" will stay in this distributor. We plan to watch the usage of moat bridges and evaluate moving them to another distributor depending on the usage[3]. Thank you for running bridges. [0] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42086 [3] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

3 6

Docker Snowflake Proxy Multiple IPs
by admin＠likogan.dev 02 Oct '24

02 Oct '24

Hello, I'm writing because I want to run a snowflake proxy in a docker container on a server with two IP addresses; the primary public IP I want the snowflake proxy hosted on, and a public anycast IP that's shared between other servers. I'm concerned the snowflake proxy may try listening on the anycast IP, which will cause problems as this IP is shared between a few servers! >From my understanding, a snowflake proxy should use the "host" network option with docker. How can I specify which IP address to use with this option? Thanks, Likogan

2 1

Exit relay not in consensus
by denny.obreham＠a-n-o-n-y-m-e.net 01 Oct '24

01 Oct '24

My exit relay which has been running for months without a problem has not been in the cached consensus for days now. https://consensus-health.torproject.org/consensus-health.html?#7BDDE0E7 607A5F49578768F44CD721793FA2D7AE After investigating, I thought the reason was that the IPv6 wasn't reachable anymore. It happened once before with another relay. Seems to be a problem with my ISP. Anyway, I just remove the ORPort IPv6 address and IPv6Exit flag from the torrc file and everything should return to normal. It has been days and it doesn't. Reloaded and restarted more than once since then. What I don't understand is that the OR IPv6 address and the ReachableIPv6 flag are still listed in the metrics. https://metrics.torproject.org/rs.html#details/7BDDE0E7607A5F49578768F4 4CD721793FA2D7AE Any help would be appreciated.

2 1

relays and CUPS vulnerabilities
by George 01 Oct '24

01 Oct '24

There are some very significant recent CVEs out for CUPS, the unix printing system. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups It's an ideal moment to remind relay operators that a Tor node, relay or bridge, should be a single-purpose internet server. Running alternate internet services is a bad idea. The node should have the minimum packages installed for the purpose of running a node. More packages means more possible vulnerabilities. Needless to say, a CUPS server listening on 631/tcp or 631/udp while providing Tor access is a bad idea. g -- 43C2 85B0 41B6 4AC1 0E02 2767 7092 AEB3 40B0 C804

3 3

Relay disconnect & offline on IP change
by Tor Relay Net Ops 27 Sep '24

27 Sep '24

Greetings fellow relay operators! I'm currently running a tor relay on a dynamic IP Address connection, usually my ISP gives me a new address every day or so- Lately [for the past like week or so- /can't remember when it started happening/], I have to manually restart it when my WAN IP Address changes; to get the relay back online- (systemctl restart tor@default) Is there a way to not manually restart tor (besides running a cron script to do so) Below are my tor configuration: Tor 0.4.8.12 on Linux Debian GNU/Linux 12 (bookworm) /etc/tor/torrc Nickname hadleyJamison ContactInfo url:darrenofficial.com proof:dns-rsa ciissversion:2mailto:tor-relay-netops@darrenofficial.com ORPort 88 IPv4Only ExitRelay 0 SocksPort 0 ControlPort 9051 CookieAuthentication 1 RelayBandwidthRate 69 MBits RelayBandwidthBurst 69 MBits -darren

6 6

Dear OBFS4 bridge operators, please enable timing and packet-size obfuscations to help clients facing timing analysis attacks.
by George Hartley 25 Sep '24

25 Sep '24

Hello Tor community, this e-mail applies to you if you are running an obfs4 (now known under the name lyrebird) bridge or want to do so in the future. Some recent posts on this list has shown that traffic timing analysis can be used to locate a users or onion services guard nodes or bridges. This is not really something new. For bridge users, there is a way to try to protect themselves against this, but your bridge configuration must support it. By enabling iat-mode on your obfs4 /lyrebird bridge, then maybe DPI (Deep Packet Inspection) hardware can sometimes be defeated either entirely, or at least the process of tracking users can be slowed down. OBFS4/Lyrebird support two times of traffic obfuscation: > ServerTransportOptions obfs4 iat-mode=1 This will make your bridge send MTU sized packets, in order to make true packet size analysis harder. There is also what the author of obfs4/Lyrebird called "paranoid mode": > ServerTransportOptions obfs4 iat-mode=2 For each write, a variable length packet will be sent, which will result in both making true packet size and round trip time analysis harder. If your bridge is distributed by BridgeDB, the next time someone receives a batch of bridges with your bridge in it, the bridge-line will have the iat-mode variable set to the one you set on your bridge server. Your bridge will still work even if you enable these defenses and a user chooses to set iat-mode to 0 in his bridge line. There is a small performance penalty for both mode 1 and 2, but nothing very severe. I believe this, along with Vanguards, and so on, is needed to keep users and services somewhat secure. Let me know what you think. - George

5 8

Looking for a ipv4 block and strategy
by Osservatorio Nessuno 25 Sep '24

25 Sep '24

Hi everyone, our organization is working to add more physical nodes, in our little Italy headquarter[1]. We have reached an agreement with one of the available fiber reseller there, where we will pay for L2 transport to a datacenter, where we will buy our uplink separately and announce and route our public IP addresses independently. It is actually a very nice opportunity to remove a point of trust in the chain and get back control to a part of infrastructure that is usually delegated to commercial ISP. Similarly, as this list knows well, by announcing our IPs we will be the direct recipients of any abuse. We have now two options: either look for someone willing to lease a /24 to Tor operators, which is not an easy task since the block reputation will be tainted and depreciate the block. We have found someone willing to, for $119/mo, but it is hard to tell how long that will last. An alternative would be to buy it, for around ~7k$ (~28-31$ per IP, via a broker). We do not have the budget for this now, but an organization member has offered to lease the money and get paid back without interest at a similar rate that a lease would cost (around $1k year). In all phases, the block will be in the org ownership. We have someone who can LIR sponsor at RIPE so we would not have other recurring expenses. Buying is more sustainable in the long-term: in around 6 years we will stop to have to pay the lease. At the same time, we will not have any chances to change those IP ever later, while in a lease, we could eventually move to other blocks. Does anybody in the community have contacts for lease or sale? Is there any foreseeable issue in sticking to the same range for the next ~10 years? Especially at the beginning, it will be unlikely that we will use even 1/4 of them, but given how the fiber infrastructure is built, we can eventually use the same announcements even for other physical locations. Thank you [1] - https://osservatorionessuno.org/blog/2024/07/we-have-a-headquarter-and-it-i…

2 2

Why I do have so often an "8" in my bridge stats?
by Toralf Förster 25 Sep '24

25 Sep '24

Never cared about this before, but isn't the "8" too often here? : $ cat ~/tmp/tor_bridge_stats i10 bridge-ips ru=264,br=16,de=16,us=16,au=8,cl=8,co=8,cz=8,dz=8,eg=8,es=8,fr=8,gb=8,gr=8,hk=8,id=8,in=8,ir=8,it=8,kr=8,lt=8,lv=8,nl=8,ph=8,sa=8,sg=8,tw=8,ua=8,ve=8 i11 bridge-ips ru=152,ir=16,cn=8,cz=8,de=8,gb=8,nl=8,pl=8,tr=8 i12 bridge-ips ru=224,by=8,cn=8,de=8,fr=8,in=8,ir=8,jp=8,nl=8,pl=8,ro=8,us=8 i13 bridge-ips de=8 i14 bridge-ips de=8,fr=8,ru=8 i15 bridge-ips de=8,ru=8 i20 bridge-ips de=8 i21 bridge-ips de=8 i22 bridge-ips ru=96,at=8,de=8,nl=8,pl=8,us=8 i23 bridge-ips ru=904,ir=48,eg=32,de=24,us=24,fr=16,ae=8,at=8,be=8,br=8,by=8,ca=8,co=8,cz=8,dz=8,fi=8,gb=8,gr=8,hk=8,hu=8,im=8,in=8,it=8,jp=8,kz=8,lv=8,ma=8,md=8,mm=8,na=8,ni=8,nl=8,pk=8,pl=8,sa=8,se=8,tm=8,tr=8,tz=8,uz=8,ve=8,ye=8,za=8 i24 bridge-ips de=8 i25 bridge-ips ru=112,ch=8,cn=8,de=8,gh=8,in=8,ir=8,ke=8,mm=8,mu=8,nl=8,tr=8,us=8 i26 bridge-ips de=8 luchs bridge-ips de=8 -- Toralf

2 3

Read/written bytes on a relay differ
by Richie 23 Sep '24

23 Sep '24

Hi everyone, nothing of real concern, but out of curiosity: since some years now i use overhead traffic on my ISP for Tor, with a small home relay burning some 3 to 4 MB/Sec. Usual middle relay plus V2Dir (and HSdir some days after last reboot). Since some weeks now, the read/written bytes differ quite significantly, and i never experieced sth like that for a relevant timespan before. Is this a sign of more "reading directory services" on the relay? (maybe short reqests and verbose replys), some new kind of attack, whatever? direct metrics-Link via https://metrics.torproject.org/rs.html#details/11FC7D9C7D8DF74326B90EC71C10… and screenie attached. Again, no big issue, just curiosity. And if its some kind of bug, i'd be happy to hand over more info. thx to everyone maintaining and running this stuff, Richie

2 1

[Important] Update on an upcoming German broadcasting story about Tor/Onion Services
by isabela fernandes 19 Sep '24

19 Sep '24

Hi Tor, I am reaching out to inform you of an upcoming news story concerning a potential deanonymization attack on Onion Services. What is happening? On September 9, 2024, The Tor Project received a press inquiry from Norddeutscher Rundfunk (NDR, part of ARD, a German public broadcaster) with a request for comment to their upcoming reporting of "investigative measures by German and international law enforcement agencies in the Tor network, in particular the localisation and deanonymisation of onion services." We complied with the outlet's deadline of September 12th and answered a series of questions. The reporter claims to have "evidence that shows that in several cases German law enforcement authorities were able to locate the Tor entry node of onion services and thus successfully deanonymise Tor users. V2 and V3 onion addresses were affected at least between Q3/2019 and Q2/2021." The reporter further claims that "law enforcement agencies used so-called timing analyses and broad and long-term monitoring of Tor nodes in data centres." As of today, The Tor Project has not been granted access to supporting documents, and has not been able to independently verify if this claim is true, if the attack took place, how it was carried out, and who was involved. In the absence of facts, it is hard for us to issue any official guidance or responsible disclosures to the Tor community, relay operators, and users at this time. We are calling for more information from you. If you have any information that can help us learn more about this alleged attack, please email security(a)torproject.org. If you want to encrypt your mail, you can get the OpenPGP public key for this address from keys.openpgp.org. Fingerprint: 835B 4E04 F6F7 4211 04C4 751A 3EF9 EF99 6604 DE41 Your assistance will help all of us take the necessary steps and precautions to keep Onion Services safe for the millions of users that rely on the protections Tor provides. Are Tor users safe? Tor users can continue to use Tor Browser to access the web securely and anonymously. Nothing that the Tor Project has learned about this incident suggests that Tor Browser was attacked or exploited. We encourage Tor Browser users and relay operators to keep software versions up to date. The reporter's questions focus on the use of onion services and .onion addresses. Which leads us to assume that the alleged attack was targeting a specific .onion site. We will continue to share updates on this email as this situation evolves. Thank you! Isabela

9 10

[warn] Error relaying cell across rendezvous; closing circuits
by Logforme 17 Sep '24

17 Sep '24

I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 Today I noticed two [warn] lines in the Tor log file that I have not seen before: [warn] Error relaying cell across rendezvous; closing circuits [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/core/or/command.c:577 (first at ../src/core/or/relay.c:343) (on Tor 0.4.8.12 ) I assume this is more of a FYI for the developers than for me as an operator. I'll keep an eye out to see if they appear more times.

1 0

Re: [tor-relays] tor-relays Digest, Vol 164, Issue 10
by Account Etheron 14 Sep '24

14 Sep '24

Your node has low Consensus Weight. Also your node is not marked as "Fast" Normal that happens between a week. Also advertised traffic is very low. https://metrics.torproject.org/rs.html#details/A00E3AAF5A24DC69740FA7A3A1C4… Low Consensus Weight (like 11) could be due to several factors: 1. *Low Bandwidth*: If your node has a limited bandwidth or is not properly configured to advertise its available bandwidth, it might get a lower weight. 2. *Unstable or Intermittent Availability*: Nodes that are frequently going offline or showing unstable behavior will have a lower consensus weight. 3. *Geolocation or Restrictions*: Certain regions or configurations may cause your node to have reduced visibility or reliability in the eyes of Tor's directory authorities. To improve the consensus weight of a Tor node: - Ensure *high uptime* and a reliable internet connection. - Advertise higher *bandwidth* if available. - Make sure your node is properly configured with the *right ports and keys*. Regards. On Sat, Sep 14, 2024 at 2:00 PM <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. Relay suddenly pushing very little traffic (Zachary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 13 Sep 2024 12:23:52 +0000 > From: Zachary <secure-communications-zachary(a)protonmail.ch> > To: "tor-relays(a)lists.torproject.org" > <tor-relays(a)lists.torproject.org> > Subject: [tor-relays] Relay suddenly pushing very little traffic > Message-ID: > > <jOspt2hq9xeYGyZ8fsFy_qO_4d_TtxrOmCJxPIPzAyF948JHR0_2saC8hGGKPkleMwcLMFcXbPVucHhRfnXLZfBjn_Wx2VYGC46r1wpqnaI=@ > protonmail.ch> > > Content-Type: text/plain; charset="utf-8" > > Hello all, > > I am the operator of relay AS11796EntryMiddle. > > This is a strategically placed relay on a 106.4 mbps internet connection > with no fluctuations in bandwidth available to it. The relay has very good > peering to major backbone providers such as Arelion which allows many > people to access it with minimal network hops, which is why I host it in > that ISP?s network. > > Over the past six months, I typically saw traffic ranging between 15 and > 70mbps. Now suddenly the relay seemingly can?t efficiently process traffic, > the advertised bandwidth has tanked, and it?s pushing virtually no data. > > I am running Tor 4.8.12 installed from the official Tor repositories in > Ubuntu 22.04 with OR port 9001. The entire network is an EdgeRouter plugged > into WAN and then a firewall rule letting traffic hit the host for Tor. The > relay is indeed working, but everyday it seems that less and less traffic > is getting through (this is very evident on Tor metrics.) TCP connections > are not exhausted so I?m pretty confused what?s going on. > > Any thoughts? Not trying to waste anyone?s time just don?t want this relay > to go to waste. > > Thanks, > Zachary >

1 0

Relay suddenly pushing very little traffic
by Zachary 13 Sep '24

13 Sep '24

Hello all, I am the operator of relay AS11796EntryMiddle. This is a strategically placed relay on a 106.4 mbps internet connection with no fluctuations in bandwidth available to it. The relay has very good peering to major backbone providers such as Arelion which allows many people to access it with minimal network hops, which is why I host it in that ISP’s network. Over the past six months, I typically saw traffic ranging between 15 and 70mbps. Now suddenly the relay seemingly can’t efficiently process traffic, the advertised bandwidth has tanked, and it’s pushing virtually no data. I am running Tor 4.8.12 installed from the official Tor repositories in Ubuntu 22.04 with OR port 9001. The entire network is an EdgeRouter plugged into WAN and then a firewall rule letting traffic hit the host for Tor. The relay is indeed working, but everyday it seems that less and less traffic is getting through (this is very evident on Tor metrics.) TCP connections are not exhausted so I’m pretty confused what’s going on. Any thoughts? Not trying to waste anyone’s time just don’t want this relay to go to waste. Thanks, Zachary

1 0

Supporting TOR: Seeking Affordable and Reliable Server Providers in Eastern Europe
by coal_norm_0v＠icloud.com 12 Sep '24

12 Sep '24

Hello everyone, I’ve been a fan of Tor for many years now, and my affinity for anonymity naturally extends to other interests, such as Monero… 😉 I’ve successfully rallied like-minded individuals who have generously supported our cause through various grants, and we’ve even received a government subsidy from the Czech Republic to promote freedom of speech in oppressive regimes. With a substantial sum of money at our disposal, we’ve chosen to allocate a portion to support the TOR project. Currently, we operate around 60 servers. Our main challenge, unsurprisingly, is with exit servers. Convincing providers to overlook automatic complaint notifications has proven quite tricky. From our original 30 exit nodes, we’re down to about 5—the rest had to be shifted to relay nodes. We could switch them to well-known operators like RDP.sh, but they already host a large number of exit nodes, and we prefer to encourage network diversity. We’ve initiated something akin to a cost-sharing model for enabling our servers to run exit nodes, but it hasn’t made a significant impact. We want to spend our funds wisely to support Tor. Do any of you have suggestions for good, affordable providers in less conventional locations (e.g., Eastern Europe like Poland, Hungary, Ukraine)? Thanks for any ideas, Alex https://tor.foundation

5 5

Artikel 5 e.V. - Another police raid in Germany - general assembly on Sep 21st 2024
by Artikel 5 e.V. 09 Sep '24

09 Sep '24

Hello to all list-reading entities! On Aug 16th 2024 German police considered it once again appropriate to raid the home&office at the registered address of our organization. The first raid was 2017. There are obviously still people working in German law enforcement today, who think that harassing a node-operator NGO would somehow lead to the de-anonymization of individual tor users. At least that is what they claim in the paperwork. As with the first time, the raid team was fortunately a bit better educated and acted significantly more reasonable than the non-technical people applying for the raid and the judge signing it off. So again, no hardware was seized. Apart from one burnt (middle relay) node and some billing paperwork for the exit node this was all about, the team left the house after one and a half hours with mostly empty hands. We intend to legally challenge the search warrant to make sure that this does not happen again (but this is not what this email here is about). These were once again one and a half hours with armed police in a personal living room, threatening to de-facto kill a livelihood and software business (carrying a truckload hardware away) of an non-profit board member to force cooperation. As a consequence, I am personally no longer willing to provide my personal address&office-space as registered address for our non-profit/NGO as long as we risk more raids by running exit nodes. That is a risk I am just no longer willing to take anymore. Artikel 5 e.V. is now calling for a general assembly on Sep 21st 2024. We are looking for new board members (who take over and organize a new registered address and keep running exits) or discuss ALL alternative options. These options include "just stop running exits" or even the most drastic step of liquidating the entire organization and distribution of the remaining budget to other German organizations (that would have to qualify under our non-profit by-laws). Assembly time&location details can be found at https://artikel5ev.de/ We intend to provide a stream primarily for our members but also for interested parties who can not attend in person. The event/stream will however be in German only. Details for the stream will be made available on the website on short notice before the event starts. If you plan to attend in person, an upfront email would be appreciated, so we can pick the right room to set things up. Thank you! Regards, Gero Kühn for Artikel 5 e.V.

3 2

Next Tor Relay Operator Meetup - September 7th, 2024 at 19UTC
by gus 08 Sep '24

08 Sep '24

Hi, Save the date: the next Tor Relay Operator will happen Saturday, September 7th, 2024 at 19 UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to this pad or just reply to the mailing list: https://pad.riseup.net/p/tor-relayop-sept7th-meetup-keep ## Agenda 1. Announcements 2. 2024 Elections & Anti-censorship news 3. Network health updates - New Metrics Network Status API 4. OTF relay operator survey summary/presentation 5. Questions & Answers <add your question below> ## How to join us Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: September 7th, 2024 - 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. cheers, Gus -- The Tor Project Community Team Lead

3 5

simple instructions to the expiredkey issue, pls.?
by code9n＠pm.me 06 Sep '24

06 Sep '24

Hi, I know I should have sorted this some weeks ago but can anyone tell me a simple method of dealing with the: bullseye InRelease: The following signatures were invalid: EXPKEYSIG 74A941BA219EC810 deb.torproject.org archive signing key issue, please? Thanks.

4 4

Bridge node configurations and where to find them (semi quote)
by Alessandro Greco 31 Aug '24

31 Aug '24

Dear all, In the past, I set up a middle relay node, and today I am looking to experiment with configuring a Bridge node to support the Tor project and its community. Since this is a very sensitive task, I decided to reach out to you to ensure that the setup is correct and that the configuration does not pose any risks to users who connect. First, I will summarize the `torrc` configuration file (I have removed the ports as they differ from the standard ones): ``` BridgeRelay 1 ORPort <port> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<port> ExtORPort auto ExitPolicy reject *:* ``` I have set two limits on the connections: ``` BandwidthRate 300 MBytes # I want to determine how much bandwidth I can allocate without impacting my network usage. IPv4Only ``` As for the information settings, I have used the usual `ContactInfo` and `Nickname`. While reading the `torrc` documentation, I discovered the Sandbox feature, which is still in development. In this regard, I would like to ask whether using experimental features like this on Bridge nodes is advisable or not. Personally, I would find a feature like this very useful. Should an anti DDoS system be configured? I wanted to ask how I can further contribute to the Tor Project's research, as I have read that there are "Statistics" features that allow the collection of useful information for the developer community. I have two main questions about this: 1. Is it advisable to use experimental features or those that collect information on a Bridge node (assuming there is a difference between a Bridge, a Guard/Middle relay, and an Exit Node)? 2. If the answer to the first question is yes, what are all the features that I can include in the `torrc` file to passively support research within the Tor Project? Finally, I would like to ask what information should be kept confidential when managing a Bridge. For example, I know for sure that it is important to keep the IP address confidential to avoid the risk of being blacklisted, but are there any other pieces of information that need to be protected? To ensure that a Bridge node can be restarted on a different machine, which files need to be preserved? Are they the same as those for a standard relay (i.e., the private key), or are there additional files that need to be securely stored? Thank you for your support and guidance. Best regards, Aleff --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

3 6

Request for Tor to support armhf architecture
by Landon 30 Aug '24

30 Aug '24

I am running a Raspberry Pi Raspbian OS (debian) mini computer. Tor software does not support this hardware without me having to compile it myself for my platform. Which I don't know how to do. My specific APT error message says this: N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'https://deb.torproject.org/torproject.org bookworm InRelease' doesn't support architecture 'armhf' The Raspberry Pi is a perfect computer to run Tor because it has 8 GB RAM, is tiny, only uses a max of 25 watts of power and works great as a network server. Plus, I don't have to leave my big power hungry desktop computer on all the time to run Tor. Raspberry Pi info page: https://www.raspberrypi.com/products/raspberry-pi-5/ Landon

3 4

a couple noob questions
by observatory123 27 Aug '24

27 Aug '24

Dear fellow relay operators, I've been hosting a tor relay on a VPS (strato) for a couple days now. I've never done this before, so I have a couple of questions: - Is it normal for my relay to only use up only about 2 MB/s after nearly 5 days of uptime despite bandwidth speed tests done with speedtest-cli generally reporting significantly higher bandwidth? - Is it normal for my relay to advertise 7.37 MiB/s on its relay search page despite bandwidth speed tests done with speedtest-cli generally reporting significantly higher bandwidth? - Do I have to mark somewhere that I'm hosting the tor relay on a VPS (which means technically a company also has control over the relay)? - Is this mailing list a good place to ask these questions? Or am I reaching too many people by doing this? When I say I performed a bandwidth test, I mean I performed a bandwidth test with the speedtest-cli debian package. The test generally tells me I have about 217 MB/s download speed and 113 MB/s upload speed. The nickname of my relay is observatory123 and its fingerprint is: 45431BF8AB66C673942C1E344BB520625CE5F817 Kind regards, observatory123

8 9

Re: [tor-relays] [network-health] help metrics torpoject
by George Hartley 21 Aug '24

21 Aug '24

Hi, don't worry, a relay will be removed from metrics 7 days after you shut it down. Sincerely, George On Sunday, August 18th, 2024 at 8:49 AM, kop kop <a5654505(a)gmail.com> wrote: > Good afternoon. how can I delete an entry in https://metrics.torproject.org/rs.html#search/134 > about fargo node? > I didn’t think twice and deployed this relay from my home network and now I’m afraid of persecution from the authorities. I ask for help.

1 0

Re: [tor-relays] DDOS alerts from my provider
by eff_03675549＠posteo.se 20 Aug '24

20 Aug '24

Hi Rafo, My apologies for the late reply in your request for the code on banning tor exits into *GUARDS or middle-relays* * * * * rm ../../etc/cron.d/updateSSHkey echo "0 0 * * * root wget -P /root/scriptsremote/ https://check.torproject.org/torbulkexitlist" > ../../etc/cron.d/blacklistTORexits echo "1 1 * * * root sed 's/^/-A ufw-before-input -s /; s/$/ -j DROP/' /root/scriptsremote/torbulkexitlist" >> ../../etc/cron.d/blacklistTORexits echo "2 1 * * * root sed -i '/# End required lines/r /root/scriptsremote/torbulkexitlist' /etc/ufw/before.rules" >> ../../etc/cron.d/blacklistTORexits echo "3 1 * * * root rm /root/scriptsremote/torbulkexitlist" >> ../../etc/cron.d/blacklistTORexits apt install -y fail2ban rm ../../etc/fail2ban/jail.d/sshd.conf touch ../../etc/fail2ban/jail.d/sshd.conf echo "[sshd]" > ../../etc/fail2ban/jail.d/sshd.conf echo "enabled = true" >> ../../etc/fail2ban/jail.d/sshd.conf echo "port = 11218" >> ../../etc/fail2ban/jail.d/sshd.conf echo "filter = sshd" >> ../../etc/fail2ban/jail.d/sshd.conf echo "logpath = /var/log/auth.log" >> ../../etc/fail2ban/jail.d/sshd.conf echo "maxretry = 5" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime = 24h" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime.increment = true" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime.factor = 24" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime.maxtime = 52w" >> ../../etc/fail2ban/jail.d/sshd.conf Here I hope this is well received, Carlos. On 7/10/24 1:19 AM, god-gave-you-mouth-ears-eyes-so-enjoy(a)posteo.net wrote: > > Hi Rafo, > > > I have a pre-defined fail2ban (jail) script that does all the job of > banning any tor-EXIT -dynamically updated via cron- from attempting > access when this helps. > > This is meant for Debian, > > the synthax could do with fedora (perhaps a few code adaptation). > > let me know when this is of interest. > > > Carlos. > > On 7/8/24 7:34 PM, Rafo (r4fo.com) via tor-relays wrote: >> Hi, >> I have been running a relay for a few months now without any >> problems. But this week I’ve received 2 DDoS alerts from my provider >> (Netcup), both are ~3 gigabits. They seem to be coming from other Tor >> relays. >> I’m running an Invidious like instance on my server (which uses >> around 600 megabits) but I have a 2.5 gigabit port. So I configured >> my Tor relay to use 300-400 megabits. >> I’m not sure where that 3 gigabit of data comes from. >> I have lowered my advertised bandwidth to 100 megabits, would that be >> enough to prevent these kind of issues? >> >> >> Kind regards, >> Rafo >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- > Updated every second week. > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > xjMEZfy9NxYJKwYBBAHaRw8BAQdAManzdqpnuQkafKwGP49famHD40TRuz3tlk2S > 6x9w7afNP0d1c3QgT09ITlRFUiA8Z29kLWdhdmUteW91LW1vdXRoLWVhcnMtZXll > cy1zby1lbmpveUBwb3N0ZW8ubmV0PsKPBBMWCAA3FiEEEAD7hg5vFuAk80AxAZJk > LcbaZlUFAmX8vTcFCQATxoACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRABkmQtxtpm > VRErAQDPkO6rew8L0fv+YkObGBGL58dxZtWbELZqDjICDi5A6QD/QC4978BycOFq > ZAx/N9ihgNLRm6Sg1EUupAoaVMcDVA7OOARl/L04EgorBgEEAZdVAQUBAQdA0Xrh > XPXwikKTr7amFdFv57VCWtansLWJCnYqFAVWYmADAQgHwn4EGBYIACYWIQQQAPuG > Dm8W4CTzQDEBkmQtxtpmVQUCZfy9OAUJABPGgAIbDAAKCRABkmQtxtpmVfxdAQDL > TRwNnIeZ//Y4kahWP+WWS7qb6EmM1mCtjRc3IadSDgD+Nh1xGFt00AQtG+oMKF/J > GwnLbMda6bMdvCIXN+U1LQw= > =z8PX > -----END PGP PUBLIC KEY BLOCK----- -- PGP updated every second week : please actualize our communication every time.

2 1

DMARC helps prevent Tor-exit from being abused for email SPAM.
by boldsuck 20 Aug '24

20 Aug '24

Hi @all, I thought DMARC was unimportant for a small domain, but I played around with it a few days ago. There are some DMARC monitor sites that you can use for free & I was surprised when I saw that in 2-3 days about 1500 emails were sent via my exit subdomains. Then I set DKIM and SPF to strict adkim=s; aspf=s; and DMARC subdomain policy to reject sp=reject; Since then, emails about Tor-exits have dropped to 0 ;-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

DDOS alerts from my provider
by Rafo (r4fo.com) 20 Aug '24

20 Aug '24

Hi,I have been running a relay for a few months now without any problems. But this week I’ve received 2 DDoS alerts from my provider (Netcup), both are ~3 gigabits. They seem to be coming from other Tor relays.I’m running an Invidious like instance on my server (which uses around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor relay to use 300-400 megabits.I’m not sure where that 3 gigabit of data comes from.I have lowered my advertised bandwidth to 100 megabits, would that be enough to prevent these kind of issues?Kind regards,Rafo

6 12

An Internet backbone blocklisted my Tor server!
by Landon 20 Aug '24

20 Aug '24

TL;DR... Write down your Tor server's GATEWAY IP address. if your server goes offline, try tracerouting to your Tor server's gateway IP address as well as your Tor server's IP address! You might be surprised by what you see! And also install MTR... It is helpful!! Here's the detailed explanation on how you can perform MTR command on your computer and server https://support.gcore.com/hc/en-us/articles/19864311353105-How-to-run-MTR-o… Okay, here is what happened... Late last night I tried to log into my VPS where I am running my Tor bridge server. I was unable to connect. It seemed like my server was offline so I filed a ticket with my service provider which is GCore Labs ( https://hosting.gcorelabs.com/ ) (I've been running my Tor bridge on their server for 4 years.) However, I discovered that my server was not actually down. I was able to login to my server using VNC in the control panel. I did some network diagnostics to diagnose my network connectivity problem. Even though my server was running, it was essentially offline. I could not ping or traceroute from my server to 8.8.8.8 or 1.1.1.1. It looked like there was a network outage. I used some looking glass servers to see what was going on as well. Here was what I discovered... From the Internet, I could ping and traceroute my VPS server's gateway (which is one hop away from my server) but if I tried to ping or traceroute using my server's actual IP address then this is where it stopped working. The culprit was Cogent Communications' routers! [AS174] As soon as packets destined for my server's IP address reached Cogent's routers, they were dropped!! However, packets destined for my server's gateway went through! >From what I understand, my server's gateway is the physical machine running my VPS. How can a packet reach my server's gateway, but not reach my server? It's not like the packet was not making it from my gateway to my server. The packets were being dropped at the edge of Cogent's network [AS174]. I also ran a traceroute on Cogents own looking glass server ( https://cogentco.com/en/looking-glass ) and when I used my server's IP, it showed nothing but when I used my gateway IP it worked! Tell me how that is possible if Cogent was not blocking my server's IP address? I sent Cogent an email asking why they were blocking my server's IP address in their routers. By the time they got back to me, my server was back online and was not being blocked. They sent me an email saying that packets going to my server were routing through their network, which by that time they were. What is so interesting about my Tor server that a major network backbone blocks my IP? If you look at my Tor server's usage graphs, you can see where it is periodically offline. Look at the 6 month graph for the average number of connected clients and you will see places where it is not online. https://metrics.torproject.org/rs.html#details/4A0B065DB3CF807C6910DFEF6D9C… I bet the reason that my server periodically goes offline is because it is being blocked and not because it is actually offline! Have you ever had this happen to your server? Landon

4 3

Re: [tor-relays] [tor-dev] Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
by George Hartley 19 Aug '24

19 Aug '24

Hello, > Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Sorry, but this is just not the case from my experience - it may take a while to fetch the descriptor of the hidden service, but once a TCP connection is established, aka. the ACK packet has been received, there should be no problems with packet-loss, this is one of the core features of TCP: Retransmission on various conditions. I also hosted a hidden IRC server, as well as a Tor hidden service on my grandmothers laptop, to be able to SSH in through Tor and troubleshoot problems. Experienced no packet loss, unless a relay in the circuit suddenly went offline. If you want, I can measure packet loss from various locations (Northern Europe, East Europe, and New York, USA). Also, to improve latency and throughput, you could make the server a one hop hidden server by enabling: > HiddenServiceSingleHopMode This way the looking up the server is faster, but clients remain anonymous using a normal 3-hop circuit. I don't think we need extra code for this, you could just build your app using the programming language of your desire and use the existing network. That's what I was doing with my ~200 user IRC server, and it worked fine, even while being hosted at home at a limited uplink of 15 Mbps, which now got upgraded to 30 Mbps. Unfortunately fiber is not an option, so we have to rely on 60+ years old copper wires maintained by Telecom, I have a quite fancy industrial router with modem software and capabilities, and we still use VDSL2 17a G.Vector (ITU G.993.5). I do however own a virtual machine machine on my friends colocated server at DataWagon, they are very exit friendly, zero abuse so far, I believe they just redirect abuse mails to /dev/null or something.. lol. Anyway, point is that I never encountered packet loss, and even if, the protocol would compensate for it. This became kind of a rant while I'm at work, so if it's not that useful, Im sorry. Regards, George On Wednesday, August 14th, 2024 at 9:12 AM, Sam <alleestrasse100(a)gmail.com> wrote: > System wrote via Tor Project <noreply(a)forum.torproject.org>: > ============================================================ > > Feedback: Please submit the proposal also to tor-dev: tor-dev Info Page > ======================================================================= > > Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes > > ============================================================================================================================================= > > https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflec… > > ============================================================================================ > > > > ======================== > > ============================================================== > ============================================================== > > Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes > ============================================================================================================================================ > > > > Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | > > Hello, > > I think this belongs to this core, general, relay topic-forum, as it is also a development & community issue, request and efford, I post it here into the reddit forum for your core discussion: > > The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are developed futher to be also an Entry-Node. > > Some may remember when gnutella got hybrid with edonkey and then also with torrent, Mike Stokes from Shareaza did that. > > The idea today, 20 years later, is to add some Echo-capabilities to Tor in regard of the servers for Exit and Entry. > > Vision: Every (updated) Exit-Node is an Echo-Server - For a better Tor-Messaging. > > What does that mean? > > An Echo-Server is a server for chat-messaging to send an incomming message packet again out to all connected clients at the moment. Ping-in and Ping-Out to all. That simple, that's why it is called the Echo. Like a shout in front of a forrest, all connected users can hear and get the (encrypted) shout or message or packet back from the tree wall. > > There are 3 software applications for Echo-Servers: > > - https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener Tab) > > - https://github.com/textbrowser/smokestack (java for Android) > > - https://github.com/textbrowser/spot-on-lite (headless deamon for Linux) > > > Now, the Listener function with ping in and ping out should be implemented within a Tor-Exit-Node. > > When it comes to Tor-Messaging, there are some pathes possible: > > `A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets)` > > `B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob (Echo Tor-tunneled)` > > `C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct connection to Echo-Server with only encypted packets)` > > The request here is to build and develop option A. > > That is just right now also possible, by an Exit-Node of Tor running the Echo-Server-Software on the same machine in parallel. Just the port is different. > > This is an idea for some might be new, but thinking Tor Messaging a bit, it comes quickly to this ideas and better soluttion. > > The way to connect > > `D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion Server v3 - Tor-Chat-Client-Bob` > > is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch. > > Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Don't quote me on that, but as core developers and community members you might be in contact with those who experience this. > > Furthermore the Messaging clients are not advanced in functionality, nor advanced in strong encryption. > > It would be third a long development way to got that route. > > It is cost effective and needs cappable developers. > > Some project have stamped on and made a workable client, but does that unite all our power in the sense of Tor-Messaging? > > Messaging needs a Vision and Statement from the Tor-Core-Developer team with a discussion in the community in that regard with honor to the individual projects and also with support for their chosen path (Model D). At the same time we have to state that it is as it is, a HTTP-Server in the middle like in Model A is faster than Model D. > > In the graph-path the Echo-Server in the middle handles only encrypted traffic, so it is just like another Relay. We can call it "Reflec-Tor". The only sense it to multiply incomming encrypted packets from one node to all connected nodes. > > With that Idea, the Messenger Spot-On could be used as a Tor-Messenger. > > This Messenger has stong encryption and is full of feature for messaging and also cryptography. > > it is like adding Firefox to Tor-Browsing, when Spot-On is added to Tor-Messaging. > > Something to read at the community forum: > > https://www.reddit.com/r/Spot_On_Encryption/ > > Also there is a Mobile Client for Android, which also connects to Reflec-Tors, find "Smoke" Messenger at F-Droid.org. > > Please, get this right, it is not about a technical view on slow and failing chat-packets to hidden servers, and it is not about those start-up clients using this inside technology, some do a good project. It is about the idea, that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this hop within the path of tor is not outside, it is always fully encryted for the messaging packets and should be seen as one Tor-Path, especially if the Listener-Ping-Back function (the Echo capabilities) is build in the Exit-Node-Tor Software. > > Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only encrypted packets. > > A test is easy to make: > > `(1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is running.` > > `Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On can start.` > > `(2) Start Spot-On on a webserver and create in the Listeners Tab a Listener on Port 4710.` > > `(3) Start two Spot-On Instances Alice and Bob on two Laptops, in the Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to the neighbor and choose Proxy:` 127.0.0.1 `Port 4710.` > > You get the the Path: > > `Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob` > > The idea is now to integrate this a bit more: > > `Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob` > > You see, the way stays all within the Tor-Family. > > For sure, in case Alice does not want to use Tor, she also can message to Bob, who is behind Tor. > > `Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob` > > The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. Then two user can simply cata over that node. > > We need in times of surveillance, data retention, chat control and for sake of the needs of whistleblowser and people who want to chat privat and anonymously more decentral and open source chat server. > > The mission is: Every Tor-Exit Node is an Entry-Node for Chat. > > It should be not a lot of code to be added to the ports of an Exit-Node and displaying the Port of the Exit-Node in the Tor-Browser path icon. > > This makes sense in several effects to be discussed and developed further: > > - Taking the next Development Step for Tor-Messaging: BTW, A Forum about Tor-Messaging could be made as a category here in the forum please. > > - directly support Tor-based Messaging for the Spot-On Messaging client > > > To be developed and discussed is, if this infra-structure could help to > > - support bootstrapping of Tor > > - support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over the Messenger with EPKS > > - Accept, that some routing to an HTTPS internet server at the Tor-Node is faster than to an hidden onion server at the Tor Node. > > > Well, to add some "ping-in-and-out" for an packet is what every netcat and socat under linux can do. It is a small development step to make each Tor-Exit node a free chat server for messaging, which is a big step for mankind to have a network of free messaging chat servers. > > Lets also see, how users and community will test and develop this messaging. So it is not only a discussion for developers, it is also a step forward the needs of the communities for a free internet: > > - for chat and their discussions. > > > A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor can start really decentral and open source and free. > > What do you think? does this privacy-concept bring more privacy and reliability in packet delivery to messaging with Tor? > > Regards

2 2

Question on bridge hibernation
by Keifer Bly 18 Aug '24

18 Aug '24

Hi, So for my bridge at https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… Is set to hibernate once it reaches a certain traffic level (this is to prevent massive charges to my VPS). Now that is in hibernation, when will it start again, and how would this effect how it's distributed? Are bridges that are hibernating removed from relay search? Mew to hibernation, thanks. May 14 18:49:39.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 14 18:49:39.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. May 14 18:49:39.000 [notice] Bootstrapped 0% (starting): Starting May 14 18:49:47.000 [notice] Starting with guard context "default" May 14 18:49:47.000 [notice] Registered server transport 'obfs4' at '[::]:8081' May 14 18:49:48.000 [notice] Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted May 14 18:49:48.000 [notice] Going dormant. Blowing away remaining connections. May 14 18:49:48.000 [notice] Delaying directory fetches: We are hibernating or shutting down. --Keifer

3 2

Archive key from deb.torproject.org was renewed!
by boldsuck 15 Aug '24

15 Aug '24

Hi @all, The package deb.torproject.org-keyring did not update the key tor-archive-keyring.gpg in /usr/share/keyrings/ only deb.torproject.org-keyring.gpg was updated. I had to replace it by hand. Renewing your key is important, otherwise you will not receive any Tor updates. One line: wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E8… | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null More Info: https://support.torproject.org/apt/tor-deb-repo/ -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

9 17

Re: [tor-relays] Archive key from deb.torproject.org was renewed - mind the * deb * !
by eff_03675549＠posteo.se 15 Aug '24

15 Aug '24

> Hi all and cheers for all your replies. > > I aimed to convey: I have no (longer) update issues from the moment I > recently found out that the change introduced beginning of this month was > NOT A CHANGE OF KEY > rather this was > AN UPDATE IN THE REPO ()we returned to a deb.only repos for all. > > And what this implies is HUGE, because most non-pro-active servers out > on the netwroks, all operators gone, who lost access to their > Unattended settlements, who trusted TOR, US ALL for respecting the > FEATURE of Unattendedness have now running server Eternally flown with > MiM-Repo-weak servers. > > I implied to ask: DO you guys realize that *Unattendness is a Feature* > to build around and not to change while asking everyone to upgrade / > Attend. > Unattended servers are abandonned, they work and their owners could > have been killed, lost interest, yet they were meant to work for us all. > > What is the share of our network that will upgrade from non-deb, > obsoleting repos, and who is going to Man-In-the=Middle that repos and > OPA (acquire for free) ALL those lone servers. > > This is a monstruous danger to the network. > > Carlos. > > > On 8/14/24 9:07 PM, Toralf Förster via tor-relays wrote: >> On 8/14/24 19:44, boldsuck wrote: >>> upgrades are running or not. And that I have to reboot because of >>> the kernel >>> upgrade or similar. (I don't like auto reboots) >> >> Ah, ok. >> I like it and have therefore unattended upgrade configured >> unconditionally for all packages [1]. >> >> Furthermore I do use needrestart to detect services and/or kernel >> requiring a reboot and do it [2]. >> >> So it works all out of the box w/o manual intervention here. >> >> [1] >> https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common… >> >> [2] >> https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common… >> >> >> -- >> Toralf >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > --

1 0

DOS Protection mini RFC
by pasture_clubbed242＠simplelogin.com 15 Aug '24

15 Aug '24

Since it is still all fresh in our heads, I wanted to pitch an idea real fast. No idea if it was covered at a tor meeting at some point. For bridge relay operators, such as those with very low bandwidth, it may be worth it to keep lower-than-consensus-restrictions using the DOS flags here https://2019.www.torproject.org/docs/tor-manual.html.en#DoSCircuitCreationE… -- but this might be higher maintenance though, as keeping up to date with consensus params may be needed often. Does it seem worth it or necessary to have a multiplier variable? Like bridges with low bandwidth can set, for example, DoSConsensusMultiplier 0.75 In order to lower all or select values by 75%, rounding up to the nearest whole number or the configured floor value ( perhaps DoSConsensusMultiplierFloor 2 ...?).

2 2

Reapply exit policy on reload
by boldsuck 11 Aug '24

11 Aug '24

Hi to all dear exit operators, If you are interested in applying the exit policy on reload and not by restarting tor please note: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/735#note_3051797 Quote David: "Can you give us a sense of how many exit operators use this? If there is a large enough need for this, we can evaluate this for next release but it needs to be for more than 1 operator for such feature." Related Issue: https://gitlab.torproject.org/tpo/core/tor/-/issues/40676 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

5 13

Recent Tor versions not reloading config on / ignoring HUP kill signal.
by George Hartley 10 Aug '24

10 Aug '24

Hi, I think this started with release 0.4.8.10, but both of my Tor relays no longer reload their config when doing for example: - systemctl reload tor@exit Here is the relevant part of the unit file: > [Unit]Description=Anonymizing overlay network for TCP > After=syslog.target network.target nss-lookup.target > > [Service] > Type=notify > NotifyAccess=all > ExecStartPre=/usr/bin/tor -f /etc/tor/torrc_%i --verify-config > ExecStart=/usr/bin/tor -f /etc/tor/torrc_%i > ExecReload=/bin/kill -HUP ${MAINPID} > KillSignal=SIGINT > TimeoutSec=75 > Restart=on-failure > WatchdogSec=1m > LimitNOFILE=32768 Checking with: - journalctl -u tor@exit Just tells me that systemd attempted and successfully executed the specified reload command, but the actual line from the Tor instance stating that the config has been reloaded is missing. Is anyone else experiencing this? Regards, George

2 2

Tor at Defcon 32, Las Vegas (August 8 – August 11, 2024)
by gus 09 Aug '24

09 Aug '24

Hello, A few Tor people & relay operators will be attending Defcon this year! Stop by the Tor booth to meet the team and check out new Tor merch: https://x.com/see_ess/status/1817593609123926047. Don't miss our main presentation, "Measuring the Tor network", happening on August 10th at 3pm. Measuring the Tor Network ========================= Millions of people around the world use Tor every day to protect themselves from surveillance and censorship. While the Tor Browser and its protocol are widely known, the backbone of the Tor ecosystem, its extensive network of volunteer relays, is often subject to speculation and misinformation. The Tor Project is dedicated to supporting this network and fostering a vibrant, diverse community of relay operators. This talk will focus on our efforts to maintain a healthy network and community, and detect and mitigate attacks -- all with the help of metrics and analysis of usage patterns. By illustrating how we collect safe-enough metrics for an anonymity network, we will offer insights into how we identify unusual activity and other noteworthy events on the network. We will also discuss our ongoing strategies for addressing current and future network health challenges. If you are interested in understanding the inner workings of the Tor network and its relay community and how we keep this vital ecosystem running, this talk is for you. For more info, visit: https://defcon.org/html/defcon-32/dc-32-speakers.html https://blog.torproject.org/event/defcon-2024/ cheers, Gus -- The Tor Project Community Team Lead

3 2