Überwachung scheitert selten daran, dass zu wenig gemessen wird. Sie scheitert an zwei anderen Stellen: Es wird zu viel gemeldet, sodass niemand mehr hinsieht, oder der Weg, auf dem die Meldung reisen soll, hängt an genau dem System, das ausgefallen ist.
Ein Alarmweg schließt keine Lücke, aber er entscheidet über die Zeit bis zur Reaktion und diese Zeit bestimmt die Kosten eines Vorfalls. Der Aufbau ist an einem Nachmittag erledigt; der Teil, den fast alle auslassen, ist die Probe.
Was einen Alarm verdient#
Kurz und unbequem: Alles, was keine Handlung auslöst, ist kein Alarm, sondern eine Notiz.
| Ereignis | Alarm? |
|---|---|
| Dienst antwortet nicht mehr | ja, sofort |
| Anmeldung als root oder neue SSH-Schlüsseldatei | ja, sofort |
| Platte über 90 % | ja, mit Vorlauf |
| Zertifikat läuft in unter 10 Tagen ab | ja |
| Ausgehende Verbindung auf gesperrten Port | ja |
| Sicherung ist ausgeblieben | ja |
| Sicherung war erfolgreich | nein, Notiz |
| CPU-Spitze für zwei Minuten | nein |
Die vorletzte Zeile ist die wichtigste dieser Tabelle: Erfolgsmeldungen erzeugen Gewöhnung. Wer täglich drei „alles in Ordnung“-Nachrichten bekommt, überliest die vierte, in der etwas anderes steht.
Der Weg muss unabhängig sein#
Ein Alarm, der über den Mailserver auf derselben Maschine läuft, ist bei deren Ausfall genau nicht vorhanden. Drei Regeln:
- Absender außerhalb der überwachten Umgebung, ein Dienst bei einem anderen Anbieter, ein zweiter kleiner Server, ein externer Versanddienst.
- Zwei Kanäle für kritische Alarme, wovon einer nicht E-Mail ist (Nachrichtendienst, SMS, Anruf).
- Kein Alarm, der von DNS derselben Domain abhängt.
Der unangenehmste Zustand in der Überwachung ist Stille, die wie Ruhe aussieht. Ein abgestürzter Melder, ein abgelaufenes Zugangstoken, ein geänderter Kanal und ab da meldet niemand mehr etwas, ohne dass irgendwo etwas rot wird. Dagegen hilft nur die Umkehrung: Der Melder meldet sich regelmäßig, und das Ausbleiben dieser Meldung ist der Alarm.
Dead-Man-Switch, minimal#
Der Server meldet sich in einem festen Takt bei einem externen Dienst. Kommt der Ruf nicht, alarmiert dieser.
# Sicherungslauf meldet Erfolg — Ausbleiben ist der Alarm
0 3 * * * /usr/local/sbin/sicherung.sh && curl -fsS -m 10 https://ueberwachung.example/ping/abc123 >/dev/nullWichtig ist das &&: Der Ruf wird nur abgesetzt, wenn der Lauf erfolgreich war. Ein Ping, der unabhängig vom Ergebnis erfolgt, meldet die Existenz des Cronjobs, nicht die der Sicherung.
Ereignisse aus den Protokollen heraus#
Wo die Protokolle bereits zentral liegen (Protokolle, die den Angreifer überleben), entstehen Alarme dort, auf dem Empfänger, nicht auf der Quelle. Eine minimale Variante ohne zusätzliche Software:
# /etc/systemd/system/ssh-root-alarm.service
[Unit]
Description=Meldung bei root-Anmeldung
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'journalctl -u ssh --since "-5min" | grep -q "Accepted .* for root" && \
curl -fsS -m 10 -d "root-Anmeldung auf $(hostname -s)" https://alarm.example/hook'# alle fünf Minuten
sudo systemctl enable --now ssh-root-alarm.timerDie Probe gehört in den Kalender#
Ein Alarmweg, der ein halbes Jahr nicht ausgelöst hat, ist ein Alarmweg mit unbekanntem Zustand. Vierteljährlich:
- Testalarm auslösen und auf dem Zielgerät bestätigen, dass er ankam.
- Prüfen, ob der Empfängerkreis noch stimmt (ausgeschiedene Personen, alte Nummern).
- Einen Melder absichtlich abschalten und prüfen, ob das auffällt.
Schritt 3 ist der, der die unangenehmen Überraschungen findet und die Frage beantwortet, ob die Überwachung wirklich überwacht wird.
Anschluss#
Was in diesen Alarmen inhaltlich stehen sollte, folgt den Signalen aus Einen Einbruch erkennen. Was danach passiert, steht in Die erste Stunde und die Prüfung, ob nach außen alles noch so aussieht wie geplant, in Angriffsfläche von außen messen.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
