- tor-relays - lists.torproject.org

How to manually change overloaded Guard?
by petrarca＠protonmail.ch 31 Oct '20

31 Oct '20

Since tonight I can't get any usable Tor connections anymore; restarting Tor gives the following error message: Guard TOR2DFNrelB ($0ED0EA324C931CF41CB5272BFB1D015B3D5772A9) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 152/217. Use counts are 45/59. 167 circuits completed, 13 were unusable, 2 collapsed, and 51 timed out. For reference, your timeout cutoff is 60 seconds. Any idea how to change the Guard - just restarting Tor doesn't help?

2 1

Snowflakes
by entensaison＠use.startmail.com 28 Oct '20

28 Oct '20

Hi everybody, I'm not sure this is the right list to ask, but is it useful to run snowflake proxies? I only recently realized they can be run by ordinary people. On the new website I don't see how you would find that out, there doesn't seem to be any link pointing to them. Metrics only shows a hundred snowflake users. What is the reason they are not advertised for? (towards humans) Have a nice day!

3 2

Re: [tor-relays] Fw: Can't update tor relay on Debian, and notice about tor log file
by Keifer Bly 27 Oct '20

27 Oct '20

Torix, I just tried your workaround, the issue still occurs. Thank you. --Keifer On Tue, Oct 27, 2020 at 1:58 PM <torix(a)protonmail.com> wrote: > Dear Keifer, > > Just guessing here, but have you tried reverting your sources.list to http? > > As for the notices and notices.1, this seems like normal linux log > rotation. See if you don't have an /etc/logrotate.d/tor file that gives > the structure of how the tor log is handled. Mine is set to rotate to a > new file daily, so notices.log is renamed to notices.log.1, and the new log > is notices.log. Notices.log.1 is zipped up to notices.2.tgz, and so on, and > the last 5 days of files are kept before being deleted. > > --Torix > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, October 27, 2020 8:30 PM, Keifer Bly <keifer.bly(a)gmail.com> > wrote: > > Hi all, so for my bridge at > > > https://metrics.torproject.org/rs.html#details/EF36AE38C162E96E0645E1DF25EF… > > > > I am some reason unable to update tor and obfs4 to the newest version. Upon running sudo apt update && sudo apt install -y --only-upgrade tor > > > > I am getting an error saying that updating from such a resprrtory can’t be > done securely and is therefor disabled by default. I have the following > entered in Debian file /etc/apt/sources.list: > > > > > > deb https://deb.torproject.org/torproject.org focal main > deb-src https://deb.torproject.org/torproject.org focal main > > > > So am not sure why it thinks this is insecure. > > > > Another thing I noticed, it seems that for some reason, for the tor > traffic log file, it switches from writing to notices.log to notices.log.1 > automatically after a while, this happened on both my bridge and my relay > though I did not tell it to do this. > > > > I wonder why the update error is happening, thank you. > > >

1 0

recently saw 4 tor relays in row on tails. bug in tor?
by BRBfGWMz 26 Oct '20

26 Oct '20

I recently saw a series of 4 relays connected to each other: itomori, MediumSlesmn, hotbrownie, pellidos itomori, docto, Geheimschreiber, 420isGay Dont most relays in the network of length 3? Bug in tor? \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

3 3

relay got suspended
by Paul Geurts 25 Oct '20

25 Oct '20

hi y'all, one of my relays got suspended today, because of heavy ddos traffic. *Hello,* *Today your VPS IP address was heavily attacked by a large DDoS, so we were forced to suspend the VPS and null the IP for the time being, since it had overloaded our upstream provider. We are keeping an eye on the situation, however in the meantime you will want to get your site behind a DDoS filter such as CloudFlare.* *Let us know if you have any further questions.* *Thank you!* *Adam* has any of you see this behauvior? I think there is no use in putting a relay behind a ddos filter, or is there? In that case I'll just spin up another one. relay in question is this one, almost 7 months with no interuption what so ever, no indication in the (munin) monitoring for high or higher traffic... because the vps is suspended I don't have the latest syslog so I don't know for sure whether anything has shown up there, but I am quite sure that yesterday there were no abnormal logging entries on this server. https://metrics.torproject.org/rs.html#details/CDE4149F0DC65A7BE1AE440340BE… rgds,. Paul

4 3

FreeBSD and Libressl from the ports
by Felix 25 Oct '20

25 Oct '20

