Ausfall gottenheim.de!?

Protokollierung längerer Ausfälle unseres Webservers im komm.one-Rechenzentrum.


Logbuch der Webserver-Ausfälle

Externes Monitoring

Seit dem mehrtägigem Ausfall im Nov. 2022 wird die Verfügbarkeit extern protokolliert:

Jahr-Mo-TgAusfall-DauerInfo?
2024-08-19ca. 12:30 - 16:30 unangekündigt
2023-01-13ca. 10:00 - 11:30 unangekündigt
2023-01-05ca. 09:00 - 11:00 unangekündigt
2022-11-25ca. 16:00 - 19:00 unangekündigt

3. Nov. 2022: Malware-Angriff den auf RZ-Webserver!

9 Tage Komplettausfall!

  1. Am Donnerstag, 3. Nov. 2022 um 18:00, hat der Webmaster von gottenheim.de das aktuelle Gemeindeblatt auf den FTP-Server hochgeladen und dabei die Website aufgerufen. Nachfrage beim RZ Dabei stellte er fest, dass der Web-Server nicht mehr antwortet:
    Unsere Website wird wie viele andere kommunale Websites auf einem Webserver im Rechenzentrum (RZ) des Dienstleisters komm.one gehostet und dieser Webserver gab kein Lebenszeichen mehr von sich.
  2. Es kommt zwar hin und wieder vor, dass die Website aufgrund von Wartungsarbeiten am Server im RZ (z.T. nach Ankündigung) 1-2 Stunden offline ist, aber als sie um 19:45 noch offline war, hat der Webmaster den RZ-Ansprechpartner per Mail nach der Wiederverfügbarkeit gefragt und zusätzlich auf seit dem 2. Nov. 11:58 angelegte Verzeichnisse auf dem FTP-Server hingewiesen mit zufälligen Namen, sehr viel Unterverzeichnissen und Dateien unklarer Inhalte... Merkwürdig! Befallene Verzeichnisse
  3. Keine zehn Minuten später kam die eindeutige Antwort vom RZ:
    ... Auf dem Server wurde heute ein Malware-Befall festgestellt! Nach derzeitigem Kenntnisstand konnte kein Datenabfluss festgestellt werden. Der Server wurde umgehend vom Netz getrennt und wird derzeit analysiert. Vorübergehend wird ab Morgen stattdessen eine Wartungsseite zu sehen sein. Sofern Sie eine lokale Kopie Ihrer Webseite besitzen, bitten wir Sie darum, uns diese zukommen zu lassen. Es beschleunigt die Wiederherstellung...
  4. Rückfrage beim Rathaus ergab, dass diese Mail bereits um 18:10 beim Bauamtsleiter, für IT zuständig, eingegangen war. Der war an dem Tag in Urlaub, es hätte aber ohnehin nichts geändert: Neben fast 20 anderen Websites, die auf dem selben RZ-Server gehostet waren, war gottenheim.de erstmals Opfer eines Malwareangriffs! Der Angriff selbst ist vermutlich per cross-site Scripting o.ä. von einer der anderen kommunalen Websites ausgegangen.
  5. Im Laufe des Freitags, 4. Nov., hat das Team im RZ einen neuen Webserver aufgesetzt und mit IP-Adressen, Bibliotheken, Zertifikaten etc. konfiguriert. Ab 13:30 wurde uns parallel ein FTP-Server zum Restore unserer lokalen Dateien bereit gestellt. Lokale Daten 6.2 GB
    Glücklicherweise arbeitet der Webmaster mit aktuellen lokalen Dateien auf seinem Rechner, die nach Neuerstellung oder Änderung redundant auf den RZ-Server hochgeladen werden und dort zusätzlich gebackupt werden (3-2-1-Prinzip). Aufgrund kompakter PDFs/JPGs handelt es sich trotz 42.000 Dateien nur um 6 Gigabyte, die aber über eine DSL-50 Leitung (Upload nur 11 Mbit/sec) hochgeladen werden mussten...
  6. Gegen 16:00 waren bereits 50% aller Daten wieder hochgeladen, allerdings brach die Verbindung zum FTP-Server immer wieder mal ab. Um 18:00 waren 90% der Dateien wieder auf dem FTP-Server, aber der Webserver noch nicht fertig... Freitag Abend ca. 22:00 antwortete der Webserver erstmals wieder, alle Dateien inzwischen hochgeladen und verifiziert: Trotzdem war von gottenheim.de nur die Navigationsleiste und einige wenige Seiten zu sehen... Was ist da los!? Offensichtlich liefen die verwendeten PHP-Scripte nicht.
    Nach Rückfrage beim RZ wurde mitgeteilt, dass die neueste PHP-Version 8.1 installiert wurde. Bisher war auf dem Server eine ältere PHP-Version, die keine Probleme gemacht hatte. Hilft nichts: Updates sind wichtig um Sicherheitslücken zu schließen.
  7. Der Webmaster suchte weiter und fand nach Tests heraus, dass die oft (z.B. "Zuletzt geändert am:" in jeder Fußzeile) verwendete PHP-Standardfunktion date() in PHP 8.1 nicht funktioniert und so fast alle Seitenanzeigen abbrechen! Außerdem wird die für Schleifen verwendete PHP-Funktion each nicht mehr unterstützt. Als Zwischenlösung hat er in 50 PHP-Dateien die date-Funktion auskommentiert, so dass ab Samstag morgen 0:30 gottenheim.de zu 95% erschien.
    Mit Ausnahme von Kalender, datumsgesteuerter Hinweise und graphischer Verzeichnisübersichten; Bildersammlungen etc.
    An der Behebung (korrekte Konfiguration des PHP-Servers mit allen Modulen) wird im RZ gearbeitet. Mal sehen wie lang...
  8. Am Dienstag 8. Nov, 8:00 hat das RZ entschieden, für gottenheim.de die Öffentlichkeit durch Anmeldung auszusperren, um eine forensische Ursachenanalyse des Malware-Angriffs durch externe Spezialisten zu ermöglichen.
  9. Sperrung durch RZ Danach konnte sich auch der Webmaster nur mit Passwort gottenheim.de ansehen! (Screenshot) Immerhin war die laufende Pflege (neue Presseartikel, Bilder, Veranstaltungen) per FTP möglich. Aber die Gottenheimer hatten zunächst keinen Nutzen davon und fragten zunehmend nach, was denn los sei? Erst am Freitag 9.11. erschien der vorsorgliche Hinweis im gedruckten Gemeindeblatt.
    Anders wie im BZ-Zeitungsartikel angegeben, konnte der Webmaster für Gottenheim garantieren, dass durch die eigene, lokale Datenhaltung keinerlei Information oder gar Bilder verloren gegangen sind.
  10. Mittwoch, 9. Nov. 15:00, Update: Die Website war leider immer noch nicht allgemein zugreifbar. Hmmm...
    Donnerstag, 10. Nov. 16:00, Update: Die Website verlangte weiter eine Anmeldung (ohne Registrierungsmöglichkeit).
  11. Freitag, 11. Nov. 14:00: Nach einer Woche war gottenheim.de wieder online! Und um 21:00 zu 100% funktional.
  12. Samstag, 12. Nov. ab spät. 22:00: gottenheim.de schon wieder nicht verfügbar! Null Information seitens komm.one :-(
    Am Sonntag lief dann auch nichts...
  13. Montag, 13. Nov. Seit spät. 10:00 wieder online. Hoffentlich dauerhaft stabil! Keine Antwort vom RZ mehr...