Was hinter dem Umzug steckt
Teil 2: Für die technisch Interessierten
Der erste Teil war die Kurzfassung. Hier die längere – für alle, die es genauer wissen wollen, und als Erfahrungsbericht für andere Vereine, denen Ähnliches passieren könnte.
Der Angriff
Ausgangspunkt war eine Sicherheitslücke in einer weit verbreiteten Editor-Erweiterung für Joomla. Die Lücke erlaubte das Hochladen von Dateien, die eigentlich nicht hätten hochgeladen werden dürfen – darunter ausführbaren Code. Über diesen Weg gelangten die Angreifer auf den Webspace.
Die Lücke war zu diesem Zeitpunkt bekannt und behoben. Unsere Installation lief auf einem älteren Stand. Das ist die ganze Geschichte, und sie ist so banal wie die meisten dieser Geschichten.
Was die Angreifer taten, war typisch für automatisierte Kampagnen: keine gezielte Spionage, kein Interesse an unseren Daten. Sie bauten Weiterleitungen ein, die Besucher – vor allem solche, die über Suchmaschinen kamen – auf fremde Seiten schickten. Dazu manipulierten sie die Seiten so, dass Suchmaschinen sie als Sprungbrett für fremde Inhalte werteten. Und sie hinterließen mehrere Hintertüren, um auch nach einer oberflächlichen Reinigung wieder hereinzukommen.
Die Lehre, die uns am meisten gekostet hat: Auf einem gemeinsamen Webspace sind Installationen keine getrennten Systeme. Was in einer Installation kompromittiert wird, kann die Nachbarn erreichen.
Warum Neubau statt Reinigung
Die Werkzeuge zum Aufspüren von Schadcode sind gut, aber sie sind nie vollständig. Ein Angreifer, der Root-nahe Rechte hatte, kann Dateien mit gültigen Zeitstempeln versehen, Code in Datenbankfelder einbetten, geplante Aufgaben anlegen. Nach jeder Reinigung bleibt eine Restfrage: Habe ich alles gefunden?
Diese Frage wollten wir nicht mit uns herumtragen. Also:
- Neuer Server bei einem anderen Anbieter, frisch aufgesetzt
- Frische Installationen statt migrierter Verzeichnisse
- Neue Datenbanken, in die nur geprüfte Inhalte übernommen wurden
- Sämtliche Zugangsdaten neu – Datenbanken, Mail, Administration, alles
Die Inhalte kamen aus Sicherungen, die vor dem Vorfall entstanden. Bilder und PDF-Dateien wurden übernommen, ausführbare Dateien nicht.
Die neue Architektur
Der Bezirk läuft jetzt auf einem eigenen virtuellen Server. Das ist mehr Arbeit als ein Baukasten-Hosting, aber es bringt drei Dinge, die uns wichtig waren:
Trennung. Jede Website läuft in einem eigenen Container – ein abgeschottetes Paket aus Anwendung und Datenbank. Was in einem Container passiert, bleibt dort. Die Nachbarn merken nichts davon. Genau das, was auf dem alten Webspace nicht der Fall war.
Kontrolle. Ein vorgeschalteter Dienst nimmt alle Anfragen entgegen, verschlüsselt sie und reicht sie an den richtigen Container weiter. Die Verschlüsselungszertifikate werden automatisch beschafft und erneuert. Kein vergessenes Zertifikat mehr, das an einem Sonntagmorgen abläuft.
Nachvollziehbarkeit. Die gesamte Konfiguration liegt in Textdateien, die versioniert sind. Wer wissen will, wann sich was geändert hat, kann nachschauen.
Die zentrale Anmeldung
Der auffälligste Unterschied für Nutzer ist die neue Anmeldung. Dahinter steht ein eigener Dienst, der ausschließlich für Identitäten zuständig ist. Die Websites selbst speichern keine Passwörter mehr.
Das klingt nach mehr Komplexität, und das ist es auch. Der Gewinn:
- Ein Ort für Passwörter. Wenn eine Website kompromittiert wird, sind die Zugangsdaten nicht mit dabei.
- Verifizierte Adressen. Ein Konto entsteht erst, wenn die E-Mail-Adresse bestätigt wurde. Keine Karteileichen, keine Fantasieadressen.
- Zentrale Rechtevergabe. Wer auf welche Bereiche zugreifen darf, wird an einer Stelle entschieden, nicht in drei Benutzerverwaltungen.
Für den geplanten geschützten Archivbereich – historische Ergebnisse, Chroniken – ist das die Voraussetzung. Solche Daten gehören nicht offen ins Netz.
Backups: der Teil, über den niemand spricht
Ein Backup, das nie zurückgespielt wurde, ist keine Sicherung. Es ist eine Behauptung.
Diesen Satz habe ich in dieser Woche schmerzhaft gelernt. Deshalb läuft die Sicherung jetzt so:
- Täglich automatisch, nachts, ohne dass jemand daran denken muss
- Geprüft: Jede Sicherung wird nach dem Schreiben auf Vollständigkeit kontrolliert. Schlägt die Prüfung fehl, wird die Sicherung nicht als gültig markiert – und die vorherigen bleiben unangetastet.
- Getestet: Wir haben tatsächlich eine Sicherung zurückgespielt, in eine isolierte Umgebung, und geprüft, ob dabei ein funktionierendes System herauskommt. Es kam eines heraus. Jetzt wissen wir es, statt es zu hoffen.
Was noch fehlt: eine Kopie an einem anderen Ort. Sicherungen auf demselben Server schützen vor Fehlern, nicht vor dessen Verlust. Daran arbeiten wir.
Was ich anders machen würde
Zur Ehrlichkeit gehört, die eigenen Fehler zu benennen:
Updates zu spät. Die ausgenutzte Lücke war bekannt und behoben. Wir waren zu langsam. Eine Vereinswebsite braucht keine tägliche Pflege, aber sie braucht jemanden, der die Sicherheitsmeldungen liest.
Zu viel auf einem Haufen. Mehrere Installationen auf einem Webspace waren bequem und billig. Der Preis wurde später fällig.
Kein Notfallplan. Als es passierte, gab es keine Antwort auf die Frage, wer was tut. Die gibt es jetzt – schriftlich.
Zu viel Wissen bei einer Person. Auch das ändert sich gerade. Die gesamte Anlage ist dokumentiert, so dass ein Nachfolger sie übernehmen kann, ohne bei null anzufangen.
Für andere Vereine
Falls ihr das lest, weil euch Ähnliches passiert ist oder ihr es vermeiden wollt:
- Updates einspielen. Nicht irgendwann. Zeitnah. Die meisten Angriffe nutzen Lücken, für die es seit Monaten eine Lösung gibt.
- Installationen trennen. Wenn möglich, nicht mehrere Websites auf einem Webspace.
- Backups testen. Einmal. Wirklich zurückspielen. Sonst wisst ihr nicht, was ihr habt.
- Bei einem Vorfall: neu bauen. Reinigen ist verlockend und selten ausreichend.
- Dokumentieren. Nicht für euch. Für den, der nach euch kommt.
Rückmeldungen erwünscht
Wenn ihr Fragen habt, Fehler entdeckt oder Vorschläge – schreibt mir. Und wenn jemand unter euch beruflich mit diesen Themen zu tun hat und einen kritischen Blick auf das Ergebnis werfen möchte: Ich freue mich darauf. Man wird betriebsblind.