hier geht es um das Default Zertifikat was unter SSL/TLS Zertifikate zu finden ist und bei der Installation von Keyhelp erstellt wird.. Das hat nichts mit Let's Encrypt zu tun. Du kannst ein neues selbstsigniertes Zertifikat erstellen, es bei Bedarf einem Serverdienst zuweisen, der das Default ...

nochmal komplett, da war ein Fehler im Jail part nano /etc/fail2ban/filter.d/ddos-404.conf # Fail2Ban filter for catching 404 responses. # Useful if you wish to block an ip that is making too many 404 requests. [Definition] failregex = <HOST> - - \[.*\] "(GET|POST|HEAD) /.* HTTP.*" (401|403|404) [0 ...

Deinen fail2ban Filter empfinde ich als "schwierig". Durch die Blockierung sperrst du auch den legitimen Google-Bot aus und kannst dir dein Ranking gewaltig versauen. Hier nochmal verbessert mit Google exclude und ohne 301, 302 ... ignoreregex noch anpassen: # Fail2Ban filter for catching 404 ...

Ich hätte noch die 43.0.0.0/8 zu bieten. Absolut nervtötend seit heute morgen... das Singapore Inferno :mrgreen: (ist ja komplett durch incl. APNIC). Mein googleusercontent Problem hat sich derweil wohl erledigt ... gegen die aufkommende Langeweile ist nuh Cloudflare Hongkong, Pakistan, Saudi-A ...

Auf dem etwas größeren Server, den ich mir gestern zuerst angeschaut habe, sind gestern insgesamt fast 42000 Requests von IPs beginnend mit 34 oder 35 zusammengekommen. Heute sind es bisher nur 6 Stück. Schaun mer mal, ob da jetzt wirklich Ruhe einkehrt. Ja, es ist heute wieder ruhiger geworden, i ...

Bis auf eine Kiste, ist momentan alles wieder ok ... Das ging über 3 Tage lang mit diesen Power Attacken, alle aus dem weltweiten googleusercontent network. Eine Kleinigkeit ist mir noch aufgefallen, die jeweilige IP Adresse verwendet unterschiedliche UA Kennungen, bzw. eine Anwendung die ...

Hmm, die user agent Strings von ein und derselben IP sind da recht unterschiedlich, was ja nichts heißen muss. Vielleicht haben die da einen VPN-Server drauf laufen und greifen darüber mit verschiedenen Geräten zu. Oder sie variieren die user agent Strings einfach nach irgendeinem Schema. J ...

sind von heute gerade mal gut 40000 Zugriffe drin Eure Probleme möchte ich haben... :shock: :lol: Das sind ja nicht mal 3k pro Stunde, da läuft die Kiste doch immer noch fast im Idle :mrgreen: :geek: ... das "Grundrauschen" :lol: Bei mir sieht es leider anders aus ... und zwar auf allen shared H ...

tab-kh wrote: ↑Wed 27. May 2026, 18:09 Meinst du die netten Adressen aus 34.4.5.0 - 34.63.255.255? Die sind da auch reichlich vertreten.

genau, die netten 34.xx, 35.xx, 8.xx, 104.xx, 102.xx, 104.xx etc.
wenn die Dir ins Auge stechen, kannst schon mal in den Alarm Modus wechseln

Hmm, in der other_vhosts_access.log sind von heute gerade mal gut 40000 Zugriffe drin. Wo die herkommen und wie sie zeitlich verteilt sind muss ich mir heute später mal anschauen. Probleme scheinen sie dem Server jedenfalls auf den ersten Blick nicht zu machen. Hatte da früher auch schon größere Men ...

Deinen fail2ban Filter empfinde ich als "schwierig". Durch die Blockierung sperrst du auch den legitimen Google-Bot aus und kannst dir dein Ranking gewaltig versauen. Nein, schau noch mal auf "logpath" bisher hat der noch keine legitime IP erwischt (kontrolliere ich) ;-) Aber, wie gesagt das reicht ...

Da wollte ich gerade drauf zurückkommen ... Diese Art von Attacke läuft (zumindest bei mir) seit 3 Tagen und bei dieser Masse an IP Adressen bzw. damit verbundenen User Cloud Systeme, muß Google davon so etwas mitbekommen haben, das hier ist keine kleine Sache und Google ist ja nun der Anbieter und t ...

Das ist ja Wahnsinn ... wie schaffen die das vorab so vele requests so megaschnell abzufeuern?
Irgendwie scheint auch alles hierbei mit Google bzw. deren Cloud Netzwerk zusammenzuhängen ...

Was haste dir denn da für nen Fail2ban-Filter gebaut? auf die schnelle erstmal den hier ... ist zu 99% alles ddos, kommt in dem Fall nur aus der other_vhosts_access.log # Fail2Ban filter for catching 404 responses. # Useful if you wish to block an ip that is making too many 404 requests. ...

Ok, jetzt weiß ich warum die anderen 404 (ohne Weiterleitung) im other_vhosts_access.log landen ...
das scheint alle Standard Anfragen auf Port 80 zu betreffen, diese tauchen im User Log file nicht auf.