Datenbank-Fehler nach Crash?

[blickgerecht]

Hallo zusammen,

ich bin etwas ratlos, vielleicht habt ihr eine Idee, bevor ich hier wild Backups einspiele …

Folgendes ist passiert:

Ich habe die Wordpress-Seite eines Kunden auf unseren Keyhelp-Server kopiert, die Domain des Kunden schon angelegt, allerdings noch ohne SSL, weil für die Domain noch die DNS-Einträge geändert werden sollten.

Heute um 16:43 Uhr wurden die Einträge durch den Kunden geändert (er verwaltet die Domain selbst). Ich sehe in unserem Monitoring zu dieser Zeit den Ausfall der Website.

Soweit alles korrekt. (Der Kunde hätte vorher Bescheid geben können, aber gut …)

Jetzt will ich mich kurz später ins Panel einloggen, erhalte aber direkt beim Aufruf des Panels eine MySQL-Fehlermeldung. Die Datenbank sei nicht erreichbar. Per SSH verbunden sehe ich, dass MariaDB "failed" ist. MariaDB neugstartet – Problem erst einmal gelöst.

In den Logs sehe ich:

Code: Select all

Apr 03 16:43:10 panel.domain.net systemd[1]: mariadb.service: A process of this unit has been killed by the OOM killer.
Apr 03 16:43:11 panel.domain.net systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr 03 16:43:11 panel.domain.net systemd[1]: mariadb.service: Failed with result 'oom-kill'.
Apr 03 16:43:11 panel.domain.net systemd[1]: mariadb.service: Consumed 2h 51min 26.758s CPU time.

Die Fehler kommen zur gleichen Zeit, als die Domain des Kunden die neuen Records erhalten hat. Der Zusammenhang ist mir bisher unklar …

Problem dabei: Der Neustart von MariaDB hat zwar geholfen, aber ich erhalte für alle Tabellen in allen Datenbanken folgenden Fehler:

Code: Select all

[ERROR] mariadbd: Table './datenbank/tabelle' is marked as crashed and should be repaired

Das ist nur ein Beispiel, aber einen solchen Eintrag gibt es eben für alle Tabellen von verschiedenen Benutzern, also in allen Datenbanken (bin nicht wirklich sicher, ob wirklich alle Tabellen, hab es nicht gezählt, aber es sieht erstmal so aus).


Jetzt die großen Fragen:

Was ist passiert, wieso konnte die Domain-Umstellung das auslösen?
Und vor allem: Was mache ich mit all den offenbar zerstörten Tabellen?

Beim Login in Wordpress (es sind alles Wordpress-Seiten) erhalte ich keine Fehlermeldungen, trotz der Meldungen im Log. Aber einfach so lassen möchte ich es natürlich nicht.

Habt Ihr eine Idee? Bin etwas verzweifelt gerade …


Edit:

Parallel hab' ich noch ein bisschen recherchiert. Offenbar ist es "normal", nach dem ersten Neustart von MariaDB nach einem Kill, dass alle Tabellen als "crashed" gelten. Daraufhin habe MariaDB noch einmal neugestartet, ohne Fehler. Danach habe ich noch

Code: Select all

mysqlcheck --all-databases

ausgeführt. Alle Tabellen zeigen an "OK".

Nachdem ich die Schnappatmung aufgehört habe, bliebe noch die Frage: Wie konnte das passieren? Habt ihr ein Idee dazu?

[Tobi]

"oom-kill" ist ein deutliches Zeichen, dass dem Server das RAM ausgegangen ist.

Über wieviel RAM reden wir?

[Florian]

Das Reparieren geht effizient im PHPmyAdmin. Die Tabellen markieren und dann unter der Liste mit den Tabellen Markierte -> Repariere Tabelle auswählen

[blickgerecht]

16 GB, davon sind die meisten die meiste Zeit frei.

Interessant in dem Zusammenhang: Nach dem Neustart von MariaDB scheint mehr frei zu sein, als vorher:

