☰

Aktualisieren von Produktions-Ubuntu-Boxen: Was man tun und lassen sollte

tag-icon • tag-icon linux ubuntu security update
Aktualisieren von Produktions-Ubuntu-Boxen: Was man tun und lassen sollte

Von Zeit zu Zeit melde ich mich bei den Produktions-Web-/DB-/Toolboxen an und sehe die typische Meldung:

30 Pakete können aktualisiert werden. 16 Updates sind Sicherheitsupdates.

Meine Frage ist, wie handhaben Sie alle Updates auf Ihren Ubuntu-Produktionsboxen? Automatisieren Sie diese Updates? Legen Sie Ausfallzeiten dafür fest? Das Problem ist, dass Sie nie wissen, wann ein Update etwas kaputt macht, beispielsweise eine vorhandene Konfigurationsdatei usw.

Der andere Teil dieses Problems ist, dass es zwar „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?

Ich denke, ein Thread mit Antworten darauf, wie Sie Ihre Updates verwalten, wäre sehr nützlich.

Antwort1

Das Patchen von Ubuntu ist im Vergleich zu Windows, RHEL, CentOS, SuSE, Debian usw. nichts Besonderes.

Die grundlegende Geisteshaltung, die Sie bei der Entwicklung Ihres Patch-Verfahrens haben müssen, ist, etwas anzunehmenWillebrechen.

Einige der grundlegenden Richtlinien, die ich beim Entwerfen eines Patch-Setups verwende, sind:

  • Verwenden Sie immer ein lokales System, um intern in Ihrem Netzwerk zu zentralisieren, von wo aus die Patches installiert werden

Hierzu kann die Verwendung von WSUS oder von Spiegelungen <your_os_here>auf einem internen Patch-Management-Rechner gehören. Vorzugsweise sollte dieser den Status der auf Ihren einzelnen Rechnern installierten Patches zentral abfragen und Ihnen mitteilen können.

  • Führen Sie die Installationen – wenn möglich – auf den Maschinen vorab durch.

Wenn möglich, lassen Sie Patches beim Erscheinen vom zentralen Server auf die einzelnen Rechner kopieren. Das spart wirklich Zeit, denn Sie müssen nicht warten, bis die Patches heruntergeladen UND installiert sind, sondern können die Installation einfach während Ihres Patch-Zeitfensters starten.

  • Holen Sie sich ein Zeitfenster für die Installation der Patches. Möglicherweise müssen Sie neu starten und wahrscheinlich wird etwas kaputt gehen. Stellen Sie sicher, dass die Beteiligten an diesen Systemen wissen, dass Patches bereitgestellt werden. Seien Sie auf Anrufe vorbereitet, die sagen: „Das funktioniert nicht.“

Gemäß meiner Grundtheorie, dass Patches Dinge kaputt machen, sollten Sie sicherstellen, dass Sie ein ausreichend langes Zeitfenster für die Patch-Anwendung haben, um kritische Probleme zu beheben und den Patch möglicherweise zurückzusetzen. Sie müssen nicht unbedingt Leute haben, die nach dem Patchen dort sitzen und Tests durchführen. Ich persönlich verlasse mich stark auf meine Überwachungssysteme, die mir mitteilen, dass alles auf dem Mindestniveau funktioniert, das wir uns leisten können. Aber seien Sie auch darauf vorbereitet, dass kleine lästige Probleme gemeldet werden, wenn die Leute zur Arbeit kommen. Sie sollten immer jemanden da haben, der bereit ist, ans Telefon zu gehen – vorzugsweise nicht den Typen, der bis 3 Uhr morgens wach war, um die Boxen zu patchen.

  • automatisieren Sie so viel wie möglich

Wie bei allem anderen in der IT gilt: Skripte, Skripte und noch mehr Skripte. Skripte für den Paketdownload, den Installationsstart, den Spiegel. Im Grunde genommen möchten Sie Patch-Fenster in eine Art Babysitter-Aufgabe verwandeln, bei der nur ein Mensch anwesend sein muss, falls etwas kaputtgeht.

  • Haben Sie jeden Monat mehrere Fenster

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 die Patches in der ersten Nacht nicht durchführen können, verlangen Sie, dass sie in der zweiten Nacht frei sind. Außerdem können Sie so die Anzahl der gleichzeitig gepatchten Server in Grenzen halten.

Am wichtigstenbleib mit den Patches auf dem Laufenden!Wenn Sie das nicht tun, müssen Sie sehr lange Patch-Fenster von über 10 Stunden bearbeiten, nur um wieder an den Punkt zu kommen, an dem Sie aufgeholt haben. Dadurch entstehen noch mehr Punkte, an denen etwas schiefgehen kann, und es wird noch schwieriger herauszufinden, welcher Patch das Problem verursacht hat.

Der andere Teil dieses Problems ist, dass es zwar „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?

Einen Server einmal im Monat oder alle zwei Monate zu patchen, ist meiner Meinung nach ein durchaus erreichbares und akzeptables Ziel. Wenn Sie mehr tun, patchen Sie ständig Server, wenn nicht, geraten Sie in Situationen, in denen Sie Hunderte von Patches pro Server anwenden müssen.

