[tor-relays] Read/written bytes on a relay differ
Hi everyone, nothing of real concern, but out of curiosity: since some years now i use overhead traffic on my ISP for Tor, with a small home relay burning some 3 to 4 MB/Sec. Usual middle relay plus V2Dir (and HSdir some days after last reboot). Since some weeks now, the read/written bytes differ quite significantly, and i never experieced sth like that for a relevant timespan before. Is this a sign of more "reading directory services" on the relay? (maybe short reqests and verbose replys), some new kind of attack, whatever? direct metrics-Link via https://metrics.torproject.org/rs.html#details/11FC7D9C7D8DF74326B90EC71C10173279738B8F and screenie attached. Again, no big issue, just curiosity. And if its some kind of bug, i'd be happy to hand over more info. thx to everyone maintaining and running this stuff, Richie ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] AirTor/ATOR continues to pester Tor relay operators, promising donations
ator.org actually works. They try to get Relay Operators to mine/receive their cryptocurrency through uptime, see https://docs.ator.io/ . Also some hardware plans regarding Wifi routers with preinstalled "ator" software/routing. Personally, i'd say "kill it with fire", but well, thats just me :) Nevertheless, i guess it could be helpful to make it clear also on behalf of torproject.org, that we're neither support nor endorse their plans and disencourage to use this stuff. greetz Richie Am 16.03.23 um 20:25 schrieb Christian Pietsch via tor-relays: Dear Tor community, maybe the notes from the Tor relay operator meetup on March 4 should have mentioned that a participant called AirTor was kicked from that BBB conference. This happened because they were using “Tor” in their name and continued to make dubious offers like the one below which just arrived in my NGO's inbox. They did not send it to the e-mail address in the ContactInfo of our Tor relays but a generic one. In BBB's text chat, they offered to change their name “if thats best,” but as you can see, they have not. Instead, the signed as ATOR – but that might be a typo. I am writing this to let you know that it's best to ignore e-mails like the one below. In the meetup, Roger made it increasingly clear that he does not believe that AirTor are acting in good faith. Cheers, Christian - Forwarded message - From: AirTor Team Message-ID: <1167510526.29240.1678981005...@eu1.myprofessionalmail.com> Subject:Support for TOR relay associations X-Mailer: Open-Xchange Mailer v8.10.73 X-Originating-IP: 24.218.88.76 Hello from ATOR! We are a community driven initiative that provides recognition rewards to supporters and operators in the TOR ecosystem. We would love to recognize your efforts and the efforts of your relay operators, and hear your opinions on the protocol we have in mind. Please let us know if this is something of interest to you. We would also like to donate to help your operation grow and remain active. Thank you for your time, we hope to hear from you soon! Sincerely, ATOR team - End forwarded message - ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay configuration not allowing optimal performance
Hi there, i also use enkidus DDoS-Migitationscripts and had some constant "overloaded" messages (along with a drop in consensus weight). Just reinstalling the scripts fixed the issue for me (i guess its just me messing up some cron stuff, nevertheless, maybe i'm not the only one). Regarding your HW/Bandwith... Am 25.02.23 um 14:44 schrieb Relayer via tor-relays: I'm running a tor relay on some older hardware that I didn't want to discard when I could still put it so good use. Some details of the box are: -- CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz -- RAM: 4GB -- ARCH: x86_64 -- HDD: 250GB -- OS: Ubuntu 22.04.1 ..i had quite the same processor on my previous relay. It actually should be able to relay some more data. If the ddos script reinstallation doesn't help: killing off the desktop enviroment (if not deactivated by default) clears up some resources. I originally configured a single Tor instance IPv4 to run as a relay only (not as an exit, nor hosting a hidden service). I am also using the iptables rules from https://github.com/Enkidu-6/tor-ddos <https://github.com/Enkidu-6/tor-ddos> to minimize DDOS overhead (please advise if there are alternatives or additions to this). My original config seemed ok until I started seeing my CPU and RAM maxing out consistently so I throttled back with the following in my torrc: RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) MaxAdvertisedBandwidth 1 MB My RAM usage now is only about 50% or marginally less of my total available. I think i had only 2GB on a quite similar machine and it made about 400-600 kB. CPU/Ram on 70-80% is normal as far as i can tell. Nyx also grabs some processor load, though (here about 10-30%). If not needed permanently, i'd recommend turning it off apart from checking actual load/connections. Your Box is a dual core. 100% CPU should not be a problem. I played around with the NumCPU-Flag in torrc back then, but https://forum.torproject.net/t/numcpus-best-practice-on-multi-core-multi-relay-servers/3802/10 says one shouldn't (and i didn't get anything out of it). Here's how the metrics look lately: https://metrics.torproject.org/rs.html#details/38939B45237BA84941C74836349C152473F84C56 <https://metrics.torproject.org/rs.html#details/38939B45237BA84941C74836349C152473F84C56> As you can see, the throughput rated dropped in half (that's when the graph drops on 2023-02-09). However, the volume continued to decline. Additionally, I'm unclear why my Middle Probability and Consensus Weight have both dropped to near 0%. Are those, in fact, where I want them? At least for me, Consensus weight is a bit difficult to interpret. It does not only measure your throughput, but its relation to the whole Tor network. If the network grows, your consensus weight drops. Here, it looks quite correlated to the 25-30k your Relay puts through. I'm monitoring with nyx and see I get some traffic through with no apparent errors or warnings. I am NOT seeing the CPU spikes any longer but I don't think I'm giving the most with my hardware. Questions: 1.) Is my tor service now misconfigured and not utilizing my hardware as best it could? As long as you don't get "overloaded" notices, i guess you'd be safe with, well, 400kB rate, 600kB Burst. More than 100 should definitely be possible. 2.) Should my Consensus Weight and/or Middle Probability be higher? right now, no :) When actual throughput rises, then it should grow, too. 3.) Should I consider running two tor instances? I don't see any advantages. Problem is definitely not a "its only one instance!". Apart from more work/configuration/overhead without advantage, ddos exposure maybe doubles. greetz Richie Nyx log snippet: 07:59:32 [NOTICE] Heartbeat: DoS mitigation since startup: 7 circuits killed with too many cells, 591 circuits rejected, 2 marked addresses, 0 marked addresses for max queue, 0 same address concurrent │ connections rejected, 0 connections rejected, 0 single hop clients refused, 19166 INTRODUCE2 rejected.[1 duplicate hidden] │ 07:59:32 [NOTICE] 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 57982 v4 │ connections; initiated 116266 and received 356623 v5 connections. │ 07:59:32 [NOTICE] Circuit handshake stats since last time: 3/3 TAP, 44849/44849 NTor.[1 duplicate hidden] │ 07:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 194128391 (server descriptor fetch); 7140 (server descriptor upload); 17539422 (consensus network-status fetch); 1794 (authority cert │ fetch); 2111765 (microdescriptor fetch) │ 07:59:32 [NOTICE] Heartbeat: Tor's uptime is 10 days 23:
Re: [tor-relays] New relay questions
Hi, Pete, won't have too much answers (and maybe the bandwith settings from your torrc-file would help). Did you set RelayBandwithRate or "only" BandwithRate? Reloading torrc-settings is better made via pkill -sighup tor since it does not restart the service (disconnecting everyone in the process) but just loads the new config. Email/GPG Settings should have no effect on anything. Greetz Richie Am 15.12.22 um 10:56 schrieb code9n via tor-relays: Hi Relay Operators, I am trying to run a non exit relay for the first time and have some questions: FYI, I have 2 virtual CPU s and 1.256 GB RAM with ‘unlimited’ bandwidth on a rented VPS running Debian 11. The logs report success and the Relay Search shows my relay (Nickname: code9nRelay) running but the advertised bandwidth is 0 B/s. It’s been running for 13 hours or so and I see a new relay that has been running for 1 hour has an advertised bandwidth of 12MiB/s. I did set the bandwidth to 100KB/s, then 200KB/s but now it’s just set to run the defaults. Ie Nothing is set. I had my email address as my first contact then my GPG fingerprint as a second contact but the fingerprint is displayed not the email. Now I have it all on one line with the email address first. Which brings me to my main question; when I run *systemctl restart tor@default* shouldn’t the new settings in the torrc file be used from that point on? Because they don’t seem to be. I have run it after making the changes above and the old settings are still shown on the Relay Search page. Ie 0KB/s and my GPG fingerprint showing as my email address. If this restart doesn’t reset the torrc then what does? Or is it just a matter of waiting for the new info to be taken up? Any one have any thoughts or advice, please? Pete Here are the recent logs: Dec 14 20:05:31.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 10 circuits open. I've sent 188.82 MB and received 168.28 MB. I've received 14629 connections on IPv4 and 1847 on IPv6. I've made 171 connections with IPv4 and 8 with IPv6. Dec 14 20:05:31.000 [notice] While not bootstrapping, fetched this many bytes: 3951317 (server descriptor fetch); 944 (server descriptor upload); 358850 (consensus network-status fetch); 49621 (microdescriptor fetch) Dec 14 20:05:31.000 [notice] Average packaged cell fullness: 95.570%. TLS write overhead: 16% Dec 14 20:05:31.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 37259/37259 NTor. Dec 14 20:05:31.000 [notice] 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 60 and received 16368 v5 connections. Dec 14 20:05:31.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Dec 15 02:05:31.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 3 circuits open. I've sent 375.23 MB and received 326.98 MB. I've received 32711 connections on IPv4 and 3289 on IPv6. I've made 306 connections with IPv4 and 14 with IPv6. Dec 15 02:05:31.000 [notice] While not bootstrapping, fetched this many bytes: 8221506 (server descriptor fetch); 944 (server descriptor upload); 766467 (consensus network-status fetch); 80676 (microdescriptor fetch) Dec 15 02:05:31.000 [notice] Average packaged cell fullness: 94.792%. TLS write overhead: 18% Dec 15 02:05:31.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 37813/37813 NTor. Dec 15 02:05:31.000 [notice] 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 88 and received 35765 v5 connections. Dec 15 02:05:31.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Dec 15 02:31:35.000 [notice] Performing bandwidth self-test...done. ……... ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bridge down
Hi there, Am 16.10.22 um 17:09 schrieb Anonforpeace via tor-relays: Hello: My Tor Bridge has been down for awhile as I was moving to a new home. I have been trying to bring it up again and have been receiving the messages you see below. I have checked the the tor project status and see that there is a Ddos attack affecting the network. Is that why I am getting this or am I doing something wrong? Thank you. To me, it looks completely unrelated to the DDoS. darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ sudo systemctl enable --now tor.service Synchronizing state of tor.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable tor darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ sudo systemctl restart tor.service darkhoodie@darkhoodie-HP-Compaq-Pro-6300-SFF:~$ journalctl -e -u tor@default Oct 16 00:20:14 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[16182]: Your server has not managed to confirm reachability for its ORPort(s) at 100.2.224.20:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. ... that looks to me like the port forwarding does not work. I assume your bridge is in the home network behind a router. You'll need to forward the ORport 100.2.224.20:443 to the local IP of your machine. Regards, &thx for running a bridge, Richie ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] many connections
Addendum: two days later, things are back to normal. Consensus still about 300, but i guess thats normal to adjust slower. Up/download now at the allowed 1,2M limit. Since i don't believe that i have some kind of special setup/situation here, i assume it takes some time to rebuild connections after the ddos protection goes into action. Maybe of interest: one of the first things i did after being overloaded permanently was deactivating the dir port. Reactivated it after traffic went down, works fine since then. greetz and thanks for all the support, Richie Am 07.10.22 um 14:58 schrieb Richie: Hi everyone, can confirm. compare.sh shows "fluctuation" of relay IPs as announced. The tor-ddos ipset is a bit smaller here (ca. 70 atm). Observation, though: since activation, data throughput went from 600-800k down to about 100 or even lower. Hardware/Connection should be able to handle about 1-1,5m (before ddos, i had it limited to 1200k, what was also actually used/handled). Unsure if related or another case of "consensus weight tanking" as mailed in a different thread here. Consensus weight went down to 140 ATM, from ca. 400 while ddosed and 1000-1200 before ddos. No connection issues, though. greetz&thx, Richie Am 07.10.22 um 13:37 schrieb Sandro Auerbach: An effect can definitely be seen. I now have an average of 30 relays and over 600 IPs in the block list. Am 07.10.22 um 09:18 schrieb Chris: Compare.sh will tell you how many of the IPs in the block list are relays. You've collected a lot more IPs in your block list. Open a terminal and type: ipset -L tor-ddos and you'll see how many IPs are sitting in your block list. On 10/6/2022 1:13 PM, Richie wrote: Hoi, Chris, oh wow, that seems to help a lot. Uptime 1/2 hour now, load 50-60% and six IPs collected according to compare.sh. No signs of overload yet. Thanks a lot, and i'll report, how things evolved. ATM, it looks like you can add the "n00b proof"-stamp to your concept :) Greets and thanks again, Richie Am 06.10.22 um 11:47 schrieb Chris: Hi Richie I was a bit lost myself having to deal with the scripts and additional packages to install. So I put something together for myself based on the same rules and added a few twists but in a simple text n00b proof format. It's as simple as copy and paste and because it's all in clear text, you can modify it without worrying about breaking any script. My rules are a tad more strict but you can modify them as you wish. But the concept is what @toralf has been implementing with a few twists for efficiency's sake. You can find them here: https://github.com/Enkidu-6/tor-ddos On 10/3/2022 6:26 AM, Richie wrote: Hi, toralf, since i'm quite a n00b regarding iptables and shellscripts: are there somewhere n00b-proof setup instructions for the ddos protection scripts? here: relay (schlafschaf) with the usual connection floods, running on Kubuntu (latest LTS) What i found out: ipset is not installed per default, added via sudo apt-get install iptables Also installed as recommended: stem, jq Trivial, nevertheless: edited the ORPort address on Line 122 Outcommented Lines 79-103 (hetzner, zwiebeltoralf only) running the script results in output as with iptables -L, containing tcp dpt:443 #conn src/32 > 30 @ the "chain input ACCEPT" line and no entries in the chain PREROUTUNG, OUTPUT, PREROUTING and OUTPUT lines. Strange: sudo watch ipv4-rules.sh results in 1: ipv4-rules.sh: not found My apologies if its not the right place to ask. greetz Korrupt Am 03.10.22 um 09:43 schrieb Toralf Förster: On 9/30/22 17:57, Sandro Auerbach wrote: 30 minutes later still 22000 connections... Have you observed something similar? I reduced those spikes [1] by using certain iptables rules [2]. [1] https://github.com/toralf/torutils/blob/main/sysstat.svg [2] https://github.com/toralf/torutils ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/l
Re: [tor-relays] many connections
Hi everyone, can confirm. compare.sh shows "fluctuation" of relay IPs as announced. The tor-ddos ipset is a bit smaller here (ca. 70 atm). Observation, though: since activation, data throughput went from 600-800k down to about 100 or even lower. Hardware/Connection should be able to handle about 1-1,5m (before ddos, i had it limited to 1200k, what was also actually used/handled). Unsure if related or another case of "consensus weight tanking" as mailed in a different thread here. Consensus weight went down to 140 ATM, from ca. 400 while ddosed and 1000-1200 before ddos. No connection issues, though. greetz&thx, Richie Am 07.10.22 um 13:37 schrieb Sandro Auerbach: An effect can definitely be seen. I now have an average of 30 relays and over 600 IPs in the block list. Am 07.10.22 um 09:18 schrieb Chris: Compare.sh will tell you how many of the IPs in the block list are relays. You've collected a lot more IPs in your block list. Open a terminal and type: ipset -L tor-ddos and you'll see how many IPs are sitting in your block list. On 10/6/2022 1:13 PM, Richie wrote: Hoi, Chris, oh wow, that seems to help a lot. Uptime 1/2 hour now, load 50-60% and six IPs collected according to compare.sh. No signs of overload yet. Thanks a lot, and i'll report, how things evolved. ATM, it looks like you can add the "n00b proof"-stamp to your concept :) Greets and thanks again, Richie Am 06.10.22 um 11:47 schrieb Chris: Hi Richie I was a bit lost myself having to deal with the scripts and additional packages to install. So I put something together for myself based on the same rules and added a few twists but in a simple text n00b proof format. It's as simple as copy and paste and because it's all in clear text, you can modify it without worrying about breaking any script. My rules are a tad more strict but you can modify them as you wish. But the concept is what @toralf has been implementing with a few twists for efficiency's sake. You can find them here: https://github.com/Enkidu-6/tor-ddos On 10/3/2022 6:26 AM, Richie wrote: Hi, toralf, since i'm quite a n00b regarding iptables and shellscripts: are there somewhere n00b-proof setup instructions for the ddos protection scripts? here: relay (schlafschaf) with the usual connection floods, running on Kubuntu (latest LTS) What i found out: ipset is not installed per default, added via sudo apt-get install iptables Also installed as recommended: stem, jq Trivial, nevertheless: edited the ORPort address on Line 122 Outcommented Lines 79-103 (hetzner, zwiebeltoralf only) running the script results in output as with iptables -L, containing tcp dpt:443 #conn src/32 > 30 @ the "chain input ACCEPT" line and no entries in the chain PREROUTUNG, OUTPUT, PREROUTING and OUTPUT lines. Strange: sudo watch ipv4-rules.sh results in 1: ipv4-rules.sh: not found My apologies if its not the right place to ask. greetz Korrupt Am 03.10.22 um 09:43 schrieb Toralf Förster: On 9/30/22 17:57, Sandro Auerbach wrote: 30 minutes later still 22000 connections... Have you observed something similar? I reduced those spikes [1] by using certain iptables rules [2]. [1] https://github.com/toralf/torutils/blob/main/sysstat.svg [2] https://github.com/toralf/torutils ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] many connections
Hoi, Chris, oh wow, that seems to help a lot. Uptime 1/2 hour now, load 50-60% and six IPs collected according to compare.sh. No signs of overload yet. Thanks a lot, and i'll report, how things evolved. ATM, it looks like you can add the "n00b proof"-stamp to your concept :) Greets and thanks again, Richie Am 06.10.22 um 11:47 schrieb Chris: Hi Richie I was a bit lost myself having to deal with the scripts and additional packages to install. So I put something together for myself based on the same rules and added a few twists but in a simple text n00b proof format. It's as simple as copy and paste and because it's all in clear text, you can modify it without worrying about breaking any script. My rules are a tad more strict but you can modify them as you wish. But the concept is what @toralf has been implementing with a few twists for efficiency's sake. You can find them here: https://github.com/Enkidu-6/tor-ddos On 10/3/2022 6:26 AM, Richie wrote: Hi, toralf, since i'm quite a n00b regarding iptables and shellscripts: are there somewhere n00b-proof setup instructions for the ddos protection scripts? here: relay (schlafschaf) with the usual connection floods, running on Kubuntu (latest LTS) What i found out: ipset is not installed per default, added via sudo apt-get install iptables Also installed as recommended: stem, jq Trivial, nevertheless: edited the ORPort address on Line 122 Outcommented Lines 79-103 (hetzner, zwiebeltoralf only) running the script results in output as with iptables -L, containing tcp dpt:443 #conn src/32 > 30 @ the "chain input ACCEPT" line and no entries in the chain PREROUTUNG, OUTPUT, PREROUTING and OUTPUT lines. Strange: sudo watch ipv4-rules.sh results in 1: ipv4-rules.sh: not found My apologies if its not the right place to ask. greetz Korrupt Am 03.10.22 um 09:43 schrieb Toralf Förster: On 9/30/22 17:57, Sandro Auerbach wrote: 30 minutes later still 22000 connections... Have you observed something similar? I reduced those spikes [1] by using certain iptables rules [2]. [1] https://github.com/toralf/torutils/blob/main/sysstat.svg [2] https://github.com/toralf/torutils ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] many connections
Hi, toralf, since i'm quite a n00b regarding iptables and shellscripts: are there somewhere n00b-proof setup instructions for the ddos protection scripts? here: relay (schlafschaf) with the usual connection floods, running on Kubuntu (latest LTS) What i found out: ipset is not installed per default, added via sudo apt-get install iptables Also installed as recommended: stem, jq Trivial, nevertheless: edited the ORPort address on Line 122 Outcommented Lines 79-103 (hetzner, zwiebeltoralf only) running the script results in output as with iptables -L, containing tcp dpt:443 #conn src/32 > 30 @ the "chain input ACCEPT" line and no entries in the chain PREROUTUNG, OUTPUT, PREROUTING and OUTPUT lines. Strange: sudo watch ipv4-rules.sh results in 1: ipv4-rules.sh: not found My apologies if its not the right place to ask. greetz Korrupt Am 03.10.22 um 09:43 schrieb Toralf Förster: On 9/30/22 17:57, Sandro Auerbach wrote: 30 minutes later still 22000 connections... Have you observed something similar? I reduced those spikes [1] by using certain iptables rules [2]. [1] https://github.com/toralf/torutils/blob/main/sysstat.svg [2] https://github.com/toralf/torutils ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