Bildschirmfoto 2024-04-03 um 17.56.09.jpg (10.35 KiB) Viewed 653 times

Ich hänge mich noch an dem zeitlichen Zusammenhang mit der Domain-Umstellung auf … Wie könnte da der Speicher so schnell ausgelastet gewesen sein? Die kurze Spitze wäre vermutlich nicht aufgezeichnet worden im Monitoring. Und bei allen Loadtests, die ich bisher gemacht habe, gab es nie so ein Problem.

[blickgerecht]

Das Reparieren geht effizient im PHPmyAdmin.

Meinst Du, das wäre noch nötig, nachdem der Check OK war? Offenbar geht das in PHPmyAdmin nicht für alle Datenbanken auf einmal, daher müsste ich die Datenbank einzeln anklicken und dann die Tabellen markieren und reparieren. Würde ich natürlich machen, falls das nötig ist. Bzw. schadet es?

[Tobi]

16 GB ist IMHO ausreichend.
Oder reden wir hier über eine extragroße Datenbank? So ab 10 GB aufwärts?

[blickgerecht]

Nein, gar nicht. Alle Datenbanken zusammen haben ca. 500 MB

[Ralph]

Einfach mal mit top oder htop die Auslastung im Auge behalten, so findet sich auch der User der die Resourcen verbraucht.
Könnte durch eine Attacke oder Crawler (badbots) verursacht werden oder eine veraltete Anwendung die Sicherheitslücken enthält.
Falls es noch Debian11 ist bzw. Amavis noch im Einsatz ist, kann der Crash auch im Zusammenhang mit amavis verursacht worden sein.
Ich tippe aber eher auf Crawler oder gezielte Attacken auf Anwendungen oder irgendwelche Plugins ...

[blickgerecht]

Danke für den Hinweis nochmal.
Ist Debian 12, alles aktuell.

Ich bin nochmal ein paar Logs durchgegangen, auch von Benutzern. In einigen PHP-Logs gab es auch Hinweise auf das Überschreiten der max. Prozesse zur gleichen Zeit.
Zudem gab es in Logs verschiedener Domains auf dem Server recht viele 404-Fehler, die auf Anfragen der gleichen IP (91.92.247.48) zurückzuführen sind. Die IP habe ich temporär mal in der Firewall blockiert.

Mir ist beim Durchsehen aufgefallen, dass es grundsätzlich relativ viele 404-Fehler von einigen IPs aus gibt. Das sind wohl auch DoS-Angriffe. Habe gesehen, dass es für fail2ban da auch Regeln geben kann, solche gezielten Anfragen zu sperren. Hat jemand von euch sowas schon aktiv?

Weil ich damit heute recht viel Zeit verbracht habe, verschiedene Logs und Ausgaben per journalctl durchzusehen: Gibt es da einen praktischeren Weg, als sich durch die Verzeichnisse (/opt/keyhelp/php/8.3/var/log, /var/log/apache2/error.log, etc.) und die Logs der einzelnen Domains durchzuschauen?

[blickgerecht]

So, ich füge selbst nochmal etwas hinzu. Mir hat es keine Ruhe gelassen

Fündig geworden für das Log, das es mir leichter gemacht hat, bin ich hier (hätte ich auch früher drauf kommen können):

Code: Select all

/var/log/apache2/keyhelp/other_vhosts_access.log

In der Zeit kurz vor der Domain-Umstellung und dem MySQL-Ausfall kam es zu extrem vielen Anfragen der beiden IPs 91.92.247.48 und 91.92.252.177. Hier mal ein Auszug:

Code: Select all

