On Thursday, December 26th, 2024 at 12:00, tor-relays-requ...@lists.torproject.org <tor-relays-requ...@lists.torproject.org> wrote: > > > Send tor-relays mailing list submissions to > tor-relays@lists.torproject.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > tor-relays-requ...@lists.torproject.org > > You can reach the person managing the list at > tor-relays-ow...@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_geo...@proton.me > > Subject: [tor-relays] Re: What're these ufw block logs saying? > To: "tor-relays@lists.torproject.org" > tor-relays@lists.torproject.org, "cod...@pm.me" cod...@pm.me > > Message-ID: <9ct9ASpMXXnKRo6w2spT3sRh5hspGh1EqSneiQFDwbhNlI4ZZLyU8F2f3 > 3x_KowFg5e-IYk7P0soKNit50FrGm61lKh50WazDZNkCyfJ5qs=@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" > t...@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@lists.torproject.org wrote: > > > Hi, > > > re. my (guard / middle relay) : 181.215.226.65 : 443 : > > http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/41D4F82AB54AE5C5FB8D3CD24B4FC84350EFEF03 > > > I'm getting traffic from another (non-exit) relay : 155.138.146.249 : 9001 > > : > > http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/87EBD436D6EC7E2A83AC1CAAF46B44CFF15CDCA8 > > ( 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 > > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: publickey - hartley_geo...@proton.me - 0xAEE8E00F.asc > Type: application/pgp-keys > Size: 657 bytes > Desc: not available > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: signature.asc > Type: application/pgp-signature > Size: 249 bytes > Desc: OpenPGP digital signature > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-relays mailing list -- tor-relays@lists.torproject.org > To unsubscribe send an email to tor-relays-le...@lists.torproject.org > > > ------------------------------ > > End of tor-relays Digest, Vol 167, Issue 16 > ******************************************* Update on this ufw logs abnormality: I received an email from Tom or someone (lausts) speaking for the source Tor node (155.138.146.249) : "[ . . . ] Since any TOR incoming traffic is encrypted, it can't be read in flight. I just pass the incoming traffic to port 9001 outbound since I have no control of the contents. [ . . . ]" Which seems to explain why this non-Tor traffic is coming to my relay from theirs. Thanks to Tom / node at 155.138.146.249's admin(s) for their help, and to George H for his. Pete _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-le...@lists.torproject.org
