KeyHelp Community

ist wohl gerade voll der Trend ... bekomme davon jede Menge ab Weiß jemand ob python-httpx Anfragen offen bleiben müssen/sollten (LetsEncrypt, CMS Updates, etc.) ?

Hab die /etc/fail2ban/filter.d/keyhelp-bad-bots.conf vorhin mal erweitert:

Moin,

ich habe mal auf einem unserer Systeme geschaut - über 30k Zugriffe nach dem Schema überwiegend von amzn sources.

Was dort für Zugriffe vermerkt sind sieht aus wie ein large scale crawl auf alles Mögliche was sensible Informationen beinhalten könnte.
phpinfo, *sql, .*js, .env, configuration.* etc. Klar, grundlegend ist das nichts neues, aber in der Form schon.

Mir war das bisher noch nicht aufgefallen.
Einfach weg damit

Daniel wrote: ↑Tue 2. Dec 2025, 21:58 ich habe mal auf einem unserer Systeme geschaut - über 30k Zugriffe nach dem Schema überwiegend von amzn sources.
Was dort für Zugriffe vermerkt sind sieht aus wie ein large scale crawl auf alles Mögliche was sensible Informationen beinhalten könnte.
phpinfo, *sql, .*js, .env, configuration.* etc. Klar, grundlegend ist das nichts neues, aber in der Form schon.
Mir war das bisher noch nicht aufgefallen.
Einfach weg damit

Ja, ist mir bisher auch nie aufgefallen, es war ein Zufallsfund ... ich nehme mal an der HTTP client verursacht weniger Last und kann daher unauffälliger scannen. Es wird wohl nicht nur bei Python HTTPX bleiben, es gibt ja noch viele klassische HTTP clients die zusammen mit Composer in bekannten Anwendungen eingesetzt werden, da wird es dann schwieriger werden ...

Wir haben AWS auf vielen Servern mittlerweile per Firewall über die IP Ranges ausgesperrt. Hat sich noch niemand beschwert.

Ich denke, da hat sich jemand nicht die Mühe gemacht in seinem Python Programm, welches die "httpx" HTTP client Bibliothek verwendet, den "User Agent" mit etwas sinnvollerem zu ersetzen.

Sprich "python-httpx" wird der User Agent in der Standardeinstellung sein und damit wird jedes Programm, welches die genannte Bibliothek verwendet und dessen UA man nicht explizit umgestellt hat sich mit dieser Kennung melden.

Es werden sich hinter "python-httpx" wahrscheinlich also mehrere verschiedene Scripts unterschiedlicher Herkunft und unterschiedlichen Zwecks (ob positiv oder negativ) "verstecken".

Das nur als Hintergrundinformation, sollte es jemanden nicht klar sein, wie das "funktioniert".

Alexander wrote: ↑Wed 3. Dec 2025, 08:59 Es werden sich hinter "python-httpx" wahrscheinlich also mehrere verschiedene Scripts unterschiedlicher Herkunft und unterschiedlichen Zwecks (ob positiv oder negativ) "verstecken".

Oh ja ... es könnte aber auch eine Lücke oder Backdoor bei Anwendungen im Zusammenhang mit python-httpx geben, wobei reguläre Systeme für Angriffe genutzt werden, also nicht Anbieter spezifisch oder mit speziell installierten Angriffssystemen. Bei mir sehe ich schon eine große Menge an httpx requests zusätzlich zu den Standard scanner requests. Es ist wohl nicht mehr übertrieben zu sagen dass momentan mehr als 95% aller Anfragen auf Hosting Systeme Attacken basierend sind.

noch ein UA blocking https://www.meterian.io/components/nodejs/axios/1.9.0/
https://security.snyk.io/package/npm/axios/1.9.0

MS weist erstaunlicherweise bereits seit Sept. auf dieses Problem hin ... ich werde in dem Fall dann mal über meinen Schatten springen
https://techcommunity.microsoft.com/blo ... ts/4420827

Wie schätzt du das ein, was wäre die beste Methode?

1. Mittels fail2ban blocken, wie von dir beschrieben
2. Mit Rewrites wie in deinem MS-Link beschrieben
3. Beides kombinieren, sollte ja auch irgendwie gehen

Wenn man sich nur auf fail2ban verlässt, dann mag das eventuell je nach Server und Frequenz der Requests in die Hose gehen, noch bevor fail2ban blockt. Rewrites sind aber natürlich auch nicht völlig umsonst.

Ich muss mal meine Logs anschauen, wie heftig das Problem ist. Meine Server sind jetzt nicht alle riesig mit quasi unbegrenzten Ressourcen.

Vor Monaten hatte ich mal einen interessanten Kontakt, eine Schule hatte Probleme mit ihrem Webhosting bei M***tu. Ein DOS-Angriff oder halt ein sehr schneller Scan von einer IP hat nach Meinung des Hosters den Webserver überlastet und spannenderweise wurde die Schule aufgefordert, solche Vorfälle künftig zu vermeiden oder ein größeres Webhosting-Paket zu mieten, ansonsten würde das Hosting fristlos gekündigt . Das waren ca 100 Requests innerhalb von ca 3 Sekunden, was angeblich den Datenbankserver überlastet hätte, der dann abgeschmiert sei. Naja, ein kleiner (4C 8GB) Keyhelp-Server von mir hat sowas im Test mit einer Kopie der Website relativ kommentarlos geschluckt. Die Load ging allerdings schon hoch dabei.

tab-kh wrote: ↑Thu 4. Dec 2025, 16:35 Wenn man sich nur auf fail2ban verlässt, dann mag das eventuell je nach Server und Frequenz der Requests in die Hose gehen, noch bevor fail2ban blockt. Rewrites sind aber natürlich auch nicht völlig umsonst.

Ich habe bisher "NUR" Attacken basierende logs bzgl. python httpx finden können ...
Aber ich denke F2B ist besser geeigent als ein rewrite weil es sofort blockiert, die Server IPs sind ja (hoffentlich) whitelisted falls eine Anwendung doch python-httpx verwendet ... somit sollte F2B ausreichen: maxretry = 1 eventl. noch findtime, bantime für das jail noch anpassen oder einen extra Filter verwenden nur für http-client Attacken.

Ah so, maxretry=1 ist natürlich relativ flott. Je nach Attacke werden vielleicht doch ein paar Requests durchkommen, aber solange es nicht zu viele sind ... Dann werde ich das bei mir jetzt auch mal im Filter ergänzen.