domain-kunde1.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "POST /wp-plain.php HTTP/1.1" 301 515 "www.google.com" "Mozilla/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
domain-kunde1.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "GET /wp-content/themes/seotheme/db.php?u HTTP/1.1" 301 561 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
domain-kunde1.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "POST /ALFA_DATA/alfacgiapi/perl.alfa HTTP/1.1" 301 551 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
domain-kunde1.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "GET / HTTP/1.1" 301 491 "-" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
domain-kunde2.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "POST /ALFA_DATA/alfacgiapi/perl.alfa HTTP/1.1" 301 561 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
domain-kunde2.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "GET /wp-content/themes/seotheme/db.php?u HTTP/1.1" 301 571 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
domain-kunde2.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "POST /wp-plain.php HTTP/1.1" 301 525 "www.google.com" "Mozilla/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
domain-kunde2.de:80 91.92.247.48 - - [03/Apr/2024:16:42:39 +0200] "GET / HTTP/1.1" 301 501 "-" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"

Willkürliche Pfade, aber alle auf Port 80, also hatte der Server schon damit zu tun, das durchzureichen, mit den typischen Weiterleitungen. Es waren viele hundert in 2-3 Minuten, Schubweise immer zig je Sekunde.
Interessant daran: Die Anfragen waren alle gleich, von beiden IPs, aber mit unterschiedlichen Ziel-Domains von unterschiedlichen Kunden. So etwas macht mich ja immer stutzig, hatten wir aber auch ohne Keyhelp schon öfter.

Was ich wohl machen könnte, wäre einen fail2ban-Filter anlegen, wie bspw.

Code: Select all

[Definition]
failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|400|301) .*$
ignoreregex =

Damit könnte dann /var/log/apache2/keyhelp/other_vhosts_access.log untersucht und entsprechende IPs gesperrt werden. Etwas Angst davor hätte ich, zu viele Leute auszusperren. Aber das könnte man ja justieren.

Die Implementierung könnte dann in etwa so aussehen:

Code: Select all

[apache-dos]
enabled  = true
port     = http,https
filter   = apache-dos
logpath  = /var/log/apache2/keyhelp/other_vhosts_access.log
bantime = 1800 
findtime = 10
maxretry = 10

Hat jmd. von euch so einen Filter im Einsatz?

Und was mir grundsätzlich nicht klar geworden ist:
Füge ich das dann an in /etc/fail2ban/jail.d/keyhelp.local?
Oder erstelle ich eine eigene (zusätliche?) local-Datei?
Denn keyhelp.local wird ja beim Update überschrieben oder verändert.

Ich würde ohnehin erst einmal abwarten, ob das häufig vorkommt. Wir haben gerade alle Kunden vom alten (nicht-Keyhelp-Server) auf den neuen Keyhelp-Server umgezogen. Das war aufregend heute

Und wie viel Zufall ist es bitte, dass auf die Minute des "Angriffs" der Domain-Umzug viel?

[Ralph]

https://www.abuseipdb.com/check/91.92.247.48

Beim 404 Filter musst du noch ein paar Ausnahmen setzen z.b.

Code: Select all

ignoreregex =.*(autodiscover|robots.txt|favicon.ico|login.svg|jpg|png|jpeg|ico|mp3|mp4|css|.well-known)

zusätzlich mal damit versuchen, muss entsprechend erweitert bzw. geändert werden auf die Fake Ziele

exploits.conf

Code: Select all

# exploits filter
[Definition]

failregex = ^<HOST> -.*(GET|POST|HEAD).*(/mbank)
            ^<HOST> -.*(GET|POST|HEAD).*(/wp-content/plugins/wp-task-scheduler/scheduler\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/wp-content/plugins/task-controller/index\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/mt-xmlrpc\.cgi)
            ^<HOST> -.*(GET|POST|HEAD).*(/mt/RxR\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/img/xmrlpc\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/css/xmrlpc\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/cgi-bin/cloud\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/gely\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/xmrlpc\.php)
            ^<HOST> -.*(GET|POST|HEAD).*(/simple\.php)

ignoreregex =

jail.local

Code: Select all

[exploits]
enabled  = true
port     = http,https
filter   = exploits
logpath = /home/users/*/logs/*/access.log
          /var/log/apache2/access.log
          /var/log/apache2/keyhelp/other_vhosts_access.log
maxretry = 1
bantime = 48h
ignorecommand = %(fail2ban_confpath)s/filter.d/ignorecommands/apache-fakegooglebot <ip>

