- tor-relays - lists.torproject.org

(No Subject)
by Azraxiel 11 Feb '25

11 Feb '25

Hello, does anybody use the Opensense Plugin for Tor? I followed every step in the Documention for setting up a Relay but it doesn't work and the opnsense community can't help either. Best regards Azra Sent from Proton Mail Android

2 1

Mass-email sent to relay operators
by Zachary 10 Feb '25

10 Feb '25

Hello my fellow relay operators, I just received an email that was sent to many relay operators' contact emails. The content is as follows: // Start message Hello to all the relays operators. My name is Zakwan Kalb. I'm investigating a possible ongoing end-to-end confirmation attack run by the Torproject. Please reply to me if you have encountered one of the following and provide as much information as possible: 1. Your relay has been removed by the Torproject. (You've seen something like that in your log files: "http status 400 ("Fingerprint and/or ed25519 identity is marked rejected ...") 2. The Torproject added flags it's not supposed to add to your relays (BadExit, MiddleOnly) 3. You have been asked by the Torproject to install unknown software, spy on users or do something else that's suspicious 4. You know something about the ongoing attack I have some evidence of the attack: the Torproject doesn't allow people to run relays by removing them from the network or making them unusable as Guard or Exit for no known reason for years. A random person cannot run a Guard or Exit relay. Thus the Tor network is entirely run by the people chosen by the Torproject by unknown criteria. More evidence and details are needed. I think we need to discuss this issue with each other, contact the media and freedom of speech organizations and let people know what's happening. // End message Looking through his mailing list history it looks like he was asking about this same thing back in 2021. Just wanted to give everyone a heads up. It doesn't seem like there's any malicious intent, maybe a bit of schizophrenia perhaps, but I've reached back out simply asking if he has any proof of anything actually going on just to appease my own curiosity. I have no further comment about this. Zachary

3 2

Adding falgs to new relays
by ZK 10 Feb '25

10 Feb '25

I'm asking the Torpoject to publicly answer the question: why do you add BadExit and MiddleOnly flags to new relays? Please don't lie as you did before and list the criteria here

3 2

Web Tunnel Bridges
by gerard＠bulger.co.uk 29 Jan '25

29 Jan '25

Web tunnel bridges Port 443, https I set up three of these. One in UK, one in Australia and one in USA. Only the USA service is attracting traffic. This might be normal. The others are very quiet. Then I look at it on Tor Relay metric it reports Running <https://metrics.torproject.org/rs.html#search/flag:running> V2Dir <https://metrics.torproject.org/rs.html#search/flag:v2dir> Valid <https://metrics.torproject.org/rs.html#search/flag:valid> Additional Flags none First Seen 2025-01-26 14:22:20 Last Restarted 2025-01-28 20:49:38 Platform Tor 0.4.8.13 on Linux Transport protocols Transport protocols supported by this bridge. webtunnel Bridge distribution mechanism Settings <https://bridges.torproject.org/info#settings> The difference between the quiet ones and the active USA server is Bridge Distribution Mechanism it says "settings" rather than HPPTS for my USA one Does this change automatically or do I need to change something? Gerry

1 0

Re: Having trouble with setting up a relay in a censored country.
by George Hartley 22 Jan '25

22 Jan '25

Hi, sorry for the late reply, I was busy working. The only thing that stands out to me immediately is that you configured two separate ControlPort authentication methods: > HashedControlPassword XX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > CookieAuthentication 1 You might want to comment out the first line. Otherwise, everything else looks correct. P.S: Since you do not run a bridge, there is no need to un-comment the obfs4 related settings: > ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy > ServerTransportListenAddr obfs4 0.0.0.0:9002 This will do nothing, unless you actually configure the relay to be a bridge. Try to comment both HashedControlPassword and the obfs4 settings, and restart the relay. nyx should now work - additionally, you might want to check the log using journalctl -u tor. There should be a line stating that your ORPort is reachable from the outside, and that your server descriptor has been published. If that is not the case, then I would conclude that your host / ISP is up to some "funny" business, and you might not be able to run a normal relay. Since I can't find any relay with your specified nickname, I assume that it is still not working. However, you could still run an obfs4 bridge, which should work fine in Russia - if you can do this, please do.. any relay or bridge not run by intelligence agencies or government helps! Regards, -GH On Wednesday, January 15th, 2025 at 3:23 PM, nyyymi <nyyymi(a)protonmail.com> wrote: > Hi, here is my torrc file. Enabling cookieauth didn't change anything >

1 0

All of my nodes have been banned
by petition_tricky750＠simplelogin.com 20 Jan '25

20 Jan '25

Hello, What are some of the most common reasons for relays and exits to be banned from Tor? Had it happen to all of my 5 nodes and I'm currently awaiting response from bad-relays list. They all present this in logs Jan 18 20:41:40 example.com Tor[2439671]: http status 400 ("Fingerprint and/or ed25519 identity is marked rejected -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to bad-relays(a)lists.torproject.org mentioning your fingerprint(s)?") response from dirserver 204.13.164.118:80. Please correct. All of them have been running just fine before 4E1E745FF661657E3D3CE10DF1A1AEEF1D3F7996 2D9D4F0D298C68044F2476DFCB191CEBCE7AC860 078B7B30953A6DA8BB73612035BB876EA90847E3 DE3550EBB205660730900C05B6330B663CEED25434A09907FB89BE444A0A456C12A1A9C54CCF1A8A I'm genuinely curious if others also had it happen to them, and the reason behind it. Thank you.

2 2

Possible attack on servers via Tor Guard relays?
by x9p 19 Jan '25

19 Jan '25

Hi, I am running a relay and other servers. Sometimes doing SSHD over Tor via a hidden service in a VPS in openbsd.amsterdam. In all my other setups, in other providers, I do not see this problem happening. Upon connecting for the first time, I do get a "banner line contains invalid characters" error, and the connection is terminated. (MSG1) Upon connecting for the second time, everything goes smooth. (MSG2) Problem is happening on my 2 servers in openbsd.amsterdam. Any directions into debugging this problem? Both via Tor or via SSHD? Is it possible a bad guard is logging the IPs first connecting, then dropping the connection, and then allowing the connection to succeed later? Any directions would be appreciated to solve the problem. System: uname -a OpenBSD xxxx.yyyy.com 7.6 GENERIC#501 amd64 Tor version: Tor version 0.4.8.13. MSG1 (BAD): localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config debug1: /root/.ssh/config line 284: Applying options for ams02 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 22: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: Connecting to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion [127.42.42.0] port 60113. debug1: Connection established. debug1: identity file /root/.ssh/oams002_2 type 0 debug1: identity file /root/.ssh/oams002_2-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.9 kex_exchange_identification: banner line contains invalid characters banner exchange: Connection to 127.42.42.0 port 60113: invalid format MSG2 (OK): localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config debug1: /root/.ssh/config line 284: Applying options for ams02 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 22: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: Connecting to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion [127.42.42.0] port 60113. debug1: Connection established. debug1: identity file /root/.ssh/oams002_2 type 0 debug1: identity file /root/.ssh/oams002_2-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9 debug1: compat_banner: match: OpenSSH_9.9 pat OpenSSH* compat 0x04000000 debug1: Authenticating to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion:60113 as 'xxxxxxxxxx' debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: sntrup761x25519-sha512 debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: chacha20-poly1305(a)openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305(a)openssh.com MAC: <implicit> compression: none --x9p

3 2

Re: Having trouble with setting up a relay in a censored country.
by Marco Moock 16 Jan '25

16 Jan '25

Am 15.01.2025 um 16:25:42 Uhr schrieb nyyymi: > > Please post your torrc (without comments). > > and the IP addresses of the machine. > Ip is 192.168.1.113. This is a private IPv4 address, unreachable from the internet by design. You need to set up port forwarding in your router to make it reachable. Did you do that? If your ISP provides IPv6, you need to create a firewall rule in your router to allow access. Because that doesn't use NAT, no port forwarding is needed. > I've let the relay run for a bit, errors started > to accumulate. "Problem bootstrapping. Stuck at 5% (conn): Connecting > to a relay. (Connection timed out; TIMEOUT; count 25.." and "25 > connections died in state connect()ing with SSL state (no SSL object)" Please test ncat -v tr.dorfdsl.de 9001 If that doesn't work, those problems must be first fixed. -- Gruß Marco Send unsolicited bulk mail to 1736954742muell(a)cartoonies.org

1 0

Re: Having trouble with setting up a relay in a censored country.
by Marco Moock 16 Jan '25

16 Jan '25

Am Wed, 15 Jan 2025 16:01:44 +0000 schrieb nyyymi <nyyymi(a)protonmail.com>: > Nickname is nyymi. It doesn't show up on the relay search That is an indicator that something isn't working. Please post your torrc (without comments). and the IP addresses of the machine.

1 0

Having trouble with setting up a relay in a censored country.
by nyyymi 15 Jan '25

15 Jan '25

Hello. For the past few days I've been trying to open a tor-relay on my old laptop running arch. The tor service starts fine but when I check nyx no traffic goes through me, both download and upload is 0. Nyx shows Unknown:portnumber. I doubt that the port is closed or somehow unavailable since arch's defaults are wide open. And for some reason my tor version (0.4.8.13) shows up as "unknown" as well. I thought the issue may lie in torproject's ban in Russia but somehow other people run relays just fine? (https://metrics.torproject.org/rs.html#search/country:ru) I've set up obsf4 as well but It didn't change anything Im quite new in all of this so bear with me. Thanks -Arttu

3 2

Question: Relay speed South Africa
by Carlo P. 15 Jan '25

15 Jan '25

Hello experts, I have, from the same provider, two VPS with same specs (also same port speed of 200MBit/s, verified via speedtest-cli) - one in Germany, one in South Africa. Whilst the German one behaves as expected (two fast relays on it), the two relays in South Africa won't really get up to speed - barely traffic, and advertised bandwidth below 2MB/s . In general, search for country:za on metrics does not really look too impressive. Do you have any idea about the reason, i.e. why, despite the VPS having the bandwidth, the relays do not get up to speed? Thanks - C. -- Sent with https://mailfence.com Secure and private email

3 2

My web-bridges looks offline in the Relay Search
by Brook Rameev 10 Jan '25

10 Jan '25

Hello! Today all my web tunnel relays become offline according to https://metrics.torproject.org/rs.html#search/BrookRameev (my web tunnel bridges have the 'W' suffix). But they are surely online (except BrookRameev7W, which is surely dead). I see traffic on them, I see no problems in logs, nothing changed in their configuration. I also checked them using tor browser. All of them "went down" at the same time: " 1 hour 17 minute and 48 seconds" from the current moment. The problem relates only to webtunnels, ordinal relays work normally. Good luck.

4 5

Tor node shutdown
by Tschador 30 Dec '24

30 Dec '24

FYI: My Tor node »TorMachine« (6A7551EEE18F78A9813096E82BF84F740D32B911) will be shut down on 2024-12-31. Sorry folks – but I'm too old for the job. Good luck and all the best wishes for the future!

3 2

Re: Strange UFW logs from another Tor node - update.
by code9n＠pm.me 30 Dec '24

30 Dec '24

On Thursday, December 26th, 2024 at 12:00, tor-relays-request(a)lists.torproject.org <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 email, send a message with subject or > body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: What're these ufw block logs saying? (George Hartley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Dec 2024 19:55:08 +0000 > From: George Hartley hartley_george(a)proton.me > > Subject: [tor-relays] Re: What're these ufw block logs saying? > To: "tor-relays(a)lists.torproject.org" > tor-relays(a)lists.torproject.org, "code9n(a)pm.me" code9n(a)pm.me > > Message-ID: <9ct9ASpMXXnKRo6w2spT3sRh5hspGh1EqSneiQFDwbhNlI4ZZLyU8F2f3 > 3x_KowFg5e-IYk7P0soKNit50FrGm61lKh50WazDZNkCyfJ5qs=(a)proton.me> > > Content-Type: multipart/signed; protocol="application/pgp-signature"; > micalg=pgp-sha512; boundary="------b4924ec6e97f2ee894d2a6644c496d719be > 5fc5bbba1fc1072274ea1ae63bf7c"; charset=utf-8 > > Hello, > > this is weird indeed, but the packet size is interesting. > > For example, using the tool MTR, you can trace the route to another host using different protocols: > > 1.) ICMP being the obvious default. > 2.) TCP. > 3.) UDP. > > If all these TCP packets were just below 100 bytes, that would be my guess. > > Looking up the relay, there is a name, e-mail contact and PGP key ID for this node operator: > > "Tom" > tom(a)kh6ilt.org > 0x620836CF > > Just ask this operator first to check his server for something that could cause this, and if he is running something special alongside Tor. > > Then, if that does not sufficiently explain or resolve the spurious packets, I would recommend to install tcpdump, and to use a syntax like: > > > sudo tcpdump tcp and src host 155.138.146.249 and not dst port 443 -w dump.pcap > > > You will need elevated privileges in order to run tcpdump. > > This will guarantee to exclude all legitimate Tor traffic originating from his server by excluding destination port 443, and log the remaining packets to file "dump.pcap". > > You can add the -i <interface> parameter to the beginning of the tcpdump argument list if you have multiple public interfaces. > > > Like so: > > tcpdump -i eth0 <other arguments> > > > Once the dump is finished, you can send signal 2 / SIGINT if the process is running in the background, or simply press CTRL + C.. both ways lead to a graceful exit of tcpdump: > > > kill --signal 2 tcpdump > > > Now you can inspect the traffic using a GUI tool like Wireshark (highly recommended) which can parse .pcap files and decode / recognize many types of packets. > > Please report back what you find! > > All the best, > -GH > > > On Monday, December 23rd, 2024 at 6:46 PM, code9n via tor-relays tor-relays(a)lists.torproject.org wrote: > > > Hi, > > > re. my (guard / middle relay) : 181.215.226.65 : 443 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… > > > I'm getting traffic from another (non-exit) relay : 155.138.146.249 : 9001 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… ( CCed) > > > always from port 9001 but to different, high number destination (on my vps) ports which ufw is blocking. > > This isn't Tor traffic I'm blocking, right? That would only come to my ORport? Is this abuse attempts? Under the cover of Tor relay traffic? They're quite infrequent (sample) : > > > Dec 23 14:33:29 xxxxxxxx kernel: [2228957.705152] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:33:34 xxxxxxxx kernel: [2228962.788380] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:52:36 xxxxxxxx kernel: [2230104.586835] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:53:16 xxxxxxxx kernel: [2230144.487410] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:53:54 xxxxxxxx kernel: [2230183.086653] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:16:42 xxxxxxxx kernel: [2231550.336547] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 > > > Dec 23 15:18:15 xxxxxxxx kernel: [2231644.112246] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:22:31 xxxxxxxx kernel: [2231900.117391] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 > > > Dec 23 15:42:30 xxxxxxxx kernel: [2233098.835686] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:43:34 xxxxxxxx kernel: [2233162.852181] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:45:42 xxxxxxxx kernel: [2233290.874044] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=0 RES=0x00 ACK PSH RST URGP=0 > > > Dec 23 16:14:43 xxxxxxxx kernel: [2235032.148940] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=1124 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=47586 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Thanks, > > > Pete > >

