Es gibt keinen Mangel an Sicherheitsmeldungen. Es gibt einen Mangel an Meldungen, die zum eigenen Bestand passen. Der Unterschied entscheidet, ob nach vier Wochen noch jemand hinsieht.
Das hier schließt keine Lücke und drängt nicht. Es entscheidet aber darüber, ob die Beiträge mit höherer Dringlichkeit überhaupt jemals ausgelöst werden, denn ohne Meldung gibt es kein Patchen außer der Reihe.
Zuordnung statt Vollständigkeit#
Die Reihenfolge ist umgekehrt zur Intuition: Erst die Bestandsliste, dann die Abos. Für jede Zeile im Bestand genau eine Quelle und wo es keine gibt, ein Termin.
| Was du betreibst | Wo die Meldung herkommt |
|---|---|
| Debian/Ubuntu-Basis | Sicherheitsankündigungen der Distribution (debian-security-announce, Ubuntu Security Notices) |
| Kernel und Firmware | dieselbe Quelle plus Hersteller-Bulletin bei eigener Hardware |
| Webserver, Datenbank, Proxy | Ankündigungsliste des jeweiligen Projekts |
| Anwendungen im Container | Release-Feed des Images bzw. des Projekts |
| Randgeräte, VPN, NAS | Herstellerseite; oft nur RSS oder gar nichts → Kalender |
| Lage allgemein (DE) | Warn- und Lagemeldungen des BSI |
Fünf bis acht Quellen sind für einen einzelnen Server realistisch. Wer mehr abonniert, filtert nicht mehr, er scrollt.
Wohin die Meldungen laufen sollen#
Nicht in das Postfach, in dem auch Rechnungen liegen. Zwei Wege haben sich bewährt:
- Getrenntes Postfach oder Ordner mit Filterregel, der nur Quellen mit Bezug zum Bestand durchlässt.
- In denselben Kanal wie die Alarme, wenn dieser bereits gelesen wird, Begründung und Fallstricke in Alarme, die nachts ankommen.
Was nicht funktioniert: ein Kanal, in den auch jede erfolgreiche Sicherung meldet. Das erzeugt Gewöhnung, und Gewöhnung ist der Grund, warum die eine wichtige Zeile übersehen wird.
Selbst nachsehen statt warten#
Die Distribution weiß, ob für deine installierte Version etwas offen ist. Das kann man abfragen, ohne auf eine Mail zu warten:
# Debian/Ubuntu: stehen Sicherheitsupdates an?
apt-get -s -o Debug::NoLocking=true upgrade | grep -i '^Inst.*security'
# Detailbetrachtung eines Pakets
apt-cache policy openssl
apt changelog openssl 2>/dev/null | head -20
# Ubuntu: Bewertung je CVE für den installierten Stand
pro fix --dry-run CVE-2024-3094 2>/dev/null || trueEin wöchentlicher Cron, der genau diese Zeilen verschickt wenn sie nicht leer sind, ersetzt drei Newsletter:
# /etc/cron.weekly/sicherheitsstand
#!/bin/sh
AUSGABE=$(apt-get -s -o Debug::NoLocking=true upgrade | grep -i '^Inst.*security')
[ -n "$AUSGABE" ] && printf '%s\n' "$AUSGABE" | mail -s "Sicherheitsupdates offen: $(hostname -s)" [email protected]
exit 0Leere Läufe schweigen, das ist der ganze Trick.
Woran man eine schlechte Quelle erkennt#
- Sie meldet Produkte, die du nicht einsetzt, und lässt sich nicht filtern.
- Sie meldet ohne Version, sodass jede Meldung eine eigene Recherche auslöst.
- Sie meldet zusammenfassend statt konkret („mehrere Schwachstellen in Linux“).
- Sie kommt von einem Anbieter, der etwas verkaufen will, und die Dringlichkeit steigt zum Quartalsende.
Bei drei von vier Punkten: abbestellen. Der Verlust ist geringer als der Aufmerksamkeitsschaden.
Was danach passiert#
Eine gelesene Meldung ist noch keine Handlung. Der Weg ist immer derselbe: Betroffenheit prüfen → einordnen → einspielen im Wartungsfenster oder außer der Reihe. Und für die Fälle, in denen die Meldung dich als Betreiber selbst zu einer Meldung verpflichtet, steht der Ablauf in Meldefristen: 24, 72, ein Monat.
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.
