abuse report from relays in family 7EAAC49A7840D33B62FA276429F3B03C92AA9327
Hey all, got an abuse report today from Hetzner concerning one middle relay we're running there. allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276... (just from family relays in 96.9.98.0/24 range, all using ORPort 443) anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp? thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans... best, d.
On 15.10.2025 09:02 "Dimitris T. via tor-relays" <tor-relays@lists.torproject.org> wrote:
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
Did those relay operators really sent an abuse report? Can you ask Hetzner about the origin? Can you check if those connections are established or terminated in an early TCP state? -- kind regards Marco Send spam to abfall1760511772@stinkedores.dorfdsl.de
Hey, Στις 15/10/25 10:11, ο/η Marco Moock έγραψε:
Did those relay operators really sent an abuse report? Can you ask Hetzner about the origin?
didn't notice at first, but this wasn't some abuse report from "portscanned" ISP. rather an internal hetzner report. abuse report subject : Abuse Message [AbuseID:xxxxxxx]: NetscanOutLevel: scansnarf-ng detected Netscan from xxx.xxx.xxx.xxx body starts with : "We have indications that there was an attack from your server. Please take all necessary measures to avoid this in the future and to solve the issue." attaching their abuse report txt file. best, d.
On 15.10.2025 10:26 "Dimitris T. via tor-relays" <tor-relays@lists.torproject.org> wrote:
body starts with : "We have indications that there was an attack from your server. Please take all necessary measures to avoid this in the future and to solve the issue."
Tell them that this traffic is intended and you run TOR. Many other TOR relays are located in their ASN. -- kind regards Marco Send spam to abfall1760516801@stinkedores.dorfdsl.de
* Marco Moock via tor-relays:
Tell them that this traffic is intended and you run TOR.
I don't recommend doing that, because an outbound netscan is neither intended, nor might it be real to begin with. I have seen these reports crop up between ca. 2-4 times per month for guard and middle nodes. Looked like spoofed TCP traffic, which Hetzner's monitoring attributed to hosts based on IP address alone. I interpret this as an attempt of some third party to cause trouble for Tor operators aiming to stir up conflicts with the ISP. Keep in mind that while Hetzner does not prohibit Tor nodes, they do prohibit disruptive use of their infrastructure. That includes port scans. I find that the best course of action is to calmly process the automated reports within the allotted timespan, verify/confirm that your server did not in fact cause any malign traffic, and file it under "shit happens". Yes, it is annoying, but I can understand that Hetzner is trying to prevent being seen as a source of abusive behaviour. -Ralph
I agree with that assessment. This is not normal Tor traffic. Not sure about this particular Abuse notice but the ones I get always include both port 443 and 74. Tor has no business sending traffic to port 74 and even if these scans were relay discovery scans, They should point to the ORPort and not exclusively to port 443. Once you click on the retest link, you'll get a notice within a few minutes informing you that the ticket has been closed. The next step which is your statement is just a legal formality. Personally, I don't try to argue my point or try to convince them of anything. They don't care and there's not much they can do. I just tell them I mitigated the problem and then I can go about my business and I'll be done wasting my time. On 10/15/2025 6:56 AM, Ralph Seichter via tor-relays wrote:
* Marco Moock via tor-relays:
Tell them that this traffic is intended and you run TOR. I don't recommend doing that, because an outbound netscan is neither intended, nor might it be real to begin with. I have seen these reports crop up between ca. 2-4 times per month for guard and middle nodes. Looked like spoofed TCP traffic, which Hetzner's monitoring attributed to hosts based on IP address alone. I interpret this as an attempt of some third party to cause trouble for Tor operators aiming to stir up conflicts with the ISP.
Keep in mind that while Hetzner does not prohibit Tor nodes, they do prohibit disruptive use of their infrastructure. That includes port scans. I find that the best course of action is to calmly process the automated reports within the allotted timespan, verify/confirm that your server did not in fact cause any malign traffic, and file it under "shit happens". Yes, it is annoying, but I can understand that Hetzner is trying to prevent being seen as a source of abusive behaviour.
-Ralph _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
I get them from time to time and the address always is for major Tor operators who host numerous Tor servers on the whole block such as 64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not related to the operators filing an abuse report. These are automatically generated reports based on the behavior of your server and they are generally wrong because their automated system is simply too sensitive and comes up with a lot of false positive. Simply block outgoing packets to the /24 block at the firewall level. Then click on the link they sent you to retest. It will be automatically tested and comes up clear. Then send them a message using the second link and tell them you blocked it at the firewall level and they'll close the ticket. You can later remove the firewall rule and get on with you life. I've given up arguing with them about how and why they're wrong. They even once admitted that it was a false report and told me not to bother. In fact I just got another abuse report for an IP that's already blocked at the firewall level. They are telling me that my server is scanning port 74 of a range of IPs when outgoing port 74 is explicitly blocked on my server and it simply can't go out. On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there.
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans...
best,
d.
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits. Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless. I sincerely hope I missed a /s somewhere here. /r0cket On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:
I get them from time to time and the address always is for major Tor operators who host numerous Tor servers on the whole block such as 64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not related to the operators filing an abuse report. These are automatically generated reports based on the behavior of your server and they are generally wrong because their automated system is simply too sensitive and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level. Then click on the link they sent you to retest. It will be automatically tested and comes up clear. Then send them a message using the second link and tell them you blocked it at the firewall level and they'll close the ticket.
You can later remove the firewall rule and get on with you life. I've given up arguing with them about how and why they're wrong. They even once admitted that it was a false report and told me not to bother. In fact I just got another abuse report for an IP that's already blocked at the firewall level. They are telling me that my server is scanning port 74 of a range of IPs when outgoing port 74 is explicitly blocked on my server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there.
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans...
best,
d.
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
You certainly did miss the important part. You may want to read it again. On 10/15/2025 5:04 AM, R0cketCloud TOR Team wrote:
Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits.
Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless.
I sincerely hope I missed a /s somewhere here.
/r0cket
On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:
I get them from time to time and the address always is for major Tor operators who host numerous Tor servers on the whole block such as 64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not related to the operators filing an abuse report. These are automatically generated reports based on the behavior of your server and they are generally wrong because their automated system is simply too sensitive and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level. Then click on the link they sent you to retest. It will be automatically tested and comes up clear. Then send them a message using the second link and tell them you blocked it at the firewall level and they'll close the ticket.
You can later remove the firewall rule and get on with you life. I've given up arguing with them about how and why they're wrong. They even once admitted that it was a false report and told me not to bother. In fact I just got another abuse report for an IP that's already blocked at the firewall level. They are telling me that my server is scanning port 74 of a range of IPs when outgoing port 74 is explicitly blocked on my server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there.
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans...
best,
d.
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
ok whatever chris said applies. no /24 block needed, our relay is down anyway (=runs on the clock w/ bandwidth meter). so, replied to hetzner that this is normal tor traffic , not malicious (no port scans, noone got "offended" by it), hetzner re-check passed, and statement accepted. seemed strange, cause it's the 1st time we got such an abuse report.. and we've been running this relay since 'tor challenge 2014' :) thanks all for your answers, hopefully we can go on without getting too many of these false-positive abuse reports. ciao, d. Στις 15/10/25 12:32, ο/η Chris Enkidu-6 via tor-relays έγραψε:
You certainly did miss the important part. You may want to read it again.
On 10/15/2025 5:04 AM, R0cketCloud TOR Team wrote:
Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits.
Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless.
I sincerely hope I missed a /s somewhere here.
/r0cket
On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays<tor-relays@lists.torproject.org> wrote:
I get them from time to time and the address always is for major Tor operators who host numerous Tor servers on the whole block such as 64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not related to the operators filing an abuse report. These are automatically generated reports based on the behavior of your server and they are generally wrong because their automated system is simply too sensitive and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level. Then click on the link they sent you to retest. It will be automatically tested and comes up clear. Then send them a message using the second link and tell them you blocked it at the firewall level and they'll close the ticket.
You can later remove the firewall rule and get on with you life. I've given up arguing with them about how and why they're wrong. They even once admitted that it was a false report and told me not to bother. In fact I just got another abuse report for an IP that's already blocked at the firewall level. They are telling me that my server is scanning port 74 of a range of IPs when outgoing port 74 is explicitly blocked on my server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there.
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans...
best,
d.
_______________________________________________ tor-relays mailing list --tor-relays@lists.torproject.org To unsubscribe send an email totor-relays-leave@lists.torproject.org
_______________________________________________ tor-relays mailing list --tor-relays@lists.torproject.org To unsubscribe send an email totor-relays-leave@lists.torproject.org
I'm tempted to agree with Chris. Though, the real solution is to apply with your regional IR for your own IP block. That would solve 99% of issues for Tor operators, but the club might be a little more exclusive. I'm not sure what's better for the network ultimately. I have a meeting with ARIN today, à propos of this mail particular list. ~KJ -------- Original Message -------- On Wednesday, 10/15/25 at 06:38 R0cketCloud TOR Team via tor-relays <tor-relays@lists.torproject.org> wrote: Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits. Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless. I sincerely hope I missed a /s somewhere here. /r0cket On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:
I get them from time to time and the address always is for major Tor operators who host numerous Tor servers on the whole block such as 64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not related to the operators filing an abuse report. These are automatically generated reports based on the behavior of your server and they are generally wrong because their automated system is simply too sensitive and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level. Then click on the link they sent you to retest. It will be automatically tested and comes up clear. Then send them a message using the second link and tell them you blocked it at the firewall level and they'll close the ticket.
You can later remove the firewall rule and get on with you life. I've given up arguing with them about how and why they're wrong. They even once admitted that it was a false report and told me not to bother. In fact I just got another abuse report for an IP that's already blocked at the firewall level. They are telling me that my server is scanning port 74 of a range of IPs when outgoing port 74 is explicitly blocked on my server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there.
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans...
best,
d.
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Hey, I received the same abuse report from Hetzner. I’m running a relay as well. Interestingly, I get an abuse report about a port scan every few months, but the IPs in question always belong to the Tor network. In the past, this explanation has always been sufficient for them to close the report. Best regards, Justus
Dimitris T. via tor-relays <tor-relays@lists.torproject.org> hat am 15.10.2025 08:02 CEST geschrieben:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there.
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans...
best,
d.
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
To summarize: Hetzner is issuing "netscan abuse" complaints because their automated systems misunderstand normal Tor behavior (TCP/SYN packets to [offline] relays). In response, we are now discussing banning Tor nodes that go down for routine maintenance. This is the wrong solution. We would be actively "lobotomizing" network diversity because of one provider's flawed policy. The problem is Hetzner's surveillance. Any provider that constantly stores and analyzes netflow data to this degree is a risk. Instead of punishing Tor diversity, we should reduce the impact of Hetzner. I propose all Hetzner-hosted relays get the MiddleOnly flag and be barred from becoming Guard nodes. I sincerely hope the network-health team sees the gravity of this. If we knowingly ban our own relays over this, we are fundamentally undermining the network. When did we become the censors? /r0cket On Monday, October 27, 2025 21:20 UTC, Toralf Förster via tor-relays <tor-relays@lists.torproject.org> wrote:
On 10/22/25 6:52 AM, Tor at 1AEO via tor-relays wrote:
No other provider appears to exhibit these same issues with this traffic pattern.
I got 3 abuse complaints related to 64.65.0.0/24, 64.65.61.0/24 and 96.9.98.0/24 in the past couple of weeks.
Open to any guidance or suggestions on how best to mitigate this.
My personal solution attempt as of today is in [1]. For that I added EGRESS_SUBNET_SLEW="45.84.107.0 64.65.0.0/23 64.65.60.0/22 96.9.98.0 109.70.100 171.25.193.0 185.220.101.0 192.42.116.0" /opt/torutils/ipv4-rules-egress.sh start
to the init script of a bare metal server hosting 5 Tor relays. After reboot it took about 10 min for the iptables stats to calm down [2].
[1] https://github.com/toralf/torutils/blob/main/ipv4-rules-egress.sh [2] https://0x0.st/K2C0.txt
-- Toralf _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Am 28.10.2025 um 07:48:47 Uhr schrieb R0cketCloud TOR Team via tor-relays:
Instead of punishing Tor diversity, we should reduce the impact of Hetzner. I propose all Hetzner-hosted relays get the MiddleOnly flag and be barred from becoming Guard nodes.
Why are so many people choosing Hetzner for TOR nodes, especially non-exits? -- Gruß Marco Send unsolicited bulk mail to 1761634127muell@cartoonies.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Why are so many people choosing Hetzner for TOR nodes, especially non-exits?
Many, many VPS companies are just resellers of Hetzner. There have been more than a few times where I had to check a company's looking glass just to find out that their IPs are on AS24940. I doubt most of these people are going to hetzner.com directly to buy their VPSes. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkA0pkACgkQBh18rEKN 1gt1KQ//cyOm3PnKG2xD7pK8gWhw07B0rKF+QEifiYPEtqofI2GvQZWo6dx5C/kI uN6QK4Ppl+HDuiH/h+M9UhUmdCphmXj5r6Tt5ycG4ynoZvZXKDMAVA7owkv6C1Si e7jDSg53HFQhhg3jh29WGdc7ngKkDZ1YwnTiJlEc+9fvBy2f78qdwm/0QDg+pP9Y ZQjZudSF8ucpQlIXYti8odGflHFK3u9lmR+6spKw0NF7lWoJFCuWHbuul+ZdnEkB cvkF4rgT7s+fMeNJ4NS1xuZ9hsYwGr6UA3ZgVTVdJzf+QCEZAa8xuNX+v3AuieUZ eJ6Jrz5JDxE60dir/OgEJtaS9ZaluZKU0dwMg+NauXOvQf1GDIl30DztGh26zju4 zFlgku//4aN1uxIIrzO/pa1i5Gwlsu6Wb+3tuirizyeaH8lLpcKJmvJbReNGM4Tt Z8xFYS4OFKwxy379p3ezgvMev4ODSHCaReSlzEahr4hU3VQ7xDk9ohKPM6Z0oP5T Yv5a6drXVZ7vcJQVGZJXQyc2swjd3n4y3DpS9EN8Sc3kQbprqujG4hgLoamEAx04 FRZxrffP2aoPib3do50zy4Yxp8pPugZXWNEkIlHi6NNwS4io6O2dPXFYE+IMwSfB 0YYCvV2u7wlzOQFigXbMF4+oyZyJgTdLMQwI3Vl6h1mdxxLi1DM= =W40C -----END PGP SIGNATURE-----
Hey all, Στις 28/10/25 13:14, ο/η Marco Moock via tor-relays έγραψε:
Am 28.10.2025 um 07:48:47 Uhr schrieb R0cketCloud TOR Team via tor-relays:
Instead of punishing Tor diversity, we should reduce the impact of Hetzner. I propose all Hetzner-hosted relays get the MiddleOnly flag and be barred from becoming Guard nodes. Why are so many people choosing Hetzner for TOR nodes, especially non-exits?
hetzner is the cheapest provider around (for certain things, like dedicated servers)... hetzner is also not exit-node friendly, so non-exits it is. 2c.
On 10/28/2025 3:48 AM, R0cketCloud TOR Team via tor-relays wrote:
The problem is Hetzner's surveillance. Any provider that constantly stores and analyzes netflow data to this degree is a risk.
Hetzner is a huge provider with diverse networks. I can't blame them for trying to keep it secure in whatever way they see fit. People are not going to change providers because you say so. They choose what works for them or they stop contributing.
Instead of punishing Tor diversity, we should reduce the impact of Hetzner. I propose all Hetzner-hosted relays get the MiddleOnly flag and be barred from becoming Guard nodes.
To be honest having a handful of operators controlling such great number of exit nodes and exit traffic on the Tor network to a point that a simple maintenance can create this kind of effect in my view is just as much of a security risk. I use Hetzner because I have a bare metal server with 12 IPv4 addresses that runs a bunch of things including Tor nodes and it relays about 160 TB up and 160 TB down of Tor traffic each month, all for a total cost of 60 Euros. There's no way I can do that on cheap VPS. Any time you feel like banning Hetzner I'd be glad to shut them down and move on. I choose where I run my server and no amount of Good / Bad ISP lists made by those who are out of touch with reality of what the average volunteer has to deal with is going to make me change my mind. And no, I'm not promoting banning those IP addresses. This is not limited to Exit nodes. It's related to single operators holding great number of IP addresses on a single server and that's where the problem lies. Once a single server goes down, it will have a major effect. In fact I received a new one for 64.65.62.0/24 two days ago for the third time in a couple of months. The whole /24 block has been down for over 2 days and they're not even Exit nodes. Dealing with Hetzner Abuse emails is quite easy. In fact they closed the ticket without me having to even answer.
I sincerely hope the network-health team sees the gravity of this. If we knowingly ban our own relays over this, we are fundamentally undermining the network.
When did we become the censors?
/r0cket
On Monday, October 27, 2025 21:20 UTC, Toralf Förster via tor-relays <tor-relays@lists.torproject.org> wrote:
On 10/22/25 6:52 AM, Tor at 1AEO via tor-relays wrote:
No other provider appears to exhibit these same issues with this traffic pattern. I got 3 abuse complaints related to 64.65.0.0/24, 64.65.61.0/24 and 96.9.98.0/24 in the past couple of weeks.
Open to any guidance or suggestions on how best to mitigate this. My personal solution attempt as of today is in [1]. For that I added EGRESS_SUBNET_SLEW="45.84.107.0 64.65.0.0/23 64.65.60.0/22 96.9.98.0 109.70.100 171.25.193.0 185.220.101.0 192.42.116.0" /opt/torutils/ipv4-rules-egress.sh start
to the init script of a bare metal server hosting 5 Tor relays. After reboot it took about 10 min for the iptables stats to calm down [2].
[1] https://github.com/toralf/torutils/blob/main/ipv4-rules-egress.sh [2] https://0x0.st/K2C0.txt
-- Toralf _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
* R0cketCloud TOR Team via tor-relays:
The problem is Hetzner's surveillance. Any provider that constantly stores and analyzes netflow data to this degree is a risk.
Nothing like making wildly sweeping statements, is there? What lurid details do you know about Hetzner's oh so risky analysis? Retention time, scope, processes? If you have any damning evidence to share for the greater good, out with it, good sir. Of course Hetzner monitors their traffic, it would be dumb not to. I fully expect any ISP targeting a mass market to monitor traffic, if only to try and keep abuse in check. By the way, in other cases Hetzner has been criticised for being "too liberal" and people have "proposed" to block Hetzner's network ranges for allegedly not taking a tough stance on spammers hosting mail servers.
I propose all Hetzner-hosted relays get the MiddleOnly flag and be barred from becoming Guard nodes.
Propose away, that does not make it a good idea.
When did we become the censors?
... asks the guy who proposes to arbitrarily ban nodes hosten on a major ISP's infrastructure from performing important services for Tor, based on nothing but a personal preference. Or is is there perhaps another motivation? For instance, I find it interesting that Hetzner is selling services which appear to compete with what r0cket.cloud offers. -Ralph
Toralf Förster via tor-relays:
On 10/22/25 6:52 AM, Tor at 1AEO via tor-relays wrote:
No other provider appears to exhibit these same issues with this traffic pattern.
I got 3 abuse complaints related to 64.65.0.0/24, 64.65.61.0/24 and 96.9.98.0/24 in the past couple of weeks.
Open to any guidance or suggestions on how best to mitigate this.
My personal solution attempt as of today is in [1]. For that I added EGRESS_SUBNET_SLEW="45.84.107.0 64.65.0.0/23 64.65.60.0/22 96.9.98.0 109.70.100 171.25.193.0 185.220.101.0 192.42.116.0" /opt/ torutils/ipv4-rules-egress.sh start
to the init script of a bare metal server hosting 5 Tor relays. After reboot it took about 10 min for the iptables stats to calm down [2].
Thanks. For those of you following along at home there is a related analysis ticket in our bug tracker[3] where this idea is investigated. There might be other stuff that could be tried as well. Thanks, Georg
[1] https://github.com/toralf/torutils/blob/main/ipv4-rules-egress.sh [2] https://0x0.st/K2C0.txt
[3] https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/105
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Tor at 1AEO wrote:
These emails suggest Hetzner monitors flow-level data (e.g., NetFlow), which raises concerns about potential exposure of Tor traffic characteristics.
Every major service provider will do that. I would be surprised if there exists any AS in the world that Tor traffic goes through that does not. What matters is whether or not this traffic flow data is insecurely transmitted over the network or sold, and whether it is triggered on an event (such as an abnormal pps/bps ratio) or if it is unconditionally enabled for all flows (which would be highly problematic for privacy). While I definitely worry that such flow records are being sold/exported to the likes of Team Cymru and other "threat analysis" services, the mere fact that Hetzner has insight into their traffic using flow-level monitoring is not something that concerns me in the slightest. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlSPI0ACgkQBh18rEKN 1gvMdhAAh2VOOp+PD0RHq6/+HVGnpXX+vWZbzuyLyK30rXdQmGiRLDGV7CfJ6fn2 vWmTSCT7VJtCxSCpi6M6aO7LDu6bE+JUXrAtUoOyWbweks9S9N2Zaos0YHjiM1lY 2cfdVFVPu1UJkTVbjI+uuuLC49FdGE9I3NpB6ZGuCuw52A1uvfNSs867+2Cu34tE 7rm1Vl9t+DlN1pwDnfWWswdmx5WnHQ0lfBpQsp511um6LZGIi5yVi4KtNj5FXJsb HdwFFbnAHdoHzYTM0D4J2KEDKvoM0c8eYURJ7TLdUgU6WDZgvn7IVBRxMIZVe1iZ o26c9tZW2GGM+UK4P/V0iKSUauKR/7oZC4J+HfqyyXMEpxhrqRDo40FL7Ljm43wF ZT9mMBjuLcM0zkaNEqzTi0ldR5EAZrOSt5Plar1BRQHxUSGV5hoblSnwkacppTDa NKLcacIvQlFiib3X5vmMuJflrPQr7EWSnE235uW8WtbAEJXCLNJLCP6I4nvoCXzT xiEPBzx+qcoAhX5gQ5oTe0d8t5z5tHi22oKzMaW152B4I+p3aVkf6PxGtd4E2y2W wxxc2LuWaZWOgVyAuE/KH1tyqBnbA/Jz808VWl1eXB71F+0XSkngLRW3IDUoTcwx q8zD28puXMBtjGwObVw3X183g1pbvXlszabkTDa4d+u5s3iI8Rk= =uVHV -----END PGP SIGNATURE-----
hey hey
I agree with that assessment. This is not normal Tor traffic. Not sure about this particular Abuse notice but the ones I get always include both port 443 and 74. Tor has no business sending traffic to port 74
i think you have a little error in that representation. got the same abuse report. but the 74 is the packet size, not the desitnation port. the abuse report goes like this TIME (UTC) SRC SRC-PORT -> DST DST-PORT SIZE PROT 2025-10-14 22:37:13 188.40.xxx.yyy 45254 -> 96.9.98.2 443 74 TCP so rather all fine and looks like legal tor traffic and still a false positive on hetzners side to me? cheers Jan
* Jan via tor-relays:
the abuse report goes like this
TIME (UTC) SRC SRC-PORT -> DST DST-PORT SIZE PROT 2025-10-14 22:37:13 188.40.xxx.yyy 45254 -> 96.9.98.2 443 74 TCP
Well, there's more, is there not? Hetzner reports of this kind typically list a whole range of destination IP addresses, i.e. portscans for network ranges (class C being pretty common).
so rather all fine and looks like legal tor traffic and still a false positive on hetzners side to me?
Portscans are /not/ fine. If you are not running an exit node, there is no reason for your node to connect to port 443 on a whole range of target hosts. That traffic is either spoofed, or something is very wrong on your node. However, if you are running an exit node, you can pretty much bet that some bozos will abuse it to run portscans. Occupational hazard. And it's not fine either. -Ralph
On 10/20/25 12:29, Ralph Seichter via tor-relays wrote:
Portscans are /not/ fine. If you are not running an exit node, there is no reason for your node to connect to port 443 on a whole range of target hosts. That traffic is either spoofed, or something is very wrong on your node.
EXTEND cells can actually contain arbitrary addresses, and AFAIK tor will actually try to connect to them and speak the Tor protocol. If the address doesn't belong to a real relay, at best it will complete the TLS handshake[1] and bail out. [1] I'm actually not 100% sure if it will even complete it when connecting to something that isn't a tor relay. I only tested this (locally) against a port that nothing was listening on.
* dzwdz via tor-relays:
EXTEND cells can actually contain arbitrary addresses, and AFAIK tor will actually try to connect to them and speak the Tor protocol.
How likely is it that this will result in >100 closely related IP addresses being targeted over the span of minutes, and all of them on port 443, I wonder? -Ralph
hey hey Am 20.10.25 um 12:29 schrieb Ralph Seichter via tor-relays:
Well, there's more, is there not? Hetzner reports of this kind typically list a whole range of destination IP addresses, i.e. portscans for network ranges (class C being pretty common).
hey hey i run a relay, not an exit node. the report from hetzner was both times ~300 lines long ================ TIME (UTC) SRC SRC-PORT -> DST DST-PORT SIZE PROT ---------------------------------------------------------------------------- 2025-10-14 22:37:13 188.40.xxx.yyy 45254 -> 96.9.98.2 443 74 TCP 2025-10-14 22:37:14 188.40.xxx.yyy 45254 -> 96.9.98.2 443 74 TCP 2025-10-14 22:37:16 188.40.xxx.yyy 45254 -> 96.9.98.2 443 74 TCP 2025-10-14 22:36:25 188.40.xxx.yyy 37016 -> 96.9.98.8 443 74 TCP 2025-10-14 22:36:26 188.40.xxx.yyy 37016 -> 96.9.98.8 443 74 TCP 2025-10-14 22:36:28 188.40.xxx.yyy 37016 -> 96.9.98.8 443 74 TCP 2025-10-14 22:37:46 188.40.xxx.yyy 35794 -> 96.9.98.9 443 74 TCP 2025-10-14 22:37:47 188.40.xxx.yyy 35794 -> 96.9.98.9 443 74 TCP 2025-10-14 22:37:49 188.40.xxx.yyy 35794 -> 96.9.98.9 443 74 TCP 2025-10-14 22:37:52 188.40.xxx.yyy 42760 -> 96.9.98.10 443 74 TCP 2025-10-14 22:37:53 188.40.xxx.yyy 42760 -> 96.9.98.10 443 74 TCP 2025-10-14 22:37:55 188.40.xxx.yyy 42760 -> 96.9.98.10 443 74 TCP 2025-10-14 22:37:44 188.40.xxx.yyy 40534 -> 96.9.98.12 443 74 TCP 2025-10-14 22:37:45 188.40.xxx.yyy 40534 -> 96.9.98.12 443 74 TCP 2025-10-14 22:37:47 188.40.xxx.yyy 40534 -> 96.9.98.12 443 74 TCP 2025-10-14 22:33:58 188.40.xxx.yyy 48910 -> 96.9.98.14 443 74 TCP 2025-10-14 22:36:43 188.40.xxx.yyy 38028 -> 96.9.98.14 443 74 TCP 2025-10-14 22:33:25 188.40.xxx.yyy 48910 -> 96.9.98.14 443 74 TCP 2025-10-14 22:35:06 188.40.xxx.yyy 52632 -> 96.9.98.15 443 74 TCP 2025-10-14 22:35:07 188.40.xxx.yyy 52632 -> 96.9.98.15 443 74 TCP 2025-10-14 22:35:09 188.40.xxx.yyy 52632 -> 96.9.98.15 443 74 TCP 2025-10-14 22:36:29 188.40.xxx.yyy 41368 -> 96.9.98.16 443 74 TCP 2025-10-14 22:36:30 188.40.xxx.yyy 41368 -> 96.9.98.16 443 74 TCP 2025-10-14 22:36:32 188.40.xxx.yyy 41368 -> 96.9.98.16 443 74 TCP .... ================ and so on *all* of those addresses are tor relay both times according to [1] and [2] and according the the same sides their torport is 443. my speculation is still in the direction that they're maybe doing maintenance, taking down all nodes, and then my relay tries to connect to them and gives up after three times. still nothing i'd see as bad behavior?
Portscans are /not/ fine. If you are not running an exit node, there is no reason for your node to connect to port 443 on a whole range of target hosts. That traffic is either spoofed, or something is very wrong on your node.
as said, the destination ip/port are *always* valid tor nodes, so i do not see this as port scan.
However, if you are running an exit node, you can pretty much bet that some bozos will abuse it to run portscans. Occupational hazard. And it's not fine either.
if i'd run an exit node i'd wonder about nothing ;) and tbh i'd also not let it run via hetzner. as there i'd expect problems of other kind on a daily basis. i', very thanktful for all the exit node operators. cheers Jan [1] https://metrics.torproject.org/rs.html#search/64.65.1 [2] https://metrics.torproject.org/rs.html#search/96.9.98
* Jan via tor-relays:
*all* of those addresses are tor relay both times according to [1] and [2] and according the the same sides their torport is 443.
Nice! If you invested the time to verify that this was Tor-to-Tor traffic, and it caused a false alarm in Hetzner's monitoring, you can tell them just that and go back to well deserved sleep. :-) -Ralph
On 20.10.2025 22:04 Jan via tor-relays wrote:
and so on *all* of those addresses are tor relay both times according to [1] and [2] and according the the same sides their torport is 443.
my speculation is still in the direction that they're maybe doing maintenance, taking down all nodes, and then my relay tries to connect to them and gives up after three times. still nothing i'd see as bad behavior?
Might be the case. To verify that, implement network logging on your system, including the TCP flags and maybe also the process info. With that you can verify that your system sent out those packages and how the remote replied. Address forging attacks are a common problem and ca be used to do reflecting attacks. There is no good way to avoid that if you are the middle machine in the reflection attack.
As the operator of family 7EAAC49A7840D33B62FA276429F3B03C92AA9327, we experienced a router update and restart. We’ve seen similar network disruptions before — BGP drops, switch failures, etc. — causing comparable issues at Hetzner. This isn’t the first incident and likely won’t be the last. A few additional notes: - Hetzner flags this type of Tor relay traffic as “port scanning,” sending automated emails to its customers — though we’ve never received one directly. - These emails suggest Hetzner monitors flow-level data (e.g., NetFlow), which raises concerns about potential exposure of Tor traffic characteristics. - Hetzner also carries a disproportionate share of Tor traffic, currently #2 by consensus weight (~10%). See: https://1aeo.com/metrics/misc/networks-by-bandwidth.html and https://1aeo.com/metrics/as/AS24940/. No other provider appears to exhibit these same issues with this traffic pattern. Open to any guidance or suggestions on how best to mitigate this. On Tuesday, October 14th, 2025 at 11:30 PM, Dimitris T. via tor-relays <tor-relays@lists.torproject.org> wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there.
allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276...
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans...
best,
d.
On 10/15/25 8:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we're running there My temporary solution (WIP):
https://github.com/toralf/torutils?tab=readme-ov-file#avoid-server-blocking-... -- Toralf
On 10/22/25 6:52 AM, Tor at 1AEO via tor-relays wrote:
No other provider appears to exhibit these same issues with this traffic pattern.
I got 3 abuse complaints related to 64.65.0.0/24, 64.65.61.0/24 and 96.9.98.0/24 in the past couple of weeks.
Open to any guidance or suggestions on how best to mitigate this.
My personal solution attempt as of today is in [1]. For that I added EGRESS_SUBNET_SLEW="45.84.107.0 64.65.0.0/23 64.65.60.0/22 96.9.98.0 109.70.100 171.25.193.0 185.220.101.0 192.42.116.0" /opt/torutils/ipv4-rules-egress.sh start to the init script of a bare metal server hosting 5 Tor relays. After reboot it took about 10 min for the iptables stats to calm down [2]. [1] https://github.com/toralf/torutils/blob/main/ipv4-rules-egress.sh [2] https://0x0.st/K2C0.txt -- Toralf
participants (14)
-
Chris Enkidu-6 -
Dimitris T. -
dzwdz -
forest-relay-contact＠cryptolab.net -
foreststack＠dmc.chat -
Georg Koppen -
Jan -
Justus Flerlage -
KJ -
Marco Moock -
R0cketCloud TOR Team -
Ralph Seichter -
Tor at 1AEO -
Toralf Förster