Wie viele Windows benötigen Sie pro Monat? Das hängt von Ihrer Umgebung ab. Wie viele Server haben Sie? Wie lange müssen Ihre Server verfügbar sein?

Kleinere Umgebungen, die rund um die Uhr geöffnet sind, kommen wahrscheinlich mit einem Patch-Fenster pro Monat aus. Große 24x7-Umgebungen benötigen möglicherweise zwei. Sehr große 24x7x365-Umgebungen benötigen möglicherweise jede Woche ein gleitendes Fenster, um jede Woche einen anderen Satz Server zu patchen.

Finden Sie eine Frequenz, die für Sie und Ihre Umgebung funktioniert.

Man sollte bedenken, dass 100% Aktualität eineunmöglichZiel zu erreichen - lassen Sie sich von Ihrer Sicherheitsabteilung nichts anderes einreden. Geben Sie Ihr Bestes, bleiben Sie nicht zu weit zurück.

Antwort2

Dinge die zu tun sind:

  1. Erstellen Sie ein Backup
  2. Stellen Sie sicher, dass es sich um ein wiederherstellbares Backup handelt (diese beiden Punkte sind allerdings allgemeiner Natur)
  3. Versuchen Sie, den Datenverkehr während des Upgrades von der Produktionsbox wegzuleiten.
  4. Versuchen Sie, für den Fall, dass alles schief geht, eine Out-of-Band-Zugriffsmethode zu haben, KVM, serielle Konsole, lokaler Zugriff oder Remote-Hands.
  5. Testen Sie auf einem Server und stellen Sie dann sicher, dass alles funktioniert, bevor Sie Updates auf weiteren Servern bereitstellen.
  6. Verwenden Sie wenn möglich Puppet, um sicherzustellen, dass die Versionsnummern auf mehreren Servern gleich sind. (Sie können damit auch Upgrades erzwingen.)
  7. Vergleichen Sie auf einem Testserver die Versionen der Konfigurationsdateien mit den neuen (Update installiert) und stellen Sie sicher, dass nichts ernsthafte Probleme verursacht. Ich glaube mich zu erinnern, dass dpkg vor der Installation neuer Versionen, die sich von den aktuell installierten unterscheiden, danach fragt.

Folgendes sollte vermieden werden:

  1. Führen Sie Updates mitten am Tag durch, oder um 9:00 Uhr an einem Montagmorgen oder um 17:00 Uhr an einem Freitagnachmittag! (danke @3influence!)
  2. Upgrade von MySQL auf sehr großen Datenbankservern (Neustart kann lange dauern)
  3. Alle Server gleichzeitig bearbeiten (vor allem Kernel)
  4. Alles tun, was /etc/networks ändern könnte (da die Verbindung verloren gehen könnte)
  5. Automatische Updates, die die oben genannten Aufgaben erledigen können, ohne dass Sie vor Ort sein müssen, um zu überprüfen, ob alles in Ordnung ist.

Antwort3

Ein weiterer wichtiger Punkt: Wenn Sie an Windows gewöhnt sind, werden Sie überrascht sein, dass die meisten Linux-Updatesnichterfordern Ausfallzeiten oder einen Neustart. Bei manchen ist das der Fall, z. B. bei Kernel-Updates. Updates, die einen Neustart oder Ausfallzeiten erfordern, werden jedoch normalerweise als solche gekennzeichnet und können nach einem separaten Zeitplan behandelt werden.

Antwort4

Wir gehen mit Updates für Ubuntu LTS-Systeme folgendermaßen um:

  1. Führen Sie eine Reihe von Abnahmetests durch, die alle kritischen Pfade unserer Software prüfen.
  2. Installieren Sie Sicherheitsupgrades unbeaufsichtigt jeden Morgen um 4 Uhr und führen Sie sofort die Abnahmetests durch. Wenn etwas schief geht, wird ein Techniker angepiept und hat genügend Zeit, die Dinge zu reparieren oder vor 9 Uhr ein Rollback durchzuführen. Dies ist bisher in fünf Jahren nur zweimal passiert – LTS ist gut getestet und stabil.
  3. Wir stellen unsere gesamte Infrastruktur jede Woche automatisch neu bereit (auf Digitalocean) mit Blue/Green-Bereitstellungen, wodurch alle Pakete auf dem neuesten Stand bleiben. Wenn eine neue Bereitstellung die Abnahmetests nicht besteht, wird die Bereitstellung angehalten, bis ein Techniker das Problem beheben kann.

Der nächste logische Schritt für uns ist die Beseitigung von In-Memory-Sitzungsinformationen, sodass wir die Infrastruktur einfach jeden Tag oder sogar mehrmals täglich neu bereitstellen können, ohne die Kunden zu beeinträchtigen, und so Schritt (2) eliminieren können.

Dieser Ansatz erfordert geringen Wartungsaufwand und vermeidet Wartungsfenster vollständig.

verwandte Informationen