Hi everybody :: That post went as well to tor-bsd(a)lists.nycbug.org but is reposted here for a potential higher attendance :: This is for those who run FreeBSD and Libressl from the ports. Because of the issue [0] we can not compile from source. Maybe you can use Libressl from the base system or you overwrite the security/libressl or security/libressl-devel port with an older version like 3.2.0 and compile from there. (Uhh, you can go with Openssl until the fix is in place) Please find the ports files in [1]. Libressl 3.2.0 works with Tor 4.4.x like a charme. Libressl 3.2.1 and 3.2.2 cause an issue with some Tor auths. Libressl 3.2.2 is/was devel and sits as well in non-devel, so we can not switch back this time :( . [0] https://gitlab.torproject.org/tpo/core/tor/-/issues/40128 [1] https://svnweb.freebsd.org/ports/head/security/libressl/ -- Cheers, Felix

1 0

My Tor exit node not visible
by netaudit 21 Oct '20

21 Oct '20

Hi there, I've set up a new Tor exit node around 15 hours ago but despite it had been such a time and my exit is visible from outside world I still get little to no traffic at all. I also cannot see my servers IP on bulk tor exit node list. I checked the logs and everything seems alright too: [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Can you please tell me what I am missing here? Thank you Sent with [ProtonMail](https://protonmail.com) Secure Email.

6 6

ContactInfo Spec Version 2 is released
by nusenu 20 Oct '20

20 Oct '20

Hi, I'm happy to announce version 2 of the ContactInfo Information Sharing Specification. https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ It comes with an easy to use ContactInfo generator, which is maintained by Eran Sandler: https://torcontactinfogenerator.netlify.app/ Example ContactInfo string as defined by this specification: email:tor[]example.com url:https://example.com proof:uri-rsa uplinkbw:100 ciissversion:2 In words this ContactInfo string means: - the technical contact for this relay can be reached at tor(a)example.com - the entity responsible for this relay has a website at https://example.com - the proof file to verify the url can be fetched from https://example.com/.well-known/tor-relay/rsa-fingerprint.txt - this tor instance can provide a bandwidth up to 100 Mbit/s - this string implements version 2 of this specification The spec has many fields to choose from but I'd like to highlight these 3 fields, also used in the example above, as some of the most relevant: - email - url - proof The proof field allows operators to make their URL value verifyable (protected against spoofing) by placing their relay fingerprints in a text file located on their website. If no website is available DNS TXT records can be used instead. Now that version 2 is out, we will work on parsing to provide operators with an easy way to check their strings (and maybe also their proofs) interactively. I intend to use the data as input for OrNetStats as operators start to set their ContactInfo strings. I have operator-level graphs in mind, showing the operator how his set of relays evolved over time. See https://raw.githubusercontent.com/nusenu/tor-network-observations/master/pn… for an example. The timespan will likely be significantly smaller than the one used in this example. The release of version 2 marks the deprecation of version 1. I aim to support version 2 for at least 2 years and aim to make future releases backward compatible. I've no plans to significantly change or extend the amount of fields, with the exception of one potentially interesting use-case (see the bottom of this email). Many changes that went into version 2 are directly related to your comments after publishing version 1, thanks for that! We also got feedback for the generator and are tracking them here: https://github.com/erans/torcontactinfogenerator/issues Changelog ---------- Most notable changes since version 1: - 'operatorurl' got renamed to just "url" - "verifyurl" field simplified/replaced with "proof" (no longer requires a webserver) - email field is no longer mandatory - UTF-8 support - xmr (monero) field added - bitcoin field renamed to btc - zcash field renamed to zec - PGP keys should be on keys.openpgp.org (verifying keyserver) - removed fields: KIST, ricochet Future Idea Since some had concerns about spam: It would be trivial to add support for an encrypted email address when the operator has a webserver and a verified url field. If there is some demand for this and the Tor Project is willing to publish a GPG key that can be used for encryption I'll add support for it. That would mean only the persons at the torproject having access to that key could fetch the encrypted address and decrypt it with their private key, others would only see "encemail:y" or similar. kind regards, nusenu

3 2

Collaborative Bad-Abuse-Sender Blocklist
by Matt Corallo 19 Oct '20

19 Oct '20

Hi all, I run a few relatively-small exit nodes, and still get a decent flow of the usual Fail2Ban, blocklist.de, and such garbage to abuse PoCs. I tend to proactively find appropriate abuse/noc contacts to provide a response informing them of how they can appropriately block all Tor exits from their SSH ports if they wish, but often get either no or indignant responses about how sending a stream of garbage abuse reports is a useful service to the internet (nevermind that most large providers don't bother handling abuse reports anymore because of exactly this behavior). After a reply or two I usually add senders to a blocklist and bounce them at the mailserver with a notice about spam not being useful. Is there any interest in building up a shared blocklist of senders who feel its their right to send Fail2Ban emails in non-machine-parsable formats and not bother handling replies to their emails they expect others to handle, or does anyone already have such a list? Matt

4 6

Help setting up 2 Relays
by postmaster＠coolcomputers.info 18 Oct '20

18 Oct '20

Hello, I was wondering it anyone more experienced could help me with fixing 1 TOR Exit and 1 TOR Relay. I have everything configured and fingerprints made they just seem to not me recognized by tor metrics. Tor Relay: B0852A98ECDB40E95319DEE339662EEF50708066 Tor Exit: A5D03FC9BE6EE32BD20EE59649BAD802BF4A49FC There is nothing in the notice logs as to why this would be happening. Maybe someone can see what the DA's think of them. Then give me advice on what to do. Thanks, John Csuti postmaster(a)coolcomputers.info

5 6

Network Performance Experiment - KISTSchedRunInterval - October 2020
by David Goulet 17 Oct '20

17 Oct '20

Greetings relay operators! Tor has now embarked in a 2 year long scalability project aimed, in part, at improving the network performance. The first steps will be to measure performance on the public network in order to come up with a baseline. We'll likely be adjusting circuit window size, cell scheduling (KIST) and circuit build timeout (CBT) parameters over the next months in both contained experiments and on the live network. This announcement is about KIST parameters, our cell scheduler. Roughly a year ago, we've discovered that all tor clients are capped to ~3MB/sec in maximum outbound throughput due to how the scheduler is operating. I won't get into the details but if you are curious, it is here: https://gitlab.torproject.org/tpo/core/tor/-/issues/29427 It turns out that we now believe that the entire network, not only clients, are actually capped at 3MB/sec per channel (a channel is a connection between client -> relay or relay -> relay also called an OR connection). We've recently conducted experiments with chutney [1], which operates on the loopback interface, and we indeed hit those limits. KIST has a parameter named KISTSchedRunInterval which is currently set at 10 msec and that is our culprit. By lowering it to 2 msec, our experiment showed that the cap goes from 3MB/sec to ~5MB/sec with burst a bit higher. Now, the question is why was it set to 10 msec in the first place? Again, without getting into the technical details of the KIST paper[2], our cell scheduler requires a "grace period" in order to be able to accumulate cells and then prioritize over many circuits using an EWMA algorithm which tor has been using for a long time now. Without this, one can clog the pipes (at the TCP level) with a very loud transfer by always being scheduled and filling the TCP buffers leaving nothing for the quieter circuit. Important to note that the goal of EWMA in tor is to prioritize quiet circuit for example, an SSH session will be prioritized over a bulk HTTP transfer. This is so "likely" interactive connections are not delayed and are snappy. But, lowering this to 2 msec means less time to accumulate and in theory worst cell prioritization. However, we think this will not be a problem because we believe the network is underloaded. And, because of this 3MB/sec cap per channel, it means that tor is sending burst of cells instead of a constant stream of cells and thus it is under processing what it possibly could at the relay side. Again, all this in theory. All in all, going to 2 msec should improve speed at the very least and not make the network worst. We want to test that, measure that for a couple of weeks and then transition to a higher value and doing that until we get to 10 msec so we can clearly well compare the effect on EWMA priority and performance. One possibility will be 2 msec, 5 msec, 10 msec transition period. Yesterday, a request to our 9 directory authorities have been made to set this consensus parameter: KISTSchedRunInterval=2 We are still missing 1 authority to enable this param for it to take effect network wide. Hopefully, it should be today in the coming hours/day. This is where we need your help. We would like you to notify us on this thread about any noticeable changes in CPU, RAM, or BW usage. In other words, anything that changes from the "average" you've been seeing is worth informing us. We do NOT expect big changes for your relay(s) but there could reasonably be a change in bandwidth throughput and thus some of you could see a traffic increase, unclear at the moment. Huge thanks to everyone here! We will carefully monitor this change and if things go bad, we'll revert it as fast as we can! Thus, your help becomes extremely important! Cheers! David [1] https://git.torproject.org/chutney.git/ [2] https://arxiv.org/pdf/1709.01044.pdf -- 7h1/NAPdaaGpI8WG6X4FtryAZZ4EhnznUVVLqIf/04A=

6 10

Shutdown of my digital ocean guard relay
by mick 16 Oct '20

16 Oct '20

Hi Guys I today received notification from DO that they have changed their Terms of Service and Acceptable Useage policies. Having read those changed notices it is clear to me that DO are no longer really Tor friendly. They do not allow exits and whilst my guard relay there (at roof.rlogin.net with fingerprint EA8637EA746451C0680559FDFF34ABA54DDAE831) has been running for nearly seven years I can no longer do that because of the likely bandwidth charges in future. My DO relay has been using around 12 TiB per month for some time now and I could afford to let it run because I was a "legacy" customer (i.e. early adopter of DO services who was given "free bandwidth forever"). It looks to me from their new ToS that I will no longer enjoy that status after 22 October. So I have shut it down. Any other relay operator using DO services should read their new ToS (1) and AUP (2) and decide for themselves whether they will be affected. My other guard relay at sink.rlogin.net on Hetzner's network will continue in operation. Mick (1) https://www.digitalocean.com/legal/terms-of-service-agreement/ (2) https://www.digitalocean.com/legal/acceptable-use-policy/ --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------

6 10

Is this next bad exit trick?
by lists＠for-privacy.net 14 Oct '20

14 Oct '20

Wtf, this exit has addresses that do not belong to it! https://metrics.torproject.org/rs.html#details/385527185E26937D05E0933DD29F… I'm very sure there are only nifty rabbits on the 185.220.101.0/24 subnet! -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

6 14

Relay JPsi2 not getting into consensus anymore
by Random Tor Node Operator 14 Oct '20

14 Oct '20

Hi all, some weeks ago, my relay JPsi2 (F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521) started experiencing moderate stability problems. It would freeze after a few hours or days. The provider said it was due to Spectre mitigations and the only way for me to fix this would be to switch to a newer (more expensive) plan... Some time later I did so and reinstalled it with Ubuntu 18.04 and placed the old keys into the new installation. It seems they are now expected to be in /var/lib/tor/.tor/keys, as opposed to /var/lib/tor/keys as I was used to in Ubuntu 16.04. However, it does not seem to be making it into the consensus anymore. Only the authority nodes moria1, dizum, and longclaw vote for Running. The others don't. So far I haven't been able to figure out the reason for that, so any help is appreciated. Here is part of the output of journalctl -u tor and the torrc file: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: Tor's uptime is 8 days 0:00 hours, with 0 circuits open. I've sent 54.04 MB and received 163.30 MB. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 9368438 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1060775 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 13332 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 2762395 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While not bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 111548029 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 100899 (server descriptor upload) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 15307429 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1785 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 942746 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Average packaged cell fullness: 96.710%. TLS write overhead: 31% Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Circuit handshake stats since last time: 1/1 TAP, 0/0 NTor. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 2 v2 connections; initiated 0 and received 114 v3 connections; initiated 0 and received 1899 v4 connections; initiated 46 and received 5694 v5 connections. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Oct 11 18:14:03 j60204.servers. # cat /etc/tor/torrc OfflineMasterKey 1 SOCKSPort 0 SOCKSPolicy reject * RunAsDaemon 1 ControlPort 9051 HashedControlPassword 16:28CD63819CB35660601EB9CED4BC2A4252D3DB80488DFD4F22CA4AE930 ORPort 9001 ORPort [2a00:1158:3::1ba]:9001 Nickname JPsi2 RelayBandwidthRate 12500 KB RelayBandwidthBurst 12500 KB ContactInfo 0xF1ADC390 Random Tor Node Operator <tor at unterderbruecke (dot) de> bitcoin:1LBoEppezy2HauE957HzfFn9UGywK6aboB DirPort 9030 MyFamily $B198C0B4B8C551F174FBB841A172616E3DB3124D, $F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 IPv6Exit 0 ExitPolicy reject *:* ExitPolicy reject6 *:*

3 3

Riseup invite code
by lists＠for-privacy.net 09 Oct '20

09 Oct '20

Hiho rise up members, I would like to receive the mails for my hosted Tor relays, such as support tickets from my provider, via Riseup. Can one of the Riseup.net users on this list send me an invite code? Right on me, not in the list ;-) mailto:admin@for-privacy.net or my lists address -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 1

Malicious Tor relays - post-analysis after two months
by Corl3ss 07 Oct '20

07 Oct '20

Hello, This summer Nusenu shared his posts about malicious relays [1][2] and it was followed by many answers. A very important is Roger's one [3] explaining that the malicious relays have been kicked out of the network and that any new one should be reported. I was wondering if, with some distance with this summer situation / discussion : * new malicious relays have been reported in any way ? * vigilance / watchfulness is still needed ? if yes : * is there specific cases to share (e.g. nodes that block HTTPS on a site or redirect to HTTP ?) * any concern to have on other protocols that use SSL (imaps, smtps, ssh) ? * is there / will there be things implemented as a conclusion of the "call for support for proposal to limit large scale attacks" ? * has it been possible to prepare / set up precautions to avoid this king of situation or it is a too long shot for such a problem ? These questions come with a lot of respect for the project, its teams and the work done. No critics, it is just made to update the knowloedge on the subject as these questions came back with other friends and relay operators. And perhaps a last one, perhaps specific for Nusenu : how do you define a malicious relay ? Sorry but I did not get that precisely, moreover in big group analysis. All answers will be read with care and gratitude ! --- Corl3ss 2042 5D39 E7C1 E657 025E A28F 937D 8A90 FCB0 E24A [1] https://lists.torproject.org/pipermail/tor-relays/2020-July/018643.html [2] https://lists.torproject.org/pipermail/tor-relays/2020-August/018817.html [3] https://lists.torproject.org/pipermail/tor-relays/2020-August/018845.html

6 7

question
by prizzz＠Safe-mail.net 05 Oct '20

05 Oct '20

Hello. Why is my Consensus Weight constantly changing? What factors influence its change? Thanks in advance for your reply =))