1 0

Re: Question about middle relays and common web usage annoyances
by Zachary 29 Dec '24

29 Dec '24

I wanted to chime in. I run an entry-middle relay in my basement connected to 300mbps fiber. It doesn’t push much traffic but it’s mine and I’m proud. The bank where I do my banking blocked our IP. After carefully explaining the situation to their IT team, they contacted their web host and had them whitelist my IP. It changed recently because I registered a new router on my ISP’s network, and they happily whitelisted that one too. My bank is a small town bank where everyone knows everyone, and I’m sure it would be much harder at some big corporate bank. Nonetheless, it’s always possible to make a change! Zachary

1 0

Question about middle relays and common web usage annoyances
by tor＠computhings.be 27 Dec '24

27 Dec '24

Hello, I'm located in Belgium. I keep two small middle relays (no exit, not even guard)… https://metrics.torproject.org/rs.html#details/89B4597169A9DBB171F0B4629C73… https://metrics.torproject.org/rs.html#details/07E3A0DC6AD4A5F07D1AF942626E… If I browse the web using a common browser using the basic services of the ISPs (no torbrowser, no tor network) and at least since may 2023, I've observed that some websites (banks, federal services,…) simply don't respond when I want to open their webpages. If I use another IP from the same locations (using vpn, ssh proxy, whatever), those same websites simply respond and works without issue. If I switch back to the local ISP IP, those are unreachable, and so on. If I contact those ISPs or the banks IT services, for them there are no problem. For me, it's clear that hosting simple middle relays puts my ISPs IPs to some black lists handled by who knows who. If hosting basic middle relays is blocking common web services, it will be hard / nearly impossible for me to encourage family, friends or customers to host a basic middle relays. Maybe there is no need for more and more middle relays, I don't know. Does someone encounter the same kind of annoyances ? regards, tierce

6 5

What're these ufw block logs saying?
by code9n＠pm.me 25 Dec '24

25 Dec '24

Hi, re. my (guard / middle relay) : 181.215.226.65 : 443 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… I'm getting traffic from another (non-exit) relay : 155.138.146.249 : 9001 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… ( CCed) always from port 9001 but to different, high number destination (on my vps) ports which ufw is blocking. This isn't Tor traffic I'm blocking, right? That would only come to my ORport? Is this abuse attempts? Under the cover of Tor relay traffic? They're quite infrequent (sample) : Dec 23 14:33:29 xxxxxxxx kernel: [2228957.705152] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:33:34 xxxxxxxx kernel: [2228962.788380] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:52:36 xxxxxxxx kernel: [2230104.586835] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:53:16 xxxxxxxx kernel: [2230144.487410] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:53:54 xxxxxxxx kernel: [2230183.086653] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:16:42 xxxxxxxx kernel: [2231550.336547] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 Dec 23 15:18:15 xxxxxxxx kernel: [2231644.112246] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:22:31 xxxxxxxx kernel: [2231900.117391] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 Dec 23 15:42:30 xxxxxxxx kernel: [2233098.835686] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:43:34 xxxxxxxx kernel: [2233162.852181] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:45:42 xxxxxxxx kernel: [2233290.874044] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=0 RES=0x00 ACK PSH RST URGP=0 Dec 23 16:14:43 xxxxxxxx kernel: [2235032.148940] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=1124 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=47586 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Thanks, Pete

2 1

An update regarding the raid in August
by Artikel 5 e.V. 25 Dec '24

25 Dec '24

