Hi,I have been running a relay for a few months now without any problems. But this week I’ve received 2 DDoS alerts from my provider (Netcup), both are ~3 gigabits. They seem to be coming from other Tor relays.I’m running an Invidious like instance on my server (which uses around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor relay to use 300-400 megabits.I’m not sure where that 3 gigabit of data comes from.I have lowered my advertised bandwidth to 100 megabits, would that be enough to prevent these kind of issues?Kind regards,Rafo
On Montag, 8. Juli 2024 19:34:51 CEST Rafo (r4fo.com) via tor-relays wrote:
But this week I’ve received 2 DDoS alerts from my provider (Netcup), both are ~3 gigabits. They seem to be coming from other Tor relays.I’m running an Invidious like instance on my server (which uses around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor relay to use 300-400 megabits.I’m not sure where that 3 gigabit of data comes from.I have lowered my advertised bandwidth to 100 megabits, would that be enough to prevent these kind of issues?Kind regards,Rafo
Reducing the advertised bandwidth does not help. ;-) In general, one tor instance will rarely reach 100 megabits.
There is little you can do on the server against targeted DDoS. But you can stop IPs with a lot of connections to your tor daemon using dynamic exit police¹ or dyn. IP/nftable rules². For targeted help, you should specify the type of relay you have and your OS.
https://gitlab.torproject.org/tpo/community/support/-/issues/40093
¹https://github.com/artikel10/surgeprotector
²https://forum.torproject.org/t/is-tor-network-resistant-to-tcp-syn-flood-dos...
More specifically, I’m running a middle relay on Debian 12 ---- On Tue, 09 Jul 2024 13:46:51 +0200 lists@for-privacy.netlists@for-privacy.net wrote ---- On Montag, 8. Juli 2024 19:34:51 CEST Rafo (r4fo.com) via tor-relays wrote: > But this week I’ve received 2 DDoS alerts from my provider > (Netcup), both are ~3 gigabits. They seem to be coming from other Tor > relays.I’m running an Invidious like instance on my server (which uses > around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor > relay to use 300-400 megabits.I’m not sure where that 3 gigabit of data > comes from.I have lowered my advertised bandwidth to 100 megabits, would > that be enough to prevent these kind of issues?Kind regards,Rafo Reducing the advertised bandwidth does not help. ;-) In general, one tor instance will rarely reach 100 megabits. There is little you can do on the server against targeted DDoS. But you can stop IPs with a lot of connections to your tor daemon using dynamic exit police¹ or dyn. IP/nftable rules². For targeted help, you should specify the type of relay you have and your OS. https://gitlab.torproject.org/tpo/community/support/-/issues/40093 ¹https://github.com/artikel10/surgeprotector ²https://forum.torproject.org/t/is-tor-network-resistant-to-tcp-syn-flood-dos... -- ╰_╯ 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
On Dienstag, 9. Juli 2024 14:04:49 CEST Rafo (r4fo.com) via tor-relays wrote:
More specifically, I’m running a middle relay on Debian 12
Here again the Github's of toralf & Enkidu from the above mentioned forum link. They have iptables: https://github.com/toralf/torutils https://github.com/Enkidu-6/tor-ddos
I just do it with nftables. https://github.com/boldsuck/tor-relay-bootstrap/blob/nft/etc/nftables.conf_d...
Be sure to adjust the SSH IP sets otherwise you will log out! I have all Dyn-IP subnets from the providers from which I connect via SSH. You can search for example on: https://bgp.tools/ or https://bgpview.io
Apart from SSH, only Tor is running and I don't have a 'table inet filter'. If you need them, they are also on my Github.
"Rafo (r4fo.com) via tor-relays" tor-relays@lists.torproject.org wrote:
More specifically, I?m running a middle relay on Debian 12 ---- On Tue, 09 Jul 2024 13:46:51 +0200 lists@for-privacy.net<lists@for-privacy.net> wrote ---- On Montag, 8. Juli 2024 19:34:51 CEST Rafo (r4fo.com) via tor-relays wrote: > But this week I?ve received 2 DDoS alerts from my provider > (Netcup), both are ~3 gigabits. They seem to be coming from other Tor > relays.I?m running an Invidious like instance on my server (which uses > around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor > relay to use 300-400 megabits.I?m not sure where that 3 gigabit of data > comes from.I have lowered my advertised bandwidth to 100 megabits, would > that be enough to prevent these kind of issues?Kind regards,Rafo Reducing the advertised bandwidth does not help. ;-) In general, one tor instance will rarely reach 100 megabits. There is little you can do on the server against targeted DDoS. But you can stop IPs with a lot of connections to your tor daemon using dynamic exit police? or dyn. IP/nftable rules?. For targeted help, you should specify the type of relay you have and your OS. https://gitlab.torproject.org/tpo/community/support/-/issues/40093 ?https://github.com/artikel10/surgeprotector ?https://forum.torproject.org/t/is-tor-network-resistant-to-tcp-syn-flood-dos-attacks-from-outside-of-tor/12690/4 -- ?_? 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
Depending upon the features of the packet filter(s) available to you on your operating system, there may be one or more options that can help defend your relay. For example, all of the main FOSS *BSD systems today have some version of the pf packet filter subsystem available as well as others. One option available in pf for TCP is synproxy. This excerpt from the pf.conf(5) man page in FreeBSD tells how it works.
----------------------------------------------------------------------- SYN PROXY
By default, pf(4) passes packets that are part of a tcp(4) handshake between the endpoints. The synproxy state option can be used to cause pf(4) itself to complete the handshake with the active endpoint, perform a handshake with the passive endpoint, and then forward packets between the endpoints.
No packets are sent to the passive endpoint before the active endpoint has completed the handshake, hence so-called SYN floods with spoofed source addresses will not reach the passive endpoint, as the sender can't complete the handshake.
The proxy is transparent to both endpoints, they each see a single connection from/to the other endpoint. pf(4) chooses random initial sequence numbers for both handshakes. Once the handshakes are completed, the sequence number modulators (see previous section) are used to translate further packets of the connection. synproxy state includes modulate state.
Rules with synproxy will not work if pf(4) operates on a bridge(4).
Example:
pass in proto tcp from any to any port www synproxy state
-----------------------------------------------------------------------
My understanding is that LINUX systems do not have pf, but rather have a less flexible filter called iptables. Whether iptables or any other packet filter that may be available on LINUX systems has synproxy or a similar feature I do not know, but I'm posting this to make novice *BSD users who run tor relays aware of it. IMHO, synproxy or its equivalents in other filters (if they exist) should always be applied to filter rules for at least the ports that tor listens on and are exposed to the outside world (e.g., ORPort and DirPort). Of course, although synproxy helps defend a tor relay (or a web server or data base or whatever), it doesn't stop what arrives at your ISP from outside.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On Donnerstag, 11. Juli 2024 09:38:34 CEST Scott Bennett via tor-relays wrote:
My understanding is that LINUX systems do not have pf, but rather have a less flexible filter called iptables. Whether iptables or any other packet filter that may be available on LINUX systems has synproxy or a similar feature I do not know
Not as nice as in *BSD's pf but a bit easier in nftables than in iptables. Can be activated in prerouting: https://wiki.nftables.org/wiki-nftables/index.php/Synproxy
tcp syncookies & timestamps have been enabled by default for years, you can check it: cat /proc/sys/net/ipv4/tcp_syncookies cat /proc/sys/net/ipv4/tcp_tcp_timestamps
In general, you should be careful with sysctl kernel parameters. If you do change them, only change individual settings and read and understand what they mean. If so, it is always good to look specifically for your network driver and DoS. With a 1G network connection, there is little to improve. In the cloudflare blog you will find a lot of in-depth expert knowledge about DoS.
On Freitag, 12. Juli 2024 10:12:09 CEST Toralf Förster via tor-relays wrote:
I prefer sysctl:
Me too, but sysctl needs root privileges. On new systems I always generate an overview of all active settings: sysctl -a > /home/user/sysctl.txt
And especially with used servers, before I start setting them up, save the output of skdump or smartctl.
I haven't read it yet, but there's a short paper at FOCI this year analyzing a case study of a DDoS attack on relays operated by the authors.
"A case study on DDoS attacks against Tor relays" Tobias Höller, René Mairhofer https://www.petsymposium.org/foci/2024/foci-2024-0014.php
On Mon, Jul 08, 2024 at 07:34:51PM +0200, Rafo (r4fo.com) via tor-relays wrote:
I have been running a relay for a few months now without any problems. But this week I’ve received 2 DDoS alerts from my provider (Netcup), both are ~3 gigabits. They seem to be coming from other Tor relays. I’m running an Invidious like instance on my server (which uses around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor relay to use 300-400 megabits. I’m not sure where that 3 gigabit of data comes from. I have lowered my advertised bandwidth to 100 megabits, would that be enough to prevent these kind of issues?
On 7/9/24 19:03, David Fifield wrote:
"A case study on DDoS attacks against Tor relays" Tobias Höller, René Mairhofer https://www.petsymposium.org/foci/2024/foci-2024-0014.php
After reading that paper I do wonder if a firewall rule would work which drops network packets with destination to the ORport if those packets are shorter than a given length?
-- Toralf
On Mittwoch, 10. Juli 2024 18:34:26 CEST Toralf Förster via tor-relays wrote:
Very interesting, thanks.
After reading that paper I do wonder if a firewall rule would work which drops network packets with destination to the ORport if those packets are shorter than a given length?
The idea is not bad. But can you simply discard every ≤ 50byte packet?
I drop fragments and uncommon TCP MSS values. ip frag-off & 0x1fff != 0 counter drop tcp flags syn tcp option maxseg size 1-536 counter drop
By the way, I actually wanted to write it as a Github issue. You have to adjust your Dir-auth IP's in iptables. IP of dizum has changed and faravahar is back ;-)
On 7/12/24 00:14, boldsuck wrote:
The idea is not bad. But can you simply discard every ≤ 50byte packet?
Probably not
I drop fragments and uncommon TCP MSS values. ip frag-off & 0x1fff != 0 counter drop
IIUC then using conntrack via iptables means that this filter cannot be implemented, right?
tcp flags syn tcp option maxseg size 1-536 counter drop
Is 536 == 514 + 22 (Tor packet size + ip header) ? It is my understanding that Tor send out TCP/IP small packets beside the 514 bytes sized.
-- Toralf
On Sonntag, 14. Juli 2024 15:54:45 CEST Toralf Förster via tor-relays wrote:
On 7/12/24 00:14, boldsuck wrote:
The idea is not bad. But can you simply discard every ≤ 50byte packet?
Probably not
I drop fragments and uncommon TCP MSS values. ip frag-off & 0x1fff != 0 counter drop
IIUC then using conntrack via iptables means that this filter cannot be implemented, right?
I have the above rule in 'chain ingress' and later in 'chain prerouting' & 'chain input' I have ct rules. Bo and I https://gitlab.torproject.org/tpo/community/support/-/issues/40093 used this nftables skeleton from the blog below for our rules.
tcp flags syn tcp option maxseg size 1-536 counter drop
Is 536 == 514 + 22 (Tor packet size + ip header) ? It is my understanding that Tor send out TCP/IP small packets beside the 514 bytes sized.
So my nftables skeleton came from the discussion on this blog: https://samuel.forestier.app/blog/security/nftables-hardening-rules-and-good...
Quote about MSS is there: "According to https://en.wikipedia.org/wiki/Maximum_segment_size the default TCP Maximum Segment Size is 536 octets (bytes)."
tor-relays@lists.torproject.org
-
boldsuck -
David Fifield -
lists＠for-privacy.net
-
Rafo (r4fo.com) -
Scott Bennett -
Toralf Förster