2 1

Reconfiguring a middle relay as a bridge
by torix＠protonmail.com 30 Sep '20

30 Sep '20

Is there a security problem with turning a middle relay, whose ip address is known, into a bridge? TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 3

Heartbeat: It seems like we are not in the cached consensus.
by Fran 27 Sep '20

27 Sep '20

Hello, I'm taking care of a server of a friend who's on holiday. The server is up and running but not part of the consensus. As beeing instructed I updated to the lastest OpenBSD snapshot when I saw that a new tor release is available (Tor 0.4.3.5 on OpenBSD). Excerpts from the log: Jul 13 20:04:02.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jul 13 20:05:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jul 13 20:05:35.000 [notice] Performing bandwidth self-test...done. Jul 14 02:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 02:04:01.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 2.04 MB and received 6.25 MB. Jul 14 02:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 33% Jul 14 02:04:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor. Jul 14 02:04:01.000 [notice] Since startup we initiated 0 and received 157 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 5 v4 connections; initiated 48 and received 124 v5 connections. Jul 14 02:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 06:04:02.000 [notice] Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 4 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections. Jul 14 08:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 08:04:01.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 1 circuits open. I've sent 3.46 MB and received 11.22 MB. Jul 14 08:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 47% Jul 14 08:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 1/1 NTor. Jul 14 08:04:01.000 [notice] Since startup we initiated 0 and received 340 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 10 v4 connections; initiated 57 and received 246 v5 connections. Jul 14 08:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 14:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 14:04:01.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 1 circuits open. I've sent 4.89 MB and received 15.33 MB. Jul 14 14:04:01.000 [notice] Average packaged cell fullness: 26.760%. TLS write overhead: 51% Jul 14 14:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 6/6 NTor. Jul 14 14:04:01.000 [notice] Since startup we initiated 0 and received 493 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 18 v4 connections; initiated 64 and received 370 v5 connections. Jul 14 14:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Atlas show the server as down: https://metrics.torproject.org/rs.html#details/AC601DBDB7FBD53454045EDC08DA… Accessing the status page on port 80 works. No FW on the machine. Any ideas? Thanks and regards Fran