Hello everyone! The holidays and the 38C3 are coming up. Unfortunately nobody from our organization will be able to attend the congress in person this year. In case that the police raid in August is going to be a topic for the relay operators meetup, we would like to provide you with a small update regarding the current state here. The legal complaint procedure is still ongoing but last week -after several delays- we were finally able to get access to the court records for the case. We are not allowed to (and will not) directly quote/publish any of this material. We can however make the following information public at this point: - This case is about an (unsuccessful) cybergrooming attempt from Q2/2024. - We have a list of IP-Adresses supposedly used by the perpetrator. - Only one of them is one of our exit nodes. - Others point to other exit nodes. - Some of these other exit nodes are also run by German organizations. - To our knowledge, none of these other organizations were visited like we were. - In contrast to what the prosecution stated as part of the complaint procedure, several pages in the case file clearly state that they knew and fully understood that the server in question was never located at the home/mail address of our organization. - This was clear even before the case was handed off to the local department responsible for our current registered address. - At least some of the people involved also fully understand Tor and the implications. - As we suspected, they also knew (and documented) upfront that this was a home address and not some sort of rented office or server farm. - In combination, it looks a lot like several involved parties did not fully read and/or understand the entire file before playing their part in the puzzle. It pretty much confirms what we already suspected. Whether all this is a simple result of repeated organizational failure, unfortunate lack of technical understanding or even malicious intent against us or the Tor network in general, is an interpretation we will leave up to you. Just be aware that if you are operating Tor exits in Germany, this could currently happen to you as well - even if you follow ALL the best-practices rules and recommendations currently out there. Maybe we just have the "luck" of being registered at the wrong city with the wrong people working on these cases. Maybe not. In any case... enjoy the holidays and (if you attend) the congress in Hamburg as well. Kind regards, Gero for Artikel 5 e.V.

1 0

Re: Question about middle relays and common web usage annoyances
by Isaac Grover, Aileron I.T. 24 Dec '24

24 Dec '24

Good morning tierce, I suspect that the sites you're unable to access are using https://www.dan.me.uk/dnsbl or another blocklist provider that naively blocks middle relays and/or entry relays instead of/in addition to exit relays. If you don't want to or can't pay for third-party hosting to move your middle relay outside your network, one solution would be to contact your ISP and move from your single IP address to a block of five IP addresses, with one IP address dedicated to your middle relay and the other IP addresses dedicated to your browsing and other traffic needs. Make your day great, Isaac Grover, President/vCIO Aileron I.T. – “ Because #ProactiveIsBetter ” O: 715-377-0440, F:715-690-1029, W: www.aileronit.com -----Original Message----- From: tor(a)computhings.be Hello, I'm located in Belgium. I keep two small middle relays (no exit, not even guard)… https://metrics.torproject.org/rs.html#details/89B4597169A9DBB171F0B4629C73… https://metrics.torproject.org/rs.html#details/07E3A0DC6AD4A5F07D1AF942626E… If I browse the web using a common browser using the basic services of the ISPs (no torbrowser, no tor network) and at least since may 2023, I've observed that some websites (banks, federal services,…) simply don't respond when I want to open their webpages. If I use another IP from the same locations (using vpn, ssh proxy, whatever), those same websites simply respond and works without issue. If I switch back to the local ISP IP, those are unreachable, and so on. If I contact those ISPs or the banks IT services, for them there are no problem. For me, it's clear that hosting simple middle relays puts my ISPs IPs to some black lists handled by who knows who. If hosting basic middle relays is blocking common web services, it will be hard / nearly impossible for me to encourage family, friends or customers to host a basic middle relays. Maybe there is no need for more and more middle relays, I don't know. Does someone encounter the same kind of annoyances ? regards, tierce ------------------------------ Subject: Digest Footer _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org ------------------------------ End of tor-relays Digest, Vol 167, Issue 13 *******************************************

1 0

Announcing the shutdown of our Tor Relay "ExitTheMatrix"
by George Hartley 23 Dec '24

23 Dec '24

Hello dear list readers and contributors, We received UDP floods (mostly through DNS Amplification) which were usually 60-70 GBit/s in size, up until a month ago this was not a problem for most of the exit relays lifetime, because we had a custom Tilera sitting between our server and the remaining infrastructure. Since the Tilera hardware was leftover hardware that we initially bought, maintained and installed in agreement with the colocation contract, the DC had no responsibility for it. Last month the Tilera failed, and additionally the DC had constant issues with their line-cards. So, now we just had our 1GbE link and the default 10GbE scrubbing provided by the DC's routers. This was not nearly enough, the largest attack ever we saw after that was reported to be over 140 GBit/s and also knocked some other servers in the same room offline too. These attacks were not directed towards my VM's bridged failover IP on the colocated server that I share with my friend, but towards the game servers he was hosting on his main NIC IP. Right now, every single attack above 10 GBit/s traffic will result in a null-route if it exceeds 60 seconds. This is incredibly cheap for malicious attackers to achieve, so I decided to take the relay offline for good and wipe the keys as well, both on my encrypted online cloud sync provider (MEGA) as well as from my machines MEGASync folder. The fingerprint is / was: 0F8538398C61ECBE83F595E3716F7CE7E4C77B21 If you look it up now, you will see it used to be on my own link for a while, but since we don't have a static IPv4 assignment (VDSL2 is still incredibly popular in rural areas such as the one that I live in), so the constantly changing IP address would have been just a pain in the butt for clients (one forced DSL disconnect every 24 hours). I currently don't have enough money for a decent dedicated server or VM and a host that I can trust which doesn't have too many Tor relays already. In total, according to vnstat, we routed 20TB's of exit traffic per month for the last 3 months, the relay was up for a total of around 292 days with a fresh set of secret keys, the relay before that, same name but different keys, was online for around 60 days while optimizing the hypervisor, libvirtd and guest OS for maximum performance / throughput). According to my calculation, we have contributed roughly ~180 Terabytes of exit traffic, and maybe 500GB's of Guard traffic (this was mainly an exit relay, so I didn't expect much more). I personally have been hosting Tor (Exit) Nodes for almost 10 years under different names and e-mail addresses, and it is definitely a New Year's resolution to continue that fashion. Tor was incredibly helpful for me, so I will continue return the favor. I also will continue to be active on the mailing list to help new people, as long as my time allows for it. Happy Holidays to everyone reading this, I sincerely hope you have a good time with your family and friends. All the best, -GH

1 0

Unable to bind to IPv6
by Eddie 23 Dec '24

23 Dec '24

I had an issue with my VPS that I didn't notice for a while where I had lost my IPv6 addressing. After contacting support they have restored the IPv6 address, but I'm now unable to bind to the address. I've a feeling it's more either my configuration or the VPS configuration at fault, not tor, but I thought I'd throw it out for ideas, as I'm not that confident (yet) with IPv6 stuff. Here's the interface: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether a6:6a:08:73:42:27 brd ff:ff:ff:ff:ff:ff altname enp0s18 inet xxx.yyy.87.222/26 brd xxx.yyy.87.255 scope global eth0 valid_lft forever preferred_lft forever inet6 aaaa:bbbb:1a:10::1/64 scope global dadfailed tentative valid_lft forever preferred_lft forever inet6 fe80::a46a:8ff:fe73:4227/64 scope link valid_lft forever preferred_lft forever root@fw1475:~# ip -6 route aaaa:bbbb:1a:10::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium default via aaaa:bbbb:1a:10:a46a:8ff:fe73:4227 dev eth0 proto static metric 1024 pref medium And the netplan configuration: root@fw1475:~# netplan status Online state: online DNS Addresses: 127.0.0.53 (stub) DNS Search: . ● 1: lo ethernet UNKNOWN/UP (unmanaged) MAC Address: 00:00:00:00:00:00 Addresses: 127.0.0.1/8 ::1/128 ● 2: eth0 ethernet UP (networkd: eth0) MAC Address: a6:6a:08:73:42:27 (Red Hat, Inc.) Addresses: xxx.yyy.87.222/26 aaaa:bbbb:1a:10::1/64 fe80::a46a:8ff:fe73:4227/64 (link) DNS Addresses: 1.1.1.1 1.0.0.1 Routes: default via xxx.yyy.87.193 (static) xxx.yyy.87.192/26 from xxx.yyy.87.222 (link) aaaa:bbbb:1a:10::/64 metric 256 fe80::/64 metric 256 default via aaaa:bbbb:1a:10:a46a:8ff:fe73:4227 metric 1024 (static) And this is what I get from the IPv6 OR port, determined by commenting/uncommenting the relevant line in my previously working configuration: 2024-12-14T20:36:38.782783+00:00 fw1475 tor[2317]: Dec 14 20:36:38.782 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. 2024-12-14T20:36:38.782821+00:00 fw1475 tor[2317]: Dec 14 20:36:38.782 [err] Reading config failed--see warnings above. Any ideas/help would be gratefully accepted. Cheers, Eddie

3 3

Standalone snowflake proxy re-testing as restricted
by 0x5fcfbd30＠proton.me 21 Dec '24

21 Dec '24

