Lösung 1:
Es ist nichts Besonderes, Ubuntu im Vergleich zu Windows, RHEL, CentOS, SuSE, Debian usw. zu patchen.
Die grundlegende Geisteshaltung, in der Sie sein müssen, wenn Sie Ihr Patch-Verfahren entwerfen, ist, davon auszugehen, dass etwas wird Pause.
Einige der grundlegenden Richtlinien, die ich beim Entwerfen eines Patch-Setups verwende, sind:
- Verwenden Sie immer ein lokales System, um es intern in Ihrem Netzwerk zu zentralisieren, von wo aus die Patches installiert werden
Dies kann die Verwendung von WSUS oder Mirrors von <your_os_here> beinhalten zu einem internen Patch-Management-Rechner. Am besten eine, die den Status der auf Ihren einzelnen Rechnern installierten Patches zentral abfragen und Ihnen mitteilen kann.
- Stellen Sie die Installationen - wenn möglich - auf den Maschinen vor.
Wenn es möglich ist, lassen Sie Patches, die herauskommen, vom zentralen Server auf die einzelnen Computer kopieren. Dies ist wirklich nur eine Zeitersparnis, sodass Sie nicht warten müssen, bis sie heruntergeladen UND installiert sind, sondern die Installation einfach während Ihres Patch-Fensters starten müssen.
- Besorgen Sie sich ein Ausfallfenster, um die Patches zu installieren, Sie müssen möglicherweise neu starten und etwas wird wahrscheinlich kaputt gehen. Stellen Sie sicher, dass die Beteiligten für diese Systeme wissen, dass Patches bereitgestellt werden. Seien Sie auf die „das funktioniert nicht“-Anrufe vorbereitet.
In Übereinstimmung mit meiner grundlegenden Theorie, dass Patches Dinge kaputt machen, stellen Sie sicher, dass Sie ein Ausfallfenster haben, um Patches lang genug anzuwenden, um kritische Probleme zu beheben, und setzen Sie den Patch möglicherweise zurück. Sie müssen nicht unbedingt Leute haben, die nach Patches testen. Persönlich verlasse ich mich stark auf meine Überwachungssysteme, um mich wissen zu lassen, dass alles auf dem absolut minimalen Niveau funktioniert, mit dem wir davonkommen können. Aber seien Sie auch darauf vorbereitet, dass kleine nörgelnde Probleme angerufen werden, wenn die Leute zur Arbeit kommen. Sie sollten immer jemanden haben, der da ist, der bereit ist, das Telefon zu beantworten - vorzugsweise nicht der Typ, der bis 3 Uhr morgens die Kisten gepatcht hat.
- so viel wie möglich automatisieren
Wie alles andere in der IT, Skript, Skript und dann noch mehr Skript. Script den Paketdownload, den Installationsstart, den Mirror. Im Grunde möchten Sie Patch-Fenster in eine Babysitter-Aufgabe verwandeln, die nur einen Menschen dort braucht, falls etwas kaputt geht.
- Jeden Monat mehrere Fenster haben
Dies gibt Ihnen die Möglichkeit, einige Server nicht zu patchen, wenn sie aus irgendeinem Grund nicht in der "festgelegten Nacht" gepatcht werden können. Wenn Sie dies in Nacht 1 nicht tun können, verlangen Sie, dass sie in Nacht 2 kostenlos sind. Außerdem können Sie die Anzahl der gleichzeitig gepatchten Server auf einem vernünftigen Niveau halten.
Am wichtigsten ist, dass Sie mit den Patches Schritt halten! Wenn Sie dies nicht tun, müssen Sie sehr große 10+-Stunden-Patch-Fenster durchführen, nur um zu dem Punkt zurückzukehren, an dem Sie eingeholt werden. Es werden noch mehr Punkte eingeführt, an denen etwas schief gehen könnte, und es wird so viel schwieriger, den Patch zu finden, der das Problem verursacht hat.
Der andere Teil dieses Problems ist, dass es „eine gute Sache“ ist, mit Patches Schritt zu halten, aber Patches werden fast täglich veröffentlicht. Wie viele geplante Ausfälle muss man machen, wenn jeden Tag ein neuer Sicherheitspatch verfügbar ist?
Das Patchen eines Servers einmal im Monat oder einmal alle zwei Monate ist - meiner Meinung nach - ein sehr erreichbares und akzeptables Ziel. Mehr als das, und Sie werden ständig Server patchen, geschweige denn, und Sie geraten in Situationen, in denen Sie Hunderte von Patches haben, die pro Server angewendet werden müssen.
Wie viele Fenster benötigen Sie im Monat? Das hängt von deiner Umgebung ab. Wie viele Server haben Sie? Was ist die erforderliche Betriebszeit für Ihre Server?
Kleinere Umgebungen, die 9x5 sind, können wahrscheinlich mit einem Patch-Fenster pro Monat davonkommen. Große 24x7-Shops benötigen möglicherweise zwei. Sehr große 24x7x365 benötigen möglicherweise jede Woche ein rollierendes Fenster, um jede Woche einen anderen Satz von Servern zu patchen.
Finden Sie eine Frequenz, die für Sie und Ihre Umgebung geeignet ist.
Beachten Sie, dass eine 100 %ige Aktualität unmöglich ist Ziel zu erreichen - lassen Sie sich von Ihrer Sicherheitsabteilung nichts anderes sagen. Geben Sie Ihr Bestes, fallen Sie nicht zu weit zurück.
Lösung 2:
Aktivitäten:
- Erstellen Sie eine Sicherungskopie
- Stellen Sie sicher, dass es sich um ein wiederherstellbares Backup handelt (obwohl dies nur allgemeine Punkte sind)
- Versuchen Sie, während des Upgrades den Datenverkehr von der Produktionsbox wegzuleiten.
- Versuchen Sie, eine Out-of-Band-Zugriffsmethode zu haben, falls alles schief geht, KVM, serielle Konsole, lokaler Zugriff oder Remote-Hands.
- Testen Sie auf einem Server und stellen Sie dann sicher, dass alles funktioniert, bevor Sie Updates auf mehreren Servern bereitstellen
- Verwenden Sie nach Möglichkeit Puppet, um sicherzustellen, dass die Versionsnummern auf mehreren Servern gleich sind. (Sie können es auch verwenden, um Upgrades zu erzwingen)
- Vergleichen Sie auf einem Testserver die Versionen der Konfigurationsdateien mit den neuen (Update installierten) und stellen Sie sicher, dass nichts die Dinge ernsthaft kaputt macht. Ich meine mich zu erinnern, dass dpkg gefragt hat, bevor neue Versionen installiert wurden, die sich von den derzeit installierten unterscheiden.
Zu vermeidende Dinge:
- Aktualisierungen mitten am Tag oder 09:00 Uhr an einem Montagmorgen oder 17:00 Uhr an einem Freitagnachmittag! (Danke @3influence!)
- Upgrade von MySQL auf wirklich großen Datenbankservern (Neustart kann lange dauern)
- Alle Server auf einmal erledigen (insbesondere Kernel)
- Alles tun, was /etc/networks ändern könnte (weil Sie die Verbindung verlieren könnten)
- Automatisierte Updates, die das Obige tun könnten, ohne dass Sie da sind, um zu überprüfen, ob alles in Ordnung ist.
Lösung 3:
Ein weiterer erwähnenswerter Punkt:Wenn Sie an Windows gewöhnt sind, werden Sie überrascht sein, dass die meisten Linux-Updates dies nicht tun Ausfallzeit oder Neustart erfordern. Einige tun dies, z. B. Kernel-Updates. Updates, die einen Neustart oder eine Ausfallzeit erfordern, werden jedoch normalerweise als solche gekennzeichnet und können nach einem separaten Zeitplan behandelt werden.
Lösung 4:
Auf unseren Ubuntu-Rechnern laufen alle LTS-Releases.
Wir installieren einfach automatisch alle Updates - sicher ist es nicht "Best Practice", aber wir sind ein relativ kleiner Shop und haben keine Test-/Entwicklungs-/Produktionsumgebung für jeden einzelnen Dienst. Die LTS-Updates sind im Allgemeinen ziemlich gut getestet und ohnehin minimal invasiv.
Ein Upgrade auf eine neue Version ist natürlich etwas aufwendiger.
Lösung 5:
Wir behandeln Updates für Ubuntu LTS-Systeme wie folgt:
- Betreuen Sie eine Reihe von Akzeptanztests, die alle kritischen Pfade in unserer Software prüfen
- Installieren Sie Sicherheits-Upgrades jeden Morgen unbeaufsichtigt um 4 Uhr morgens und führen Sie sofort die Abnahmetests durch. Wenn irgendetwas fehlschlägt, wird ein Techniker angerufen und hat genügend Zeit, um die Dinge zu reparieren oder vor 9 Uhr ein Rollback durchzuführen. Dies ist bisher nur zweimal in fünf Jahren passiert - LTS ist gut getestet und stabil.
- Wir stellen unsere gesamte Infrastruktur automatisch jede Woche (auf Digitalocean) mit Blau/Grün-Bereitstellungen neu bereit, wodurch alle Pakete auf den neuesten Versionen bleiben. Wenn eine neue Bereitstellung die Akzeptanztests nicht besteht, wird die Bereitstellung angehalten, bis ein Techniker das Problem beheben kann.
Der nächste logische Schritt besteht für uns darin, In-Memory-Sitzungsinformationen zu eliminieren, damit wir die Infrastruktur einfach jeden Tag oder sogar mehrmals am Tag neu bereitstellen können, ohne Kunden zu beeinträchtigen und Schritt (2) zu eliminieren.
Dieser Ansatz ist wartungsarm und vermeidet Wartungsfenster vollständig.