4 7

Exit not utilizing full bandwidth
by 4punk7＠mailbox.org 26 Sep '20

26 Sep '20

Hi, i am running a tor exit node for over 2 years now and it's just using around 1.7 MiB/s of a 100 MBit/s connection. My other relays (not exits) from the same hoster (same bandwidth) are using around 10 MiB/s (which is the rate I expect). I have tried to limit the bandwithrate, set no limits, adding IPv6 and also excluding relays from overseas (i'm located in Germany). Nothing happened. CPU is around 10%... Any idea how to speed up the exit ? Thanks, apunkt Tor Version is 0.4.2.7, here is my current torrc: /var/log/tor/notices.log RunAsDaemon 1 DataDirectory /var/lib/tor ControlPort 9051 ORPort 1234 ORPort [2a0a:51c0::103]:9001 Nickname 4punk7e1 RelayBandwidthRate 100 MBytes # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 100 MBytes # But allow bursts up to 200KB (1600Kb) MyFamily $CEFBCB5FCE5FB37784AD489BCDEC46F1D59C06CB,$ABA31795BAD2AB8097F3AD0FE1A9 20E518D3D3F3 ExitRelay 1 IPv6Exit 1 ExitPolicy reject6 *:22 ExitPolicy reject6 *:587 #ExitPolicy reject6 *:* ExitPolicy accept *:20-21 # FTP #ExitPolicy accept *:22 # SSH ExitPolicy accept *:23 # Telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79 # finger ExitPolicy accept *:80-81 # HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:465 # URD for SSM (more often: an alternative SUBMISSION port, see 587) ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL #ExitPolicy accept *:587 # SUBMISSION (authenticated clients [MUA's like Thunderbird] send mail over STARTTLS SMTP here) ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:853 # DNS over TLS ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-990 # FTP over SSL ExitPolicy accept *:991 # Netnews Administration System ExitPolicy accept *:992 # TELNETS ExitPolicy accept *:993 # IMAP over SSL ExitPolicy accept *:994 # IRCS ExitPolicy accept *:995 # POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8082 # HTTPS Electrum Bitcoin port ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8232-8233 # Zcash ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* ExcludeNodes {US},{CA}

1 0

"Your server (xxxx:443) has not managed to confirm that its ORPort is reachable."
by Pham Minh Duc 23 Sep '20

23 Sep '20

I see this in syslog: Your server (xxxx:443) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. torrc: Nickname Contake ORPort 443 ExitRelay 0 SocksPort 0 ControlSocket 0 ContactInfo contakechuyennghicmt(a)gmail.com What happened and how to fix this?

3 7

Who am I?
by Kencf0618＠riseup.net 22 Sep '20

22 Sep '20

Whatever the torrc, with "Tor" I get Sep 18 08:02:12.538 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. Sep 18 08:02:12.538 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Sep 18 08:02:12.538 [notice] Read configuration file "/etc/tor/torrc". Sep 18 08:02:12.542 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand. Sep 18 08:02:12.542 [notice] Scheduler type KIST has been enabled. Sep 18 08:02:12.542 [notice] Opening OR listener on 0.0.0.0:443 Sep 18 08:02:12.542 [warn] Could not bind to 0.0.0.0:443: Permission denied Sep 18 08:02:12.542 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Sep 18 08:02:12.542 [err] Reading config failed--see warnings above. whereas with "sudo Tor" (yeah, yeah, I know, I know -"bad form") I get ep 18 08:04:12.236 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. Sep 18 08:04:12.236 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Sep 18 08:04:12.237 [notice] Read configuration file "/etc/tor/torrc". Sep 18 08:04:12.240 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand. Sep 18 08:04:12.240 [notice] Scheduler type KIST has been enabled. Sep 18 08:04:12.240 [notice] Opening OR listener on 0.0.0.0:443 Sep 18 08:04:12.241 [warn] /home/kenneth/.tor is not owned by this user (root, 0) but by kenneth (1000). Perhaps you are running Tor as the wrong user? Sep 18 08:04:12.241 [warn] Failed to parse/validate config: Couldn't access/create private data directory "/home/kenneth/.tor" Sep 18 08:04:12.241 [err] Reading config failed--see warnings above. What is happening?

4 6

Expiration time from torbulkexitlist
by Julien Moutinho 22 Sep '20

22 Sep '20