Hey there, I have been running a standalone snowflake proxy for quite some time now. First in a docker container, but now in its own linux container to have more control over it myself. This has worked out great so far with an ephemeral-ports-range of 200 ports. Those are forwarded to the linux container in my router. Since a few days, I noticed a big drop in connections per hour. I restarted the proxy and it tested as restricted even though all ports are properly forwarded and I see the UDP packets reaching the machine via tcpdump. After several restarts, I finally got it to confirm unrestricted but 6 hours later (default re-test period?), its restricted again. Just to rule out the obvious, is it only me having this problem? I'm building from source and git log says: commit f940d7d6efe423c4d7a901a33d34bb51086b4a41 Date: Tue Nov 26 16:19:49 2024 +0000 chore(deps): update module github.com/pion/ice/v4 to v4.0.3 I wonder if this is a problem of my local setup or a bug snowflake itself. Any ideas? Best regards, 0x5fcfbd30

3 3

Tor activities at 38th Chaos Communication Congress, Hamburg, 2024
by gus 20 Dec '24

20 Dec '24

Hello, Join us for Tor activities @ 38th Chaos Communication Congress (38C3): https://events.ccc.de/congress/2024/ The 38th Chaos Communication Congress runs from December 27 to 30, 2024 in Hamburg. We've got a lineup of Tor activities happening during this congress! - December 28: "Guardians of the Onion" (20:30 - 21:30, Day 2): (live streaming, recorded) https://events.ccc.de/congress/2024/hub/en/event/guardians-of-the-onion-ens… - December 29: "Tor Relay Operator meetup & State of the Onion Operators" (23:00 - 01:00, Day 3): https://events.ccc.de/congress/2024/hub/en/event/tor-relay-operators-meetup… - December 30: "All things Tor related!" (11:00 - 13:00, Day 4): https://events.ccc.de/congress/2024/hub/en/event/tor/ - Tor Project assembly (near Cold North/BornHack assembly): https://events.ccc.de/congress/2024/hub/en/assembly/tor-project/ See you there! \o/ Gus -- The Tor Project Community Team Lead

1 0

Next Tor Relay Operator Meetup - December 7th 2024 @ 1900 UTC
by gus 17 Dec '24

17 Dec '24

Dear Relay operators, Save the date! Our next online meetup is happening on Saturday, December 7th, 2024 at 1900 UTC[1]. I'm happy to announce that we'll have a special guest, Ben Collier, joining us to discuss his new book:"Tor: From the Dark Web to the Future of Privacy."[2] (2024) ## Agenda 1. Announcements - New WebTunnel bridges campaign - https://blog.torproject.org/call-for-webtunnel-bridges/ - Upcoming in-person events 2. Ben Collier's book presentation & discussion ## How to join Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - Date & Time: Saturday, December 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 link above. The room will open 10 minutes before the meetup starts. ## DON'T MISS SOTO This month, the Tor team was very busy with State of the Onion (SOTO), and I'd like to invite you all to watch the videos: - Community Day: https://www.youtube.com/watch?v=EODNtLqD7f8 - Tor Project Teams update: https://www.youtube.com/watch?v=HjPdReNmf_g cheers, Gus [1] If you're confused about UTC and your timezone, @anarcat maintains a cool project called undertime - https://gitlab.com/anarcat/undertime [2] "Tor: From the Dark Web to the Future of Privacy" book is available here: https://direct.mit.edu/books/oa-monograph/5761/TorFrom-the-Dark-Web-to-the-… -- The Tor Project Community Team Lead

2 3

install OBFS4
by Keifer Bly 13 Dec '24

13 Dec '24

Hi, So for Debain 12, what is the command to install OBFS4? For my bridge at https://metrics.torproject.org/rs.html#details/0E547D99DEB753B20A19EEAA053C… Even though I configured obfs4 in torrc its saying no transport protocols. Thanks. The torrc Nickname udeservefreedom ORPort <hidden> Log notice file /var/tornitces.log/notices.log SocksPort 0 BridgeRelay 1 PublishServerDescriptor bridge BridgeDistribution email ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<hidden> ExtOrPort auto ExitPolicy reject *:* ContactInfo keiferdodderblyyatgmaildoddercom --Keifer

4 6

Question about WebTunnel bridge
by apfelnymous＠tutanota.de 11 Dec '24

11 Dec '24

Hi, can I run a webtunnel bridge on the same device that already runs a common bridge ? I have 1 bridge relay running 24/7, I could setup another machine for the webtunnel bridge but I can't get another ipv4 . Should I put it down and replace with a webtunnel bridge ? Thoughts ? Cheers

1 0

Tor Relay via Tailscale Funnel?
by Derek Martin 08 Dec '24

08 Dec '24

Long time lurker. Saw the call for more middle relays. I have a large amount of spare capacity on my homeserver and 2.5GB fiber to the house. Is there precedent for running a relay through a Tailscale Funnel? I would need to check to make sure Tailscale TOS was okay with it, but to my ISP, it'd just look like Wireguard traffic. Any thoughts or fools errand?

1 0

ORPort bug is an impediment to running on my servers
by Red Oaive 07 Dec '24

07 Dec '24

Bug 40994 (reported at https://gitlab.torproject.org/tpo/core/tor/-/issues/40994) has become a fairly serious impediment to running relays. I generally obtain two ipv4 addresses on my machines and the ports I want to use for tor are not available on both addresses. So listening on 0.0.0.0 is not an option for me. And listening on a specific address incurs the serious problem where NoListen even when not specified seems to be assumed without recourse (see discussion at https://v236xhqtyullodhf26szyjepvkbv6iitrhjgrqj4avaoukebkk6n6syd.onion/t/re…)

1 2

Countering botnet traffic using DNS blocklists
by Imre Jonk 07 Dec '24

07 Dec '24

Hi all, Haven't posted in a while here, it's good to see that this list is still going strong :) I hope that some Tor Project employee can reply on list item 2 below. I've been co-operating an exit relay for some four years now. My usual response to abuse notifications is adding a reject rule to my ExitPolicy that blocks outgoing traffic to the attacked IP address/subnet. I do this mostly to prevent overhead for the volunteer abuse coordinators that operate the network that my exit resides in, but also to "do something" (not much, but at least something) for the attacked network. Yesterday however, I received a notification from my government's proactive security alerting service, notifying me of a botnet using my exit relay for communication. Now, I both like the Tor Project and privacy in general, and at the same time dislike botnets. And this made me think: what if I configure my DNS resolution to block queries for known botnet C&C domains? It would make it a bit harder to abuse the Tor network for botnet communications, and save a bit of bandwidth for users that have a good faith need for anonimity (you know, these users [1]). [1] https://2019.www.torproject.org/about/torusers.html.en Now, I'm aware there are a couple of downsides to this: 1. Starting to block things could be considered a slippery slope. First it's botnets, then it's piracy, then whatever else the government dislikes. I'm not too worried about this as long as I can choose what I block myself, and I already counter BitTorrent usage by using the well-known ReducedExitPolicy. 2. This old GitLab wiki page [2] lists a relay that is using a censored DNS provider as an example of a bad relay. It however doesn't provide a reason for this. If the DNS provider *only* blocks requests for known C&C domains, would that be okay? [2] https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReportingBadRelays#wh… 3. Obviously, the Unbound blocklist source or censoring DNS provider that would be used would gain some control over traffic on the Tor network. I'd say this is a tradeoff. If *only* C&C domains are blocked, I would be okay with this. 4. Potential legal issues. I know that in some jurisdictions (the U.S. I believe is a good example) setting up selective filtering makes the filter operator at least somewhat responsible for the traffic that passes through the filter. I'm not too worried about this at the moment. Both my exit relay and I are situated in the Netherlands. What do you guys think? Do we accept DNS filtering for blocking botnet traffic, or do we all cry censorship over this? Cheers, Imre

1 0

Tor automatic start
by Keifer Bly 04 Dec '24

04 Dec '24

Hi, So on Debain 12, is there a way to configure tor to start automatically when the os boots? Thanks. --Keifer

4 4

WebTunnel Hardware Requirements
by Dan 04 Dec '24

04 Dec '24

Hi all, I'm hoping to spin up some webtunnel bridges in response to the call for more. I currently run a few middle relays, but have never setup a bridge. I have found a provider in the good-bad-isps list that offers additional IPv4 addresses for a small fee so I'm planning to run 5 bridges from 1 VPS to make management easier. Is this enough horsepower to run 5 WebTunnel bridges? - 4 vCore AMD EPYC Rome - 8 GB memory - 48 GB SSD Thanks

2 1

Re: Tor automatic start
by fossdd 02 Dec '24

02 Dec '24

On Sun Dec 1, 2024 at 8:15 PM CET, Keifer Bly wrote: > Hi, > > So on Debain 12, is there a way to configure tor to start automatically > when the os boots? Thanks. > > --Keifer Do you mean something like, `systemctl enable tor`?

1 0

A call for more WebTunnel bridges
by gus 02 Dec '24

02 Dec '24

