Bundeshack: Outlook kann nicht das einzige Problem sein – I

Posted on by

Mittwoch früh erhielt ich eine Nachricht von einer guten Bekannten; der Mailinhalt bezog sich auf den SZ-Artikel
http://www.sueddeutsche.de/ digital/ exklusiv-so-schleusten-die-hacker-daten-aus-dem-auswaertigen-amt-1.3894534
zum Hacker-Angriff auf das IVBB. Offenbar wird dieser Angriff jetzt als “Bundeshack” bezeichnet – und beschäftigt wohl einige Sicherheitsexperten in der Republik. Meine Bekannte schrieb mir, ich hätte mit meinen regelmäßig kritischen Anmerkungen zur Sicherheit heutiger IT-Infrastrukturen und im Besonderen zu MS-Produkten – wie Outlook – wohl mal wieder Recht gehabt. Das stimmt in diesem Fall aber nicht so ganz, denn tatsächlich sind mit der Sicherheit des IVBB Fachleute befasst, die die Gefahrenlage und auch die eingesetzten SW-Produkte in und auswendig kennen. Und leider verführt der SZ-Artikel dazu, das Versagen primär bei Outlook zu sehen. Das ist aber zu kurz gedacht; die im IVBB aufgetretenen Probleme müssen – wenn man mal glaubt, was die Presse kolportiert – aus meiner Sicht noch tieferliegende Ursachen haben. Was mich als IT-affinen Bürger dann eher beunruhigt …