Hello Tor fans, New to Tor here, nonetheless this month I've tried to work on some type-checking and hardening of Tor in NixOS (see https://github.com/NixOS/nixpkgs/pull/97740 in case this interests you), hence I've tested Tor as an Exit node a few hours behind 80.67.180.251, as visible in: https://collector.torproject.org/recent/exit-lists/2020-09-22-01-02-00 > ExitNode 483F3347218DA225540D67AC3B9D48235A23DB89 > Published 2020-09-07 19:22:15 > LastStatus 2020-09-08 01:00:00 > ExitAddress 80.67.180.251 2020-09-08 01:59:25 And, if I'm not mistaken, only used it as a non Exit node since then (mostly to test a new NixOS abstraction around onion services). It's now 14 days past my Exit node test, yet that IPv4 is still listed in: https://check.torproject.org/torbulkexitlist despite https://lists.torproject.org/pipermail/tor-project/2020-March/002759.html announcing that: > This list is updated at most once every 40 minutes depending on the > number of exit relays in the network at the time, fetching it every hour > would be reasonable. A quick grep in https://collector.torproject.org/archive/exit-lists/exit-list-2020-07.tar.xz shows that in the past at least some exit nodes have been removed after one month: > $ grep LastStatus exit-list-2020-07/13/2020-07-13-18-02-00 | sort -r | tail -1 > LastStatus 2020-06-15 03:00:00 > $ grep LastStatus exit-list-2020-07/13/2020-07-13-19-02-00 | sort -r | tail -1 > LastStatus 2020-07-11 20:00:00 Am I right to assume that one month is the expiration time from torbulkexitlist? And can I do anything to trigger the removal before that delay? Thanks in advance for your answers, Julien

1 0

Fwd: Re: "Your server (xxxx:443) has not managed to confirm that its ORPort is reachable."
by lists＠for-privacy.net 17 Sep '20

17 Sep '20

Please always reply to the list so that everyone can help you. -------- Original Message -------- Subject: Re: [tor-relays] "Your server (xxxx:443) has not managed to confirm that its ORPort is reachable." Date: 17.09.2020 13:42 From: Pham Minh Duc <phamducvn.0308(a)gmail.com> To: lists(a)for-privacy.net > Help, I've followed steps on your Github but I still see this error. My > IP address is dynamic. It may affects? How to fix this? dynamic IP = you have your relay running at home? Then things are quite different. I guess: You have a router that connects you to the Internet and your computer running Tor gets the IP/IPv6 via DHCP? Then you have to set up port forward (ORPort, DirPort) on the router and don't need iptables on the computer in the LAN. Which OS do you have exactly. Your syslog can be every GNU/Linux, *BSD or another UNIX. Be sure you have absolutely no exit traffic, add to your torrc: ExitPolicy reject *:* and advertise the directory service on some port: DirPort 80 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

Become a Fallback Directory Mirror (deadline: July 23)
by gus 17 Sep '20

17 Sep '20

Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. Important: you have until July 23 2020 to reply to this message to get in the fallback directory mirror list. If your relay is on the current fallback list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, Gus [1] https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDire… [2] https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc [3] https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_… -- The Tor Project Community Team Lead http://expyuzz4wqqyqhjn.onion/

26 30

OVH Warnings
by Dr Gerard Bulger 15 Sep '20

15 Sep '20

OVH seemed to have upped their game with more information than just throwing all traffic into "mitigation" which can result in bad exit status, with no information as to what their systems are detecting as a threat of denial of service attack. For the first time I got an email.no mitigation. Dear Customer, Abnormal activity has been detected on your VPS Attack detail : 4Kpps/2Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason 2020.09.15 19:02:21 CEST <http://51.38.64.136:42845/> my ip:42845 <http://212.22.93.124:25565/> 212.22.93.124:25565 TCP SYN 60 ATTACK:TCP_SYN 2020.09.15 19:02:21 CEST <http://51.38.64.136:39673/> my ip:39673 <http://212.22.93.124:25565/> 212.22.93.124:25565 TCP SYN 60 ATTACK:TCP_SYN Etc Gerry

1 0

Odd error with tor 4.3 log file
by Keifer Bly 14 Sep '20

14 Sep '20

1 0

non-encrypted connections from Tor exit relays
by kirgali＠riseup.net 10 Sep '20

10 Sep '20

hi, generalized question about Tor exit relays and exit relay operators. do some exit relay operators have a policy to prevent connections leaving their exit node via non-encrypted ports (e.g. port 25)? this could be a philosophical position - not even wanting to be in a position to observe users' data passing through the exit node in clear text. or a pragmatic position - hoping that encrypted connections provide some level (even very weak) of plausible deniability in the event that a connection attracts the attention of law enforcement. this is just my thoughts.

3 2

Re: [tor-relays] Could Zoom be using the wrong dan-tor blacklist
by Eddie 10 Sep '20

10 Sep '20

Gus, It's "OnNoNotAnotherTorRelay"; D195E5CE8AE77BAC91673E6CFB7BD0AF57281646 Cheers. On 9/9/2020 7:44 PM, gus wrote: > Hi Eddie, > > Could you inform your relay fingerprint? > > Thanks, > Gus > > On Mon, Sep 07, 2020 at 11:54:47AM -0700, Eddie wrote: >> Starting yesterday (maybe Saturday) we have been unable to initiate any Zoom >> calls. They just sit "connecting". According to Zoom, there are no issues >> that would lead to this. >> >> My investigation, traces I have run on the server, and using a VPN (on a >> tablet on my LAN) show the exact same symptoms I had a year (or so) ago with >> a couple of AT&T sites, which I eventually narrowed down to being caused by >> the same blacklist by routinely switching IPs and then eventually shutting >> down my relay temporarily. >> >> Is anyone else seeing similar and/or have any suggestions as I rather not >> have to shut my relay down. Running a multitude of VPNs on my internal >> machines is not really an option and my relay isn't going to function if I >> throw a VPN on my server. >> >> Cheers. >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

SMTP port 465/587
by kirgali＠riseup.net 10 Sep '20

10 Sep '20