Dear relay operators, Last week, we kicked off a campaign to grow the number of Tor WebTunnel bridges. And the response has been amazing! In less than five days, we've already increased 80+ new WebTunnel bridges! Today is 'Cyber Monday', and it's a good opportunity to take advantage of special offers from hosting providers and contribute to this campaign. Learn how to join this campaign below or read our blog post for more details: https://blog.torproject.org/call-for-webtunnel-bridges/ Thank you for running relays & bridges, Gus ## Summary We are calling on the Tor community and the Internet freedom community to help us scale up WebTunnel bridges. If you've ever thought about running a Tor bridge, now is the time. Recent reports from Tor users in Russia indicate an escalation in online censorship with the goal of blocking access to Tor and other circumvention tools. This new wave includes attempts to block Tor bridges and pluggable transports developed by the Tor Project, removal of circumvention apps from stores, and targeting popular hosting providers, shrinking the space for bypassing censorship. Despite these ongoing actions, Tor remains effective. One alarming trend is the targeted blocking of popular hosting providers by Roscomnadzor. As many circumvention tools are using them, this action made some Tor bridges inaccessible to many users in Russia. As Roscomnadzor and internet service providers in Russia are increasing their blocking efforts, the need for more WebTunnel bridges has become urgent. ## Bridge campaign rules for participation The campaign starts today, November 28, 2024, and will run until March 10, 2025. As a token of our appreciation for your volunteer work, we're offering a Tor t-shirt to operators who run 5 or more WebTunnel bridges during this period. Please note: Only one t-shirt will be awarded per operator. See the technical requirements below to participate in the campaign. WebTunnel deployment guide: https://community.torproject.org/relay/setup/webtunnel/ ## Technical requirements to join this campaign 1. Operators must run one WebTunnel bridge per IPv4. It is acceptable to use multiple subdomains or distinct domains. 2. Include a valid email address as your contact information. Or we won't be able to confirm and validate your participation in the campaign. 3. Maintain your bridges running for at least 1 year. 4. Ensure your bridges have a solid uptime, operating close to 24/7. Reboots for updates are fine. 5. Your bridge must remain functional during the campaign period. 6. Do not host your bridges with Hetzner. See: https://ntc.party/t/12845 ## How to participate After spinning up and verifying that your 5 WebTunnel bridges are working, confirm your participation by emailing frontdesk(a)torproject.org with the following template: ``` Subject: Participation in Bridge Campaign 2025 Body: Hi, I'm signing up for the Tor Bridge Campaign. These are my bridges: <Add here your bridge lines> My t-shirt is (pick your size: https://gitlab.torproject.org/tpo/community/team/-/wikis/tshirts/tshirt-siz…) ``` To validate your participation, please contact us using the same email address listed in your contactinfo. You can expect your reward to be shipped in Q2 2025. -- The Tor Project Community Team Lead

1 0

haproxy webtunnel
by Softail 01 Dec '24

01 Dec '24

I'm trying to set up a webtunnel bridge using haproxy since that's what I use for ssl. I have the webtunnel docker image, which is a bit oldish but seems to be working, is reachable from the internet, listening on 15000 etc. When I connect with a browser using the random string exactly as it is in the bridge line it finds it and passes it on. That doesn't work but haproxy did the right thing. I can append anything to that and haproxy works. When I try to connect from android tor browser using the browser line, it tries to connect and I see it in the logs but as far as I can tell is not sending that string. I expected to have trouble with the websockets but this has never been a problem with haproxy before. ATM not really sure where to turn other than back to nginx, which after all is possible but yet another thing to tend, or recompiling, try not Android? Thanks

1 0

Regarding IPv6 & webtunnel bridge
by Dionysios K. 30 Nov '24

30 Nov '24

Hello, Is there any particular configuration change I have to do in torrc/nginx for my bridge to be listed as both v4/v6 on the metrics website? It's a webtunnel bridge and that complicates things, for obfs4 the configuration is pretty much straightforward. D.

3 2

Restart of standalone Snowflake proxies required
by Cecylia Bocovich 28 Nov '24

28 Nov '24

We recently completed an upgrade to the Snowflake broker machine[0] that required us to move the broker to a different IP address. We found, after updating our DNS records, that the standalone (command-line) proxies will not re-resolve the domain name of the broker and will continue to make connections to the old IP address until restarted. If you run a standalone Snowflake proxy, please restart when you get a chance. Thanks! [0] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

1 0

relay operator meeting postponed
by George 23 Nov '24

23 Nov '24

Greetings fellow relay operators! Sorry for the last minute notice, but we're postponing the usual relay operators meeting previously set for tomorrow. Stay tuned for a new date. George -- 43C2 85B0 41B6 4AC1 0E02 2767 7092 AEB3 40B0 C804

1 0

Solicitation for an IPv4 block
by Christopher Sheats 21 Nov '24

21 Nov '24

