Flood auf Webserver/Wordpress

  • Okay, dann anders.
    Hast du Zugriff auf den Server wo NGINX läuft ?
    Wenn ja, schalte erstmal die Access-Logs aus - das ist bei einem Flood gift.
    2. Schau dir mal den User-Agent an der da zugreift - wenn das jetzt ein Bot ist oder sowas kannst du das relativ easy via return 444; in Nginx filtern und sperren.

    Sonst würde ich mal kurzzeitig CloudFlare auf CaptchaOnly stellen und schauen wie CF damit umgeht

    Vollzugriff ist vorhanden.

    Die User-Agents waren am Anfang immer gleich und hatte ich dann auch komplett geblockt, jetzt sind das unterschiedliche Client-Agents. Somit nicht möglich, diese zu blocken.

    CloudFlare hab ich vorhin mal Unter Attack gestellt, war sofort ruhe. Aber das kann doch nicht die Lösung sein. :/

    Ich würde auf Apache verzichten und ausschließlich nginx verwenden. Nginx bekommt das zum einen selbst ganz gut gebacken und ist zweitens deutlich effizienter.


    Desweiteren ist leider relativ wenig von der Konfiguration der Webserver und php-fpm oder was auch immer du verwendest bekannt. Die Tatsache das der Server viel RAM hat macht tatsächlich wenig aus, wenn du die power nicht nutzt. Im übrigen würde mich noch brennend interessieren was in der nginx.conf steht.

    Ich probier das mal aus, danke für den Tipp.

    Jetzt nutzt du schon Cloudflare und nutzt die Cache funktion scheinbar nicht. Da du ja geschrieben hast das dir das zu gefährlich ist pauschal zu cachen via Cloudflare wäre die Überlegung doch nahe mittels entsprechender Header z.B. Bilder, CSS und JS auf Langzeit zu cachen und dynamischen Inhalt für 5 Sekunden oder was in dem Dreh. Da kann man je nach Seite bestimmt nochmal deutlich optimieren durch entsprechende Weiterentwicklung. Würde ja schon reichen wenn man die Kommentare via XHR nachlädt (ohne Cache Funktion) und den Rest einfach für 1h oderso cached.

    Das werde ich mir auch anschauen müssen, dass CloudFlare so ziemlich den kompletten Cache übernimmt. Ich möchte aber nicht unbedingt immer von CloudFlare abhängig sein: Auf dem Server selbst bekommt man so eine optimale Lösung sowieso nicht hin, oder? Zudem weil CloudFlare ja so eine riesen Infrastruktur hat ...

    Übrigens: du kannst dir ja mal anschauen von welchen IP's die Anfragen ursprünglich abgesendet werden. Steht in $_SERVER["HTTP_CF_CONNECTING_IP"] Variable.

    Hab ich nun in den access logs eingebaut, dass die Client-IPs angezeigt werden.

    Sich den Useragent mal anzuschauen könnte vielleicht hilfreich sein, ist es aber in den wenigsten Fällen. Welcher Angreifer ist so blöd und nimmt einen UA mit dem er identifizierbar und problemlos sperrbar ist? Sofern man ne Message hinterlassen will gepaart mit nem Angriff reicht auch ne Mail + der Angriff.

    Das war vorher tatsächlich der Fall, da wurde immer ein unreaslistischer User-Agent genutzt. Jetzt sind die leider zufällig und völlig ok.

  • Versuch es mal mit der Konfiguration, Fail2Ban wird ohne die Access-Logs nicht funktionieren...

    It’s not about what technology can do.

    It’s about what you can do with it.

    The post was edited 1 time, last by Azey ().

  • worker_processes 1;

    die 1 am besten durch auto ersetzen



    worker_connections 10000;

    Eine Abfrage durch `ulimit -n` sagt dir was du hier eintragen kannst. Sofern da unlimited steht kannst du 65535 eintragen, wenn die Zahl unter 65535 liegt dann machste eben nen `ulimit -n 65535`


    gzip Komprimierung würde ich einschalten, das keepalive Timeout kleiner machen

    proxy_send_timeout 1200s;
    proxy_read_timeout 1200s;
    fastcgi_send_timeout 1200s;
    fastcgi_read_timeout 1200s;

    Das erscheint mir viel zu hoch!

    Auf dem Server selbst bekommt man so eine optimale Lösung sowieso nicht hin, oder?

    Ich weiß nicht auf welchen Punkt du genau heraus willst, clientseitiges, kontrolliertes caching geht aber auch ohne cloudflare.

  • Versuch es mal mit der Konfiguration, Fail2Ban wird ohne die Access-Logs nicht funktionieren...

    Danke für den Post, leider startet nginx danach nicht mehr. Da scheint es einen Fehler zu geben.

    Mit diesen Settings ist es schon sehr gut, danke! Gzip war bereits aktiv.

  • Danke für den Post, leider startet nginx danach nicht mehr. Da scheint es einen Fehler zu geben.

    Mit diesen Settings ist es schon sehr gut, danke! Gzip war bereits aktiv.

    OK. Ohne eine Fehlermeldung kann dir wahrscheinlich hier keiner weiterhelfen.

    Code
    1. nginx -t

    danke

  • Danke nochmal für Eure Tipps letztens. Ist wirklich um einiges stabiler und läuft schneller (auch durch verbessertes Caching & Co.)


    Nun hab ich den nächsten Fall: Der nächste Lustige versucht meine CPU mit lauter Query Strings und zahlreichen Nutzern gleichzeitig komplett zu überlasten. Die CPU bzw. der Datenbank-Prozess dreht hier auf 100% und nginx blockt danach alles ab. Schaut ungefähr so aus:


    NOBw9.png


    Hab bei CloudFlare unter "Caching" auch bereits "Igore Query String" angehakt, bringt nichts.

  • keine gute idee die ganzen IP-Adressen hier zu publizieren. Am besten einfach die IP's blocken ^^

  • keine gute idee die ganzen IP-Adressen hier zu publizieren. Am besten einfach die IP's blocken ^^

    "einfach", wenn jedes Mal 100 neue IPs dazu kommen? Stelle dich gerne als IP-Blocker bei mir ein. ;)

    Wieso sollte das mit dem IP-Adressen ein Problem sein?


    B2T: Es muss doch eine Lösung für so einen Flood geben ...

  • "einfach", wenn jedes Mal 100 neue IPs dazu kommen? Stelle dich gerne als IP-Blocker bei mir ein. ;)

    Wieso sollte das mit dem IP-Adressen ein Problem sein?


    B2T: Es muss doch eine Lösung für so einen Flood geben ..

    Bin ein leie in diesem Thema, aber es wird doch sicherlich unter Linux eine Möglichkeit geben Ip-Adressen zu blockieren die in Sekundenabschnitten mehrmals (wie in deinem Fall) die Seite aufrufen. Der Angriff hat identische Muster, hier bei ist doch weder relevant noch bedeutsam auf welcher Seite geflooded wird. Es scheint so, als ob hier die grundlegende Konfiguration für Requests fehlt.