Hi, question for Tor exit relay operators. Do exit relay operators allow connections to SMTP port 587 more than port 465? The RiseUp webpage says “SMTP port 465 is often blocked by Tor exit nodes but port 587 is less frequently blocked” (https://riseup.net/en/email/clients) because port 465 is considered deprecated (see RFC 8314). In practice do most exit relay operators allow connections to both SMTP ports? Thanks

1 0

OVH Mitigation
by Dr Gerard Bulger 10 Sep '20

10 Sep '20

I know we should dilute our dependence on OVH, but cheap and seem to ignore the fact the machine is an exit node. OVH has a seemingly patented a system to deal with denial of service attacks. I am not sure what they detect but when they do we get this: "We have just detected an attack on IP address x.x.x.x. In order to protect your infrastructure, we vacuumed up your traffic onto our mitigation infrastructure. The entire attack will thus be filtered by our infrastructure, and only legitimate traffic will reach your servers. At the end of the attack, your infrastructure will be immediately withdrawn from the mitigation" To be fair, the automated system takes it off after an our or two. If my tor server is left in this mitigated state, the tor exit gets labelled a BAD EXIT which is something to avoid as takes days to be trusted again. As soon as I get their email I now stop TOR to prevent that embarrassing label, and perhaps doing so stops whatever it is OVH is detecting. Being shutdown for a few hours seems better than being a bad exit. Gerry

3 2

Could Zoom be using the wrong dan-tor blacklist
by Eddie 07 Sep '20

07 Sep '20

Starting yesterday (maybe Saturday) we have been unable to initiate any Zoom calls. They just sit "connecting". According to Zoom, there are no issues that would lead to this. My investigation, traces I have run on the server, and using a VPN (on a tablet on my LAN) show the exact same symptoms I had a year (or so) ago with a couple of AT&T sites, which I eventually narrowed down to being caused by the same blacklist by routinely switching IPs and then eventually shutting down my relay temporarily. Is anyone else seeing similar and/or have any suggestions as I rather not have to shut my relay down. Running a multitude of VPNs on my internal machines is not really an option and my relay isn't going to function if I throw a VPN on my server. Cheers.

1 0

How many threads needed for unbound at a fast relay?
by Toralf Förster 05 Sep '20

05 Sep '20

I do wonder about a reasonable number. -- Toralf

3 3

Re: [tor-relays] Tor relay marked "false positive" from NCSC-FI
by Peter Gerber 03 Sep '20

03 Sep '20

Hi tschador(a)posteo.de: > today my ISP received an abuse report from > ncsc-fi-autoreporter(a)traficom.fi [1]: > --- > The information below is presented in the following format: > ASN | IP | TIMESTAMP (UTC) | PTR/DNAME | CC | TYPE | CASE | INFO > > 24940|95.217.16.212|2020-09-01 07:27:48 > +0000|95.217.16.212|DE|malweb|1130659|Datasource: b, Url: > hxxp://95.217.16.212/tor/server/fp/23ad6b165137d957c09aa0f7a3ee7b05cec4a8f2, > Http Request: GET, Additional Information: This host is most likely > serving a malware URL., Artifact Hash: 69b9e2721018f0ebaebf901d98d8c9b9 > --- > The ip belongs to my non-exit relay. [2] There is no action required for > me, but I wonder why they mark traffic on the dirport as 'malware'? I've received a similar mail not too long ago. Looking into it, I couldn't but conclude that it was some sort of phishing scam. When following the link one was asked to provide a lot of information. The webpage seems to be outdated, incomplete and nowhere was explained why they'd scan the internet for anything. All in all, the page looked as "phishy" as it gets. For reference, below is the abuse mail I received. Regards Peter -------- Forwarded Message -------- Subject: Fwd: Abuse Message [AbuseID:730BD4:2C]: AbuseCleanMXInfo: [clean-mx-viruses-172313691](95.216.14.206)-->(abuse(a)hetzner.de) viruses sites (1 so far) within your network, please close them! status: As of 2020-08-09 16:47:16 CEST Date: Sun, 09 Aug 2020 16:48:21 +0200 From: abuse(a)hetzner.com Reply-To: abuse(a)hetzner.com To: <removed> Dear Mr Peter Gerber, For your information we are forwarding you the email of the ticket [AbuseID:730BD4:2C]. The source email with details about the issue is attached to this email. Important note: When replying to us, please leave the abuse ID [AbuseID:730BD4:2C] unchanged in the subject line. Kind regards Abuse department Hetzner Online GmbH Industriestr. 25 91710 Gunzenhausen / Germany Tel: +49 9831 505-0 Fax: +49 9831 505-3 abuse(a)hetzner.com www.hetzner.com Register Court: Registergericht Ansbach, HRB 6089 CEO: Martin Hetzner, Stephan Konvickova, Günther Müller For the purposes of this communication, we may save some of your personal data. For information on our data privacy policy, please see: www.hetzner.com/datenschutzhinweis On 09 Aug 16:47, abuse(a)clean-mx.de wrote: > Dear abuse team, > > please have a look on these perhaps offending viruses sites(1) so far. > > Notice: We do NOT urge you to shutdown your customer, but to inform him about a possible infection/misbehavior ! > > status: As of 2020-08-09 16:47:16 CEST > > Please preserve on any reply our Subject: [clean-mx-viruses-172313691](95.216.14.206)-->(abuse(a)hetzner.de) viruses sites (1 so far) within your network, please close them! status: As of 2020-08-09 16:47:16 CEST > > > http://support.clean-mx.de/clean-mx/viruses.php?email=abuse@hetzner.de&resp… > > (for full uri, please scroll to the right end ... > > This information has been generated out of our comprehensive real time database, tracking worldwide viruses URI's > > If your review this list of offending site(s), please do this carefully, pay attention for redirects also! > Also, please consider this particular machines may have a root kit installed ! > So simply deleting some files or dirs or disabling cgi may not really solve the issue ! > > Advice: The appearance of a Virus Site on a server means that > someone intruded into the system. The server's owner should > disconnect and not return the system into service until an > audit is performed to ensure no data was lost, that all OS and > internet software is up to date with the latest security fixes, > and that any backdoors and other exploits left by the intruders > are closed. Logs should be preserved and analyzed and, perhaps, > the appropriate law enforcement agencies notified. > > DO NOT JUST DELETE THE FILES. IF YOU DO NOT FIX THE SECURITY > PROBLEM, THEY WILL BE BACK! > > You may forward my information to law enforcement, CERTs, > other responsible admins, or similar agencies. > > +----------------------------------------------------------------------------------------------- > > |date |id |virusname |ip |domain |Url| > +----------------------------------------------------------------------------------------------- > |2020-08-09 16:05:31 CEST |172313691 |PUA.Win.Trojan.Generic-6629274-0 |95.216.14.206 |95.216.14.206 |http://95.216.14.206/tor/status-vote/current/consensus-microdesc/0232af+14c131+23d15d+27102b+49015f+d586d1+e8a9c4+ed03bb+efcbe7.z > +----------------------------------------------------------------------------------------------- > > > Your email address has been pulled out of whois concerning this offending network block(s). > If you are not concerned with anti-fraud measurements, please forward this mail to the next responsible desk available... > > > If you just close(d) these incident(s) please give us a feedback, our automatic walker process may not detect a closed case > > explanation of virusnames: > ========================== > unknown_html_RFI_php not yet detected by scanners as RFI, but pure php code for injection > unknown_html_RFI_perl not yet detected by scanners as RFI, but pure perl code for injection > unknown_html_RFI_eval not yet detected by scanners as RFI, but suspect javascript obfuscationg evals > unknown_html_RFI not yet detected by scanners as RFI, but trapped by our honeypots as remote-code-injection > unknown_html not yet detected by scanners as RFI, but suspious, may be in rare case false positive > ...javascript.insert Please pay attention for script code after </html> > unknown_exe not yet detected by scanners as malware, but high risk! > all other names malwarename detected by scanners > ========================== > > > yours > > Gerhard W. Recher > (CTO) > > net4sec UG (haftungsbeschraenkt) > > Leitenweg 6 > D-86929 Penzing > > GSM: ++49 171 4802507 > > Geschaeftsfuehrer: Martina Recher > Handelsregister Augsburg: HRB 27139 > EG-Identnr: DE283762194 > > w3: http://www.clean-mx.de > e-Mail: mailto:abuse@clean-mx.de > PGP-KEY: Fingerprint: A4E317B6DC6494DCC9616366A75AB34CDD0CE552 id: 0xDD0CE552 > Location: http://www.clean-mx.de/downloads/abuse-at-clean-mx.de.pub.asc

1 0

anyone else with this issue?
by niftybunny 30 Aug '20

30 Aug '20

Daily DDOS love the last 14 days … https://imgur.com/a/rfu0OUA <https://imgur.com/fCsIv6V> even for my standards, thats a shit-ton of sockets … Tor DDOS protection is configured but I get more connections than I can drop … nifty

7 9

ubuntu focal and Tor
by potlatch 28 Aug '20

28 Aug '20

Question: What's with the failure when installing Tor of the "no valid keys" for focal? I've had to back up to ubuntu 18 several times. --potlatch-- Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Hello CypherpunkLabs Tor relays
by nusenu 25 Aug '20

25 Aug '20

Hello CypherpunkLabs, I noticed your set of new relays and wanted to say hi, welcome you to the Tor relay community and give you a few recommendations and pointers especially since you are aiming to run 100 tor relays. The Tor relay guide has a lot of useful information, so you probably want to start there: https://torproject.org/relay-guide Since all your current relays appear to be OVH based I'd like to point out the following quote from the guide: > Try to avoid the following hosters: > > OVH SAS (AS16276) > Online S.a.s. (AS12876) > Hetzner Online GmbH (AS24940) > DigitalOcean, LLC (AS14061) https://community.torproject.org/relay/technical-considerations/ The reasoning behind this, is that those hosters are already hosting many tor relays, and the network dislikes centralization. OVH is the biggest commercially available tor hoster in terms of exit capacity today already. Depending on your per-relay size you might end up running a big fraction of the network and especially big exit operators are encourage to take care of their DNS resolution. Specific guidelines can be found here: https://community.torproject.org/relay/setup/exit/ IPv6 connectivity is also encouraged (which currently none of your relays appear to have). Especially for big operators it is recommended to managed their relays using configuration management (puppet, salt, ansible, ...) and update them regularly. An ansible role for Tor relay operator (I maintain) can be found at: https://github.com/nusenu/ansible-relayor The ContactInfo Information Sharing Specification is a spec about a machine readable ContactInfo string: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification Your site suggests that you (will) run bridges and exits. Combining these two types of nodes under a single operator is generally a bad idea since tor's MyFamily configuration is not supported for bridges, so users might end up using your bridges _and_ your tor exits - which puts them at risk should someone compromise you, please consider running non-bridges only. For strong protections for your long term relay keys you can use tor's OfflineMasterKey feature, especially relevant if your run a big fraction of the network: https://2019.www.torproject.org/docs/tor-manual.html.en#OfflineMasterKey kind regards, nusenu PS: don't forget about your MyFamily setting if you do not choose a solution that manages that for you automatically. -- https://mastodon.social/@nusenu

2 1

IPv6 Support or Uptime?
by Josh Lawson 24 Aug '20

24 Aug '20

I have IPv6 with my ISP, but there seems to be a bug in the firmware of my networking equipment that causes IPv6 to stop working periodically and I have to take my network down and bring it back up. If I do not do this, my relay stops functioning as I have torrc configured to use IPv6 and IPv4. So, my question is whether or not having a higher uptime is more important or having IPv6 support? My relay never goes down when on IPv4 only. I apparently cannot have both until the firmware bug is fixed. I appreciate it!

4 4

Tor bandwidth scanner "longclaw" slow to the US West Coast
by Neel Chauhan 23 Aug '20

23 Aug '20

Hi, I believe the Tor bandwidth scanner nicknamed "longclaw" is measuring relays in the US West Coast worse than other bandwidth scanners in North America. This happens on multiple ISPs, both ones I have and ones I don't. This includes two Tor exit instances on a dedicated server hosted in Los Angeles on Psychz Networks (AS40676): https://metrics.torproject.org/rs.html#details/156AAC3FAD1ACC8906316519DCB4… https://metrics.torproject.org/rs.html#details/A69CEB30328B1E85C6B167FECAF2… And two Tor non-exit instances on a home server in Seattle on Wave Broadband (AS11404), using a symmetrical Gigabit link: https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… The consensus weight values from longclaw are much lower than other North American bandwidth scanners, according to https://consensus-health.torproject.org/. This also affects other relays/ISPs on the West Coast US/Canada, such as Emerald Onion, AT&T U-verse, Sonic.net, and QuadraNet. The same ISPs/hosts in the East Coast aren't affected. This discrepancy in the measurement disproportionately favors European and East Coast US/Canada relays at the expense of West Coast relays, centralizing the Tor network even further than it already was. This wasn't an issue in the past, even as early as a few months ago. It only started appearing around June. Is anyone else hosting West Coast relays having this issue? Is "longclaw" actually measuring bandwidth from Europe? If so, WHY? I got in contact with "longclaw"'s admin and he wasn't too helpful. Best, Neel Chauhan === https://www.neelc.org/

4 4

Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)
by nusenu 23 Aug '20

