Relays spamming my OR port
I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 I have tried to mitigate the current DoS by implemented connection limits in my iptables using Toralf's template: More than 25 connection during 10 mins and you end up on my naughty list. Lots of connection attempts from the naughty list dropped but still my relay gets "overloaded" However, I have noticed that a few relays also end up on the naughty list, and I wonder how that can happen. My understanding is that a relay will only open 1 connection to another relay so should therefore never end up on the list. Correct? D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent naughty boy. Maybe these relays disconnect and reconnect to my relay frequently due to network issues (effect from the DoS?) or from not having enough connections available on the router? I guess my real question is if these connections are legit and I'm hurting the Tor network by using connection limits?
On Mittwoch, 17. August 2022 19:31:48 CEST Logforme wrote:
I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
I have tried to mitigate the current DoS by implemented connection limits in my iptables using Toralf's template: More than 25 connection during 10 mins and you end up on my naughty list. Lots of connection attempts from the naughty list dropped but still my relay gets "overloaded"
However, I have noticed that a few relays also end up on the naughty list, and I wonder how that can happen. My understanding is that a relay will only open 1 connection to another relay so should therefore never end up on the list. Correct?
10, 20 or more users can have set up the circuits using the same relays. kantorkel's Article10 relays have more than 100 connections per IP to me. On my smaller relays I allow 100 connections per IP: https://privatebin.deblan.org/?b4768471c3c9e7ef#EhDETgMKQRvpL6VwH7ABE3bN2cuM... But I can't use that on the big servers because Linux kernel “conntrack” tables and nftables sets only have 65535 entries. See: The dark side of using conntrack https://blog.cloudflare.com/conntrack-tales-one-thousand-and-one-flows/
D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent naughty boy. ;-) It is very, very unlikely that there is a naughty relay in AS680. That relay most likely does DNS-, BW- or network healing test in the Tor network. https://metrics.torproject.org/rs.html#search/as:AS680 (German university or research institutes)
I guess my real question is if these connections are legit and I'm hurting the Tor network by using connection limits? Yes, never block other relays. If you think there is somewhere a malicious relay, report it on bad-relay or in this list.
-- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
On 8/18/22 18:19, lists@for-privacy.net wrote:
D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent naughty boy. ;-) It is very, very unlikely that there is a naughty relay in AS680. That relay most likely does DNS-, BW- or network healing test in the Tor network. https://metrics.torproject.org/rs.html#search/as:AS680 (German university or research institutes)
Do you know more about those tests ? That relay produces many wrong ORStatus.CLOSED events: $> grep D767979FE4C99 /tmp/orstatus.9051 | uniq -c 896 TLS_ERROR D767979FE4C99D310A46EC49037E9FE7E3F64E9D 141.20.103.33 443 v4 0.4.5.10 $> grep D767979FE4C99 /tmp/orstatus.29051 | uniq -c 965 TLS_ERROR D767979FE4C99D310A46EC49037E9FE7E3F64E9D 141.20.103.33 443 v4 0.4.5.10 The data were collected using [1] over the past 20 hours at [2]. [1] D767979FE4C99D310A46EC49037E9FE7E3F64E9D [2] 65.21.94.13 -- Toralf
On Donnerstag, 18. August 2022 19:22:44 CEST Toralf Förster wrote:
On 8/18/22 18:19, lists@for-privacy.net wrote:
D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent naughty boy.
;-) It is very, very unlikely that there is a naughty relay in AS680. That relay most likely does DNS-, BW- or network healing test in the Tor network. https://metrics.torproject.org/rs.html#search/as:AS680 (German university or research institutes)
Do you know more about those tests ? That relay produces many wrong ORStatus.CLOSED events:
So I don't know exactly. If someone is really screwing things up, it might be a student who hacked a server. I'll take Sebastian in CC, maybe he knows more about it.
$> grep D767979FE4C99 /tmp/orstatus.9051 | uniq -c 896 TLS_ERROR D767979FE4C99D310A46EC49037E9FE7E3F64E9D 141.20.103.33 443 v4 0.4.5.10
$> grep D767979FE4C99 /tmp/orstatus.29051 | uniq -c 965 TLS_ERROR D767979FE4C99D310A46EC49037E9FE7E3F64E9D 141.20.103.33 443 v4 0.4.5.10
The data were collected using [1] over the past 20 hours at [2].
[1] D767979FE4C99D310A46EC49037E9FE7E3F64E9D [2] 65.21.94.13
@Sebastian Do you know more about the relay in the DFN? -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
On 8/18/22 18:19, lists@for-privacy.net wrote:
10, 20 or more users can have set up the circuits using the same relays. kantorkel's Article10 relays have more than 100 connections per IP to me.
IMO there'se no 1:1 relation of circuits to TCP connections, or ? Doesn't 1 TCP connection between 2 relays will handle all circuits going between them ? -- Toralf
On Donnerstag, 18. August 2022 19:25:54 CEST Toralf Förster wrote:
On 8/18/22 18:19, lists@for-privacy.net wrote:
10, 20 or more users can have set up the circuits using the same relays. kantorkel's Article10 relays have more than 100 connections per IP to me.
IMO there'se no 1:1 relation of circuits to TCP connections, or ? Heck, I'd have to read the tor specs for that. All I know is when I had tor-arm or NYX on some relays 2-3 years ago, there were multiple simultaneous connections to the same relay.
Doesn't 1 TCP connection between 2 relays will handle all circuits going between them ? If that's really the case, I can set up the ip|nftables rules much more strictly.
-- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
On 8/18/22 21:31, lists@for-privacy.net wrote:
If that's really the case, I can set up the ip|nftables rules much more strictly.
Currently I do have it set to "3" [1], before it was 2, which seemed to work too. [1] https://github.com/toralf/torutils/blob/main/ipv4-rules.sh -- Toralf
On 8/18/22 18:19, lists@for-privacy.net wrote:
kantorkel's Article10 relays have more than 100 connections per IP to me.
Those IPs mostly close with an error: $> grep -h " 185.220.101.*" /tmp/orstatus.*9051 | awk '{ print $1 }' | sort | uniq -c 341 CONNECTRESET 78 DONE 783 IOERROR Data were collected with [1] over past 20 hours. [1] https://github.com/toralf/torutils/blob/main/orstatus.py -- Toralf
On Donnerstag, 18. August 2022 19:47:45 CEST Toralf Förster wrote:
On 8/18/22 18:19, lists@for-privacy.net wrote:
kantorkel's Article10 relays have more than 100 connections per IP to me.
Those IPs mostly close with an error:
$> grep -h " 185.220.101.*" /tmp/orstatus.*9051 | awk '{ print $1 }' | sort | uniq -c OK, that's all 4 of us. We don't have IPv4 connections to each other, the Tor protocol doesn't allow that.
341 CONNECTRESET 78 DONE 783 IOERROR
I have connections to kantorkel via IPv6 (2a0b:f4c2:2::/64). This is actually fast but stupid when Tor relays connect in the same rack. IPv6 connections should better be limited to /48 subnets in the Tor protocol. Or /32 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
On 8/18/22 22:10, lists@for-privacy.net wrote:
IPv6 connections should better be limited to /48 subnets in the Tor protocol. Or /32
Limiting IPv6 to N connections per /64 will definitely affect relays of https://metrics.torproject.org/rs.html#search/2a0b:f4c2:2 Similar to their /24 IPv4 segment, eg. https://metrics.torproject.org/rs.html#search/185.220.101 FWIW Hetzner gives /64 to its customers. -- Toralf
On Thu, Aug 18, 2022 at 06:19:06PM +0200, lists@for-privacy.net wrote:
On Mittwoch, 17. August 2022 19:31:48 CEST Logforme wrote:
I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
I have tried to mitigate the current DoS by implemented connection limits in my iptables using Toralf's template: More than 25 connection during 10 mins and you end up on my naughty list. Lots of connection attempts from the naughty list dropped but still my relay gets "overloaded"
However, I have noticed that a few relays also end up on the naughty list, and I wonder how that can happen. My understanding is that a relay will only open 1 connection to another relay so should therefore never end up on the list. Correct?
10, 20 or more users can have set up the circuits using the same relays. kantorkel's Article10 relays have more than 100 connections per IP to me.
On my smaller relays I allow 100 connections per IP: https://privatebin.deblan.org/?b4768471c3c9e7ef#EhDETgMKQRvpL6VwH7ABE3bN2cuM...
But I can't use that on the big servers because Linux kernel “conntrack” tables and nftables sets only have 65535 entries. See: The dark side of using conntrack https://blog.cloudflare.com/conntrack-tales-one-thousand-and-one-flows/
Is your 65535 limit self-imposed? I'm running a server, that is not Tor related, on Linux where I was hitting conntrack table limits so I increased the limit by setting net.nf_conntrack_max=500000 since I have memory to spare. As far as I'm aware, there is no hard limit in the kernel as long as you have memory for it.
D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent naughty boy. ;-) It is very, very unlikely that there is a naughty relay in AS680. That relay most likely does DNS-, BW- or network healing test in the Tor network. https://metrics.torproject.org/rs.html#search/as:AS680 (German university or research institutes)
I guess my real question is if these connections are legit and I'm hurting the Tor network by using connection limits? Yes, never block other relays. If you think there is somewhere a malicious relay, report it on bad-relay or in this list.
-- ╰_╯ Ciao Marco!
Debian GNU/Linux
It's free software and it gives you freedom!
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (4)
-
Andreas Kempe -
lists＠for-privacy.net -
Logforme -
Toralf Förster