After changing my server, the connections settled between 6000-8000 incoming connections in the first 2 weeks of the warm-up period. (Guard/non exit)
Since it seems that many relays have been overloaded in the last few weeks, I think a big DDOS is running again.
Yesterday I tried to reduce the bandwidth a bit. I’ve just looked again and see over 26800 incoming connections.
Is this even possible or is it more of a bug in the system? 30 minutes later still 22000 connections…
Have you observed something similar?
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].
Every place is the right place for feedback, thx for yours !
I updated the readme [1] at the experimental branch and will merge it to main soon. Feel free to give additional feedback -and/or- make directly a pull request at GH.
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.
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].
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.
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].
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.
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].
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.
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].
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.
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].
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.
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].