23 Aug '20

Hi, here is my motivation for working on automated verification of operatorurls in ContactInfo: https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in… -- https://mastodon.social/@nusenu

9 16

relayor v20.1.0 is released
by nusenu 23 Aug '20

23 Aug '20

Hi, relayor v20.1.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor This version contains a bugfix, for corner cases where the newly generated tor configuration would not be used. relayor users are encouraged to update to this release. Changes ------- * bugfix: restart tor instead of reloading it when configuration changed (reloading is not supported by tor in all cases) * make tor_ContactInfo variable mandatory * update tor alpha version: 0.4.3 -> 0.4.4 * add support for FreeBSD 11.4 * increase min. ansible version to 2.9.12 kind regards, nusenu -- https://mastodon.social/@nusenu

1 0

Re: [tor-relays] Tor bandwidth scanner "longclaw" slow to the US West Coast
by info＠backplanedns.org 21 Aug '20

21 Aug '20

Same herehttps://metrics.torproject.org/rs.html#details/29BBD80A1702C7FDEF6557C4… from my T-Mobile 4G LTE device------ Original message------From: EddieDate: Wed, Aug 19, 2020 6:40 PMTo: tor-relays(a)lists.torproject.org;Cc: Subject:Re: [tor-relays] Tor bandwidth scanner "longclaw" slow to the US West CoastNot sure if my relay is similar, but I've been seeing a slow fall in consensus weight and advertised bandwidth over the past few months even though absolutely nothing has changed at my end. Well, apart from me *increasing* the RelayBandwidth settings. Also before I shut my relay down for a couple of weeks late last year, it had, and maintained guard status for about 6 months. Now it yo-yos in and out of guard on a regular basis. https://metrics.torproject.org/rs.html#details/D195E5CE8AE77BAC91673E6CFB7B… Cheers. On 8/15/2020 5:41 PM, Neel Chauhan wrote: > Hi, > > Is anyone else hosting West Coast relays having this issue? Is > "longclaw" actually measuring bandwidth from Europe? If so, WHY? > _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

