Flood auf Webserver/Wordpress

1. offizieller Beitrag

    Liebe Community,

    ich habe in letzter Zeit öfters mit Floods auf meinen Webserver zu kämpfen. Dieser läuft nebenbei angemerkt mit Plesk, im Mix mit Apache und nginx. Hosted by Hetzner.

    Jetzt versuchen seit kurzer Zeit einige Leute öfters unsere RPG Wordpress-Page mit PHP Requests zu flooden. Es wird einfach eine spezielle Seite oder die Startseite von mehreren IPs angegriffen, konkret meist mit 10 Clients und dazu 100 Threads pro Sekunde - also massiv. Während der "Attacke" lädt die Seite nicht mehr und ich bekomme folgende Fehlermeldungen im Zugriffslog "29042#0: *21099 upstream timed out (110: Connection timed out) while SSL handshaking to upstream".

    Habe mich auch bereits durch die Plesk Hilfeseiten (https://support.plesk.com/hc/en-us/artic…teway-Time-out-) durchgekämpft und auch in der nginx.conf folgendes hochgedreht:

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

    Hat irgendwer eine Ahnung, am besten jemand der auch solche Seiten betreibt die gegen solche Angriffe gewappnet sind, wie man hier vorgehen kann? Am Server sollte es nicht scheitern, der hat genügend Leistung.

    Danke!

    Zitat von ThomiMe

    Ist aktiv, hat aber bislang noch nie zugeschlagen :P

    Hast du vielleicht eine spezielle Jail für mich, die das blockiert? Immerhin "sieht" das ja wie ein ganz normaler Request aus ... User-Agents und andere Sachen passen bei den Angriffen ja immer.

    pasted-from-clipboard.png

    fail2ban ist ziemlich individuell anpassbar, sofern eine statisches angriffsmuster verwendet wird könnte man da ja mal schauen.

    ps: diese tollen filter via webinterface (nehme ich mal an) bringen dir rein garnichts, wenn der webserver und/oder fail2ban nicht richtig konfiguriert sind. die manuelle systemadministration wäre sicherlich sinnvoller.

    keine ahnung ob das an meiner verachtung von plesk und co oder meiner erfahrung liegt ¯\_(ツ)_/¯

    Zitat von PixelFriend

    ps: diese tollen filter via webinterface (nehme ich mal an) bringen dir rein garnichts, wenn der webserver und/oder fail2ban nicht richtig konfiguriert sind. die manuelle systemadministration wäre sicherlich sinnvoller.

    Ist korrekt konfiguriert, blockt ja auch fleißig fehlgeschlagene SSH-Logins oder fehlgeschlagene .htaccess Apache-Logins. Über 100 IPs geblockt. ;)

    Zitat von PixelFriend

    fail2ban ist ziemlich individuell anpassbar, sofern eine statisches angriffsmuster verwendet wird könnte man da ja mal schauen.

    Das Angriffsmuster ist immer unterschiedlich. Meist gehen die auf die Startseite "/" oder Unterseiten, wie Archive "/2018/10" oder holen sich Bilder/PDFs vom Server. Obwohl die Seite gut gecached ist, hat der Server hier irgendwie keine Chance nachzukommen. Liegt wohl an Wordpress ... :/

    Hab zwar das hier (https://www.garron.me/en/go2linux/fa…dos-attack.html) gefunden, scheint aber nicht das Gelbe vom Ei zu sein. Erwähnt er ja selbst: "Consider that you will have one GET for each css, js, html, ico and other files that are part of your webpage, so if you have 20 components, some client needs only to load 15 pages in 5 minutes to get blocked. Be sure to adjust those values to fit your needs."

    Wenn ich mehrere GET-Requests pro Aufruf eines normalen Besuchers logischerweise habe, wird auch der dann unabsichtlich geblockt. Mhmm ... :/

    Wenn deine Seite schon bei 10 Clients sofort down geht, hält deine Kiste nicht viel aus. Oder ist ungeschickt konfiguriert. Beobachte doch mal den Ressourcenverbrauch zum Zeitpunkt des Angriffs und im „Normalzustand“ - stoßen RAM, CPU & Co. dann irgendwo an ihre Grenzen?

    Ich weiß nicht ob du CloudFlare verwendest, jedenfalls hast du es nicht erwähnt. Falls nicht, kann ichs dir ans Herz legen, CloudFlare zu verwenden, als zusätzliche Absicherung. Sollte sehr effektiv sein bzw könnte das Problem sogar lösen, wenn du den Traffic darüber leitest.

    Ausgehend von deiner Beschreibung wird es sich wahrscheinlich um einen Layer 7 Angriff handeln, obwohl Wordpress normalerweise nicht auffallend anfällig für so Attacken ist, solange man eben keine Schwachstellen hat. Eventuell hast du Apache oder PHP nicht ordentlich eingestellt. Werf einen Blick auf die Apache, nginx und PHP Einstellungen - insbesondere die, bei denen Connection Timeouts, Max Execution Times, Max RAM Usage oder Input Limits gesetzt werden. Check ob irgendeine Seite deiner Website besonders aufwändige Scripts ausführt. Lass POST Anfragen ohne Captcha gar nicht erst zu, limitiere die Max Request Length, reduziere die Connection Keep Alive / Timeout, setze Max Connections runter und so weiter.

    Eventuell weiter hilfreich:

    https://www.nginx.com/blog/mitigatin…and-nginx-plus/

    https://support.plesk.com/hc/en-us/artic…er-performance-

    https://docs.plesk.com/en-US/12.5/cus…websites.65276/

    https://docs.nginx.com/nginx/admin-gu…s-proxied-http/

    https://blog.sucuri.net/2014/02/layer-…od-attacks.html

    Aber: Ich denke nicht, dass das Herumschrauben an den Einstellungen viel bewirken wird, es sei denn, etwas ist total falsch eingestellt - was so gut wie nie der Fall ist. Normalerweise macht man solche Performance Tunings erst bei weitaus größeren, hartnäckigen Angriffen. Ich gehe einfach davon aus dass dein Server zu schwach ist. Würde im Zweifel auf einen Dedicated Server, bestenfalls inkl. DDoS Protection und CloudFlare setzen. Bei Shared Hostings und VPS gehts oft zulasten der Ressourcen. Wenn du einen entschlossenen Gegner hast, wird er dich aber auch dann nicht ruhen lassen. In solchen DoS Fällen kann ich dir grundsätzlich nur zu Website Firewalls raten, Sucuri soll da sehr gut sein und schont auch den Server :p. https://sucuri.net/website-firewall/signup

    Zitat von ThomiMe

    Ist korrekt konfiguriert, blockt ja auch fleißig fehlgeschlagene SSH-Logins oder fehlgeschlagene .htaccess Apache-Logins. Über 100 IPs geblockt. ;)

    Das Angriffsmuster ist immer unterschiedlich. Meist gehen die auf die Startseite "/" oder Unterseiten, wie Archive "/2018/10" oder holen sich Bilder/PDFs vom Server. Obwohl die Seite gut gecached ist, hat der Server hier irgendwie keine Chance nachzukommen. Liegt wohl an Wordpress ... :/

    Hab zwar das hier (https://www.garron.me/en/go2linux/fa…dos-attack.html) gefunden, scheint aber nicht das Gelbe vom Ei zu sein. Erwähnt er ja selbst: "Consider that you will have one GET for each css, js, html, ico and other files that are part of your webpage, so if you have 20 components, some client needs only to load 15 pages in 5 minutes to get blocked. Be sure to adjust those values to fit your needs."

    Wenn ich mehrere GET-Requests pro Aufruf eines normalen Besuchers logischerweise habe, wird auch der dann unabsichtlich geblockt. Mhmm ... :/

    Werden die Anfragen großflächig mit HTTP 200 beantwortet?

    Läuft auf deiner Webseite irgendein Dienst, der im Hintergrund XHR an deinen Server schickt? Wenn nein könnte man sich ja mal Gedanken um ein Limit der Anfragen machen.

    PS: schalte mal das Cloudflare CDN dazwischen und konfiguriere es ordentlich. Vielleicht hilft dir das auch schon weiter im Bezug auf den Traffic. Cloudflare hat im übrigen auch gute heuristische Mittel um Angriffe zu erkennen und Kapazität diese abzuwehren.

    Zitat von Airport

    Wenn deine Seite schon bei 10 Clients sofort down geht, hält deine Kiste nicht viel aus. Oder ist ungeschickt konfiguriert. Beobachte doch mal den Ressourcenverbrauch zum Zeitpunkt des Angriffs und im „Normalzustand“ - stoßen RAM, CPU & Co. dann irgendwo an ihre Grenzen?

    Komischerweise stößt nichts an seine Grenzen. Im Dedi-Server steckt ein Intel Xeon E3-1246V3, gemeinsam mit 32 GB RAM + 200 GB SSD.

    Zitat von Airport

    Ich weiß nicht ob du CloudFlare verwendest, jedenfalls hast du es nicht erwähnt. Falls nicht, kann ichs dir ans Herz legen, CloudFlare zu verwenden, als zusätzliche Absicherung. Sollte sehr effektiv sein bzw könnte das Problem sogar lösen, wenn du den Traffic darüber leitest.

    CloudFlare ist aktiv, bringt in der Free-Version bei mir aber überhaupt nichts. Wirklich nichts. Die leiten das trotzdem weiter, da die User-Agents und alle sonstigen Werte bei jedem Angriff okay sind.

    Zitat von Airport

    Ausgehend von deiner Beschreibung wird es sich wahrscheinlich um einen Layer 7 Angriff handeln, obwohl Wordpress normalerweise nicht auffallend anfällig für so Attacken ist, solange man eben keine Schwachstellen hat. Eventuell hast du Apache oder PHP nicht ordentlich eingestellt. Werf einen Blick auf die Apache, nginx und PHP Einstellungen - insbesondere die, bei denen Connection Timeouts, Max Execution Times, Max RAM Usage oder Input Limits gesetzt werden. Check ob irgendeine Seite deiner Website besonders aufwändige Scripts ausführt. Lass POST Anfragen ohne Captcha gar nicht erst zu, limitiere die Max Request Length, reduziere die Connection Keep Alive / Timeout, setze Max Connections runter und so weiter.

    Memory Limit: 256M, Max Execution/Input Time: 60, Post/Upload Max Size: 50M
    Aufwende Scripts gibt es nicht, ist alles komprimiert und auf Geschwindigkeit angepasst. Ohne Angriffe lädt sie Seite ja auch ziemlich schnell

    Zitat von PixelFriend

    Werden die Anfragen großflächig mit HTTP 200 beantwortet?

    So ziemlich, ja.

    Zitat von PixelFriend

    Läuft auf deiner Webseite irgendein Dienst, der im Hintergrund XHR an deinen Server schickt? Wenn nein könnte man sich ja mal Gedanken um ein Limit der Anfragen machen.

    Ist kein so ein Dienst vorhanden oder läuft.

    Zitat von PixelFriend

    PS: schalte mal das Cloudflare CDN dazwischen und konfiguriere es ordentlich. Vielleicht hilft dir das auch schon weiter im Bezug auf den Traffic. Cloudflare hat im übrigen auch gute heuristische Mittel um Angriffe zu erkennen und Kapazität diese abzuwehren.

    Hab die Security und Performance-Tools ziemlich gepimpt, aber irgendwie tut sich nichts, da die alle Clients ohne Probleme auf die Seite durchleiten. Aber der Server sollte das doch generell selbst auch aushalten :/

    Einmal editiert, zuletzt von ThomiMe (19. Oktober 2018 um 17:40)

    Zitat von ThomiMe

    Memory Limit: 256M

    Holy Moly... Schraub das hoch!!!1!elf!eins!!!eins

    Zitat von ThomiMe

    Im Dedi-Server steckt ein Intel Xeon E3-1246V3, gemeinsam mit 16 GB RAM + 200 GB SSD.

    ein Dedi mit 16GB RAM? Ich glaube du hast das Angebot missverstanden oder wurdest über den Tisch gehauen!


    Zitat von ThomiMe

    CloudFlare ist aktiv, bringt in der Free-Version bei mir aber überhaupt nichts. Wirklich nichts. Die leiten das trotzdem weiter, da die User-Agents und alle sonstigen Werte bei jedem Angriff okay sind.

    Du kannst den "I'm under attack" Modus aktivieren um vor möchtegern Hackern etwas Abstand zu nehmen bis weitere Problemlösungungen vorliegen.

    Zitat von ThomiMe

    Ist kein so ein Dienst vorhanden oder läuft.

    Na dann könnte man ja mal die legitime Durchschnittsbelastung pro Besucher ermitteln und fail2ban entsprechend anpassen.

    Zitat von PixelFriend

    Holy Moly... Schraub das hoch!!!1!elf!eins!!!eins

    ein Dedi mit 16GB RAM? Ich glaube du hast das Angebot missverstanden oder wurdest über den Tisch gehauen!


    Du kannst den "I'm under attack" Modus aktivieren um vor möchtegern Hackern etwas Abstand zu nehmen bis weitere Problemlösungungen vorliegen.

    Na dann könnte man ja mal die legitime Durchschnittsbelastung pro Besucher ermitteln und fail2ban entsprechend anpassen.

    Ist auf 512M, besser, oder?

    Sorry, Schreibfehler meinerseits. 32GB RAM, natürlich. Der Server ist virtualisiert und der Webserver liegt in einer VM mit 16GB RAM.
    Würdest du bei fail2ban einfach die Requests limitieren, wie bei dem Link oben? Oder wie würdest du bei der Konfiguration da vorgehen, die Kiddys haben ja kein spezielles Angriffsmuster.

    Ein Scherz, dass das ein herkömmlicher Plesk-Webserver ohne fail2ban nicht mal einigermaßen packt ... wollte schon umsteigen, die brauchen aber unbedingt die Plesk-Verwaltung (wollen auf nichts anderes wechseln)

    OK, kurzes Update hier: Gerade wieder ein Angriff da gewesen und in htop mal mitgeschaut. Die CPU ist tatsächlich auf den insgesamt 4 Cores für die VM komplett auf 100%.

    Eine Attacke sah gerade eben so aus:

    NRdTY.png

    Was kann da los sein, dass die CPU derart eskaliert?

    Einmal editiert, zuletzt von ThomiMe (19. Oktober 2018 um 18:06)

    Zitat von Bruno

    https://serverfault.com/questions/3891…-1-0-with-nginx

    Sollte dein CPU-Problem minimieren.

    Alle Requests blockieren ist aber auch keine Lösung ..

    Zitat von Airport

    Die Datei, die aufgerufen wird (xmlrpc.php), ist bekannter Maßen anfällig für Brute Force und DoS Attacken.

    Habe sie damals bei mir einfach gelöscht. Gibt aber auch Plugins "Disable Xmlrpc" oder ähnlich.

    https://www.kuketz-blog.de/wordpress-angr…hp-unterbinden/

    https://www.hostinger.com/tutorials/xmlrpc-wordpress#gref

    Ist nicht nur xmlrcp, sondern auch oft Anfragen wie alles von der Wordpress-Suche abfragen: ?s=* oder wp-admin-ajax.php

    Ich hab die obere Datei jetzt mal mittels fail2ban feinjustiert, löst mir aber nicht das Problem der anderen Pages/generell aller Seiten ...

    Zitat von Azey

    Du hast doch CloudFlare, mein Gott lass den Mist der da Angefragt wird einfach großflächig Cachen - oder lösch die Datei wie Airport bereits schrieb ?!

    Das ist wieder keine gute Option, wenn jemand einen neuen Kommentar schreibt wird das Zeugs dann wieder nicht angezeigt oder wenn ein neuer Artikel erscheint dieser auch nicht, etc. ...

    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

    Zitat von ThomiMe

    Ist auf 512M, besser, oder?

    Sorry, Schreibfehler meinerseits. 32GB RAM, natürlich. Der Server ist virtualisiert und der Webserver liegt in einer VM mit 16GB RAM.
    Würdest du bei fail2ban einfach die Requests limitieren, wie bei dem Link oben? Oder wie würdest du bei der Konfiguration da vorgehen, die Kiddys haben ja kein spezielles Angriffsmuster.

    Ein Scherz, dass das ein herkömmlicher Plesk-Webserver ohne fail2ban nicht mal einigermaßen packt ... wollte schon umsteigen, die brauchen aber unbedingt die Plesk-Verwaltung (wollen auf nichts anderes wechseln)

    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.

    ------------------------------------------------------------------

    Zitat von ThomiMe

    OK, kurzes Update hier: Gerade wieder ein Angriff da gewesen und in htop mal mitgeschaut. Die CPU ist tatsächlich auf den insgesamt 4 Cores für die VM komplett auf 100%.

    Eine Attacke sah gerade eben so aus:

    NRdTY.png

    Was kann da los sein, dass die CPU derart eskaliert?

    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.

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

    ------------------------------------------------------------------

    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.

    Zitat von Bruno

    Ich glaube es gibt da draußen keinen normalen User der mit der HTTP Version 1.0 unterwegs ist. Die wurde doch so um 1996 abgelöst.

    1996 wurde HTTP 1.0 nicht abgelöst, 1996 wurde die RFC Richtlinie 1945 offiziell freigegeben, sprich es war kein Entwurf mehr. Ich verstehe dennoch nicht was du mit deiner Antwort überhaupt sagen willst.. Das Problem ist genauso relevant unter HTTP 1.1 und ganz besonders bei HTTP 2. Bei letzteren sehe ich im Vergleich zu den Vorgängern deutlich größere Bedenken. Hoffentlich wird HTTP 2 irgendwann wieder zurückgezogen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden