OK, der Bugfix oder Patch scheint doch enthalten zu sein, der Status wurde jetzt aktualisiert. https://security-tracker.debian.org/tracker/CVE-2026-49975 Die Apache Last geht hier ein wenig runter, aber ist noch nicht vorbei ... Bald werden dann vermutlich noch gekaperte Enduser-Geräte zum Einsatz ...

hmm, zu früh gefreut ... da wurde zwar vorhin ein Apache Update angeboten, aber dies scheint nicht CVE-2026-49975 zu betreffen ... jedenfalls ist es weiterhin als vulnerable gelistet:
https://security-tracker.debian.org/tra ... 2026-49975

Auch wenn die Angreifer genauso blöd sind wie sie aussehen ... die gleichen Aktionen werden nun auch via VPN und CloudFlare getarnt. War nur eine kurze Verschnaufpause mit den IPsets, ich arbeite aber momentan daran noch sehr viel skrupelloser zu werden :shock: Bald werden dann vermutlich noch ...

Ja, es geht dann wieder heftig los ...
Die IPsets bleiben jetzt auch permanent aktiv ... sche*ß der Hund drauf

H2MaxSessionStreams 100 ist default, also testen und anpassen z.b. 20 ....
Interessant ist hierbei die Quelle ... gut 95% davon kommen von googleusercontent (massenhaft) ansosnten wie gehabt, AWS, DO usw.

OK, so müsste es funktionieren ... nano /etc/apache2/mods-available/http2.conf # hinzufügen: # Restrict concurrent streams H2MaxSessionStreams 100 # Cap memory per stream to prevent bomb bursts H2StreamMaxMemSize 65536 H2MaxDataFrameLen 65536 # neu starten apache2ctl configtest systemctl restart a ...

Keine Ahnung ob diese HTTP/2 Bomb vulnerability mit den aktuellen o.g. Attacken zu tun hat, aber es deutet einiges darauf hin, wie z.b. die Geschwindigkeit bzw. die extrem kurzen Zeitspannen der requests die auch in meinen Logs zu sehen waren. Gestern ist es auch kurzzeitig wieder aufgeflammt ...

Kommt der momentan bei Euch auch so aufdringlich zu Besuch? crusoe.ai
UA:
CoreAutoPDFPretrainingBot (+contact URL or email)" 124 569474

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 ...