Die ersten Stunden nach einem kritischen CVE: eine Checkliste, die funktioniert

Eine Schwachstelle höchster Schwere in einer zentralen Komponente wird veröffentlicht. Von diesem Moment an läuft die Uhr für alle, Angreifer eingeschlossen. Der Unterschied zwischen einem ruhigen Tag und einer schlechten Woche ist selten der Patch selbst. Es ist das, was Sie in den Stunden davor und danach tun. Dies ist die Abfolge, der wir folgen, so aufgeschrieben, dass Sie sie an Ihre eigene Flotte anpassen können.

Stunde null: das Advisory zweimal lesen

Lesen Sie das Advisory einmal, um die Schwachstelle zu verstehen, und einmal, um die Bedingungen zu verstehen. Die meisten ernsthaften Advisories kommen mit Einschränkungen: nur wenn ein bestimmtes Modul geladen ist, nur in einem bestimmten Servermodus, nur wenn eine Funktion aus dem Netzwerk erreichbar ist. Diese Einschränkungen entscheiden, welche Ihrer Hosts dringend sind, welche lediglich betroffen sind, und welche Gegenmaßnahme passt.

Schreiben Sie drei Dinge auf, bevor Sie irgendetwas anfassen: die Namen der betroffenen Pakete, das korrigierte Upstream-Release und die Bedingungen für eine Ausnutzung. Alles, was folgt, wird gegen diese Notiz geprüft.

Jeden Host finden, auf dem es läuft

Fragen Sie die Paketdatenbank auf jedem Host, statt sich darauf zu verlassen, was Sie für installiert halten:

for h in $(cat hosts.txt); do
  printf '%s: ' "$h"
  ssh -o BatchMode=yes "$h" 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" <package> 2>/dev/null || echo not-installed'
done | tee exposure-$(date +%F).txt

Dann prüfen Sie die Bedingungen. Wenn die Schwachstelle in einem Modul steckt, listen Sie auf, was tatsächlich geladen ist. Wenn sie eine erreichbare Funktion braucht, prüfen Sie, ob sie erreichbar ist. Sortieren Sie das Ergebnis in drei Gruppen: exponiert und erreichbar, installiert, aber in der vorliegenden Konfiguration nicht ausnutzbar, und nicht vorhanden. Die erste Gruppe bekommt jetzt ihre Gegenmaßnahme.

Gegenmaßnahmen, bevor der Fix existiert

Fast immer gibt es etwas, das Sie tun können, bevor ein korrigiertes Paket verfügbar ist: die verwundbare Funktion abschalten, einen Konfigurationswert ändern, am Edge eine Regel setzen, die die Request-Form blockiert, die der Exploit braucht. Wählen Sie die am wenigsten störende Gegenmaßnahme, die den Pfad schließt, und wenden Sie sie mit Disziplin an:

• Führen Sie eine Liste jeder Gegenmaßnahme, die Sie gesetzt haben, damit Sie diejenigen, die Leistung kosten, wieder aufheben können, sobald der echte Fix da ist. Gegenmaßnahmen, die nichts kosten, können bleiben.

Den Fix selbst bauen, wenn es sein muss

Manchmal hat das Upstream-Projekt korrigierten Quellcode veröffentlicht und die Distribution hat ihn noch nicht paketiert. Warten ist eine Option, aber nicht die einzige. Wenn wir uns entscheiden, nicht zu warten, bauen wir das Paket selbst: aus der Spezifikation des Distributions-Maintainers selbst, in einem sauberen Wegwerf-Container, aus Quellcode, dessen Prüfsumme gegen die offizielle Download-Seite des Projekts verifiziert ist, mit einem Release-Tag, das so gewählt ist, dass der Build des Herstellers unseren automatisch ersetzt, sobald er eintrifft. Die Pakete gehen in unseren eigenen Mirror, mit ihren Prüfsummen im Protokoll. Die vollständige Methode, mit Befehlen, steht in Ihr eigener RPM-Mirror, und der Fix, gebaut bevor die Distribution ihn ausliefert.

