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 ...
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:
Hab bei CloudFlare unter "Caching" auch bereits "Igore Query String" angehakt, bringt nichts.
Codeuser root; worker_processes auto; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; include /etc/nginx/modules.conf.d/*.conf; events { use epoll; worker_connections (HIER DIE AUSGABE VON ulimit -n EINTRAGEN OHNE DIE KLAMMERN); multi_accept on; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log /var/log/nginx/access.log main; reset_timedout_connection on; sendfile on; send_timeout 7s; tcp_nopush on; tcp_nodelay on; client_body_timeout 7s; client_header_timeout 7s; keepalive_timeout 12s; keepalive_requests 50; gzip off; server_tokens off; include /etc/nginx/conf.d/*.conf; # plesk recommended settings proxy_send_timeout 120s; proxy_read_timeout 120s; fastcgi_send_timeout 120s; fastcgi_read_timeout 120s; } # override global parameters e.g. worker_rlimit_nofile include /etc/nginx/*global_params;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.
Alles anzeigendie 1 am besten durch auto ersetzen
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
Das erscheint mir viel zu hoch!
Ich weiß nicht auf welchen Punkt du genau heraus willst, clientseitiges, kontrolliertes caching geht aber auch ohne cloudflare.
Mit diesen Settings ist es schon sehr gut, danke! Gzip war bereits aktiv.
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.
#user nginx;
worker_processes 1;
#error_log /var/log/nginx/error.log;
#error_log /var/log/nginx/error.log notice;
#error_log /var/log/nginx/error.log info;
#pid /var/run/nginx.pid;
include /etc/nginx/modules.conf.d/*.conf;
events {
worker_connections 10000;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#tcp_nodelay on;
#gzip on;
#gzip_disable "MSIE [1-6]\.(?!.*SV1)";
server_tokens off;
include /etc/nginx/conf.d/*.conf;
# plesk recommended settings
proxy_send_timeout 1200s;
proxy_read_timeout 1200s;
fastcgi_send_timeout 1200s;
fastcgi_read_timeout 1200s;
}
# override global parameters e.g. worker_rlimit_nofile
include /etc/nginx/*global_params;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.
https://serverfault.com/questions/3891…-1-0-with-nginx
Sollte dein CPU-Problem minimieren.
Alle Requests blockieren ist aber auch keine Lösung ..
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.
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 ...
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. ...
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:
Was kann da los sein, dass die CPU derart eskaliert?
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)
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.
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.
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
Werden die Anfragen großflächig mit HTTP 200 beantwortet?
So ziemlich, ja.
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.
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
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.
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 ...
Ist aktiv, hat aber bislang noch nie zugeschlagen 
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.
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:
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!