Blog-Störung…
Mmmmh.
Einige Leser hatten mich gerade informiert, dass das Blog hängt, ein 504 Gateway Time-out kommt.
Ich habe es nicht gleich mitbekommen und auch nicht gleich alle Mails verstanden. Wenn mir Leute schreiben, dass sie mein Blog vermissen oder nicht mehr draufkommen, ist das zwar nett und ich bedanke mich dafür, aber nicht sehr offensichtlich, was das Problem ist.
Ich kann jetzt nicht genau sagen, was das Problem war, weil sich das wohl schon wieder gelöst hatte, als ich nachgesehen habe, und ich aufgrund der ungünstigen Uhrzeit gerade mitten in der Hauptverkehrszeit aktualisiert habe (normalerweise mache ich sowas nachts um zwei oder drei). Laut Logs lief der Webserver (nginx) völlig normal, konnte aber keine Verbindung zum php-Interpreter aufbauen, weil der intern einen Hänger hatte. Warum das so war, habe ich jetzt zumindest auf Anhieb nicht gesehen, und auch keine Log-Eintrag entdeckt, der es unmittelbar erklären würde.
Angriffsversuche gibt es viele, jede Menge. Welche, die versuchen, SQL-Dumps runterzuladen. Welche, die versuchen, PHP- oder Zugriffsrechteprobleme auszunutzen. Viel, aber nicht ungewöhnlich, daily business. Auch eher automatisiert, denn in der SQL-Datenbank zum Blog steht – außer ein paar unveröffentlichten Entwurfstexten und drei gesperrten Artikeln – auch nichts, was man nicht sowieso als Blogartikel abrufen könnte. Es gibt in dieser Datenbank keine Geheimnisse, die diesen Namen verdienen. Die ist ja zur Veröffentlichung gedacht. Und sonst ist auf der Maschine auch nichts installiert.
Das Blog abschießen könnte man sicherlich, ich würde nicht drauf wetten, dass WordPress und PHP wasserdicht sind. Da ich die Maschine aber automatisch installiere und Backups der Daten mache, würde es vermutlich so etwa zwei, drei Stunden dauern, die Maschine wieder herzustellen. Oder etwas länger, weil ich dabei gleich einen Upgrade machen würde. Deshalb muss ich mir in solchen Fällen immer überlegen, ob ich das System weiterlaufen lasse oder aus Sicherheitsgründen wegschmeiße und komplett neu aufsetze.
Ich kann deshalb jetzt nicht auf Anhieb sagen, ob da jemand irgendeinen Angriff geschafft oder schlicht und einfach PHP/Wordpress irgendwie abgestürzt sind.
Ich habe zumindest theoretisch mal drüber nachgedacht, die einzelnen Module (nginx, php) als Docker-Container zu bauen und hochzuladen, was den Update und die Wiederherstellung sogar vereinfachen könnte, aber dafür andere Probleme mit sich bringt. Immerhin kann man bei Dockercontainern relativ einfach einen Health-Check anbringen, der in solchen Fällen den Prozess automatisch neu startet.
Ich hatte aber auch nicht die allerneueste WordPress-Version drauf. Manchmal schreiben mich Leser an und „erinnern“ mich daran oder werfen mir vor, dass ich nicht die neueste Version drauf habe, weil doch Bug X oder Sicherheitsloch Y gefixt sei. Das mache ich deshalb nicht immer sofort, weil ich die Selbst-Aktualisierung von WordPress nicht benutze. Dazu nämlich muss WordPress seine Software selbst überschreiben können, und das halte ich für weit, weit gefährlicher als den Vorteil durch die einfache Aktualisierung. In der Frühzeit des Blogs (müsste nachschauen, aber vor gefühlten ungefähr 10 Jahren) hatte mir nämlich genau darüber, dass WordPress in seiner Normaleinstellung seine Softwaredateien selbst (über-)schreiben kann, eine Backdoor reingehauen. Und zwar über ein Sicherheitsloch in einem Scheme, das ich nicht einmal aktiviert hatte, aber es reichte halt, wenn es im Verzeichnis rumliegt. Als Konsequenz daraus habe ich die Schreibrechte für WordPress weitgehend abgeschaltet, und damit auf Funktionen wie das Hochladen von Medien über die Webseite und automatisches Aktualisieren verzichtet. Ich mache das stattdessen mit Ansible. (Demnächst wohl eher Puppet.) Nur hat Ansible in den letzten Tagen unter Ubuntu nicht funktioniert, weil die Versionen der Bibliotheken nicht zusammen passen.
Und seit Jahren habe ich eigentlich vor, die Software durch eigene zu ersetzen. Und hätte das inzwischen auch getan, wenn ich nicht einiges an juristischen Angriffen abzuwehren gehabt hätte und mir nicht das Projekt Zypern dazwischen gekommen wäre. Ich habe die Software schon mal so zu zwei Dritteln geschrieben, dabei aber noch ein paar Sachen gelernt und neu überdacht, und bin zu etwas anderen, besseren Designentscheidungen gekommen, auch von einem anderen Softwareprojekt her, und werde die Blogsoftware mit diesem Wissen demnächst nochmal neu schreiben, um die Überlegungen und Gedanken, die mir daraus entstanden sind, neu einzubauen. Macht die Sache flexibler und leistungsfähiger. Habe ich aber für dieses Jahr vor. Mit einer der Gründe für das Projekt Zypern, dort ist nämlich Ruhe. Ein zentrales Element daran ist auf jeden Fall, das System schnell wiederherstellen zu können und natürlich die Angriffsflächen von WordPress/PHP zu eliminieren.
Aber wie gesagt, ich kann jetzt spontan, auf den ersten Blick, nicht sagen, ob das ein Angriff oder einfach ein Softwarefehler war, zumal die Last auf diesem Webserver jetzt auch nicht gerade klein ist, ich habe da ja schon etwas traffic. Bis vor ein paar Jahren war ich auf einem Webserver, auf dem noch über 100 andere Domains liefen, und so um die 98% des Netzverkehrs entfiel auf mein Blog. Und eigentlich läuft’s ja auch stabil, es ist ja sehr selten, dass es zu Störungen kommt, die wirklich am Blog selbst liegen.
Es war halt die letzten Monate wirklich Arbeitsüberlauf, von allem zuviel.
Und dazu das Problem, dass viel Arbeitszeit drauf geht, bestehende Software zu debuggen und zu verstehen, was nicht so genau in der Doku steht. Das ist heute alles nicht mehr so leicht, wie es früher einmal war.