Die Entscheidung zu bauen ist ein Urteil, kein Reflex. Bauen Sie, wenn die Schwachstelle ausgenutzt wird oder trivial ausnutzbar ist, die betroffenen Hosts erreichbar sind und keine Gegenmaßnahme den Pfad gut genug schließt. Andernfalls ist eine solide Gegenmaßnahme plus eine kurze Wartezeit auf das Paket des Herstellers in der Regel die ruhigere Wahl.

Protokoll führen, und die Menschen informieren

Während der Arbeit eine Zeitleiste führen

Öffnen Sie zur Stunde null eine einfache Textdatei und schreiben Sie eine Zeile pro Aktion, mit Uhrzeit: Advisory gelesen, Inventur abgeschlossen, Gegenmaßnahme auf welchen Hosts gesetzt, Paket gebaut, jeder gepatchte Host, Log-Prüfung abgeschlossen. Das kostet Sekunden pro Zeile. Es liefert Ihnen das genaue Expositionsfenster für jeden Host, das die Log-Prüfung braucht, und es macht aus dem Bericht, den Sie danach schulden, eine Überarbeitung statt einer Gedächtnisübung.

Die Menschen informieren, bevor sie fragen

Die Menschen, die von den betroffenen Systemen abhängen, erfahren von einer bekannten Schwachstelle aus den Nachrichten, oft innerhalb von Stunden. Sagen Sie es ihnen zuerst. Eine kurze Nachricht, die festhält, ob ihre Systeme betroffen sind, was bereits getan wurde und wann der Fix kommt, ist mehr wert als ein perfekter Bericht eine Woche später. Wenn ein Schritt Ausfallzeit braucht, stimmen Sie den Zeitpunkt mit ihnen ab, bevor Sie ihn nehmen.

Einen Host nach dem anderen ausrollen, mit Nachweis

Jeder Host bekommt eine Vorab-Prüfung und eine Nachprüfung, und die beiden werden verglichen, nicht überflogen:

php -m | sort > pre-modules.txt      # or the equivalent for your component
curl -s -o /dev/null -w '%{http_code}\n' https://<site>/health
# install, then reload gracefully
systemctl reload php-fpm
php -m | sort > post-modules.txt && diff pre-modules.txt post-modules.txt

In einer größeren Flotte automatisieren Sie den sorgfältigen Teil, statt ihn zu überspringen. Ein Rollout, der pro Lauf einen Server aktualisiert, vorher und nachher echte Websites stichprobenartig prüft und den gesamten Durchlauf anhält und einen Ingenieur ruft, sobald eine einzige Website nicht zurückkommt, ist schneller und sicherer zugleich als ein Mensch, der nachts eine Liste abarbeitet.

Dann fragen, ob das Fenster genutzt wurde

Patchen schließt die Tür. Es sagt Ihnen nicht, ob jemand hindurchgegangen ist, solange sie offen war. Sobald der Rollout abgeschlossen ist, durchsuchen Sie auf jedem exponierten Host die Web- und Authentifizierungs-Logs für den Zeitraum zwischen Veröffentlichung und Patch. Suchen Sie nach den Request-Formen, die der Exploit braucht, nach unerwarteten Prozessen oder Dateien, die in diesem Fenster entstanden sind, und nach Anmeldungen, die nicht ins übliche Muster passen. Schreiben Sie auf, was Sie gefunden haben, auch «nichts», denn die Menschen, die von diesen Systemen abhängen, werden fragen.

Die Kurzfassung

• Lesen Sie die Bedingungen, nicht nur die Schwere.
• Inventur aus der Paketdatenbank, nicht aus dem Gedächtnis.
• Gegenmaßnahmen innerhalb von Stunden.
• Den Fix nur dann selbst bauen, wenn es gerechtfertigt ist, und dann auf die saubere Art.
• Eine Zeitleiste führen und die Betroffenen früh informieren.
• Einen Host nach dem anderen ausrollen, mit vergleichbaren Prüfungen vorher und nachher, und mit automatischem Stopp.
• Das Expositionsfenster in den Logs prüfen, und darüber berichten.

Wenn eine Veröffentlichung eintrifft und Sie Hilfe möchten, sie auf Ihrer eigenen Plattform durchzuarbeiten, sind wir da. Mit einem Ingenieur sprechen

Verwandt: Schnelle Reaktion auf Schwachstellen, am selben Tag · Die Hardening-Baseline auf jedem Host · Aktuelle Plattformen und Upgrade-Disziplin