Daher vermute ich, dass mein Server möglicherweise Opfer eines Denial-of-Service-Angriffs ist.
Wir wurden von Pingdom (Website-Überwachung) benachrichtigt, dass unsere Website ab etwa 3 Uhr morgens nicht verfügbar war. Heute früh begannen wir, die Apache-Fehlerprotokolle zu überprüfen und sahen eine ganze Reihe dieser Fehler:
AH00485: Anzeigetafel ist voll, nicht bei MaxRequestWorkers
Wir haben auch festgestellt, dass unser PHP-FPM-Prozesspool häufig weitere Server starten musste:
[pool www] scheint ausgelastet zu sein (Sie müssen möglicherweise pm.start_servers oder pm.min/max_spare_servers erhöhen) und erzeugt 8 Kinder
Wir haben versucht, MaxRequestWorkers in der Apache-Konfiguration zu erhöhen und einige andere Abhilfemaßnahmen, aber diese haben uns nicht von dem Scoreboard-Fehler im Apache-Fehlerprotokoll befreit, also bin ich gegen mein besseres Wissen dem Rat in gefolgt.dieser Threadund setzenMinSpareThreadsUndMaxSpareThreadsgleichMaxRequestWorkers. Diese Änderungen scheinen den Anzeigetafelfehler behoben zu haben.
Ich habe auch MaxRequestWorkers stark erhöht, da wir viel RAM haben, der offensichtlich nicht genutzt wird. Unser Server hat 8 Kerne und scheint trotz dieser wirklich hohen Konfigurationswerte seinen RAM kaum zu nutzen:
$ free -h
total used free shared buff/cache available
Mem: 7.8G 1.8G 2.0G 38M 4.0G 5.8G
Swap: 0B 0B 0B
Ich bin ziemlich nervös wegen dieser hohen Werte für MaxRequestWorkers in der Apache-Konfiguration und pm.max_children in der PHP-FPM-Konfiguration.
Hier ist die grundlegende Konfiguration in mpm_event.conf
<IfModule mpm_event_module>
StartServers 2
MinSpareThreads 800
MaxSpareThreads 800
ThreadLimit 64
ThreadsPerChild 25
ServerLimit 800
MaxRequestWorkers 800
MaxConnectionsPerChild 0
</IfModule>
Hier sind einige Einstellungen in einer php-fpm-Konfigurationsdatei:
pm.max_children = 256
pm.start_servers = 64
pm.min_spare_servers = 64
pm.max_spare_servers = 128
Hier sind einige grundlegende Serverinformationen:
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2019-10-08T13:31:25
Server's Module Magic Number: 20120211:52
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
Und hier sind einige Daten aus der Apache-Serverstatusausgabe:
Server Version: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g
Server MPM: event
Server Built: 2019-10-08T13:31:25
Current Time: Friday, 10-Jan-2020 22:58:55 CST
Restart Time: Friday, 10-Jan-2020 22:26:32 CST
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 32 minutes 22 seconds
Server load: 4.69 5.06 5.12
Total accesses: 78434 - Total Traffic: 1.5 GB
CPU Usage: u2970.53 s5037.34 cu0 cs0 - 412% CPU load
40.4 requests/sec - 0.8 MB/second - 19.7 kB/request
797 requests currently being processed, 3 idle workers
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
6124 28 yes 25 0 0 0 3
6125 27 yes 25 0 0 0 2
6182 30 yes 25 0 0 1 4
6210 28 yes 25 0 0 0 3
6211 29 yes 25 0 0 0 5
6266 28 yes 25 0 0 2 1
6267 25 yes 25 0 0 0 1
6269 28 no 24 1 0 1 3
6276 28 yes 25 0 0 0 3
6378 28 yes 25 0 0 0 3
6379 31 no 24 1 0 4 3
6380 27 yes 25 0 0 0 3
6384 26 yes 25 0 0 0 2
6397 28 yes 25 0 0 2 1
6405 27 yes 25 0 0 0 2
6414 26 yes 25 0 0 1 0
6423 27 no 24 1 0 1 1
6602 27 yes 25 0 0 0 3
6603 28 yes 25 0 0 0 4
6604 26 yes 25 0 0 0 1
6617 30 yes 25 0 0 0 5
6646 26 yes 25 0 0 0 2
6676 27 yes 25 0 0 0 2
6694 30 yes 25 0 0 0 5
6705 28 yes 25 0 0 0 3
6730 29 yes 25 0 0 0 4
6765 29 yes 25 0 0 0 4
6781 27 yes 25 0 0 0 2
6805 28 yes 25 0 0 0 4
6836 28 yes 25 0 0 0 3
6858 27 yes 25 0 0 0 3
6859 27 no 25 0 0 1 1
Sum 888 797 3 0 13 86
Der Teil mit dem Arbeitsmodus ist am beunruhigendsten. Fast jeder einzelne befindet sich im Lesemodus:
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
Und zum Schluss noch das:
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 2176
subcaches: 32, indexes per subcache: 88
time left on oldest entries' objects: avg: 220 seconds, (range: 197...243)
index usage: 77%, cache usage: 99%
total entries stored since starting: 60122
total entries replaced since starting: 0
total entries expired since starting: 0
total (pre-expiry) entries scrolled out of the cache: 57946
total retrieves since starting: 3405 hit, 59594 miss
total removes since starting: 0 hit, 0 miss
Und netstat zeigt über 3000 Verbindungen zu Port 80 und Port 443:
$ netstat -n | egrep ":80|443" | wc -l
3715
Was zum Teufel ist hier los? Der Server läuft seit Monaten einwandfrei mitdeutlich bescheidenere Konfigurationseinstellungen.Gestern Nacht gegen 3 Uhr morgens scheint sich etwas schlagartig geändert zu haben.
Für jede Anleitung wäre ich sehr dankbar. Ich habe zuerst hier gesucht und gefundendieser andere Threadaber es ist eine andere Version von Apache, die im Prefork-Modus läuft, statt im Event-Modus wie bei mir. Ich verstehe auch nicht, wie die wenigen Informationen in diesem Thread zu einer SlowLoris-Diagnose geführt haben.
EDIT: Es scheint, ich muss meine Fragen präziser formulieren:
1) Wie kann ich die Reaktionsfähigkeit meines Servers wiederherstellen? Offensichtlich stecken die Apache-Arbeiter fest inRModus ist ein Symptom eines Problems.
2) Gibt es eine zuverlässige Reihe von Schritten, mit denen ich das eigentliche Problem genauer identifizieren kann?
3) Gibt es eine Möglichkeit zu bestätigen, dass der Computer einem DoS-Angriff ausgesetzt ist?
Antwort1
Das bloße Zählen der Anzahl der Verbindungen auf der Anzeigetafel ist kein ausreichender Beweis dafür, dass Kunden unhöflich sind und ihre Verbindungen nicht weiterverfolgen. Das ist ein drastischer Anstieg, also ist entweder die Web-App sehr beliebt geworden oder jemand stellt dumme Anfragen.
Sehen Sie sich die Rate der pro Sekunde abgeschlossenen Anfragen an. Bei so vielen Mitarbeitern sollte sie ziemlich hoch sein, vorausgesetzt, Ihre Webanwendung funktioniert ausreichend. Überprüfen Sie alle Aspekte der Webserverleistung, einschließlich der für Benutzer verfügbaren Bandbreite, der Serverlast und der Leistung zugehöriger Komponenten wie Datenbanken. Beheben Sie alle Leistungsprobleme aufgrund unzureichender Ressourcen.
Analysieren Sie die Verteilung der mit den Web-Ports verbundenen IP-Adressen. Eine IP, die alle Hunderte von Verbindungen herstellt, ist ungewöhnlich, obwohl IPv4-NATs dies erschweren. Ermitteln Sie die ISPs der Quelladressen. Überprüfen Sie die Sicherheitsreputationsbewertungen der IP-Adressen und ob es sich um ein riesiges NAT handeln könnte.
Führen Sie eine Paketerfassung eingehender Anfragen durch, während Sie weiterhin Ihre Überwachung durchführen. Sie sollten zumindest einige HTTP-Anfragen von Clients sehen, die sich gut verhalten. Wenn Clients sich einfach verbinden und dort warten, sieht das ein bisschen nach einer Ressourcenerschöpfung im SlowLoris-Stil aus.
Beachten Sie die Optimierungsempfehlungen in der verlinkten Antwort. Unter Linux net.ipv4.tcp_fin_timeout = 10können Sie versuchen, die Timeouts mit sysctl oder Ähnlichem etwas zu reduzieren.
Erwägen Sie, diesen Webserver hinter einem sicherheitsorientierten und lastausgleichenden Proxy zu platzieren. Mithilfe von Web Application Firewall-Funktionen können Sie Anfragen clever filtern. Durch horizontale Skalierung können Sie möglicherweise mehr Anfragen verarbeiten.
Antwort2
Gibt es eine Möglichkeit zu bestätigen, dass der Computer einem DoS-Angriff ausgesetzt ist?
DOSist Denial-of-Service.
Attackeist eine feindselige Handlung, die mit der Absicht durchgeführt wird, Schaden zuzufügen.
(Passive Aggressionist ein Oxymoron, das von Leuten benutzt wird, die nicht verstehen, dasspassivbedeutet Abwesenheit einer Handlung – Untätigkeit, per Definition, undAggression(per Definition auch) bedeutet feindliche Handlung. Aber das ist natürlich eine andere Geschichte.)
Zwischen diesen beiden gibt es eine Lücke, in der es sich zwar um DoS handelt, aber nicht um einen Angriff im Sinne einer feindlichen Handlung. Nehmen wir an, F5 bleibt auf der Tastatur eines Benutzers hängen, kann DoS verursachen, sofern keine Gegenmaßnahmen ergriffen werden, aber es ist kein Angriff im Sinne einer feindlichen Handlung, die mit der Absicht ausgeführt wird, Schaden anzurichten. Andererseits ist es ein Angriff, wenn der Benutzer weiß, dass dies zu DoS führen würde, und die Taste absichtlich gedrückt hält.
Um Ihre Frage zu beantworten: Es ist offensichtlich unmöglich, dies mit Sicherheit zu sagen, es sei denn, Sie können nachweisen, dass eine Absicht vorliegt. Ob es sich um einen DoS handelt, lässt sich erkennen, wenn die Dienstunterbrechung aufgrund fehlender Ressourcen – Überlastung – auftritt.