[tor-relays] many connections

Richie richie at zuviel.org
Sun Oct 9 07:47:59 UTC 2022


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 at lists.torproject.org
>>>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>>>>
>>>>>> _______________________________________________
>>>>>> tor-relays mailing list
>>>>>> tor-relays at lists.torproject.org
>>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>>
>>>> _______________________________________________
>>>> tor-relays mailing list
>>>> tor-relays at lists.torproject.org
>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



More information about the tor-relays mailing list