Neutraler und sachlicher im Ton als der SZ-Beitrag ist der kommentierende Artikel bei Heise (s. https://www.heise.de/ security/ meldung/ Bundeshack-Daten-sollen-ueber-Outlook-ausgeleitet-worden-sein-3987759.html?xing_share=news). Dort wird zu Recht festgestellt, dass die Informationen der SZ mehr Fragen aufwerfen, als sie beantworten.

Ich fasse nachfolgend und in einem weiteren Artikel ein paar eigene Gedanken zum Thema “Bundeshack” zusammen. Ich hoffe, das hilft, eben jene Fragen besser zu erkennen, die sich nach dem SZ-Artikel aufdrängen. Meine Argumente sind dabei weitgehend unabhängig von der Frage “MS oder nicht” – und deshalb hoffentlich auch für Linux-Freunde interessant. Kommentare könnt ihr gerne per Mail an mich schicken.

Verschlüsselte Kommunikationsverbindungen ins Internet – und ihre zwei Seiten

Zunächst wollen wir die Grund-Information des SZ-Artikels – nämlich, dass die Hacker Mails (ggf. über Manipulationen von Outlook) zur Kommunikation mit einer Schad-Software und zum Transfer von geheimen Informationen nach außen genutzt haben – genauer einordnen. Als Voraussetzung ist dazu, für den einen oder anderen vielleicht überraschenderweise, ein Blick auf Datenverschlüsselung erforderlich.

Ich gehe mal davon aus, dass der Leser mit mir einig ist, dass ein essentielles Problem von Angriffen auf Behördennetze ein nachfolgender unkontrollierter Abfluss von Daten an Unbefugte ist. (Das ist natürlich nur ein Bedrohungsaspekt von Hacker-Angriffen; andere blende ich hier aber mal aus). Der illegale Zugriff auf Daten betrifft u.a. geheime Informationen der Exekutive sowie der Legislative, die z.Z. auch im Behördennetz hängt, aber ggf. auch Daten der Judikative. In keinem Fall kann man wollen, dass Hackern ein unbefugter Zugriff auf geheimzuhaltende Daten von Behörden (wie etwa dem Auswärtigen Amt) gelingt und diese nach außen transferiert werden. Wie erfolgt denn eigentlich ein unbemerkter Daten-Transfer von einem gehackten Gerät (PC, Notebook, Smartphone, …) und aus einem Firmen/Behörden-Netzwerk nach außen an irgendwelche Empfänger im Internet? Wieso ist das überhaupt möglich?

Antwort: U.a. wegen zu großen Freiräumen für elektronische Kommunikation am Arbeitsplatz und ausgerechnet auch noch durch ein wichtiges IT-Sicherheits-Element – nämlich Verschlüsselung. Wie das?

Als ich vor Jahren mal an einem Projekt in einer öffentlichen Institution arbeitete, hatte ich eine erbitterte “Diskussion” mit einer hoch positionierten – und politisch gut verdrahteten – Führungskraft zum Thema HTTPS. Es gab im Zuge der
Auseinandersetzung sogar eine schriftliche Beschwerde: Ich könne doch wohl nicht am Vormittag HTTPS-Verbindungen fordern und am Nachmittag HTTPS in einem anderen Kontext als problematisch darstellen. Tja, … kann ich doch … Es ging dabei nämlich um zwei ganz verschiedene Dinge: Am Vormittag wurde HTTPS als (halbwegs) sicheres Verbindungsprotokoll diskutiert, das es Kunden/Bürgern ermöglichen sollte, über das Internet auf einen künftig zu betreibenden Web-Service der Institution zuzugreifen. Am Nachmittag aber waren verschlüsselte Web-Verbindungen von den Arbeitsplatz-PCs der Behörden-Angestellten aus zu Web-Mail-Diensten privater Anbieter im Internet das Thema. Letzteres war erlaubt …

Mancher sicherheitsbewusster Leser wird schon jetzt den Kopf schütteln … Ich hatte damals (am Nachmittag) diese “Policy” als ideale Möglichkeit für korrupte, unzufriedene oder schlicht böswillige Mitarbeiter charakterisiert, unkontrollierbar und auch im Nachhinein nur äußerst schwer nachweisbar interne, geheimzuhaltende Daten nach außen abfließen zu lassen.

Meine Kritik stieß damals leider auf völliges Unverständnis. Man müsse seinen Mitarbeitern/innen doch wohl vertrauen können … Nun ja, ich sehe das von Haus aus anders. Zudem sind bei Sicherheitsthemen nicht nur die Mitarbeitermotivation sondern auch Gefahrenpotentiale zu berücksichtigen, die durch das unbedarfte Handeln von Mitarbeitern im Kontakt mit dem Internet ungewollt auftreten können (s.u.). Unabhängig davon: Der Versuch, einem Politiker den Unterschied

  • zwischen den Gefahrenpotentialen ausgehender verschlüsselter Verbindungen vom Arbeitsplatz-PC eines Angestellten (oder dortiger Programme) ins Internet einerseits
  • und den Gefahren bei der Behandlung von Daten eingehender verschlüsselter Verbindungen zu vom Betreiber kontrollierten Webservern in einer gesicherten Zone andererseits

zu vermitteln, erwies sich im Nachgang jedenfalls als unerwartet, ja geradezu verblüffend schwierig…

Den Lesern dieses Linux-Blogs ist dagegen natürlich klar, dass Verschlüsselung ab einem Endgerät (PC, Notebook, …) und aus einem Verwaltungsnetz heraus zu externen Servern ein echtes Problem darstellt. Grund: Niemand kann dann mehr kontrollieren, was über eine solche Verbindung an ggf. unbefugte Empfänger im Internet übertragen wird. Zumindest nicht ohne Zusatzmaßnahmen. Man erkennt bei etwas Nachdenken unschwer, dass Sicherheit durch Verschlüsselung immer eine Frage der Autorität über die verschlüsselten Daten ist und zum zweischneidigen Schwert werden kann:

Als Privatperson sollte ich unzweifelhaft der Herr meiner Daten sein – und z.B. auf einer Verschlüsselung in der Kommunikation mit Behörden bestehen. Als Behörde habe ich stellvertretend die Autorität über die mir vom Bürger anvertrauten Daten erlangt – und muss durch Sicherheitsmaßnahmen u.a. Folgendes garantieren:

  • Behörden müssen kontrollieren können, dass zu schützende Daten nur Befugte erreichen und von Unbefugten nicht eingesehen werden können.
  • Behörden müssen dafür sorgen, dass zu schützende Daten im Transfer zu Befugten verschlüsselt werden, wenn dabei öffentliche Netze passiert werden.

Hierbei gibt es aber Risiken (u.a. durch böswillige Mitarbeiter), denen durch Maßnahmen zu begegnen ist. Die Autorität über Datenflüsse nach außen und über evtl. zu schützende Inhalte kann ich aus Gründen der Risikoeindämmung in der IT nicht an einzelne Mitarbeiter oder Programme am Arbeitsplatz-PCs abtreten. Erforderlich ist vielmehr eine unabhängige, unbestechliche Kontrolle darüber, welche elektronischen Daten über welche Kanäle nach außen wandern. Das ist zumindest meine Erwartung an Behörden in demokratisch verfassten Staaten. Unkontrollierter Abfluss von geheim zu haltenden Daten von Arbeitsplatz-PCs
aus geht gar nicht. Und eine durchgehende Verschlüsselung durch Mitarbeiter vom Arbeitsplatz zu Empfängern im Internet erweist sich hier gerade als Problem, da die Verschlüsselung i.d.R. irreversibel ist und auch im Nachhinein keine Inhalts- und Berechtigungskontrolle zu dem Transfervorgang mehr möglich ist.

Das gilt u.a. für Mail-Verschlüsselung in Mail-Anwendungen am Arbeitsplatz genauso wie für HTTPS-Verbindungen zu irgendwelchen Web-Servern. Betroffen sind potentiell aber auch andere Netzwerk-Protokolle. Die nach außen übermittelten verschlüsselten Inhalte sind in allen Fällen auch im Nachhinein nur schwer zu – wenn überhaupt – zu ermitteln. Ggf. durch die Koinzidenz von Zeitstempeln bei Datei-Zugriffen und darauf anschließendem Mailversand. Zeitstempel liefern aber nur Indizien. Ein rechtskräftiger Beweis lässt sich daraus nur schwerlich ableiten, wenn man die Verschlüsselung nicht knacken kann. Gut verschlüsselter Inhalt an illegitime Empfänger ist halt immer noch gut verschlüsselt.

Wenn man dann noch die Aufnahme verschlüsselter Verbindungen zu vom Arbeitsplatz zu beliebigen Zieladressen im Internet zulässt, wird das Problem immens:

Nicht nur ein böswilliger Mitarbeiter kann über einen verschlüsselten Kanal von einem Endgerät aus geheime Daten nach außen schleusen. Über verschlüsselte Verbindungen kann man sich ggf. auch Malware unkontrolliert einhandeln, bevor ein lokaler Virenscanner die eliminieren kann. Und – noch schlimmer: Prinzipiell kann natürlich auch jede Malware (Schad-Software), die man sich irgendwie und irgendwann mal durch Unachtsamkeit eingefangen hat, einen verschlüsselten Verbindungskanal nach außen nutzen, um Informationen an externe Empfänger zu senden.

Vertrauen in Mitarbeiter ist eine Sache; unerkannte Malware, die mit der Nutzerkennung des Anwenders ausgehende Verbindungen zu Systemen im Internet aufnimmt, ein andere.

Nun wird der eine oder andere Leser sagen: Aber wir haben ja Firewalls!? Tja, schon – aber der transferierte Inhalt wurde ja schon im Browser am Arbeitsplatz mit einem zwischen Browser und Zielserver ausgehandelten Schlüssel verschlüsselt. Die Firewall kann die Legitimität der Verbindung damit in keinem Fall mehr am Inhalt festmachen. Höchstens und vielleicht noch am Adressaten. Aber auch ein legitimer Adressat kann illegitime Inhalte über verschlüsselte Verbindungen erhalten.

Nächste Frage: Warum sind verschlüsselte Verbindungen in der öffentlichen Verwaltung dann überhaupt sinnvoll und erlaubt? Hatte ich weiter oben nicht gerade selbst verlangt, dass Kommunikation über das Internet verschlüsselt werden muss? Liegt hier nicht ein Widerspruch vor?

Gute Frage! Betrachten wir zunächst mal eine Privatperson: Die braucht Verschlüsselung, um über das Internet sicher mit anderen Diensteanbietern (in der “Cloud”) kommunizieren zu können. Man denke dann z.B. an die Notwendigkeit der Verschlüsselung von Daten im Online-Banking, aber – und ebenso wichtig – an die Notwendigkeit, die Identität eines Webservers feststellen zu können, um nicht auf vorgegaukelte Webseiten hereinzufallen, die dem Original täuschend ähnlich sehen. Auf privaten PCs/Notebooks/Smartphones wird eine dortige “Personal Firewall” deshalb also kaum HTTPS-Verbindungen nach außen blocken. Im Gegenteil sind Privatpersonen eher dazu zu ermuntern, HTTPS wann und wo immer möglich zu nutzen.

Das gilt für Privatpersonen. Im Grunde aber doch auch für Behörden?

Wir dürfen bei der Beurteilung den oben diskutierten Punkt nicht übersehen: Die Tatsache, dass verschlüsselte Verbindungen von Nutzer-Geräten nach außen zu Web- und Dienste-Servern der “Cloud” in unserer internet-dominierten Welt so (überleben-) wichtig sind, dass sie zumindest auf normalen PCS, Smartphones, etc. nicht ohne weiteres geblockt werden können, ist aber eben auch ein erheblicher Schwachpunkt moderner web-orientierter IT und macht einmal eingefangene Schad-Software so erfolgreich und gefährlich:

Der Mensch wird einerseits als Schwachstelle für das Einschleusen von Malware genutzt; die Malware nutzt danach verschlüsselte Verbindungen vom Gerät des Anwenders zu Computern im Internet, welche direkt oder wiederum über Schad-Software durch den Angreifer kontrolliert werden. Was dabei alles vom eigenen PC, aus dem umgebenden Firmen- oder Behördennetz nach außen übertragen wird, können wir dann leider nicht mehr kontrollieren.

Darin besteht die problematische, “dunkle” Seite von Verschlüsselung in bestimmten Arbeitsumgebungen. Kann man diese negative Seite und andererseits die positive Seite von Verschlüsselung bei Behörden überhaupt in Einklang bringen?

Verschlüsselung und Closed Source

Mal (nicht) ganz nebenbei: Unter dem Gesichtspunkt “unkontrollierter Datenabfluss” stellt “Closed Source-Software”, die regelmäßig verschlüsselte Verbindungen zu Herstellern und deren Servern aufnimmt, von Haus aus ein großes Problem dar. Auch da haben wir überhaupt keine Chance zu prüfen, was da von unseren Systemen nach außen abfließt. Für mich ist das ein entscheidender Grund dafür, warum der Einsatz von Closed Source Software und Betriebssystemen im öffentlichen Verwaltungsbereich grundsätzlich ein Fehlgriff ist.

Die Umkehrung der Bedrohungsverhältnisse

Nicht nur ein böswilliger Mitarbeiter, sondern auch jede Art von Schad-Software wird typischerweise versuchen, vom “beherbergenden” System aus verschlüsselte Kommunikationskanäle von innen nach außen (!) zu Systemen im Internet aufzubauen, die unter Kontrolle des Angreifers liegen. Der nachfolgende Kommunikationsfluss erfolgt in beide Richtungen; er kann dabei sowohl Kommandos zur Steuerung der Schad-SW (und nach einer Rechteeskalation ggf. des gesamten umgebenden Systems) beinhalten oder aber den Transfer von Informationen zum Angreifer in ganz unterschiedlicher Form.

Früher betrachtete man die Absicherung von Netzen als Aufgabe, zu deren Lösung man einen “Schutzwall” um das eigene Netz aufbaut, der von außen kommende Angriffs- und Eindring-Versuche blockt. Das war schon immer ein unzureichendes Bild. Der Angriff auf IT-Strukturen erfolgt nicht nur von außen nach innen; mit “Social Engineering” und dem Ausnutzen mentaler Schwachpunkte von Menschen gelingt die Platzierung von Malware im Zeitalter von “Bring your own device” auch in Firmen immer irgendwann. Der wirkliche Angriff läuft danach aber sozusagen eher ungeblockt von innen nach außen. Modetrends wie “Bring your own Device (BYOD)” und das Nutzen von Cloud-Diensten lassen zudem die Grenzen zwischen Firmen- und Behörden-Netzen und dem Internet immer weiter verschwimmen. Wenn System-Administratoren meinen, sie müssten in der heutigen Zeit vor allem den Datenverkehr von außen nach innen kontrollieren, irren sie gewaltig. Die Überwachung des Verbindungsaufbaus von innen nach außen und die Überwachung zugehöriger Datenströme ist in bestimmten Netzen noch wichtiger. Übrigens: UDP-basierte Multimedia-Anwendungen, die mit Internet-Diensten kommunizieren, stellen dabei ein besonderes Problem-Umfeld dar und haben in sicheren IT-Umgebungen meiner Meinung nach nichts verloren. Das betrifft im besonderen Skype und dessen Ableger für Firmen.

Leider ignorieren das viele Firmen … Auch manche Behörden erheben eine Policy zur Erlaubnis verschlüsselter Verbindungen vom Arbeitsplatz-PC ins Internet geradezu zum mitarbeiterfreundlichen Prinzip .. und verlieren dabei jegliche Kontrolle über den Datenabfluss.

Verschlüsselte Verbindungen – ein Dilemma?

Unsere bisherige Diskussion hat bislang ein Dilemma beschrieben:
In einem Behördennetz mit Geheimhaltungsbedarfen sind verschlüsselte Verbindungen/Mails zwischen User-Endgeräten und Servern im Internet ein großes Problem. Andererseits erscheint Verschlüsselung im Datenaustausch über das
Internet geradezu als Pflicht … (Tatsächlich werden ausgehende verschlüsselte Verbindungen ins Internet in vielen Netzen – u.a. denen von Behörden – erforderlich und werden von sog. Perimeter-Firewalls oft auch zugelassen.)

Das Dilemma gipfelt in der Frage: Sollte man Verwaltungsangestellten die Aufnahme verschlüsselter Verbindungen von Netzen, in denen geheimzuhaltenden Informationen gelagert sind, nach außen überhaupt erlauben? Eigentlich kann die Antwort nach dem bisher Ausgeführten nur “Nein” lauten.

Was ist also tun? Der entscheidende Punkt besteht darin, die Irreversibilität von Verschlüsselung ab dem Arbeitsplatz zu vermeiden.

Im Fall hoher Sicherheitsbedürfnisse wird man daher im Regelfall Verschlüsselung nicht direkt von den Endgeräten der Anwender aus zulassen. Das Ziel typischer Lösungsansätzen ist es vielmehr, die Kommunikation über aktive Server des eigenen Netzes zu leiten, bevor ein irreversibler Verschlüsselungsprozess einsetzt. Zentrale Sicherheits-Appliances auf Servern, die im eigenen Netz platziert sind und die die Kommunikation nach außen herstellen, müssen dabei die Kontrolle über die über die ausgehende Verbindung sowie die ausgetauschten Daten und Inhalte behalten.

Entsprechende Lösungsansätze bestehen im Fall von E-Mail darin, Mailverschlüsselung erst ab einem und über einen zentralen Mailserver zuzulassen und automatisiert sowie in Abhängigkeit von den Empfängeradressen durchzuführen. Die Verbindung zwischen Enduser-PC und Mailserver verbleibt dabei unverschlüsselt – oder wird mit eigenen Schlüsseln geregelt, die an den zentralen Servern eine Entschlüsselung der Inhalte erlauben. Die eigenen Server behalten dabei die Kontrolle über die transferierten Inhalte in beide Richtungen. Nicht besonders datenschutzfreundlich bzgl. der Mitarbeiter? Die Frage ist eher, ob private verschlüsselte Mails in Verwaltungsnetzen, in denen hohe Sicherheitsbedarfe gegeben sind, überhaupt etwas zu suchen haben.

Im Fall von HTTP / HTTPS bestehen Lösungswege darin, ausgehende HTTPS-Verbindungen und andere verschlüsselte Verbindungen von User-Geräten entweder zu verbieten oder aber zwischengeschaltete Web-Proxy-Server einzusetzen, die die Verschlüsselung/Entschlüsselung sozusagen als legitimierte “Man-in-the-Middle”-Instanz übernehmen. Proxys müssen dabei die Zertifikate der Zielserver prüfen, den Inhalt der ausgetauschten Datenströme analysieren, protokollieren, etc.. Der User kann dabei evtl. sogar in Richtung Proxy verschlüsseln, aber eben mit Schlüsseln, die mit dem Proxy ausgehandelt werden und nicht mit Schlüsseln für Zielserver im Internet. Der Proxy kann daher Inhalte des Datenstrom entschlüsseln und behält so die Kontrolle über die ausgetauschten Inhalte. Letztere verschlüsselt er dann automatisch neu im Rahmen einer separat aufzubauenden Verbindung mit dem Zielserver im Internet. (Ein verschmerzbarer Nachteil ist, dass der Anwender selbst die Gültigkeit von Zertifikaten der Empfangsstelle nicht direkt kontrollieren kann.)

IVBB und verschlüsselte Verbindungen

Gem. SZ und Heise-Artikel sind verschlüsselte Verbindungen von Anwendern aus dem IVBB nach außen verboten. Gut so! Genau richtig! Das entspricht meinen Erläuterungen von oben. Worin besteht dann das beim Bundeshack laut SZ aufgetretene Problem?

Mail als Kommunikationskanal zu Schad-SW ?

Nun kennen professionelle Angreifer/Hacker/Geheimdienste vermutlich die Verschlüsselungspolitik im IVBB genau. Sie werden sich also intensiv Gedanken darüber gemacht haben, wie sie “Kommunikationskanäle” von einer einmal auf einem angegriffenen IVBB-Gerät implantierten Schad-SW nach außen aufbauen können. Das “unauffällige” und “elegante” Vorgehen, wie die SZ einen Sicherheitsfachmann zitiert, besteht nun wohl darin, ein Mail-Programm als Kommunikationskanal zu nutzen.

Das ist allerdings viel naheliegender als die Presse das
darstellt. E-Mail-Kommunikation wird in Organisationsnetzen womöglich noch weniger unterbunden und von den Zieladressen her eingegrenzt als HTTPS- und HTTP-Verbindungen. Behörden müssen ja auch mit anderen Institutionen des öffentlichen Lebens und ggf. sogar Bürgern kommunizieren. Das ist Teil ihrer Aufgabe.

Ein- und ausgehende dienstliche Mails von und zu Mitarbeitern in Behörden werden aber (hoffentlich) auf die dabei transferierten Inhalte geprüft – u.a. durch Virenscanner – und in besonders sicherheitslastigen Umgebungen (hoffentlich) auch durch intelligentes Scannen der textuellen Inhalte: Eingehende Texte u.a. wegen Spam, ausgehende Texte in Kombination mit der Empfängeradresse u.a. wegen illegitimer Inhalte. Voraussetzung ist wiederum, dass eine evtl. Verschlüsselung der Mails erst ab einem eigenen Ausgangsserver (SMTP-Server) erfolgt.

Was aber, wenn ein Angreifer in den Inhalten einlaufender Mails (durch einfache Sprach- oder Buch-Codes) gar keine Malware oder Spam-Inhalte, sondern gestückelt und über den Text verteilt Kommandos an eine SW unterbringt? Und umgekehrt eine Schad-Software oder ein böswilliger Mitarbeiter ausgehende Geheiminformationen illegalerweise in scheinbar harmlosen Texten oder Bildern einer Mail verbirgt – und die geheimzuhaltenden Informationen nur stückweise über mehrere Mails an unbefugte Empfänger überträgt? So, dass das mengenmäßig nicht auffällt? Dann haben Virenscanner ein Problem. Und wird dann zusätzlich nicht auf “seltsame” Empfangs- und Zieladressen reagiert, so gibt es ein absehbares Sicherheitsloch.

Es braucht dann theoretisch nur noch zwei Zutaten für ein Sicherheits-Desaster:

  1. Die bereits vorhandene, implantierte Schad-SW muss eingehende Mails und/oder deren Anhänge auslesen können.
  2. Die Schad-SW muss eigene Mails kodieren und über zentrale Server zu Zieladressen, die der Angreifer kontrolliert, verschicken können – ohne dass das auffällt.

Wie konnte der Datenabfluss über Mails nach außen eigentlich gelingen?

Der SZ-Artikel hebt vor allem auf die Methodik ab, dass von den Angreifern E-Mails zur Steuerung einer ansonsten autonom lebenden Schad-SW, die in diesem Fall offnbar keine aktiven Verbindungen nach außen aufnahm, genutzt wurde. Ja, das ist in der Tat bemerkenswert – und sollte zu einer anderen Einstellung gegenüber dem Aufbau von Arbeitsplätzen in sicherheitsrelevanten Bereichen führen. Darauf komme ich im zweiten Artikel zurück.

Aber viel naheliegender und kritisch zu betrachten ist doch folgender Punkt:
Der Schaden ist vor allem dadurch entstanden, dass Informationen nach außen geschleust werden konnten. Wir hatten aber festgestellt, dass man in sicherheitsrelevanten Netzen die Kontrolle über alle auslaufende Datenströme und deren Inhalte behalten muss. Deswegen wurde ja im IVBB gerade – zumindest gemäß der SZ – der Aufbau verschlüsselter Verbindungen nach außen unterbunden. Nun würde man annehmen, dass das dann auch für den E-Mail-Kanal gilt. Sprich:

  1. Alle Mails gehen ausschließlich über einen eigenen zentralen Mail-Versand-Server (SMTP-Server). Der direkte Versand von Mails mittels eines Mail-Clients vom Arbeitsplatz aus über andere (externe) SMTP-Server wird durch Firewalls strikt unterbunden.
  2. Der eigene Versandserver kann die Identität des Senders nicht nur anhand der IP-Adressen des Arbeitsplatz-PCs sondern auch über elektronische Signaturen an den Mailinhalten feststellen. Die intern verwendeten Signaturschlüssel sind natürlich durch Passwörter geschützt …
  3. Der eigene Mailserver kann den Mailinhalt und den Inhalt von Anhängen analysieren, bevor vor dem Versand nach außen eine ggf. erforderliche Verschlüsselung in Richtung Adressat erfolgt. Bereits am Arbeitsplatz-PC verschlüsselte Inhalte werden vor dem Versand erkannt und nicht akzeptiert.
  4. Alle Klartext-Inhalte ausgehender Mails (und deren Anhänge) werden zumindest auf Schlüsselbegriffe und versteckte Botschaften hin analysiert. Die Möglichkeit von kodierten Botschaften in Multimediadateien (Steganographie) wird in Betracht gezogen und geprüft (statistische Analyse oder Vergleiche mit Originalen aus definierten offiziellen Datei-Depots. Unbekannte Multimediadateien werden eliminiert.)
  5. Der zentrale Versandserver prüft die Mail-Adresse des Adressaten auf Auffälligkeiten – und stoppt die Mail gegebenenfalls. In diesem Zusammenhang sind von Mitarbeitern ggf. explizite Deklarationen und Freigaben von Ziel-Adressaten in zentralen Listen/Datenbanken einzufordern.

Nun drängt sich – unabhängig von Problemen mit Outlook – der Verdacht auf, dass an einem dieser Punkte etwas schief gegangen sein muss. Oder, dass meine – hoffentlich einsichtige Haupt-Annahme – nicht stimmt und zentrale Mail-Versand-Server und dortige Prüfungen durch die Schad-Software umgangen werden konnten. Was beides peinlich wäre, da alle genannten Punkte grundsätzlicher Natur sind. Entsprechende Schwachpunkte hätten dann ja auch bereits Menschen – z.B. korrupte Angestellte – ausnutzen können. Zu allen oben genannten Punkten fallen einem natürlich noch weitere Unterpunkte und Fragen ein.

Zum ersten Punkt ist zu sagen, dass eine Perimeter-Firewall einen Mailversand über IVBB-externe SMTP-Server natürlich unterbinden muss. Davon ist hoffentlich auszugehen?

Bei Punkt 2 kommt die Frage ins Spiel, wie die Schad-SW überhaupt die ausgehenden Mails konstruiert hat – mit oder ohne Nutzung bzw. steuernde Manipulation von Outlook? Wenn letzteres: Wieso war/ist das überhaupt möglich und zugelassen? Und wieso wird überhaupt ein so anfälliger und durch Dritt-Software unter Windows manipulierbarer Mailclient wie Outlook in einem Netz mit hohen Sicherheitsbedarfen eingesetzt?

Falls die Schad-Software ihre Mails aber autonom verfasst hat: Wieso und wie konnte sie interne Signatur-Schlüssel erfassen? Oder werden im IVBB gar keine internen Signaturen zur Authentizitätsfeststellung der Verfasser vor dem Versand verwendet?

Punkt 4 ist fundamental, aber in der Praxis ggf. problematisch. Aber daran hängt doch irgendwie alles! Das Thema muss sich doch jemand bereits gründlich durchdacht haben – zumindest beim BSI. Ein gestückelter Datenabfluss über versteckte Nachrichten in Texten und Multimedia-Dateien ist doch ein Grund-Risiko, das sich zur Behandlung durch technische Maßnahmen geradezu aufdrängt. Erst recht, wenn man schon richtigerweise ein Verbot verschlüsselter Verbindungen nach außen gegenüber Mitarbeitern durchsetzt, um ausgetauschte Inhalte kontrollieren zu können.

Punkt 5 ist ebenfalls fundamental. Mailversand zu x-beliebigen ungeprüften Empfangsadressen in der Welt erscheint irgendwie als ein “No Go”. Dass es in diesem Kontext nicht reicht zu prüfen, ob es zu einer Mailadresse auch schon mal einen Eingang gab, liegt auf der Hand. Die Gültigkeit einer Adressaten-Adresse muss sich an viel mehr Kriterien festmachen.

An dieser Stelle schließt sich eine weitere interessante Unterfrage an: War die Zieladresse vielleicht gar eine bekannte? Wenn ja, dann würde das bedeuten, dass auch die dortigen Systeme unter Kontrolle von Angreifern liegen und der Hack insgesamt viel größere Ausmaße hat als bislang gedacht.

Zusammenfassend müssen sich die Betreiber des IVBB folgende Fragen gefallen lassen :

  • Wie konnten Mails mit kritischen Inhalten überhaupt an den Angreifer versandt werden? Welche Lücken wurden da ausgenutzt? Sind diese Lücken ggf. von allgemeinem öffentlichen Interesse, weil sie mit Schwachpunkten der SW Outlook und/oder bestimmter Mailserver zu tun haben?
  • Wieso und wie haben andere befreundete Geheimdienste das mitbekommen? Waren die in der Lage die Mails abzufangen und die Kritikalität der Inhalte zu erkennen? Wieso? Und
    wieso die IVBB-Betreiber nicht?
  • Im Kontext von E-Geovernment in Deutschland tauchen regelmäßig die Themen “verschlüsselnde OSCI-Infrastruktur” (s. Wikipeadia zu Online-Services-Computer-Interface), “Virtuelle Poststelle des Bundes”, “Governikus-Server” (https://www.governikus.de/ anwendung-des-it-planungsrates/faqs-zur-anwendung-governikus/ und Governikus-Portfolioueberblick-Juni2017-Einzelseiten.pdf) u.a. in der Funktion als sichere Mail-Gateways ins Internet auf. Wie passen die offenbar vorhandenen Lücken und Defizite eigentlich damit zusammen?

Bzgl. des letzten Punkts ist auch interessant, dass 2017 Sicherheitslücken im OSCI-Transport-Protokoll festgestellt wurden.

Es sollte nun hinreichend klar geworden sein, dass es beim Bundeshack nicht allein um Schwächen von Outlook geht.

Nachtrag 23.03.2018:
Zwei Nachrichten passen gut zum Kern der obigen Ausführungen:
http://www.sueddeutsche.de/ digital/ attacke-auf-auswaertiges-amt-die-geschichte-eines-cyber-angriffs-1.3917502
Tja, irgendwie peinlich, dass ein ausländischer Nachrichtendienst verdächtige Mails aus dem eigenen Netz entdeckt. Dass einer eigenen Überwachung gesetzliche Hindernisse im Wege stehen könnten, dürfte wohl bei Scans nach selbst versandten Mails, eigenen IP-Adressen und zugehörigen Mustern kein Argument sein.

Bzgl. des Bezugs zu proprietärer Software ist folgender Artikel interessant:
https://www.heise.de/ix/meldung/Bund-will-Windows-10-ueber-Bundesclient-sicher-nutzen-koennen-3907088.html
Ich finde es beunruhigend, wenn man Desktop-Systeme von Spezialkräften aus Sicherheitsgründen so hinbiegen lassen muss, dass sie für die Verwaltung geeignete sind und eine Überwachung von Datenströmen zwischen Clients und Servern (s.o.) überhaupt erlauben.

Im nächsten Beitrag befasse ich mich ein wenig mit der Frage, ob ein Standard-Arbeitsplatz, bei dem Mail, Dateibearbeitung, Internet-Browsing durch Programme einer Desktop-Umgebung abgewickelt werden, überhaupt noch zeitgemäß und höchsten Sicherheitsanforderungen in Behörden angemessen ist.

KVM – virtuelles Netzwerk, libvirt, IP-Forwarding auf dem Host und die Susefirewall2

Posted on by

Hinweis:
Der nachfolgende Artikel wurde am 21.02.2017 vollständig überarbeitet – ein von mir am 20.02.2017 als Problem dargestelltes Verhalten der “Susefirewall2” im Zusammenspiel mit “libvirtd” halte ich nun für korrekt und angemessen. Ich konnte das am gestrigen Abend in einem Anfall von geistiger Umnachtung nur nicht sofort richtig einordnen. Aber auch aus der eigenen Vergesslichkeit kann man ja was lernen ….

Virtuelles Netzwerk mit “virt-manager”

Ich habe gestern probeweise einen KVM-Gast (Kali) unter Opensuse Leap 42.3 installiert. Das von der KVM-Instanz zu nutzende virtuelle Netzwerk namens “deb” hatte ich mit Hilfe von “virt-manager” als “Isolated network, internal and host routing only” aufgesetzt. In diesem Fall für ein C-Netz 192.168.10.0/24.

Die korrespondierende Definitionsdatei “/etc/libvirt/networks/deb.xml” sieht dann wie folgt aus 

mytux:/etc/libvirt/qemu/networks # cat deb.xml 
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit kali
or other application using the libvirt API.
-->

<network>
  <name>deb</name>
  <uuid>8a344aae-20c0-436b-b2a6-daf4d1d10e90</uuid>
  <bridge name='virbr3' stp='on' delay='0'/>
  <mac address='52:54:00:bf:4f:73'/>
  <domain name='kali'/>
  <ip address='192.168.10.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.10.10' end='192.168.50.254'/>
    </dhcp>
  </ip>
</network>

Für jemanden, der sich mit virtuellen Netzwerken auskennt, erscheint an dieser Stelle klar, dass auf dem Host eine virtuelle Bridge (in meinem Fall “virbr3”) implementiert wird, die eine IP-Adresse auf dem Host erhält (192.168.10.1; Device virbr3-nic). Virtuelle KVM Gast-Maschinen, die das eben definierte virtuelle Netz nutzen, erhalten dann je ein virtuelles Netzwerk-Device (vnetx, x=0,1,2 …), welches an die Bridge angebunden wird. Ebenso klar ist, dass das neue Netzwerk ohne IP-Forwarding auf dem Host nur den Host selbst erreichen wird.

Im laufenden Betrieb meines KVM-Gastes sieht das dann auf dem Host so aus: 

mytux:/etc/sysconfig # brctl show virbr3
bridge name     bridge id               STP enabled     interfaces
virbr3          8000.525400026902       yes             virbr3-nic
                                                        vnet0

In meinem Fall sollte die virtuelle Maschine über einen Gateway-Rechner des realen Netzwerks (z.B. 192.168.90.0/24) ins Internet dürfen. Auf dem KVM-Host selbst hatte ich entsprechende Routes angelegt und das IP-Forwarding aktiviert. In Firewall-Regeln auf dem KVM-Host wie dem Gateway wurde der Paket-Transport zwischen den Netzwerken zunächst vollständig zugelassen.

Eine interessante Frage ist nun: Reicht das erstmal? Oder aber: Ist das virtuelle Netzwerk wirklich “isoliert”?

Meine Erwartung aus früheren Installationen war: Nein – sobald das Forwarding auf dem KVM-Host aktiviert ist, erreicht das Gastsystem den Gateway und auch das Internet.

Isoliert oder nicht isoliert – das war dann die Frage …

Auf einem KVM-Host nutze ich normalerweise ein IPtables-Paketfilter-Setup (Skript) mit selbst definierten Regeln. Diese Regeln werden über eine systemd-Unit nach dem Starten von libvirtd über ein Skript geladen. Dabei werden alle evtl. bereits existierenden Regeln verworfen und ersetzt.

Ein Test ergab: Mit meinen eigenen selektiven “Iptables”-Regeln funktionierte das Forwarding auf dem KVM-Host anstandslos. Erlaubte Web-Server im Internet konnten vom KVM-Gast problemfrei angesprochen
werden.

Meine KVM-Maschine soll später allerdings auf einem Host zum Einsatz kommen, auf dem eine Susefirewall2 läuft. Deswegen deaktivierte ich in einem weiteren Test mal mein eigenes Firewall-Skript und griff auf die “Susefirewall2” zurück. Die hatte ich über Einträge in der Datei “/etc/sysconfig/SuSEfirewall2” so konfiguriert, dass ein Fowarding/Routing zwischen den betroffenen Netzen erlaubt wurde; relevant hierfür ist die Zeile: 

FW_FORWARD="192.168.90.0/24,192.168.10.0/24 192.168.10.0/24,192.168.90.0/24"

Nach einem Neustart des Hosts rieb ich mir dann aber zunächst die Augen:

Pings der virtuellen Maschine in Richtung Gateway und umgekehrt erreichten nicht ihr Ziel.

Das trieb mich gestern zunächst in die Verzweiflung. Nach einem Abschalten von IPtables und nach einem testweisen Laden eigener Regeln lief nämlich alles wieder wie erwartet. Ein nachfolgender Start der Susefirewall2 blockierte dagegen erneut die Verbindung des KVM-Gastes zum Gateway. Das virtuelle Netzwerk wurde durch die Susefirewall2 faktisch isoliert.

Ein detailiertes Verfolgen der Pakete mit Wireshark zeigte dann, dass das Forwarding auf dem Host nicht funktionierte, sondern zu Reject-Meldungen der Art “icmp-port-unreachable” führte. Ein erster Blick in die generierten Firewall-Regeln brachte gestern Abend zunächst keine sinnvollen Erkenntnisse, da zu komplex.

Neudefinition des virtuellen Netzwerks mit virt-manager

In meiner Not versuchte ich das virtuelle Netzwerk mit “virt-manager” neu anzulegen. Dabei erreicht man zwischenzeitlich die Seite 4 des Setup-Dialogs:

Wegen meines Problems entschied ich mich diesmal testweise für ein nicht-isoliertes Netzwerk – sondern für ein “Routed network”:

Danach: Neustart von libvirtd mittels “systemctl restart libvirtd” und Neustarten der Susefirewall2 über YaST:

Und, oh Wunder: Danach lief die Verbindung meines KVM-Hostes ins Internet!

Die Botschaft dieses Experiments war also, dass die Susefirewall2 Einstellungen des Isolationslevels für virtuelle Netzes, die mit virt-manager/libvirt definiert wurden, aufgreift!

libvirt generiert IPtables-Regeln

Heute früh wurde mir beim Aufwachen dann klar, was ich gestern beim Testen übersehen (besser:vergessen) hatte: Das Gespann “virt-manager/libvirt” generiert im Zuge der Generierung virtueller Netzwerke selbst IPtables-Regeln zur Umsetzung der verschiedenen Isolationsniveaus:

Legt man ein (virtuelles) “Isolated network” an, stoppt man danach die Susefirewall und startet man anschließend “libvirtd” neu, so zeigt das Kommando “iptables -S” folgenden Output: 

mytux:/etc/sysconfig # iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
.....
-A INPUT -i virbr3 -p udp 
-m udp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 67 -j ACCEPT
...
-A FORWARD -i virbr3 -o virbr3 -j ACCEPT
-A FORWARD -o virbr3 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr3 -j REJECT --reject-with icmp-port-unreachable
..
-A OUTPUT -o virbr3 -p udp -m udp --dport 68 -j ACCEPT

Hier geht also nichts – außer innerhalb des virtuellen Netzwerks, das über die Bridge “virbr3” verköpert wird.

Definiert man dagegen ein “Routed network”, so ergibt sich ein anderer, freundlicherer Regelsatz: 

mytux:/etc/sysconfig # iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i virbr3 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 67 -j ACCEPT
...
-A FORWARD -d 192.168.10.0/24 -o virbr3 -j ACCEPT
-A FORWARD -s 192.168.10.0/24 -i virbr3 -j ACCEPT
-A FORWARD -i virbr3 -o virbr3 -j ACCEPT
-A FORWARD -o virbr3 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr3 -j REJECT --reject-with icmp-port-unreachable
...
-A OUTPUT -o virbr3 -p udp -m udp --dport 68 -j ACCEPT

Ein nachfolgender Start der Susefirewall2 respektiert nun diese Regeln (trotz Änderung der Default-Policy). Ich zeige nachfolgend nur einige relevante Zeilen für den Fall des “Routed network”, in dem die Kommunikation erlaubt wird: 

rux:/etc/sysconfig # iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N forward_ext
-N forward_int
-N input_ext
-N input_int
-N reject_func
-A INPUT -i virbr3 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 67 -j ACCEPT
...
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
...
-A INPUT -j input_ext
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
-A INPUT -j DROP
-A FORWARD -d 192.168.10.0/24 -o virbr3 -j ACCEPT
-A FORWARD -s 192.168.10.0/24 -i virbr3 -j ACCEPT
-A FORWARD -i virbr3 -o virbr3 -j ACCEPT
-A FORWARD -o virbr3 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr3 -j REJECT --reject-with icmp-port-unreachable
...
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
...
-A FORWARD -i virbr3 -j forward_ext
-A FORWARD -i virbr3_nic -j forward_ext
...
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options
-A FORWARD -j DROP
-A OUTPUT -o virbr3 -p udp -m udp --dport 68 -j ACCEPT
...
-A OUTPUT -o lo -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 0 -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 3 -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 11 -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 12 -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 14 -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 18 -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 3/2 -j ACCEPT
-A forward_ext -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 5 -j ACCEPT
-A forward_
ext -s 192.168.90.0/24 -d 192.168.10.0/24 -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-FWDext-ACC-FORW " --log-tcp-options --log-ip-options
-A forward_ext -s 192.168.90.0/24 -d 192.168.10.0/24 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A forward_ext -s 192.168.10.0/24 -d 192.168.90.0/24 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A forward_ext -s 192.168.10.0/24 -d 192.168.90.0/24 -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-FWDext-ACC-FORW " --log-tcp-options --log-ip-options
-A forward_ext -s 192.168.10.0/24 -d 192.168.90.0/24 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A forward_ext -s 192.168.90.0/24 -d 192.168.10.0/24 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A forward_ext -m comment --comment "sfw2.insert.pos" -m pkttype ! --pkt-type unicast -j DROP
-A forward_ext -p tcp -m limit --limit 3/min -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-FWDext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A forward_ext -p icmp -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWDext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A forward_ext -p udp -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-FWDext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A forward_ext -j DROP
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 0 -j ACCEPT
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 3 -j ACCEPT
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 11 -j ACCEPT
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 12 -j ACCEPT
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 14 -j ACCEPT
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 18 -j ACCEPT
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 3/2 -j ACCEPT
-A forward_int -p icmp -m conntrack --ctstate RELATED,ESTABLISHED -m icmp --icmp-type 5 -j ACCEPT
-A forward_int -s 192.168.0.0/24 -d 192.168.10.0/24 -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-FWDint-ACC-FORW " --log-tcp-options --log-ip-options
-A forward_int -s 192.168.90.0/24 -d 192.168.10.0/24 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A forward_int -s 192.168.10.0/24 -d 192.168.90.0/24 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A forward_int -s 192.168.10.0/24 -d 192.168.90.0/24 -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-FWDint-ACC-FORW " --log-tcp-options --log-ip-options
-A forward_int -s 192.168.10.0/24 -d 192.168.90.0/24 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A forward_int -s 192.168.90.0/24 -d 192.168.10.0/24 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A forward_int -m comment --comment "sfw2.insert.pos" -m pkttype ! --pkt-type unicast -j DROP
-A forward_int -p tcp -m limit --limit 3/min -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-FWDint-DROP-DEFLT " --log-tcp-options --log-ip-options
-A forward_int -p icmp -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWDint-DROP-DEFLT " --log-tcp-options --log-ip-options
-A forward_int -p udp -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-FWDint-DROP-DEFLT " --log-tcp-options --log-ip-options
-A forward_int -j reject_func
-A input_ext -p udp -m pkttype --pkt-type broadcast -m udp --dport 5353 -j ACCEPT
..
-A input_ext -m pkttype --pkt-type broadcast -j DROP
...
-A input_ext -s 192.168.10.0/24 -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-INext-ACC-TRUST " --log-tcp-options --log-ip-options
-A input_ext -s 192.168.10.0/24 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
...
-A input_ext -j DROP
-A input_int -j ACCEPT
-A reject_
func -p tcp -j REJECT --reject-with tcp-reset
-A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
-A reject_func -j REJECT --reject-with icmp-proto-unreachable

 
Damit lässt sich mein Befund von gestern Abend ganz einfach erklären:

Mein eigener Regelsatz löschte zunächst alle vordefinierten Regeln von “libvirt” und erlaubte das Forwarding über den Gateway in jedem Fall. Im Falle eines Starts der Susefirewall2 und eines “Isolated network” respektiert die Susefirewall2 die blockierenden Regeln, die über “virt-manager/libvirt” für das virtuelle Netzwerk vorgegeben wurden. Dito im positiven Fall des “Routed network”.

Merke:

Die “Susefirewall2” setzt die IPtables-Regeln von “virt-manager/libvirtd” für virtuelle Netzwerke nicht außer Kraft!

So simpel; man muss sich halt nur daran erinnern. Nachdem nun das Grundsätzliche geklärt ist, kann ich endlich spezifischere, engmaschigere IPtables-Regeln mit der Susefirewall2 für den eigentlichen Zielhost meiner virtuellen Maschine festlegen. In meinem eigenen Netz nutze ich dagegen lieber weiterhin meine eigenen Firewall-Skripte … und vergesse hoffentlich nicht mehr, welche grundsätzlichen Unterschiede das im Vergleich zur Susefirewall2 nach sich zieht und warum.

Upgrade auf Opensuse Leap 42.3 – Nvidia Problem

Posted on by

Ende Januar sind die letzten Nachzügler in meinem Umfeld von Opensuse Leap 42.2. auf Leap 42.3 upgegradet worden. Bei zwei Desktop-Systemen ist mir dabei noch ein unangenehmer Nebeneffekt des proprietären Nvidia-Treibers aufgefallen.

Auf dem ursprünglichen “Opensuse Leap 42.2”-System war zum damals aktuellsten Kernel 4.4.104 der Nvidia-Treiber in der Version 384.98 installiert worden – aus der von Nvidia heruntergeladenen Datei “NVIDIA-Linux-x86_64-384.98.run”.

Nach dem Upgrade mit zypper etc. (s. hierzu https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/) hatte ich erwartet, dass das neue Leap 42.3-System maximal in den Konsolenmodus hochfahren und die grafische Oberfläche nicht anzeigen würde.

(Den Konsolenmodus erreicht man auch unter systemd üblicherweise durch Eingabe von “init 3″ auf der Kommandozeile oder durch Angabe des Kernelparameters ” 3″ beim Booten. Auf das Starten des grafischen Targets wird dann verzichtet.)

Eine Neukompilation des Treibers ist nach Kerneländerungen ja Standard – und unter Leap 42.3 war die Kernel-Version 4.4.114 gegeben. Zudem wusste ich von früheren Upgrade-Versuchen bereits: Beim Upgrade wird aus unerfindlichen Gründen das Paket “drm-kmp-default” für “back-ported drm kernel modules” installiert, welches aber nicht mit den ansonsten installierten “drm”-Bibliotheken und auch nicht zusammen mit den aktualisierten Kernel-Versionen (> 4.4.79) funktioniert.

Man kam denn auch nur in eine Art Konsolenmodus (unter Opensuse auf tty1). Leider flackerte das angezeigte Terminal aber unaufhörlich; es war mir dabei nicht möglich, normale Tastatureingaben zu machen. Das System befand sich in einem Zwischenzustand zwischen “init 3” und dem vollen grafischen Target (“init 5”) von systemd. Bzw.: Wechselte laufend zwischen beiden Modi hin und her. Äußerst übel – und sicher auch nicht gerade förderlich für die HW des Schirms! Den schaltete ich dann erstmal zur Sicherheit ab.

Ich konnte das Problem nur beheben, indem ich mich von einem anderen System aus per SSH als root anmeldete und dann (remote) am Prompt “init 3” eingab. Das führte dann auch am Schirm des betroffenen Systems zu einem benutzbaren Zustand auf der Konsole.

Die nächsten Schritte bestanden dann im Aufruf von “yast”, um erstens das Paket “drm-kmp-default” zu deinstallieren und dann eine Neuinstallation des Nvidia-Treibers vorzunehmen. Was schließlich zu einem reibungslosen Systemstart in den grafischen Modus führte.

Ich habe nicht getestet, ob alternativ ein Neustart unter Auswahl des “Wiederherstellungsmodus” über das Submenu von Grub2 geholfen hätte. Ich vermute das, weiß es aber nicht.

Eine Variante, die man bei Auftreten des “Flacker-Problems” auch ausprobieren sollte, ist: Mehrfach mit “Ctrl-Alt-Delete” einen Neustart erzwingen. Dann den Grub-Editor vor dem Booten (Taste “e”) nutzen und an die Startzeile den Kernelparameter ” 3″ anhängen.

Also liebe Opensuse- und Nvidia-Fans:
Ihr seid gewarnt! Vielleicht ist es eine gute Idee, vor dem Upgrade den proprietären Nvidia-Treiber zuerst zu deinstallieren (NVIDIA-Linux-x86-384.98.run –uninstall) und sich auf den “nv”-Treiber zurückzuziehen.

Upgrade-Zeit – Vorsorge durch Fallback-Installationen – II

Posted on by

Im letzten Beitrag
Upgrade-Zeit – Vorsorge durch Fallback-Installationen – I
hatte ich versucht darzustellen, wie man mehrere parallele, bootfähige Linux-Installationen auf einem Einzelplatzsystem (PC, Laptop) nutzen kann, um die Arbeitsfähigkeit im Fall von Update/Upgrade-Problemen zu sichern. Man arbeitet normalerweise auf einer “Hauptinstallation“, die zu einer bestimmten Partition (z.B. “/dev/sdf7”) gehört.

Eine Fallback-Installation auf einer separaten Partition (z.B. “/dev/sdf9”) wird dagegen zu geeigneten Zeitpunkten als Abbild (Partitionskopie) eines funktionierenden Zustands der Hauptinstallation erzeugt und danach hinsichtlich von Updates extrem konservativ behandelt.

Updates/Upgrades werden grundsätzlich erst in einer dritten “Experimental-Installation” (z.B. auf “/dev/sdf3”) für Experimente getestet, bevor sie in der Hauptinstallation nachgezogen werden.

Nutz- und Projektdaten des/der Anwender werden dagegen auf speziellen Datenpartitionen untergebracht, die man in den jeweiligen Installationen bei oder nach einem Bootvorgang auf vorgegebene Knoten des Verzeichnisbaumes mountet. Das geschieht auf Basis gleichartiger Einträge für die Datenpartition(en) in den “/etc/fstab”-Dateien der verschiedenen Installationen; z.B.

myexp:~ # cat /etc/fstab
...
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....

Diese Einträge werden beim Kopieren der entstehen im Rahmen der Erstellung der Fallback- und Experimental-Installation als Kopie der Hauptinstallation automatisch übernommen.

Ablauf zur Erstellung und Nutzung der Fallback- und der Experimental-Installation

Der Ablauf zur Erstellung und Nutzung der verschiedenen Installationen (auf jeweils unterschiedlichen Partitionen) ist in folgender Abbildung dargestellt:

Die Kuchendiagramme deuten die (wachsende) Partitionsverteilung an. Wir gehen nachfolgend auf einige wichtige Punkte ein, die bei der Erstellung von Partitionskopien als Grundlage der Fallback- und Experimental-Installation zu beachten sind.

Erstimplementierung Hauptinstallation plus Rettungssystem/Minimalinstallation

Die Erst-Installation eines Linux-Systems (z.B. Opensuse Leap 42.2) erfolgt wie üblich aus dem Netz oder per DVD. Man richtet dann seine Datenpartitionen ein und legt zugehörige Mount-Einträge in der “/etc/fstab” fest. Unter Opensuse unterstützt einen dabei der YaST-Partitioner. Dann “gewöhnt” man sich an das neue System und führt erste sinnvolle Updates durch.

Für die Erstellung der Fallback-Installation wollen wir den Inhalt der Partition, die die Hauptinstallation in einem definierten Zustand enthält, in eine andere (freie) Partition kopieren. Eine Kopie des gemounteten Root-Filesystems kann und sollte aber nicht aus der laufenden Hauptinstallation heraus erstellt werden. Der Grund ist einfach: Während der Kopie würden im Hintergrund stattfindende Schreiboperationen beim Kopieren nicht konsistent abgebildet werden. Das gleiche Thema gibt es ja bereits für Backups.

Wir benötigen daher eine weitere unabhängige Minimalinstallation (ohne grafischen Schnickschnack) in einer separaten Partition. Das dortige System booten wir dann zum Erstellen von Kopien anderer nicht gemounteter Partitionen. Alternativ können wir zum Kopieren natürlich auch ein ein Linux-Live-System einsetzen. Für Opensuse
Tumbleweed existieren entsprechende ISO-Images (siehe https://de.opensuse.org/openSUSE:Tumbleweed_installation).

Eine andere Alternative bietet ein Rettungssystem, wie es auf Installations-DVDs etlicher Distributionen vorhanden ist. Ein Rettungs- oder Live-System ist aber auch leicht zu erstellen (s. etwa http://www.system-rescue-cd.org/Download/, https://en.opensuse.org/SDB:Live_USB_stick, https://linux-club.de/wiki/opensuse/Installationsmedien_zu_openSUSE).

Hat man später bereits eine Experimental-Installation angelegt, so kann man natürlich auch die einsetzen, um die Partition der Hauptinstallation für eine Fallback-Installation auf eine andere Partition zu kopieren.

Partition für Kopie der Hauptinstallation erstellen

Eine Fallback-Installation entsteht am einfachsten durch Kopie der Partition mit der Hauptinstallation auf eine andere (Ziel-) Partition – und einige nachfolgende Schritte. Die Ziel-Partition muss man natürlich vor dem Kopiervorgang angelegt haben. Hierbei ist folgender Punkt wichtig:

Die Zielpartition muss mindestens die gleiche Größe haben wie die Original-Partition; die Zielpartition kann aber auch größer sein. Das gewährleistet man bei der Erstellung durch geeignete Wahl des Start- und Zielsektors (bzw. des Start- und End-Zylinders). Die Differenz – also die Anzahl der Sektoren (bzw. Zylinder) in der Zielpartition – sollte den gleichen Wert haben wie beim Original.

(Das Zusammenfallen von Partitionsgrenzen mit Zylindergrenzen ist ein Spezialthema für HDs mit MBR und sog. CHS-Adressierung; ich kann hier nicht darauf eingehen. Partitionierungstools achten in der Regel bei der Partitionsanlage auf eine entsprechende Optimierung. Auf Platten mit GPT-Partitionstabelle und LBA-Adressierung operiert man sehr viel einfacher mit Sektoren.)

Es gibt eine Reihe von Tools, um Partitionen aufzulisten, anzulegen und zu verändern. Für Opensuse hatten wir ja schon den “YaST-Partitioner” erwähnt. Interessanterweise bietet dieses Tool eine Dimensionierung neuer GPT-Partitionen über die Eingabe von Start/End-Zylinder an. Ein distributionsübergreifendes grafisches Tool ist “gparted” (welches auf dem CLI-Tool “parted” aufsetzt). gparted unterstützt natürlich GPT-HDs/SSDs und zeigt Start- und End-Sektoren für Partitionen an.

Daneben findet sich das CLI-Tool “fdisk“, das inzwischen auch mit GPT-Disks umgehen kann. Speziell für GPT-HDs/SSDS ist das CLI-Tool “gdisk” gedacht. Auch mit gdisk können wir die Größe neuer Partitionen präzise über Angaben zu Sektoren festlegen.

Die Sektor-Information sieht z.B. für zwei gleich große Partitionen “dev/sdf3”, “/dev/sdf7” einer Platte “/dev/sdf” unter fdisk wie folgt aus: 

myexp:~ # fdisk -l /dev/sdf
Disk /dev/sdf: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 04AD1B2B-6934-444D-BD93-83FE4A3AE15C

Device         Start       End   Sectors  Size Type
...
/dev/sdf3  171960320 339742719 167782400   80G Linux filesystem
...
/dev/sdf7  507590656 675373055 167782400   80G Linux filesystem

Ich ziehe auf GPT-Platten für eine präzise Dimensionierung jedoch meist “gdisk”
heran: 

myexp:~ # gdisk -l /dev/sdf 
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 286739053 sectors (136.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   ....
   3       171960320       339742719   80.0 GiB    8300  primary
   ....
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
myexp:~ #
myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-8): 7
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 85C6892A-D709-4A3F-9758-D521A7A11F68
First sector: 507590656 (at 242.0 GiB)
Last sector: 675373055 (at 322.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Command (? for help): i
Partition number (1-8): 3
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 4C6C4872-1C36-465A-A09F-7CC0EF542E4D
First sector: 171960320 (at 82.0 GiB)
Last sector: 339742719 (at 162.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Wie erstellt man nun eine weitere neue Partition mit identischer Größe? Wir machen das mal versuchsweise mit “gdisk”; dort gibt es dafür das Subkommando “n” (für “new”). Ein Blick in die man-Seiten zu “gdisk” zeigt übrigens auch, dass Änderungen erst dann wirksam werden, wenn wir unter gdisk abschließend den “w”-Befehl absetzen. 

myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
... 
Found valid GPT with protective MBR; using GPT.
Command (? for help): n
Partition number (9-128, default 9): 
First sector (34-1000215182, default = 717672448) or {+-}size{KMGTP}: 
Last sector (717672448-1000215182, default = 1000215182) or {+-}size{KMGTP}: +167782400
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 118956653 sectors (56.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   ...
   3       171960320       339742719   80.0 GiB    8300  primary
   ...
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
   9       717672448       885454847   80.0 GiB    8300  Linux filesystem

Command (? for help): i
Partition number (1-9): 9
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 696C551B-591D-4411-A951-18D337F548D9
First sector: 717672448 (
at 342.2 GiB)
Last sector: 885454847 (at 422.2 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'Linux filesystem'

Command (? for help): q

Man beachte hier die GUID, die eine Partition in eindeutiger Weise auf einem Device identifiziert. Die GUID ist von einer sog. “UUID” des Filesystems (s.u.) in einer Partition zu unterscheiden !

Schreibt man die geänderte Partitionstabelle im letzten Schritt tatsächlich mit “w” auf die Platte, informiert “gdisk” den laufenden Kernel nicht über die Änderungen! Das geschähe ohne weitere Maßnahmen erst bei einem Reboot. Will man das vermeiden, hilft das CLI-Kommando “partprobe“, das zusammen mit dem Tool “parted” installiert wird. 

myexp:~ # partprobe /dev/sdf

es geht alternativ auch 

myexp:~ # /sbin/blockdev --rereadpt /dev/sdf

Kopieren der Partition mit der Hauptinstallation mit Hilfe des CLI-Kommandos “dd”

Ein “geeigneter Zeitpunkt” zum Erstellen einer Kopie der Hauptinstallation ergibt sich im laufenden Betrieb im Zuge von Updates nach einer Phase zufriedenstellender täglicher Arbeit. Steht man vor einer Upgrade-Aktion für sein Linux-System, wird man die laufende Hauptinstallation in jedem Fall kopieren und daraus eine bootfähige Fallback-Installation herstellen.

Für eine bitweise Kopie ist der Einsatz des CLI-Kommandos “dd” am einfachsten. Siehe zu einer Einführung bzgl. “dd” etwa https://wiki.ubuntuusers.de/dd/ und https://wiki.archlinux.de/title/Dd). “dd” ist unter Linux ein wirkliches wichtiges Werkzeug, das man in Kombination mit “gzip” und “tar” nicht zuletzt auch für die Erzeugung von Updates nutzen kann! Man sehe sich also zu “dd” unbedingt mal die man-Seiten und auch unten angegebene Links an.

Nehmen wir an, unsere aktuell benutzte Hauptinstallation liegt auf einer Partition “/dev/sdf7”. Auf der gleichen Platte befinde sich bereits eine Partition “dev/sdf9” gleicher Größe (man prüfe hierzu die Sektor- oder Zylinderanzahl in einem Partitionierungstool; s.o.). Aktuell gebootet worden sei eine Installation auf einer Partition “/dev/sdax” (x im Beispiel ungleich 7 oder 9) oder eben ein Live- oder Rettungs-System. Im gebooteten System erreicht man dann eine bitweise Kopie von “/dev/sdf7” auf “/dev/sdf9” per 

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M

Zum Parameter “bs” siehe die man-Seiten! Auf einer optimal angebundenen SSD dauert ein solcher Kopier-Prozess für eine “80 GByte”-Partition deutlich weniger als 10 Minuten. 

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M
81925+0 records in
81925+0 records out
85904588800 bytes (86 GB, 80 GiB) copied, 418.97 s, 205 MB/s

Die SSD operiert hier mit ca. 400 MB/s, da sie ja lesen und schreiben muss.

Haben wir damit schon unsere gewünschte “Fallback-Installation” erstellt? Da wir ja mit der Partition auch das dortige Filesystem samt Inhalten bitweise kopiert haben, könnte man meinen, dass mit der Kopie schon alles erledigt sei – und man nur noch den Bootmanager “Grub2” unter Einbeziehung aller verfügbaren OS-Installationen (z.B. mittels YaST2 >> Bootloader” neu schreiben lassen muss.

Das ist ein gewaltiger Irrtum!:

Warnung: Bitte schreibt nach Kopie einer Partition mit einer Betriebssysteminstallation nicht den Boot-Manager neu – und schon gar nicht unter Einbeziehung aller bootbaren Filesysteme.

Warum? Die Antwort gibt der nächste Abschnitt …

Vermeidung gleicher UUIDs
verschiedener Filesysteme nach dem Kopieren von Partitionen

Wenn wir eine Partition bitweise kopieren, wird der gesamte Inhalt (Filesystem + dessen Inhalte) 1:1 in die Zielpartition übertragen. Jedes Filesystem hat nun aber eine ID, die sog. “UUID“, die in einem System eindeutig sein sollte.

Die UUID eine Filesystems ist eine (hoffentlich eindeutige) Kombination aus alphanumerischen Zeichen. S. die nachfolgende Abbildung:

Die UUID vorhandener Partitionen kann man sich mit vielen Partitionstools und auch dem Kommando “tune2fs” anzeigen lassen. Ein geeignetes Kommando für die Kommandozeile ist aber auch “blkid“. Testet man unmittelbar nach unserem Kopiervorgang von “/dev/sdf7” auf “/dev/sdf9”, so erhält man 

myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Diese leider von uns selbst erzeugte Uneindeutigkeit hat nach dem Kopiervorgang noch keine unmittelbaren Folgen. Der Befund ist aber dennoch außerordentlich problematisch, denn es gilt:

Aktuelle Linux-Distributionen identifizieren zu mountende oder im Bootprozess anzusprechende Filesysteme (bzw. Partitionen) nämlich genau über die “UUID”.

Siehe zu der Thematik auch: https://wiki.ubuntuusers.de/UUID/. Unter Opensuses “YaST Partitioner” gibt es hierzu übrigens eine Grundeinstellung, die man auch modifizieren kann:

Unter Linux steuert u.a. die Datei “/etc/fstab” bekanntermaßen das Mounten von Filesystemen – u.a. auch des root-Filesystems – in bestimmten Phasen des Systemstart mit. Werden nun die zu mountenden Filesysteme (Partitionen) in der Datei “/etc/fstab” tatsächlich durch UUIDs gekennzeichnet, können schon beim nächsten Bootvorgang ernsthafte Probleme auftreten; es gibt nach unserer Partitionskopie mittels “dd” ja zwei Filesysteme mit derselben UUID!

Noch schlimmer werden die Verhältnisse, wenn wir auch noch die Grub2-Konfiguration unter Einschluss aller bootbaren Installation updaten; das ist dann ein sicherer Weg in den Abgrund; mit Doppelmounts auf “/” und nachfolgenden Katastrophen ist zu rechnen!

Deshalb gilt:

Warnung: Bevor man irgendetwas nach dem bitweisen Kopieren einer Partition in einen andere auf dem Datenträger ein und desselben aktiven Systems unternimmt, sollte man unbedingt die UUID des kopierten Filesystems ändern, sowie die Einträge in den dortigen Dateien “/etc/fstab” und “/boot/grub(2)/grub.cfg” an die neue Situation anpassen.
Nur dann werden wir die kopierten Installationen auch ohne Probleme bootfähig zu bekommen! Auf keinen Fall sollte man vor Erledigung dieser Schritte im aktuell gebooteten System die Bootloader-Konfiguration neu schreiben lassen.

Ändern der UUID im Filesystem der kopierten Partition

Wie ändert man die UUID eines (kopierten) Filesystems? Hierzu braucht man zwei Schritte:

  • Schritt 1: Generieren einer neuen UUID mittels des Befehls “uuidgen“
  • Schritt 2: Ändern der UUID auf der kopierten Partition mittels des Kommandos “tune2fs device -U newUUID“

Wir führen das mal am Beispiel unseres kopierten Filesystem auf der Partition “/dev/sdf9” durch: 

myexp:~ # uuidgen 
a65d6a9b-cc87-4af7-95bf-f407f463f344
myexp:~ # tune2fs /dev/sdf9  -U a65d6a9b-cc87-4af7-95bf-f407f463f344
tune2fs 1.42.11 (09-Jul-2014)
myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="a65d6a9b-cc87-4af7-95bf-f407f463f344" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Damit sind wir aber keineswegs fertig …

Anpassen der Datei “/etc/fstab” und der “/boot/grub2/grub.cfg” im kopierten Filesystem

Bevor wir den Bootloader neu schreiben lassen, ändern wir zunächst die Dateieen “/etc/fstab” und zur Sicherheit auch der “/boot/grub2/grub.cfg” ab. Hierzu mounten wir das frisch kopierte Filesystem im aktuell gebooteten System – z.B. auf “/mnt” -und ersetzen in der dortigen “fstab” (also in der /mnt/etc/fstab”) die Einträge mit der alten UUID:

myexp:~ # mount /dev/sdf9 /mnt
myexp:~ # cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....
....

Problematisch ist vor allem der zweite Eintrag, der noch die kopierte UUID beinhaltet! Diese UUID ändern wir nun mit Hile eines Editors unserer Wahl auf die neue – per uuigen generierte und per tune2fs zugeordnete – UUID ab: 

# cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=a65d6a9b-cc87-4af7-95bf-f407f463f344       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....

Damit haben wir schon mal größeres Unglück verhindert. Eine Anpassung der “/etc/fstab” ist der wichtigste Schritt.

Ganz auf die sichere Seite gegenüber späteren manuell verursachten Fehlern kommen wir aber erst mit entsprechenden Änderungen in der Datei “/mnt/boot/grub2/grub.cfg” – oder aber einer Elimination der Datei für das (versehentliche) Schreiben des Bootloaders unter der neuen Installationm. .

In der “/mnt/boot/grub2/grub.cfg” finden sich Boot-Einträge der Form 

menuentry 'openSUSE 42.2 (x86_64) (on /dev/sdf7)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-96c9a3bf-60fe-496e-801c-3a3047ac71a9' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt7 --hint-efi=hd5,gpt7 --hint-baremetal=ahci5,gpt7  96c9a3bf-60fe-496e-801c-3a3047ac71a9
	else
	  search --no-floppy --fs-uuid --set=root 96c9a3bf-60fe-496e-801c-3a3047ac71a9
	fi
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9 ro resume=/dev/disk/by-uuid/d9a73a89-b89b-4fda-8c4c-9034e42d1274 splash=silent quiet showopts elevator=deadline intel_pstate=disable swapaccount=1 pti=on
	initrdefi /boot/initrd-4.4.104-18.44-default
}
submenu 'Advanced options ......
....
......

Würden wir diese “grub.cfg” (nach einem Booten der kopierten Installation) dummerweise direkt zur Implementierung des
Bootloaders per “grub-install” nutzen, gäbe es ein vermeidbares Chaos.

In der Datei müssen wir deshalb natürlich alle Strings “96c9a3bf-60fe-496e-801c-3a3047ac71a9” ersetzen durch “a65d6a9b-cc87-4af7-95bf-f407f463f344”. Das geht mit Editoren wie “kate” relativ gefahrlos.

Ein noch einfacherer Schritt zur Absicherung gegenüber späteren potentiellen Unglücken durch manuelle Befehle zum Schreiben des Bootloaders ohne vorherige Neugenerierung der “boot.cfg” ist, die Datei schlicht umzubenennen – und damit für versehentliche Installationen auszuschalten: 

    
myexp:~ # mv /mnt/boot/grub2/grub.cfg /mnt/boot/grub2/grub_before_copy_180219.cfg_orig

Bootfähigkeit der neuen Installation herstellen

Natürlich schreiben wir den Bootloader aber eher von der funktionierenden “ursprünglichen” Hauptinstallation aus. Haben wir die “etc/fstab” in er kopierten Partition auf die neue UUID angepasst, können wir – ohne vorheriges Verändern des Grub2-Bootloaders – unser System getrost neu booten und dabei die ursprüngliche Hauptinstallation starten. Von dort aus nehmen wir nun eine Erweiterung des Bootloaders vor, so dass dei neue “Fallback”-Installation später im Grub2-Bootmenü mit angeboten wird.

Unter Opensuse nutzen wir dazu YaST’s Bootloader-Modul:

Dieses Programm bietet 3 per Reiter (Tabs) erreichbare Konfigurationsseiten an. Die letzte ist für unsere Zwecke am wichtigsten und sieht wie folgt aus:

Hier müssen wir die Option “Fremdes OS testen” abhaken.

[Zu alternativen CLI-Kommandos “grub_mkconfig”, “update-grub” (Ubuntu) bzw. “grub2-mkconfig” (Opensuse) und “grub-install” siehe den letzten Beitrag und die Doku eurer Distribution. Unter Opensuse Leap prüft “grub2-mkconfig” durch Aufruf des “os-prober”-Skripts fremde OS gleich mit und schreibt den gesamten Output defaultmäßig in die “/boot/grub2/grub.cfg”.]

Danach finden wir in der Datei “/boot/grub2/boot.cfg” Einträge folgender Art zum Filesystem auf “/dev/sdf9” vor: 

 
....
### BEGIN /etc/grub.d/30_os-prober ###
...
...
menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt9'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  a65d6a9b-cc87-4af7-95bf-f407f463f344
	else
	  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
	fi
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
	initrdefi /boot/initrd-4.4.104-18.44-default
}
submenu 'Erweiterte Optionen für openSUSE 42.2 (x86_64) (auf /dev/sdf9)' $menuentry_id_option 'osprober-gnulinux-advanced-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.4.104-18.44-default--a65d6a9b-cc87-4af7-95bf-f407f463f344' {
		insmod part_gpt
		insmod ext2
		set root='hd5,gpt9'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  
a65d6a9b-cc87-4af7-95bf-f407f463f344
		else
		  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
		fi
		linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
		initrdefi /boot/initrd-4.4.104-18.44-default
	}

Diese Einträge im Boot-Menü hat YaSTs Bootloader-Modul dann auch schon gleich auf der Platte verewigt. Sie werden beim nächsten Bootvorgang mit angeboten.

Damit haben wir unsere durch “dd” erzeugte “Fallback-Installation” auf “/dev/sdf9” bootfähig verankert.

Experimental-Installation und Upgrade

Eine Experimental-Installation” erzeugt man in einer weiteren Partition auf ganz ähnliche Weise wie oben beschreiben und macht auch diese nach UUID-Änderung und Anpassung der dortigen “/etc/fstab” bootfähig. Für die Experimentalinstallation kann man dann eine probeweises Upgrade vornehmen. (Im Beispiel von Opensuse Leap 42.2 auf Leap 42.3 …).

Andere Einstellungen in der “/etc/fstab”

Das “Gefährliche” bestand bei unserem Vorgehen vor allem in der Duplizierung der UUID – und eventuellen diesbezüglichen Einstellungen in der “/etc/fstab”. Natürlich kann man die Einträge in der “/etc/fstab” auch auf Basis konventioneller Laufwerksbezeichnungen (“dev/sdxn”) vornehmen.
Der Yast-Partitioner bietet hierfür sogar eine Einstellungsoption an:

Einträge mit normalwer Bezeichnung sähen so aus: 

 
/dev/sdf9       /       ext4    acl,user_xattr 1 1

Dies befreit aber aus einer Vielzahl von Gründen nicht davon, die UUID des Filesystems trotzdem abzuändern.

SSDs – und Intervalle für Partitionskopien

Eine Kopie größerer Partitionen durchzuführen ist schreibintensiv. Nicht alle SSDs haben eine hinreichende Qualität, um solche Schritte oft durchführen zu können. Die SSD leidet darunter (wear leveling count). Man sollte die Erstellung einer neuen “Fallback-Installation” als Kopie der Hauptinstallation daher nur in größeren Zeitabständen vornehmen.

Hat man gute Erfahrungen mit Updates sowohl in der Experimental-Installation als auch auf der Hauptinstallation gemacht, spricht ja nichts dagegen, Updates auch auf der Fallback-Installation systematisch und kontrolliert nachzuziehen. Nur vor Upgrades erscheint mir die Anlage einer Fallback-Installation als Kopie der aktuellen Hauptinstallation unvermeidlich.

Ich hoffe, der eine oder andere hat beim Lesen ein paar Dinge aufgeschnappt, die er noch nicht kannte …

Links

Übersicht GPT
https://en.wikipedia.org/wiki/GUID_Partition_Table
https://de.wikipedia.org/wiki/GUID_Partition_Table
https://www.thomas-krenn.com/de/wiki/GUID_Partition_Table

Übersicht Linux Partitioning Tools
http://dwaves.de/2017/05/23/linux-overview-partitions-difference-fdisk-gdisk-cfdisk-parted-gparted/

Partition Alignment
https://www.thomas-krenn.com/de/wiki/Partition_Alignment

UUID ändern
http://www.sudo-juice.com/how-to-change-the-uuid-of-a-linux-partition/

Backups mit dd
https://www.linux.com/learn/full-metal-backup-using-dd-command
https://wiki.archlinux.de/title/Image-Erstellung_mit_dd
https://www.thegeekstuff.com/2010/10/dd-command-examples/
http://www.linux-community.de/Archiv/Tipp-der-Woche/Mit-dd-schnell-Festplattenimages-erstellen
https://www.thomas-krenn.com/de/wiki/Dd_unter_Linux

Upgrade-Zeit – Vorsorge durch Fallback-Installationen – I

Posted on by

Vor wenigen Wochen lief bei Opensuse und bei Ubuntu der Supportzeitraum für die jeweils vorletzten Versionen ab. Ein Leser des Blogs hat mich angeschrieben und gebeten, mal für einen Linux-Einsteiger zu beschreiben, wie ich denn bei System-Upgrades “immer wieder auftauchenden Problemen aus dem Weg” ginge.

Erste spontane Antwort: Gar nicht 🙂 ; Probleme tauchen halt auf und sind zu lösen oder zu umgehen. Ich habe die Frage dann aber mal wie folgt interpretiert:

Wie erhält man sich trotz möglicher Upgrade-Probleme die Fähigkeit zum beruflich dringend erforderlichen Weiterarbeiten, wenn es nach dem Upgrade Probleme gibt?

Das ist durchaus ein paar Betrachtungen wert. Gerade Freiberufler können sich Arbeitsausfälle aufgrund “zerschossener” Systeme nicht leisten. Das betrifft bei mobilen Beratern u.a. Laptop-Installationen.

Beim Schreiben fiel mir allerdings auf, dass ich vor Upgrades/Updates alleinstehender Linux-Systeme zu Methoden greife, in die sich ein “Einsteiger” erst mal einarbeiten muss und die selbst auch ein gewisses Gefahrenpotential in sich bergen. Leute, das kann ich euch leider nicht ersparen. Deshalb vorweg:

Bitte seid bei einer Nachahmung der nachfolgenden Vorschläge extrem vorsichtig, macht Backups und testet erstmal in einer risikofreien Umgebung – im Besonderen das Kopieren von Festplatten-Partitionen. Ich hafte nicht bei Schäden.

Ferner benötigt man für meinen Ansatz HDs/SSDs mit 500GB aufwärts; man braucht Plattenplatz. Dennoch hat sich die nachfolgend beschriebene Methodik bewährt; sie hat mir schon des öfteren wertvolle Zeit für Problemlösungen verschafft. Die Vorgehensweise hat aber nur einen Sinn auf Einzelplatz-Systemen; sie ist nicht (!) für Server oder Firmen-Installationen geeignet. Und: Sie ersetzt keineswegs (regelmäßige) Backups auf externe Medien!

Frust nach und mit Upgrades/Updates unter Linux? Ja, das gibt es …

Viele Linux-Einsteiger beschreiben ein gar nicht so seltenes Erlebnis mit ihrem Desktop- oder Laptop-System so: “Dann hab’ ich mein Linux upgedated bzw. upgegradet und dabei wohl was falsch gemacht – und mir das System zerschossen. Musste neu installieren.“. (Siehe u.a. Linux-Foren unter Facebook). Das sollte eigentlich unter Linux nicht so ablaufen … passiert aber dennoch.

Ein Grund ist vermutlich: Für Einsteiger ist schwer zu erkennen, was mögliche Ursachen für das “Zerschießen” sind und wo bzw. wie man die richtigen Maßnahmen zur Korrektur einleitet. Der Wunsch, möglichst schnell wieder arbeiten zu können, führt dann gerade bei Windows-Umsteigern fast reflexartig zu Neuinstallationen.

Was manchmal schon im Zuge komplexer Packet-Updates passiert, gilt erst recht für Linux-System-Upgrades, bei denen womöglich auch noch an Grundfesten des Systems gerüttelt wird (wie etwa bei der Einführung von systemd, neuen KDE-Haupt-Versionrn, etc…). Spätestens nach der ersten schlechten Erfahrung mit einem System-Upgrade stellt man sich beim nächsten Mal Fragen:

Soll ich (nach einer Datensicherung) die neue Linux-Version auf einer neuen oder der bisherigen System-Partition ganz von Null neu installieren? Oder die alte Installation durch komplizierte Schritte auf die neue Version bringen? Mit dem Risiko, dass dabei etwas schiefgeht, das System nicht mehr bootet, man sich nicht mehr einloggen kann oder die graphische Oberfläche nicht mehr läuft? Und man nicht mehr produktiv arbeiten kann?

Das sind alles berechtigte Fragen! Frustrierende Erlebnisse mit System-Komponenten, die nach Updates/Upgrades nicht mehr erwartungsgemäß funktionieren, haben nämlich auch erfahrene Linux-User immer wieder. Glaubt keinem, der etwas anderes behauptet!

Auch unter Linux gilt: Shit happens! Und oft genug liegt die Schuld nicht mal bei einem selbst … Linux
ist halt ein komplexes Konglomerat aus unterschiedlichen Komponenten, die von unterschiedlichen Teams entwickelt werden. Die Zusammenstellung übernehmen Distributoren, die auch nicht jede mögliche Installationsvariante testen können. Hinzu kommen ggf. problematische Treiber, u.a. für Grakas. Ergebnis: Fehler treten häufiger auf, als einem als Linux-Fan lieb wäre ….

Vorsorge und Arbeits-“Continuity”

Erfahrene Linux-Nutzer sorgen vor, indem sie eine funktionierende Arbeitsumgebung vorhalten. Komplette Neuinstallationen sind bei Update-Problemen nur selten der richtige Weg: erstens lernt man durch Neuinstallationen nichts und zweitens besteht die Gefahr, wieder in die gleiche Falle zu tappen. Im Falle von System-Upgrades führt eine Neuinstallation dagegen zum mühsamen Nachziehen von bereits getroffenen Konfigurationsentscheidungen – und ohne Rückgriff auf eine noch funktionierende Installation ist das Arbeiten in dieser Phase ggf. eingeschränkt.

Natürlich denkt man vor Updates/Upgrades an Backups der vorhandenen funktionstüchtigen Installation auf externe Medien. Das setzt voraus, dass man sich mit der Restaurierung ganzer Betriebssysteme und den zugehörigen Linux-Tools befasst. Zu dieser wichtigen Grundübung findet man viele hilfreiche Artikel im Internet. Ich möchte in diesem Artikel aber eine andere, zusätzliche Maßnahme besprechen – und zwar den den Ansatz einer

vorsorgenden Partitionierung – unter Einschluss jederzeit bootbarer “Fallback- und Experimental-Partitionen”.

Das ersetzt (regelmäßige) Backups (u.a. für den Fall vom Plattendefekten) keineswegs, erleichtert aber den Umgang mit komplexen Updates oder System-Upgrades.

Motivation ist die Aufrechterhaltung der Möglichkeit zum schnellen Fortsetzen der produktiven Arbeitfür den Fall, dass beim Updaten/Upgraden etwas schief geht. Man spricht auch von ArbeitsKontinuität oder neudeutsch “Continuity“, die eben die Verfügbarkeit funktionierender Installationen voraussetzt.

Nun höre ich schon die Profis fragen: Schon mal was von Snapshots gehört? Ja, aber der von mir beschriebene Ansatz ist auch dann wirkungsvoll, wenn man sich mit Snapshot-Systemen (wie etwa auf Basis von BtrFS oder LVM2) noch nicht auskennt. Zudem sind Filesystem-Snapshots bei vollständigen System-Upgrades eher in Frage zu stellen.

Voraussetzungen und Zielgruppe

Der Artikel richtet sich an Linux-Ein/Um-Steiger, die schon ein paar Schritte mit dem System gegangen sind und sich bereits ein wenig in Plattenpartitionierung wie den Systemstart über Boot-Manager eingearbeitet haben – oder willens sind, das zu tun. So setze ich voraus,

  • dass man weiß, was Partitionen (oder ggf. LVM-Volumes) und Filesysteme sind, wie man die mit entsprechenden Tools seiner Linux-Distribution oder auf der Kommandozeile erstellt, dimensioniert und in den Hauptverzeichnisbaum einhängt (mounted),
  • dass man bereit ist, sich mit den Befehlen “dd”, “uuidgen” und “tune2fs” auseinanderzusetzen
  • dass man keine Scheu hat, System-Dateien zu editieren.
  • dass man bereit ist, sich ein wenig um Grub2 als Boot-Manager auseinanderzusetzen.
  • dass genügend Festplattenplatz vorhanden ist, um 3 Betriebssystem-Partitionen mit einer Größe von etwa 40 bis 80 GByte aufzunehmen.

Der letzte Punkt mag dem einen oder anderen als Platzverschwendung erscheinen. Ja, das erscheint mir aber in der Abwägung gegenüber dem Punkt “kontinuierliche Arbeitsfähigkeit” und auch gegenüber der Schonung von Nerven zweitrangig.

Übrigens: Bis auf spezielle EFI- und Swap-Partitionen, verwende ich den Begriff “Partition” nachfolgend auch synonym für logische LVM2-Volumes. Das ist technisch natürlich nicht korrekt; der Unterschied tut
hier aber nichts zur Sache. LVM2 ist im besonderen mit dem Grub2-Boot-Manager kompatibel. Wem die Begriffe LVM2 und LVM-Volume nichts sagen, kann deren weitere Erwähnung in Klammern erstmal getrost ignorieren.

Ich erläutere die hier verfolgte Philosophie einer Fallback-Partition für Desktop-Systeme und Laptops anhand von Opensuse. Die Grundprinzipien lassen sich meist aber einfach auf andere Distributionen wie etwa Ubuntu abbilden – auch wenn sich ein paar Bezeichnungen von Dateien oder Programmen leicht unterscheiden. Es geht mir auch nur um alleinstehende Desktop-/Laptop-Systeme, auf denen man weitgehend der Herr des Geschehens ist – nicht aber um Server-Systeme oder server-basierte Installationen; letztere erfordern andere Fallback- und Continuity-Strategien.

Vier Maxime für den Umgang mit Updates/Upgrades

Beim Umgang mit kritischen Updates von Systemkomponenten oder gar Upgrades des Betriebssystems orientiere ich mich an folgenden Leitlinien:

  • Never touch a running system – ohne die Konsequenzen zu kennen oder solide einschätzen zu können.
  • Haupt-Installation und separate Partitionen für Nutz- und Anwendungsdaten: Die Betriebssystem-Installation für den täglichen Gebrauch erfolgt auf einer Festplattenpartition begrenzter Größe. Es wird von vornherein eine getrennte Ablage von OS-System-Dateien einerseits und späteren Projekt-Daten (Applikationsdaten, Nutzerdateien, ggf. Virtualisierungsumgebungen) andererseits auf unterschiedlichen Partitionen (LVM-Volumes) der Systemplatte(n) angestrebt.
  • Fallback-Installation: Im beruflichen Einsatz muss man bei Problemen schnell auf eine noch funktionierende Installation zurückgreifen können – hierzu braucht es eine jederzeit bootbare Fallback-Installation auf einer weiteren, separaten Partition der HD/SSD des Systems.
  • Experimental-Installation: Man braucht eine Spielwiese, um neue Programme, aber auch umfassendere oder kritische Updates/Upgrades gefahrlos ausprobieren zu können. Eine entsprechende dritte Betriebssystem-Installation sollte auf einer weiteren eigenen Partition (Volume) untergebracht werden.

Während die erste Maxime übergreifend gilt, haben die anderen drei offenbar eine Auswirkung auf die Partitionierung (und/oder das LVM-Layout) des Systems. Die “Methodik” zur Erhaltung der Arbeitsproduktivität besteht also darin,

  • dass man eine garantiert funktionsfähige Fallback-Installation in bootfähigem Zustand bereit hält,
  • dass man komplexe Updates/Upgrades erstmal auf einer Experimental-Installation austestet, bevor man die Updates/Upgrades auf der Haupt-Installation nachzieht.
  • dass man zu geeigneten Zeitpunkten sowohl die Fallback-Installation als auch die Experimental-Installation als Kopie eines funktionierenden Zustands der Hauptinstallation erneuert. (Falls in zeitlicher Nähe: zuerst die Experimental-Installation und dann die Fallback-Installation.)

Das ist zunächst mal einfach und hoffentlich auch einleuchtend. Wie man die Partitions-“Kopien” erzeugt und dabei Boot-Probleme vermeidet, besprechen wir später. Zunächst gilt:

“Continuity” erfordert, mehrere funktionierende Betriebssystem-Installationen auf ein und demselben System vorzuhalten. Eine dient als Fallback für das produktive Arbeiten, wenn es mal zu Problemen mit der “Haupt-Installation” kommt. Die Fallback-Installation ist daher bzgl. Updates extrem vorsichtig zu behandeln. Ggf. wird man Updates sogar völlig unterlassen. Die Funktionstüchtigkeit dieser Installation ist wichtiger als ein aktueller Paket-Status!

Alle drei in der Liste angesprochenen Installationen müssen separat bootbar sein – und die Daten, mit denen man kontinuierlich (weiter-) arbeiten will, müssen deshalb unabhängig von den einzelnen OS-Installationen gelagert werden.

Ein Zugriff auf produktive Projekt-Daten muss von jeder der drei Installationen aus durch ein “Mounten” des Filesystems der Datenpartitionen in definierte Knotenpunkte des jeweiligen Verzeichnisbaums in gleichartiger Weise ermöglicht werden (s.u.).

Wir benötigen jedenfalls mehrere Partitionen (oder LVM-Volumes) auf der/den Systemplatte/n. Das kann dann in etwa so aussehen:

Die erste Aufgabe für den Linux-Einsteiger, der der obigen Philosophie folgen will, ist also:

Mache dich mit der Partitionierung einer Festplatte und Tools wie etwa “gdisk“, “gparted” oder unter Opensuse auch mit dem “Yast Partitioner” vertraut. Zur Einrichtung eines reinen Linux-Systems sollte man dabei auch schon mal was von ein GPT-Layout von Festplatten gehört haben – und sich (soweit möglich) von veralteten Dingen wie “erweiterten Partitionen” aus MSDOS- bzw. MBR-Zeiten lösen. Siehe etwa: https://wiki.ubuntuusers.de/Partitionierung/Grundlagen/, http://www.linux-community.de/Internal/Artikel/Print-Artikel/EasyLinux/2016/01/OpenSuse-Leap-42.1, https://kofler.info/opensuse-leap-42-1/.

(Merke nebenbei: MS Windows gehört unter Linux eigentlich ins “Fenster”; genauer in eine virtuelle Maschine; zumindest dann, wenn man Windows nicht für 3D-Games benötigt. Auf sowas wie eine primäre NTFS-Partition in einem MBR-Plattenlayout kann man dann völlig verzichten. Will man eine vorhandene NTFS-Windows-Partition aber aus berechtigten (!) Lizenz-Ängsten und auf UEFI-Systemen aus Ängsten vor Boot-Fehlern nicht zerstören, sollte man sie in jedem Fall verkleinern. Die meisten Linux-Installationsprogramme bieten das an.)

Partitionsgrößen für die Betriebssystem-Installationen relativ klein halten!

Als Einsteiger tendiert man dazu, während der Linux-Erstinstallation ein vom Installer der jeweiligen Distribution vorgeschlagenes Partitionsmuster für die Festplatten zu übernehmen. Die meist vorgeschlagenen 2 oder 3 Linux-Partitionen (neben einer Swap- und ggf. auch einer EFI-Partition) umfassen dann insgesamt oft den gesamten Plattenplatz. Kennt man sich dann aber nicht mit so schönen Dingen wie LVM aus, nimmt einem das erhebliche Flexibilität!

Leuten mit ein wenig Erfahrung rate ich deshalb eher dazu, sich im Vorfeld einer Installation genau zu überlegen, welche Partitionen man tatsächlich für welche Zwecke auf seinem Desktop-System benötigt. Den Platz für die zu hauptsächlich zu nutzende Betriebssystem-Installation sollte man dabei auf das Notwendige (s.u.) begrenzen und den Rest der Platte erstmal frei halten.

Zweite Aufgabe für Umsteiger:

Bei der ersten Installation von Linux sollte man die Partition für das Root-Filesystem in der Größe begrenzen; sinnvolle Werte liegen nach meiner Erfahrung zwischen 40GB und 80GB. Das lässt einem genügend Luft für Programm-Installationen und Experimente. Persönlich nehme ich meist 80 GB. Den Vorschlag für eine Swap-Partition kann man übernehmen. Auf weitere Partitionen (etwa wie oft vorgeschlagene für “/home”) kann und sollte man dagegen erst mal verzichten; sie kann man später bei Bedarf immer noch anlegen.

(Bei Nutzung von LVM sollte man unabhängig von der zugrunde liegenden Partitionierung und Volume-Gruppen das logische Volume für das Root-Filesystem begrenzen). Auf einem reinen Linux-PC-System gibt es in meinem Ansatz daher zunächst nur : ggf. eine EFI-Partition, eine rel. kleine Swap-Partition (< 4GB) und eine Partition für das Root-/-Filesystem (mit 40 bis 80GB; in ext4-Formatierung, s.u). Sonst nix!

Wir nutzen den freigelassenen Plattenplatz für unsere Daten-Partition(en) und für weitere Partitionen (Volumes), die unsere Fallback- bzw. Experimental-Installation aufnehmen. Wir werden die Inhalte der Fallback-Partition und der Experimental-Partition später als Kopien eines bestimmten Zustands der Hauptinstallation erstellen. Wir benötigen also mindestens 2 x die Größe der Partition für die Hauptinstallation (also z.B. 3 x 80GB) als freien Plattenplatz; den Rest können wir für eine oder mehrere Datenpartitionen nutzen. (Hinweis: Will man mit schnellen Virtualisierungssystemen arbeiten, braucht man ggf. auch dafür weitere Partitionen (Volumes).)

Unter Opensuse wird während der Installation der sog. YaST-Partitionmanager angeboten. Er erlaubt eine Reduktion der Partitionsgröße im sog. “Expertenmodus”. Ein weiterer Punkt: Nehmt als Anfänger lieber “ext4” als Filesystem und nicht BtrFS. Ich habe hierfür gute Gründe, die ich aus Platzmangel an dieser Stelle aber nicht erläutern kann.

Hat man aber die Erstinstallation bereits hinter sich und wurden dabei zu große Partitionen angelegt, muss man im Nachhinein Platz schaffen. Hierbei muss man sich mit Hilfe der genannten Partitionierungstools dazu kundig machen, welche Partitionen im aktuellen Zustand noch wie weit verkleinert werden können. Danach kann man die vorhandenen Partitionen mit Hilfe der Partitionstools in der Größe reduzieren. Ggf. muss man dazu vorher ein Live-System oder eine Rettungsinstallation von CD/DVD oder USB-Disk booten.

Einsatz eines Bootmanagers – Grub2

Unsere Strategie läuft auf mehrere bootbare Linux-Installationen hinaus. Linux erlaubt über die Installation von sog. “Boot-Managern” das Booten verschiedener Betriebssystem-Installationen aus unterschiedlichen Partitionen der HDs/SSDs des Systems. Hierzu wird einem beim Systemstart eine Liste verfüg- und bootbarer Installationen angezeigt.

Bootmanager werden von den meisten Linux-Distributionen bereits im Rahmen der Erstinstallation des Systems eingerichtet. Der aktuelle distributionsübergreifende Standard ist hierbei wohl “Grub2“. Eine gute Übersicht über diesen relativ komplexen Bootmanager liefern folgende Artikel:

https://en.wikipedia.org/wiki/Grub2#GRUB_version_2
https://opensource.com/article/17/3/introduction-grub2-configuration-linux
https://wiki.ubuntuusers.de/GRUB_2/ und https://wiki.ubuntuusers.de/GRUB_2/Konfiguration/
Für Details siehe: https://www.gnu.org/software/grub/manual/grub/grub.pdf

Ich kann in diesem Artikel aus Platzgründen nicht auf Details von Grub2 eingehen. Für unsere Zwecke ist es ausreichend zu wissen, dass der Grub2-BootLoader in drei Schritten installiert oder modifiziert wird: Zunächst wird aus Vorgaben in der Definitionsdatei “/etc/default/grub” und weiteren Skript- und Konfigurations-Dateien unter dem Verzeichnis “/etc/grub.d/” eine temporäre Konfigurationsdatei erzeugt. Der notwendige Befehl ist je nach Distribution “grub-mkconfig” (z.B. Ubuntu) oder “grub2-mkconfig” (z.B. Opensuse). Das Ergebnis kann man dann über die Kommandozeile mit dem Kommando “update-grub” in die Datei “/boot/grub/grub.cfg” (Ubuntu) bzw. “/boot/grub2/grub.cfg” (Suse) schreiben lassen. Schließlich
schreibt man dann die notwendigen Informationen und Boot-Programme mittels des CLI-Befehls “grub-install” (Ubuntu) oder “grub2-install” (Suse) in bestimmte Plattenbereiche (die wiederum u.a. vom Platten-Layout, GPT oder MBR abhängen).

Spezialtools der verschiedenen Distributionen führen zumindest Teile oder gar alle dieser Schritte in einem Arbeitsvorgang durch:
Opensuse: Yast2 >> System >> Bootloader”
Ubuntu: z.B. Grub Customizer (https://www.pcwelt.de/ratgeber/Grub-Bootloader_anpassen-10017211.html, https://www.bitblokes.de/den-bootloader-via-gui-im-griff-grub-customizer/, https://wiki.ubuntuusers.de/GRUB_Customizer/)
Diese Tools erlauben es auch, die Systempartitionen nach anderen bootbaren Installationen durchsuchen zu lassen – und binden letztere in die Auswahlliste des Boot-Menüs ein.

In unserem Kontext ist/wird vor allem die Konfigrationsdatei “/boot/grub[2]/grub.cfg” relevant. Man kann diese Datei zur Not auch mit einem Editor modifizieren, wenn man sicher ist, was dabei zu tun ist. Wir werden weiter unten lediglich bestimmte begrenzte Strings der “grub.cfg” (in kopierten Partitionen) durch andere ersetzen.

Dritte Aufgabe für Umsteiger:

Befasst euch mit dem Boot-Vorgang und dem Grub2-Boot-Manager.

Nutzdaten auf separaten Partitionen – und die besondere Rolle des eigenen Home-Verzeichnisses “~”

In meiner “Methodik” ist die Unterscheidung zwischen Partitionen für die Systeminstallation einerseits und für Nutzdaten andererseits essentiell. Die meisten Nutzdaten, die man als Benutzer anlegt, lassen sich in Projekte und eigene Ordnerhierarchien gliedern und schlagen sich in dortigen Dateien nieder (z.B. Text-Dateien, Präsentationen, selbst entwickelte Programme, Bilder, Movies …). Hinzu kommen Daten wie Favoriten aus bestimmten Applikationen, die man meist aber zur Sicherungszwecken in separate Files exportieren und importieren kann. Selbst den Ablageort von Datenbank-Dateien kann man meist selbst festlegen. Für all diese Daten lege ich grundsätzlich eine oder mehrere eigene Partitionen (LVM-Volumes) mit zugehörigen Filesystemen (ext4) an, die auf selbst definierte Knotenpunkte im Dateibaum gemountet werden – etwa in Subverzeichnisse unter “/mnt” (/mnt/MyProjects, /mnt/MySamba, /mnt/MyPics …). Eine von der System-Installation unabhängige Datenhaltung vereinfacht im übrigen Backups erheblich.

Hat man die Nutzdaten erstmal vom OS-“Rest” absepariert, so können die Nutzdaten über Filesystem-Mounts in jede funktionierende und gebootete Betriebssysteminstallation eingebunden werden. Die Vorgaben dazu hinterlegt man in der jeweiligen Datei “/etc/fstab”; s. hierzu die man-Seiten oder https://wiki.ubuntuusers.de/fstab/. Unter Opensuse kann man die Einträge auch mit dem YaST-Partitionmanager vornehmen lassen. Natürlich muss man die Dateien und Mount-Punkte jeweils mit den nutzerbezogenen Rechten versehen.

Es ergibt sich also eine dritte Aufgabe für Ein- und Umsteiger:

Arbeitet euch in das “Mounten” von Filesystemen ein – studiert die Bedeutung der Einträge in der /etc/fstab.

[Ergänzung für Fortgeschrittene: Persönlich halte ich meine Projektdateien zudem weitgehend in SVN- oder Git-Verzeichnissen, die mit einem zentralen SVN-/Git-Server abgeglichen wird. Das gilt auch für Dokument-Dateien. Serverbasierte Versionsmanagement-Systeme erlauben neben der Versionierung seiner Arbeiten zudem schnelle “Backups” durch Replikation der Dateien auf weitere Systeme (Server, PCs, mobile Laptops, …). ]

Ausnahmen von der Lagerung eigener “Daten” in
separaten Partitionen
Neben selbst erzeugten Projekt-Daten in Dateien gibt es auch automatisch generierte Konfigurationsdateien, die Einstellung zur persönlichen grafischen Desktop-Umgebung und persönliche Einstellungen zu bestimmten Applikationen betreffen. Auch diese Dateien werden meist in Unterordnern des eigenen Home-Verzeichnisses “/home/uid” [~] untergebracht – u.a. unter “~/.config”.

Diese “Konfigurations”-Dateien sind im Sinne einer schnellen Restauration der Produktionsfähigkeit wichtig! Sie sind ferner relativ eng mit anderen Bibliotheken einer Distributionsversion verzahnt. Wir wollen später mehrere Partitionen mit funktionstüchtigen Installationen, aber auf unterschiedlichen Versionsständen, durch das Kopieren von Partitionen einrichten. Das spricht dann dafür,

die Inhalte des eigenen Home-Verzeichnisses im Gegensatz zu sonstigen Nutzdaten nicht auf eine separate Partition zu legen.

Warum?
Der eigene grafische Desktop und OS müssen im Verbund funktionieren! Das führt dann beim Starten einer neuen Desktopversion u.U. zu automatischen Updates der Konfigurationsdateien. Diese Modifikationen kann man danach ohne Spezialkenntnisse nicht mehr so einfach zurückdrehen. Hat man also das eigene “~”-Verzeichnis auf eine separate Partition verlagert, die man dann nach einem Systemupgrade unter der neuen Installation mounted, so ist nach einem Start der neuen Desktop-Umgebung die spätere Nutzbarkeit der Konfigurationsdateien unterhalb von “~” in der noch vorhandenen alten Installation in Frage gestellt! Das muss man vermeiden – und deswegen ist es besser, das “/home”-Verzeichnis in unserem Verfahren nicht aus dem Root-Filesystem abzuseparieren.

In den turbulenten KDE4-Anfangszeiten (gerade mit Kontact/Kmail) ist mir schmerzlich bewusst geworden, dass es auf einem Stand-Alone-System kaum Sinn macht, das eigene Home-Verzeichnis mit seinen Konfigurationsdateien in eine separate Partition zu verlagern – auch wenn dass bei vielen Distributionen im Installationsprozess so vorgeschlagen wird. Man muss das alte Home-Verzeichnis dann in jedem Fall sichern, wenn man wieder auf die alte Installation zurück will. Dann kann man es in den unterschiedlichen Installationen gleich mit vorhalten – auch wenn das Platz kostet. (Das sieht auf einer serverbasierten Installation, bei der das Home-Verzeichnis ggf. auf einem zentralen NFS-Server liegt und über Netz auf dem lokalen PC gemountet wird, natürlich anders aus.)

Eine weitere Ausnahme bilden womöglich Mail- und Groupware-Daten, die zumeist ebenfalls in Unter-Ordnerhierarchien des persönlichen Desktops – also unterhalb irgendwelchen Konfigurationsordnern des eigenen Home-Verzeichnisses untergebracht werden. Entsprechende Dateien lassen wir mal außen vor – die Ursprungsdaten zu Mails gehören aus meiner Sicht eh’ immer auf einen (ggf. lokalen und virtualisierten) IMAP-Server. In lokalen Mailsystemen der Desktops sollten davon höchstens Kopien vorgehalten werden.

Zwischenfazit

Genug für heute! Es sollte klar geworden sein, dass ich die Kontinuität meiner Arbeitsfähigkeit gegenüber Update/Upgrade-Probleme neben Backups durch verfügbare Fallback-Installationen und eine Speicherung von Nutzdaten auf separaten Partitionen sicherstelle.

Im nächsten Beitrag

Upgrade-Zeit – Vorsorge durch Fallback-Installationen – II

bespreche ich dann den Einsatz des “dd”-Kommandos zum Anlegen von Partitionskopien – und bespreche, wie ihr ein mögliches Chaos beim Booten, das sich aus duplizierten sog. UUIDs der Filesysteme ergeben würde, vermeidet.