[Ralph]

Und wie viel Zufall ist es bitte, dass auf die Minute des "Angriffs" der Domain-Umzug viel?

Die Attacken haben mit Sicherheit auch vor dem Umzug auf dem alten System stattgefunden, einem System welches automatisierte Attacken ausführt ist es egal wo die Domains auflösen oder ob ein Umzug stattfindet.
Wenn aber ein Scanner irgendwo eine veraltete Anwendung gefunden hat die sich als Angriffs-Ziel lohnt wird dieses Ziel gespeichert und immer wieder von Bots attackiert, solange bis es keine Schwachstellen mehr gibt die zu attackieren wären.
2 einzelne IPs blockieren nützt da gar nichts, das sind Botnetze von gekaperten Geräten die über einen Pool von hundert-tausenden IP Adressen verfügen.

[blickgerecht]

Vielen Dank schonmal für die Unterstützung!

Beim 404 Filter musst du noch ein paar Ausnahmen setzen z.b.

Absolut, danke! Baue ich ein.

Der Filter mit den Exploits ist auch super. Den müsste ich nur pflegen… Vermutlich lassen die sich öfter was neues einfallen. Hab's mir heute Morgen nochmal angeschaut, die 404-Fehler zu lesen und dementsprechend auszusperren, hätte recht schnell geholfen. Darauf konzentriere ich mich als erstes.

Eine Frage, die mich noch beschäfigt: Du sprichst auch von der Datei jail.local.

Es gibt ja die Datei keyhelp.local im Ordner

Code: Select all

/etc/fail2ban/jail.d

Wenn ich dort nun eine jail.local erstelle (ich nehme an, die kommt dort rein?), wird die dann zusätzlich von fail2ban herangezogen oder ersetzt diese die keyhelp.local? Muss ich die keyhelp.local löschen/umbennen bzw. sollte ich die als Ausgangspunkt nehmen?

Wie macht ihr das, auch im Sinne der Update-Sicherheit?

Die Attacken haben mit Sicherheit auch vor dem Umzug auf dem alten System stattgefunden, einem System welches automatisierte Attacken ausführt ist es egal wo die Domains auflösen oder ob ein Umzug stattfindet.

Der Vollständigkeit halber hierzu noch: Die Angriffe fanden auf vielen Domains statt, aber nicht auf der neuen. Das dachte ich ja auch erst, dass die "mit umgezogen" sind. Aber die Domain war nicht direkt der Auslöser, so wie ich nicht betroffen. Immer noch ein seltsamer Zufall trotzdem

[Ralph]

Wenn ich dort nun eine jail.local erstelle (ich nehme an, die kommt dort rein?), wird die dann zusätzlich von fail2ban herangezogen oder ersetzt diese die keyhelp.local? Muss ich die keyhelp.local löschen/umbennen bzw. sollte ich die als Ausgangspunkt nehmen?

die jail.local ist eine angepasste Kopie der jail.config da kann entweder alles rein oder die *.conf einzeln oder zusammengefasst unter jail.d

[blickgerecht]

die jail.local ist eine angepasste Kopie der jail.config da kann entweder alles rein oder die *.conf einzeln oder zusammengefasst unter jail.d

Ich hab mich gerade noch einmal versucht, da zu belesen. Auf die Schnell bin ich nicht ganz schlau geworden – oder ich stehe gerade einfach auf dem Schlauch (man verzeihe es mir ) …

Soweit ich gelesen habe, wird beim Start von fail2ban die jail.conf und auch die Dateien im Verzeichnis jail.d herangezogen. Eine jail.local, die im Verzeichnis /etc/fail2ban direkt liegen sollte (so habe ich es auf die Schnelle gelesen), wird zusätzlich herangezogen, oder? D.h. darin könnten also auch ausschließlich meine Ergänzungen stehen, also meine Regel mit dem apache-dos-Filter, richtig?

Das würde ja auch Modular Sinn ergeben und wäre vermutlich sicher für Updates …