Hello everyone, In light of Tor Project's push into the global south, I'm bringing on a new advisory board member (https://freeradical.zone/@kedislav) from Chile, and together we're documenting co-location and IP transit costs in the country for a possible Tor exit relay deployment. However, in order to do this, we need some company/university/nonprofit, or some kind person, to donate to us a /24 (or greater) IPv4 block. If said entity is in the USA, it's possible to make this a tax-deductible donation since we are a 501(c)(3). If you could connect me to anyone who might be able to do this for Tor, please feel free to connect me over Signal or email. We can use our existing IPv6 block for dual-stack relays. Or we might get a new ASN and new IPv6 block for that region. If you have any information about Chilean co-location and/or IP transit deals, or contacts, or even good places to get used or new servers, please let me know. I'm hoping that our involvement in the region will help inspire others to do something similar. We'll of course do a full bi-lingual write up like we did in 2017 (https://emeraldonion.org/blog/starting-a-human-rights-isp/) -- Christopher Sheats Director, Emerald Onion Signal: +1 206.739.3390 // emerald.01 Web: https://emeraldonion.org Mastodon: https://digitalcourage.social/@EmeraldOnion

1 0

Journal warnings spam
by Dionysios K. 19 Nov '24

19 Nov '24

Hey guys, Do you have any solution to stop the spam caused by tor: The IPv4 ORPort address 127.0.0.1 does not match the descriptor address <IP>. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. Indeed I have a static IP but behind nat, so defining it in torrc is not possible as it can't bind to it.

2 2

Re: Looking for a new provider? Try Wedos.
by George Hartley 16 Nov '24

16 Nov '24

First of all, sorry for the late re-post of this e-mail to the list. An individual also active on the tor-relays list messaged regarding a new provider, I recommended one which is not crowded with Tor nodes, but our fellow decided to lie about the provider. Please read their quote. I can still recommend Wedos.cz for Guards/Middle relays, as well as bridges, and if you have very restrictive exit policy, maybe also for exits - however, confirm with staff first, and let them know which ports you want to allow. Also, always reply to all non-automated abuse reports, and forward them to the address for processed abuse reports given to you by staff. This was my original reply: Because their AI chat bot has infinite intelligence right? I know 2 people working there personally, Michal Jakubec and Roman Mondek, and they both reassured me yesterday that Guard/Middle and Bridge are NOT a problem, as long as they stay Guard/Middle or Bridge nodes. Using Tor FROM their network is also no problem.. using Tor to access THEIR is no problem. But, I did not trust their word.. So I tried it myself: No problem accessing the website using around 10 different exit nodes.. Then, I tried to order: Again, no problem! Received bitcoin payment information using a Tor mail service within 10 minutes: This is where I stopped, I did not pay the invoice and e-mailed Wedos stafff to please remove the order. But, Wedos supports Tor, and is a great choice especially for Guards/Middle nodes as well as bridges. Please don't lie about providers.. alternatively, if they still don't support Tor for you, please show the symptoms you are encountering. -GH On Thursday, November 7th, 2024 at 5:11 PM, Red Oaive clearly(a)ivegotyour.pw wrote: > On 2024-11-05 16:32, George Hartley via tor-relays wrote: > > > Also, please consider using a provider that is not overcrowded with > > Tor nodes already like OVH. > > > > I can recommend Wedos.cz ... https://wedos.cz/en/ > > They block access to their web site to Tor users. This doesn't bode well > for how Tor friendly they are. Their chatbot also claims tor is not > allowed: > > "Running Tor relays on a VPS from WEDOS is generally not allowed > due to the potential misuse of such services for attacks" > > Too bad becasue the price you quotes is attractive.

1 0

Re: Update: Tor relays source IPs spoofed to mass-scan port 22
by littlehoster.denote399＠passinbox.com 14 Nov '24

14 Nov '24

Hi, I had very similar reports to [tor-operator_urdn.co](https://forum.torproject.org/u/tor-operator_urdn.co): DateTime Action AttackClass SourceIP Srcport Protocol DestinationIP DestPort 0 30-Oct-2024 14:06:13 BLOCKED attempted-recon 92.51.45.21 0 202.91.162.47 22 1 30-Oct-2024 14:43:35 BLOCKED attempted-recon 92.51.45.21 0 202.91.162.24 22 2 30-Oct-2024 15:11:40 BLOCKED attempted-recon 92.51.45.21 0 202.91.162.24 22 3 30-Oct-2024 15:19:05 DENIED 92.51.45.21 64006 TCP 202.91.162.172 22 4 30-Oct-2024 15:19:20 BLOCKED attempted-recon 92.51.45.21 0 202.91.162.24 225 30-Oct-2024 15:44:49 DENIED 92.51.45.21 18054 TCP 202.91.161.94 22 The report is from the same IP-range.

1 0

Update: Tor relays source IPs spoofed to mass-scan port 22
by gus 12 Nov '24

12 Nov '24

Hello everyone, I'm writing to share that the origin of the spoofed packets has been identified and successfully shut down today, thanks to the assistance from Andrew Morris at GreyNoise and anonymous contributors. I want to give special thanks to the members of our community who have dedicated their time and efforts to track down the perpetrators of this attack. Although this fake abuse incident had minimal impact on the network -- temporarily taking only a few relays offline -- it has been a frustrating issue for many relay operators. However, I want to reassure everyone that this disruption had no effect on Tor users whatsoever. We're incredibly fortunate to have such a skilled and committed group of relay operators standing with Tor. Thank you all for your resilience, ongoing support and for making the Tor network possible by running relays. Gus -- The Tor Project Community Team Lead

11 18

Re: Raspberry Pi 4
by Keifer Bly 12 Nov '24

12 Nov '24

Ok thanks all. --Keifer On Thu, Nov 7, 2024, 6:43 AM Michael Wächter via tor-relays < tor-relays(a)lists.torproject.org> wrote: > Hi all, > I’m running a relay on a Pi 4 now for almost 2 years, almost no issues at > all. Average CPU load 40 %, average bandwidth 5 MB. > Updating to a newer version of tor is a bit tricky. > > Rads > > Michael > > > Am 04.11.2024 um 12:40 schrieb jl2238--- via tor-relays < > tor-relays(a)lists.torproject.org>: > > It works. My relay is running on a Raspberry Pi 4B with 4 GB RAM. Bandwith > for the relay is 2 Mbit/s, CPU Load of the relay is about 20 % > > > Am 02.11.24 um 02:15 schrieb Keifer Bly: > > 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 > > _______________________________________________ > tor-relays mailing listtor-relays@lists.torproject.orghttps://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 > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 2

Running a middle relay on home network
by Keifer Bly 11 Nov '24

11 Nov '24

Hi, So wondering for running a middle relay on a raspberry pi esque micro computer, what are the recommed maximum bandwidth for running a middle relay on a hole network (by a stock isp router, etc?)? Thanks. --Keifer

3 2

Tor relays source IPs spoofed to mass-scan port 22?
by Pierre Bourdon 11 Nov '24

11 Nov '24

Hi relay ops, A few hours ago I received a forwarded abuse report from Hetzner for one of my machines running a Tor relay (not exit). Some random ISP was claiming I was sending SSH connections to them, and at first I couldn't find any corroborating evidence in my own network logs and I was ready to dismiss it. But then I noticed that there is in fact something weird: all 4 of my machines running Tor relays are seeing *return* TCP traffic (RSTs or SYN-ACKs) from port 22 from various machines all over the world, at a very low rate. Kind of like someone spoofing source IPs to send SYNs everywhere. I can't figure out at all whether that's actually what's happening and what the intent would be though. Some tcpdumps showing random RSTs coming back to my machines running relays (with no traffic being initiated by said machines beforehand): 04:19:14.705034 IP 198.30.233.69.22 > 172.105.199.155.39998: Flags [R.], seq 0, ack 171173954, win 0, length 0 04:20:15.135733 IP 124.198.33.196.22 > 172.105.199.155.23506: Flags [R.], seq 0, ack 1985822135, win 0, length 0 04:21:30.222739 IP 223.29.149.158.22 > 172.105.199.155.27507: Flags [R.], seq 0, ack 3614869158, win 0, length 0 04:14:25.286063 IP 45.187.212.68.22 > 195.201.9.37.59639: Flags [R.], seq 0, ack 41396686, win 0, length 0 04:14:25.291455 IP 107.152.7.33.22 > 195.201.9.37.39793: Flags [R.], seq 0, ack 1391844539, win 0, length 0 04:14:25.322255 IP 107.91.78.158.22 > 195.201.9.37.48900: Flags [R.], seq 0, ack 1434896088, win 65535, length 0 04:12:39.470366 IP 121.150.242.252.22 > 77.109.152.87.57627: Flags [R.], seq 0, ack 2452733863, win 0, length 0 04:13:05.549920 IP 46.188.201.102.22 > 77.109.152.87.9999: Flags [R.], seq 0, ack 3253922544, win 0, length 0 04:14:33.027326 IP 1.1.195.62.22 > 77.109.152.87.52448: Flags [R.], seq 0, ack 351972505, win 0, length 0 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? Best, -- Pierre Bourdon <delroth(a)gmail.com> Software Engineer @ Zürich, Switzerland https://delroth.net/

26 43

Metrics issue with my relay?
by Carlo P. 10 Nov '24

10 Nov '24

Dear experts, my relay https://metrics.torproject.org/rs.html#details/0FBABB8C7B22CEDDFC849331E8E9… is shown as "down since more than three days" in Metrics. The logs on the server however seem to show normal activity: Nov 10 06:45:35 odin Tor[87753]: Heartbeat: It seems like we are not in the cached consensus. Nov 10 06:45:35 odin Tor[87753]: Heartbeat: Tor's uptime is 12:00 hours, with 59518 circuits open. I've sent 69.19 GB and received 71.95 GB. I've received 24885 connections on IPv4 and 524 on IPv6. I've made 326621 connections with IPv4 and 106790 with IPv6. Nov 10 06:45:35 odin Tor[87753]: While not bootstrapping, fetched this many bytes: 10227682 (server descriptor fetch); 6336 (server descriptor upload); 595320 (consensus network-status fetch); 307663 (microdescriptor fetch) Nov 10 06:45:35 odin Tor[87753]: Average packaged cell fullness: 12.651%. TLS write overhead: 2% Nov 10 06:45:35 odin Tor[87753]: Circuit handshake stats since last time: 0/0 TAP, 36156/36641 NTor. Nov 10 06:45:35 odin Tor[87753]: Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 0 v4 connections; initiated 61280 and received 25404 v5 connections. What caught my attention is the "seems like we are not in the cached consensus" log statement and also the Platform "Tor 0.4.8.13 on FreeBSD (version is 0.4.8.12 in consensus)" on Metrics While being shown as "down" in Metrics, the stats continue to be updated and config changes like 'MaxAdvertisedBandwidth' are properly reflected in Metrics Is there some issue with Metrics in conjunction with FreeBSD ? On the OS, the only changes were automated OS updates. Thanks for your feedback Regards, C. -- Sent with https://mailfence.com Secure and private email

1 0

Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your service vps-3e661acc.vps.ovh.net
by Keifer Bly 10 Nov '24

10 Nov '24

Just got this note, I run a middle relay on ovh. Why would this suddenly happen? Thanks. Relay is usdeserveprivacy --Keifer ---------- Forwarded message --------- From: <ticket+KMLTFQPGVQ.ca83(a)abuse.ovh.net> Date: Sat, Nov 2, 2024, 9:07 PM Subject: [Abuse #KMLTFQPGVQ] Abusive use of your service vps-3e661acc.vps.ovh.net To: <keifer.bly(a)gmail.com> Hello, An abusive behaviour (Intrusion) originating from your VPS vps-3e661acc[.]vps[.]ovh[.]net has been reported to or noticed by our Abuse Team. Technical details showing the aforementioned problem follow : -- start of the technical details -- <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head> <body><pre> Greetings Fellow Sys Ad/s I hope this message finds you well. I'm reaching out to you today regarding a matter of potential concern involving one or more IP addresses associated with your system Our network security logs have recently detected unusual activity originating from these IP addresses. While we understand that such incidents can sometimes occur innocently, it's crucial to investigate and address them promptly to ensure the security of all networks involved To assist you in understanding the situation, we have provided the relevant log data below, with timestamps adjusted to our GMT &#43;8 timezone: DateTime Action AttackClass SourceIP Srcport Protocol DestinationIP DestPort 0 01-Nov-2024 05:07:55 DENIED 51[.]68[.]197[.]220 44959 TCP 202[.]91[.]161[.]97 22 1 01-Nov-2024 05:24:37 DENIED 51[.]68[.]197[.]220 58734 TCP 202[.]91[.]161[.]98 22 2 01-Nov-2024 08:48:23 BLOCKED 51[.]68[.]197[.]220 8551 TCP 202[.]91[.]161[.]132 22 3 01-Nov-2024 08:53:27 BLOCKED 51[.]68[.]197[.]220 2419 TCP 202[.]91[.]161[.]169 22 4 01-Nov-2024 08:58:05 BLOCKED 51[.]68[.]197[.]220 5917 TCP 192[.]168[.]200[.]216 22 5 01-Nov-2024 08:59:24 BLOCKED 51[.]68[.]197[.]220 56858 TCP 202[.]91[.]161[.]132 22 6 01-Nov-2024 09:04:23 BLOCKED 51[.]68[.]197[.]220 32161 TCP 202[.]91[.]161[.]169 22 7 01-Nov-2024 09:17:30 BLOCKED 51[.]68[.]197[.]220 33472 TCP 202[.]91[.]161[.]132 22 8 01-Nov-2024 09:18:02 BLOCKED 51[.]68[.]197[.]220 11282 TCP 202[.]91[.]161[.]132 22 9 01-Nov-2024 09:19:00 BLOCKED 51[.]68[.]197[.]220 3727 TCP 202[.]91[.]161[.]132 22 10 01-Nov-2024 09:20:31 BLOCKED 51[.]68[.]197[.]220 4388 TCP 202[.]91[.]161[.]169 22 11 01-Nov-2024 09:25:57 BLOCKED 51[.]68[.]197[.]220 6898 TCP 202[.]91[.]161[.]165 22 12 01-Nov-2024 09:32:06 BLOCKED 51[.]68[.]197[.]220 18202 TCP 202[.]91[.]161[.]132 22 13 01-Nov-2024 09:39:40 BLOCKED 51[.]68[.]197[.]220 51142 TCP 202[.]91[.]161[.]132 22 14 01-Nov-2024 09:45:32 BLOCKED 51[.]68[.]197[.]220 46914 TCP 192[.]168[.]200[.]216 22 15 01-Nov-2024 10:40:48 BLOCKED 51[.]68[.]197[.]220 60991 TCP 192[.]168[.]200[.]216 22 16 01-Nov-2024 10:42:58 BLOCKED 51[.]68[.]197[.]220 42833 TCP 202[.]91[.]161[.]132 22 17 01-Nov-2024 10:47:13 BLOCKED 51[.]68[.]197[.]220 38382 TCP 202[.]91[.]161[.]132 22 18 01-Nov-2024 10:47:23 BLOCKED 51[.]68[.]197[.]220 30596 TCP 192[.]168[.]200[.]216 22 19 01-Nov-2024 10:47:46 BLOCKED 51[.]68[.]197[.]220 56767 TCP 202[.]91[.]161[.]185 22 20 01-Nov-2024 10:52:10 BLOCKED 51[.]68[.]197[.]220 8983 TCP 202[.]91[.]161[.]132 22 21 01-Nov-2024 10:55:04 BLOCKED 51[.]68[.]197[.]220 55684 TCP 192[.]168[.]200[.]216 22 22 01-Nov-2024 10:57:43 BLOCKED 51[.]68[.]197[.]220 37003 TCP 202[.]91[.]161[.]185 22 23 01-Nov-2024 10:58:43 BLOCKED 51[.]68[.]197[.]220 10524 TCP 192[.]168[.]200[.]216 22 24 01-Nov-2024 11:01:06 BLOCKED 51[.]68[.]197[.]220 6384 TCP 202[.]91[.]161[.]132 22 25 01-Nov-2024 11:03:46 BLOCKED 51[.]68[.]197[.]220 6779 TCP 202[.]91[.]161[.]185 22 26 01-Nov-2024 11:06:05 BLOCKED 51[.]68[.]197[.]220 23062 TCP 192[.]168[.]200[.]216 22 27 01-Nov-2024 11:58:01 BLOCKED 51[.]68[.]197[.]220 33174 TCP 202[.]91[.]161[.]132 22 28 01-Nov-2024 11:58:05 BLOCKED 51[.]68[.]197[.]220 29422 TCP 202[.]91[.]161[.]132 22 29 01-Nov-2024 11:58:26 BLOCKED 51[.]68[.]197[.]220 53504 TCP 202[.]91[.]161[.]185 22 30 01-Nov-2024 12:00:03 BLOCKED 51[.]68[.]197[.]220 5898 TCP 192[.]168[.]200[.]216 22 31 01-Nov-2024 12:00:20 BLOCKED 51[.]68[.]197[.]220 38324 TCP 202[.]91[.]161[.]185 22 32 01-Nov-2024 12:00:30 BLOCKED 51[.]68[.]197[.]220 6362 TCP 202[.]91[.]161[.]132 22 33 01-Nov-2024 12:03:11 BLOCKED 51[.]68[.]197[.]220 38581 TCP 202[.]91[.]161[.]132 22 34 01-Nov-2024 12:05:37 BLOCKED 51[.]68[.]197[.]220 43932 TCP 202[.]91[.]161[.]132 22 35 01-Nov-2024 12:07:27 BLOCKED 51[.]68[.]197[.]220 5141 TCP 202[.]91[.]161[.]185 22 36 01-Nov-2024 12:08:42 BLOCKED 51[.]68[.]197[.]220 56161 TCP 202[.]91[.]161[.]132 22 37 01-Nov-2024 12:12:26 BLOCKED 51[.]68[.]197[.]220 6269 TCP 202[.]91[.]161[.]132 22 38 01-Nov-2024 12:14:33 BLOCKED 51[.]68[.]197[.]220 164 TCP 192[.]168[.]200[.]216 22 39 01-Nov-2024 12:15:48 BLOCKED 51[.]68[.]197[.]220 25787 TCP 202[.]91[.]161[.]185 22 40 01-Nov-2024 12:16:39 BLOCKED 51[.]68[.]197[.]220 9188 TCP 202[.]91[.]161[.]185 22 41 01-Nov-2024 12:16:58 BLOCKED 51[.]68[.]197[.]220 32317 TCP 202[.]91[.]161[.]132 22 42 01-Nov-2024 12:22:28 BLOCKED 51[.]68[.]197[.]220 21955 TCP 202[.]91[.]161[.]185 22 43 01-Nov-2024 12:29:50 BLOCKED 51[.]68[.]197[.]220 33563 TCP 202[.]91[.]161[.]185 22 44 01-Nov-2024 12:32:18 BLOCKED 51[.]68[.]197[.]220 48519 TCP 202[.]91[.]161[.]132 22 45 01-Nov-2024 12:33:24 BLOCKED 51[.]68[.]197[.]220 42914 TCP 202[.]91[.]161[.]132 22 46 01-Nov-2024 12:34:07 BLOCKED 51[.]68[.]197[.]220 11296 TCP 202[.]91[.]161[.]185 22 47 01-Nov-2024 12:36:43 BLOCKED 51[.]68[.]197[.]220 6522 TCP 202[.]91[.]161[.]132 22 48 01-Nov-2024 12:37:55 BLOCKED 51[.]68[.]197[.]220 57962 TCP 202[.]91[.]161[.]185 22 49 01-Nov-2024 12:37:56 BLOCKED 51[.]68[.]197[.]220 53189 TCP 202[.]91[.]161[.]132 22 50 01-Nov-2024 12:39:29 BLOCKED 51[.]68[.]197[.]220 7411 TCP 192[.]168[.]200[.]216 22 51 01-Nov-2024 12:41:51 BLOCKED 51[.]68[.]197[.]220 27413 TCP 192[.]168[.]200[.]216 22 52 01-Nov-2024 12:44:00 BLOCKED 51[.]68[.]197[.]220 355 TCP 202[.]91[.]161[.]181 22 53 01-Nov-2024 12:50:35 BLOCKED 51[.]68[.]197[.]220 28953 TCP 202[.]91[.]161[.]185 22 54 01-Nov-2024 12:50:53 BLOCKED 51[.]68[.]197[.]220 46927 TCP 192[.]168[.]200[.]216 22 55 01-Nov-2024 12:52:00 BLOCKED 51[.]68[.]197[.]220 45122 TCP 202[.]91[.]161[.]185 22 56 01-Nov-2024 12:55:04 BLOCKED 51[.]68[.]197[.]220 4184 TCP 202[.]91[.]161[.]181 22 57 01-Nov-2024 12:55:15 BLOCKED 51[.]68[.]197[.]220 33245 TCP 202[.]91[.]161[.]185 22 58 01-Nov-2024 12:57:38 BLOCKED 51[.]68[.]197[.]220 50897 TCP 192[.]168[.]200[.]216 22 59 01-Nov-2024 12:58:58 BLOCKED 51[.]68[.]197[.]220 35903 TCP 202[.]91[.]161[.]132 22 60 01-Nov-2024 12:59:35 BLOCKED 51[.]68[.]197[.]220 16158 TCP 192[.]168[.]200[.]216 22 61 01-Nov-2024 13:01:40 BLOCKED 51[.]68[.]197[.]220 18404 TCP 202[.]91[.]161[.]181 22 62 01-Nov-2024 13:04:12 BLOCKED 51[.]68[.]197[.]220 32885 TCP 202[.]91[.]161[.]181 22 63 01-Nov-2024 13:05:50 BLOCKED 51[.]68[.]197[.]220 6316 TCP 202[.]91[.]161[.]132 22 We believe that by working together to resolve this matter swiftly, we can help safeguard the integrity of our networks and prevent any further issues. If you require any additional information or support from our end to facilitate your investigation, please don't hesitate to reach out. Your prompt attention to this matter would be greatly appreciated. We value your expertise and cooperation in resolving this situation effectively. Thank you for your time and consideration. For any corrections/updates, kindly email email-removed@provider [.]com</pre></body></html> -- end of the technical details -- Your should investigate and fix this problem, as it constitutes a violation to our terms of service. Please answer to this e-mail indicating which measures you've taken to stop the abusive behaviour. Cordially, The OVHcloud Trust & Safety team.

5 6

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

09 Nov '24

Hello all, those watchdogcyberdefense "specialists" have meanwhile publicly admitted their mistake (of course, hidden in a political wording to create a different impression): https://watchdogcyberdefense.com/2024/11/is-this-attackers-ip-spoofed/ Quote: "This experience got us thinking about the need for a swift way to identify spoofed IPs involved in attacks that create substantial backscatter traffic" On November 8, 2024 at 4:44 PM, <tor-operator(a)urdn.com.ua> wrote: gus : > I'm writing to share that the origin of the spoofed packets has been > identified and successfully shut down today, thanks to the assistance > from Andrew Morris at GreyNoise and anonymous contributors. Are you sure that it has been effectively shut down? We're still receiving spoofed packets with IP addresses of Tor relays set as source after this message has been posted. We've also received more "reports" from the same newbies after this message was posted. Our traps even see packets with the IP addresses of Tor relays that are in the same subnet. So far we've been able to trace this to a certain peer, we'll be monitoring. _______________________________________________ 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

Re: tor-relays Digest, Vol 166, Issue 7
by Account Etheron 08 Nov '24

08 Nov '24

Furthermore, an identical email was received on a server operated by me, Running I2PD. The email originated from watchdogcyberdefense.com, which is hosted on a server located in the Philippines. Additionally, the company has published an article on this matter, which can be accessed via the following link: https://watchdogcyberdefense.com/2024/11/is-this-attackers-ip-spoofed/. On Thu, Nov 7, 2024 at 4:02 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. Re: Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your service > vps-3e661acc.vps.ovh.net (Ren? Ladan) > 2. Re: Raspberry Pi 4 (Michael W?chter) > 3. Re: Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your service > vps-3e661acc.vps.ovh.net (George Hartley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Nov 2024 18:33:25 +0100 > From: Ren? Ladan <rene0(a)freedom.nl> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your > service vps-3e661acc.vps.ovh.net > Message-ID: <a0332b84-ada5-435a-8f02-3eaae04b236e(a)freedom.nl> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 11/3/24 05:10, Keifer Bly wrote: > > Just got this note, I run a middle relay on ovh. Why would this suddenly > > happen? Thanks. Relay is usdeserveprivacy > > > Interestingly (for some definition), I got an abuse mail forwarded by my > ISP today with exactly the same destination addresses and from the same > last Friday as in the your report. > > > > > > --Keifer > > > > Regards, > Ren? > > > ---------- Forwarded message --------- > > From: <ticket+KMLTFQPGVQ.ca83(a)abuse.ovh.net > > <mailto:ticket%2BKMLTFQPGVQ.ca83@abuse.ovh.net>> > > Date: Sat, Nov 2, 2024, 9:07?PM > > Subject: [Abuse #KMLTFQPGVQ] Abusive use of your service > > vps-3e661acc.vps.ovh.net <http://vps-3e661acc.vps.ovh.net> > > To: <keifer.bly(a)gmail.com <mailto:keifer.bly@gmail.com>> > > > > > > Hello, > > > > An abusive behaviour (Intrusion) originating from your VPS > > vps-3e661acc[.]vps[.]ovh[.]net has been reported to or noticed by our > > Abuse Team. > > > > Technical details showing the aforementioned problem follow : > > > > -- start of the technical details -- > > > > <html> > > <head> > > <meta http-equiv="Content-Type" content="text/html; > > charset=us-ascii"></head> > > <body><pre> > > Greetings Fellow Sys Ad/s > > > > I hope this message finds you well. I'm reaching out to you today > > regarding a matter of potential concern involving one or more IP > > addresses associated with your system > > Our network security logs have recently detected unusual activity > > originating from these IP addresses. While we understand that such > > incidents can sometimes occur innocently, it's crucial to > > investigate and address them promptly to ensure the security of all > > networks involved > > > > > > To assist you in understanding the situation, we have provided the > > relevant log data below, with timestamps adjusted to our GMT &#43;8 > > timezone: > > > > > > ? ? ? ? ? ? ? ? DateTime? ?Action AttackClass? ? ? ?SourceIP Srcport > > Protocol? ? DestinationIP DestPort > > 0? ?01-Nov-2024 05:07:55? ?DENIED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?44959? ? ? TCP? ? 202[.]91[.]161[.]97? ? ? ?22 > > 1? ?01-Nov-2024 05:24:37? ?DENIED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?58734? ? ? TCP? ? 202[.]91[.]161[.]98? ? ? ?22 > > 2? ?01-Nov-2024 08:48:23? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 8551? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 3? ?01-Nov-2024 08:53:27? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 2419? ? ? TCP? ?202[.]91[.]161[.]169? ? ? ?22 > > 4? ?01-Nov-2024 08:58:05? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 5917? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 5? ?01-Nov-2024 08:59:24? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?56858? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 6? ?01-Nov-2024 09:04:23? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?32161? ? ? TCP? ?202[.]91[.]161[.]169? ? ? ?22 > > 7? ?01-Nov-2024 09:17:30? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33472? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 8? ?01-Nov-2024 09:18:02? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?11282? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 9? ?01-Nov-2024 09:19:00? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 3727? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 10? 01-Nov-2024 09:20:31? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 4388? ? ? TCP? ?202[.]91[.]161[.]169? ? ? ?22 > > 11? 01-Nov-2024 09:25:57? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6898? ? ? TCP? ?202[.]91[.]161[.]165? ? ? ?22 > > 12? 01-Nov-2024 09:32:06? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?18202? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 13? 01-Nov-2024 09:39:40? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?51142? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 14? 01-Nov-2024 09:45:32? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?46914? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 15? 01-Nov-2024 10:40:48? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?60991? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 16? 01-Nov-2024 10:42:58? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?42833? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 17? 01-Nov-2024 10:47:13? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?38382? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 18? 01-Nov-2024 10:47:23? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?30596? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 19? 01-Nov-2024 10:47:46? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?56767? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 20? 01-Nov-2024 10:52:10? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 8983? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 21? 01-Nov-2024 10:55:04? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?55684? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 22? 01-Nov-2024 10:57:43? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?37003? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 23? 01-Nov-2024 10:58:43? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?10524? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 24? 01-Nov-2024 11:01:06? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6384? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 25? 01-Nov-2024 11:03:46? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6779? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 26? 01-Nov-2024 11:06:05? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?23062? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 27? 01-Nov-2024 11:58:01? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33174? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 28? 01-Nov-2024 11:58:05? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?29422? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 29? 01-Nov-2024 11:58:26? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?53504? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 30? 01-Nov-2024 12:00:03? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 5898? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 31? 01-Nov-2024 12:00:20? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?38324? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 32? 01-Nov-2024 12:00:30? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6362? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 33? 01-Nov-2024 12:03:11? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?38581? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 34? 01-Nov-2024 12:05:37? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?43932? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 35? 01-Nov-2024 12:07:27? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 5141? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 36? 01-Nov-2024 12:08:42? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?56161? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 37? 01-Nov-2024 12:12:26? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6269? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 38? 01-Nov-2024 12:14:33? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?164? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 39? 01-Nov-2024 12:15:48? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?25787? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 40? 01-Nov-2024 12:16:39? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 9188? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 41? 01-Nov-2024 12:16:58? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?32317? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 42? 01-Nov-2024 12:22:28? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?21955? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 43? 01-Nov-2024 12:29:50? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33563? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 44? 01-Nov-2024 12:32:18? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?48519? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 45? 01-Nov-2024 12:33:24? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?42914? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 46? 01-Nov-2024 12:34:07? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?11296? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 47? 01-Nov-2024 12:36:43? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6522? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 48? 01-Nov-2024 12:37:55? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?57962? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 49? 01-Nov-2024 12:37:56? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?53189? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 50? 01-Nov-2024 12:39:29? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 7411? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 51? 01-Nov-2024 12:41:51? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?27413? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 52? 01-Nov-2024 12:44:00? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?355? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 53? 01-Nov-2024 12:50:35? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?28953? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 54? 01-Nov-2024 12:50:53? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?46927? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 55? 01-Nov-2024 12:52:00? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?45122? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 56? 01-Nov-2024 12:55:04? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 4184? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 57? 01-Nov-2024 12:55:15? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33245? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 58? 01-Nov-2024 12:57:38? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?50897? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 59? 01-Nov-2024 12:58:58? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?35903? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 60? 01-Nov-2024 12:59:35? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?16158? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 61? 01-Nov-2024 13:01:40? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?18404? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 62? 01-Nov-2024 13:04:12? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?32885? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 63? 01-Nov-2024 13:05:50? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6316? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > > > We believe that by working together to resolve this matter swiftly, we > > can help safeguard the integrity of our networks and prevent any further > > issues. If you require any additional information or support from our > > end to facilitate your investigation, please don't hesitate to reach > > out. > > Your prompt attention to this matter would be greatly appreciated. We > > value your expertise and cooperation in resolving this situation > > effectively. Thank you for your time and consideration. > > For any corrections/updates, kindly email email- > > removed(a)provider[.]com</pre></body></html> > > > > -- end of the technical details -- > > > > Your should investigate and fix this problem, as it constitutes a > > violation to our terms of service. > > > > Please answer to this e-mail indicating which measures you've taken to > > stop the abusive behaviour. > > > > Cordially, > > > > The OVHcloud Trust & Safety team. > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > ------------------------------ > > Message: 2 > Date: Mon, 4 Nov 2024 14:30:59 +0100 > From: Michael W?chter <mwaechter(a)mac.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Raspberry Pi 4 > Message-ID: <A709A06F-E27D-40CE-8A9F-43D028277066(a)mac.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > I?m running a relay on a Pi 4 now for almost 2 years, almost no issues at > all. Average CPU load 40 %, average bandwidth 5 MB. > Updating to a newer version of tor is a bit tricky. > > Rads > > Michael > > > > Am 04.11.2024 um 12:40 schrieb jl2238--- via tor-relays < > tor-relays(a)lists.torproject.org>: > > > > It works. My relay is running on a Raspberry Pi 4B with 4 GB RAM. > Bandwith for the relay is 2 Mbit/s, CPU Load of the relay is about 20 % > > > > > > Am 02.11.24 um 02:15 schrieb Keifer Bly: > >> 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 > >> > >> > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org <mailto:tor-relays@lists.torproject.org > > > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

1 0

Inquiry about a possible DDoS case
by Jose A 07 Nov '24

07 Nov '24

Hello everyone. I have received a communication from my ISP regarding the IP where I have a Middle Relay and a Bridge, informing me that this IP is being used for a DDoS attack. I have checked the servers and everything is correct; there are no strange processes running. I have run various tools and everything seems to be in order. Therefore, has anyone encountered a similar case? Or even better, could someone be using Tor to carry out DDoS attacks? I am a bit puzzled by this situation. Thanks for your time King regards JAC -- Sent with https://mailfence.com Secure and private email

2 2