don't publish detailed metrics about your relays
by nusenu 20 Aug '20

20 Aug '20

Don't publish detailed metrics about your relays. Here is a good example what NOT to do with your relays: http://51.77.135.89:19999/#menu_net_submenu_eno1;theme=slate http://51.75.144.43:19999/#menu_net_submenu_eno1;theme=slate The relay guide has detailed guidelines on what granularity is considered safe. -- https://mastodon.social/@nusenu

2 1

"Our IP Address has changed from" log lines
by torix＠protonmail.com 17 Aug '20

17 Aug '20

Dear list, I get this on just one of my relays - "Our IP Address has changed from xxx toxxx; rebuilding descriptor (source: METHOD=GETHOSTNAME HOSTNAME=xxx). Aug 11 00:33:54.000 [notice] Your IP address seems to have changed to xxx (METHOD=GETHOSTNAME HOSTNAME=xxx). Updating." This is 99% of my tor log. What's going on? Is this normal for a middle relay and somewhere I've set the log level to be too sensitive? My torrc log line: Log notice file /var/log/tor/notices.log # location to log notices, warnings, and errors: But my other relays have the same line. I was looking at this relay because it only seems to connect with the bwauths every few days to a week - now not showing at all. It has stayed at 200 connections for the last 6 weeks as a result. It is currently missing completely from the tor metrics list. But I have no idea if these 2 things are related. I have run it with and without ipv6 with the same results. Any help I would appreciate, --Torix

2 2

Possible to run multiple tor instances from one machine?
by Keifer Bly 16 Aug '20

16 Aug '20

6 5

need help with riseup account
by potlatch 14 Aug '20

14 Aug '20

Hello server operators, I have a favor to ask of someone with a riseup.net email account. I have an account but screwed something up changing passwords. Riseup won't/can't help me fix the problem or issue new access codes. My anonymous email account is useless. This would not be a problem but I travel (pre and post Covid) to countries where I have exit relays. [1-9] Exit relays in some of these countries are problematic--it's why I put them in hard-to-reach places. I would like to re-establish my riseup email account before I travel again. Will someone volunteer to provide me with a riseup access code? Thanks [1] Romania/exit 4061C553CA88021B8302F0814365070AAE617270 [2] Finland/exit 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 [3] Moldova/exit 742C45F2D9004AADE0077E528A4418A6A81BC2BA [4] Moldova/exit B06F093A3D4DFAD3E923F4F28A74901BD4F74EB1 [5] Seattle 2F642EAB773CE94EF218C0CB38604040283F347A [6] bridge 4D5A781282C3FCC3EEE3E63FAE69032BD10F1879 [7] Albania/exit 373BF7A2CD16E86D4C5BEC591A41945C9AED392D [8] Albania/exit D78D1B4489CF4FFB0FD74014BDF2D600D8EE5B05 [9] Chile F120F1B939C7ED8FD62347A800F2B67BE84D84DA Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

Cookie Authorization files
by Kathi 13 Aug '20

13 Aug '20

I have no Idea where to go with this, a little help please! :-) I'm trying to set up and operate a bridge. Thank You for any help!! Kathi I get this repeated error message in nyx: specify an explicit cookieauthfile to make it group readable (3 dups) TORRC says: CookieAuthentication 1 CookieAuthFileGroupReadable 1 -- This email has been checked for viruses by AVG. https://www.avg.com

1 0

wrong country in METRICS
by tor-operator-sahara-it 11 Aug '20

11 Aug '20

Hello. I am very new tor operator. For now i have only two relays. And one of them show wrong country in METRICS. I run in Estonia, but it shown as Germany. The same AS has another two relays, both in Estonia. IP-lookup shows Estonia. How change contry in METRICS? Thank you.

3 6

Guard flag got removed after only 48 hours of downtime.
by William Kane 11 Aug '20

11 Aug '20

Please discard the previous (empty) email, it was an error on my end. Today, I noticed that my guard flag has been taken away: https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73A… Does this have to do with the recent two, major downtime's of the relay? While I wasn't monitoring the server, the kernel decided (or rather oom-killer did) to reap the tor process for consuming too much memory (keep in mind, this is a virtual machine with only 1GB of RAM which running another daemon consuming about ~92MB's of RAM). I promptly restarted the relay, but the same thing happened again yesterday. So today, I manually set a lower MaxMemInQueues value instead of letting Tor calculate one for me - 640MB's instead of 732MB's. Still, I am confused as for why the guard flag has been taken away - I recently opted in to be a fallback directory mirror, does this have anything to do with it? The relay was stable and online for almost a year, so only 48 hours of downtime shouldn't affect the variables qualifying a relay to become and stay a guard that much? If this is because of the directory mirror thing, then please take my relay out of that pool - I want to stay a guard for a number of reasons - mainly because my host is only hosting about 10 tor relays unlike all the other big hosters that are commonly used - network variety is very important or so I've been taught, especially when it comes to guard relays. If this is a mistake on Tor Project's end, I please ask for it to be resolved - however, if it's the Directory Authorities disqualifying my relay, then there's nothing to be done except to wait. Greetings, William Kane

5 11

why non-exit node becomes last in the circuits?
by tor-operator-sahara-it 10 Aug '20

10 Aug '20

Hello. On Tails: Today i found that my jabber messenger (with server in *.onion) use onion circuit with three nodes, and two times from two exit-nodes were very strange. https://metrics.torproject.org/rs.html#details/92E807AC5E23CCD9FE623EA4DC02… https://metrics.torproject.org/rs.html#details/AC5CECEF6AF649F2A7F047D102FE… They havnt exit-flag. Why it happen?

3 3