Autorenarchiv: Jörg Kastning

Datenträger unter Linux mit cryptsetup (LUKS) verschlüsseln

Ihr möchtet einen Datenträger wie z.B. eine Festplatte oder einen USB-Stick verschlüsseln, damit bei einem Verlust des Datenträgers nicht jeder ohne weiteres Zutun eure Daten lesen kann? Dann haben wir ein gemeinsames Ziel!

Im Folgenden beschreibe ich, wie unter Linux mit Hilfe des Programms cryptsetup eine Festplatte verschlüsselt werden kann. Dazu gehört die Beschreibung, wie das verschlüsselte Gerät anschließend zur Nutzung geöffnet wird und wie man es in die /etc/crypttab einträgt, um das Gerät automatisch beim Start des Rechners zu öffnen. Es handelt sich dabei um eine zusätzliche Festplatte. Wie die erste Festplatte eines Systems verschlüsselt werden kann ist hingegen nicht Gegenstand dieses Artikels. Hier hilft (hoffentlich) ein Blick in die Installationsanleitung der jeweiligen Linux-Distribution weiter.

Das Programm cryptsetup ist in allen gängigen Linux-Distributionen verfügbar. Falls nicht, kann es direkt von der Projekt-Homepage auf GitLab bezogen werden. Die hier gezeigten Kommandos funktionieren prinzipiell auf jedem Linux-System, auf dem cryptsetup verfügbar ist.

Bevor es losgeht noch ein Hinweis. Ich möchte ein verschlüsseltes Gerät erstellen, mit dem Ziel, dass nicht jeder die Daten einfach lesen kann, dem das Gerät in die Hände fällt. Dabei denke ich an Szenarien wie Verlust, Diebstahl, Verkauf etc. Die Daten vor dem Zugriff durch Sicherheitsbehörden, Geheimdiensten oder Schurkenstaaten zu schützen erfordert einen deutlichen höheren Aufwand und ist nicht Gegenstand dieses Artikels.

Ich verwende im Folgenden LUKS2. Wer stattdessen lieber dm-crypt verwendet, sei auf die Manpage cryptsetup(8) verwiesen.

Die zu verschlüsselnde Festplatte wird in diesem Tutorial als /dev/sdX bezeichnet. Dieser Bezeichner muss auf das tatsächlich zu nutzende Gerät angepasst werden. Wichtig: Wird versehentlich das falsche Gerät verschlüsselt gehen vorhandene Daten unwiederbringlich verloren!

LUKS-Container erstellen

Zur Erstellung eines LUKS-Containers wird der folgende Befehl ausgeführt und die Bildschirmanweisungen befolgt. Für die dabei abgefragte Passphrase gilt grundsätzlich: „Je länger und komplizierter, desto sicherer. Wobei es mehr auf die Länge als die Komplexität ankommt.“

Weitere Hinweise zur Passwort-Sicherheit bietet der Wikipedia-Artikel zu Passsatz.

$ sudo cryptsetup luksFormat --type luks2 /dev/sdX
WARNING: Device /dev/sdX already contains a 'dos' partition signature.

WARNING!
========
This will overwrite data on /dev/sdX irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/sdX: 
Verify passphrase:

Hinzufügen einer Backup-Passphrase

LUKS-Passphrasen werden in sogenannten Key-Slots gespeichert. Bei LUKS2 stehen 32 Key-Slots zur Verfügung, welche von 0-31 nummeriert sind. Bei LUKS1 waren es 8 Key-Slots. Die Passphrase aus dem vorigen Abschnitt wurde in Slot 0 gespeichert.

Vergisst man die Passphrase, wird der Key-Slot oder der LUKS-Header beschädigt, ist ein Zugriff auf die Daten nicht mehr möglich. Um mich gegen die ersten beiden Fälle abzusichern, erstellte ich zwei Backup-Passphrasen, welche ich in den Key-Slots 3 und 8 speicherte. Wie man sich gegen den Verlust des LUKS-Headers schützt, beschreibe ich im folgenden Abschnitt.

$ # Hinzufügen der ersten Backup-Passphrase in Key-Slot 3
$ sudo cryptsetup luksAddKey /dev/sdX --key-slot 3
Enter any existing passphrase: 
Enter new passphrase for key slot: 
Verify passphrase:

$ # Hinzufügen der zweiten Backup-Passphrase in Key-Slot 8
$ sudo cryptsetup luksAddKey /dev/sdX --type luks2 --key-slot 8
Enter any existing passphrase: 
Enter new passphrase for key slot: 
Verify passphrase:

Für die Backup-Passphrasen gilt selbstverständlich das im vorangegangenen Abschnitt Beschriebene. Die einzelnen Passphrasen sollten von gleicher Güte sein.

Die Backup-Passphrasen sind an einem sicheren Ort aufzubewahren. Ich verwende dazu bspw. einen Passwort-Tresor (vgl. Sichere Passwörter und wie man sie verwaltet).

LUKS-Header sichern

Nun nützen alle Backup-Passphrasen nichts, wenn der LUKS-Header beschädigt wird. Daher empfehle ich diesen mit Hilfe des folgenden Kommandos in eine Datei zu sichern.

$ sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /var/tmp/luksHeaderBackup_2020-10-18

Die so erstellte Datei ist sicher — am besten offline und vom Datenträger getrennt — aufzubewahren. Mit Hilfe dieser Datei und einer Passphrase, welche bei Erstellung des Backups gültig war, kann ein defekter LUKS-Header und damit der Zugriff auf ein verschlüsseltes Gerät wiederhergestellt werden.

Ändert man im Laufe der Zeit in Key-Slots gespeicherte Passphrasen, löscht alte oder fügt neue hinzu, so ist eine erneute Sicherung des LUKS-Headers sinnvoll und angeraten.

LUKS-Container öffnen und nutzen

Bis jetzt haben wir auf dem Block-Gerät /dev/sdX einen verschlüsselten LUKS-Container erstellt, Backup-Passphrasen hinzugefügt und den LUKS-Header gesichert. Der folgende Code-Block zeigt, wie der LUKS-Container geöffnet und damit nutzbar gemacht wird. Dabei ist sdX_crypt ein Bezeichner, welcher für den Device Mapper verwendet wird. Dieser Bezeichner kann von euch frei gewählt werden.

$ sudo cryptsetup open /dev/sdX sdX_crypt
$ lsblk | grep sdX
sdX              8:16   0 111,8G  0 disk  
└─sdX_crypt    254:3    0 111,8G  0 crypt

Der so geöffnete LUKS-Container kann nun mit einem Dateisystem eurer Wahl formatiert werden. Folgender Code-Block zeigt ein Beispiel für ext4. Dies kann in Abhängigkeit zur Größe des LUKS-Containers einige Zeit dauern.

$ sudo mkfs.ext4 /dev/mapper/sdX_crypt
[...]
$ sudo blkid | grep sdX
/dev/sdX: UUID="Eine-furchbar-lange-UUID" TYPE="crypto_LUKS"
/dev/mapper/sdX_crypt: UUID="Eine-andere-furchbar-lange-UUID" TYPE="ext4"

Man beachte, dass der LUKS-Container direkt mit einem Dateisystem formatiert werden kann. Die Erstellung einer Partition ist nicht erforderlich.

Das erstellte Dateisystem kann anschließend wie gewohnt eingehängt werden.

$ sudo mount /dev/mapper/sdX_crypt /mnt

Mit den folgenden Kommandos wird das Dateisystem wieder ausgehängt und der LUKS-Container verschlossen. Damit liegen die Daten nur noch in verschlüsselter Form vor, bis sie das nächste Mal geöffnet werden.

$ sudo umount /dev/mapper/sdX_crypt
$ sudo cryptsetup close sdX_crypt
$ sudo cryptsetup status sdX_crypt
/dev/mapper/sdX_crypt is inactive.

Verschlüsseltes Dateisystem bei Startvorgang des Rechners öffnen und einhängen

Soll das erstellte Dateisystem /dev/mapper/sdX_crypt bereits beim Start des Rechners eingehängt werden, ist folgende Reihenfolge einzuhalten:

  1. LUKS-Container sdX_crypt mit Hilfe der /etc/crypttab öffnen
  2. Dateisysteme aus /etc/fstab einhängen

Die Einträge in den entsprechenden Dateien sehen in meinem Fall wie folgt aus. In /etc/crypttab wird dabei die UUID des Gerätes /dev/sdX verwendet.

$ sudo cat /etc/crypttab
sdX_crypt UUID="Eine-furchbar-lange-UUID" none luks,discard

$sudo cat /etc/fstab
/dev/mapper/sdX_crypt /mnt ext4 defaults 0 0

Man beachte, dass der Rechner nun den Startvorgang unterbricht und zur Eingabe der Passphrase zum Öffnen des LUKS-Containers auffordert. Anschließend wird der Startvorgang fortgesetzt.

Damit sind wir eigentlich am Ende des Tutorials angelangt. Wie fandet ihr es? War es verständlich genug, um folgen zu können und Eingangs erwähnte Ziele zu erreichen?

Wer noch Zeit und Lust hat, kann gerne weiterlesen. In den folgenden Abschnitten werde ich als Zugabe noch beschreiben, wie man Key-Slots löscht und einen LUKS-Header aus einem Backup wiederherstellt.

Key-Slots löschen

Mit dem folgenden Befehl werden sämtliche Key-Slots des LUKS-Containers gelöscht. Ein Zugriff auf den LUKS-Container ist anschließend nicht mehr möglich. Die Angabe eines Passworts ist nicht erforderlich.

Warnung: Dieser Vorgang kann nicht rückgängig gemacht werden.

$ sudo cryptsetup erase /dev/sdX

WARNING!
========
This operation will erase all keyslots on device /dev/sdb.
Device will become unusable after this operation.

Are you sure? (Type uppercase yes):

Das war’s.

LUKS-Header aus Sicherung wiederherstellen

Und nun halte ich noch fest, wie man einen LUKS-Header und die darin enthaltenen Key-Slots aus einer Datensicherung wiederherstellen kann.

$ sudo cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /tmp/luksHeaderBackup_2020-10-18 

WARNING!
========
Device /dev/sdX already contains LUKS2 header. Replacing header will destroy existing keyslots.

Are you sure? (Type uppercase yes):

Uns schon kann man wieder auf seinen LUKS-Container zugreifen.

Reflexion

Um meine Festplatte zu verschlüsseln und diesen Beitrag zu schreiben, habe ich einige Zeit in der Manpage cryptsetup(8) und auf der Projekt-Seite gelesen. Nur mit der Manpage allein wäre mir eine Nutzung vermutlich erst nach deutlich längerer Zeit gelungen.

Dabei vermisse ich in der Manpage vor allem eine Inhaltsübersicht und Beispiele, mit denen man sich gängige Aufgaben schnell ins Gedächtnis rufen kann. Zwar existiert seit ca. zwei Jahren ein Ticket zur Überarbeitung der Manpage, doch fehlt es bei den am Projekt beteiligten Personen wie so oft an der Zeit. Diese wird primär zur Arbeit am Code genutzt. Für die Dokumentation bleibt keine Zeit übrig.

Aktuell erkundige ich mich auf der Mailling-Liste, wie man am besten dazu beitragen kann, die Manpage zumindest in Teilen zu verbessern. Mal sehen, was sich da machen lässt.

Da man vermutlich nicht täglich mit cryptsetup arbeitet, ist eine gute Dokumentation um so wichtiger, da vermutlich niemand alle notwendigen Befehle dauerhaft im Gedächtnis behält.

Mit diesem Tutorial habe ich mir meine eigene Dokumentation für meine häufigsten Anwendungsfälle geschaffen. Wenn ihr sie ebenfalls nützlich findet, freut mich dies umso mehr.

Social-Red_Hat-Accelerators-Personal_Post-Twitter-RGB

Das Red Hat Accelerator Programm ist offiziell gestartet

In seiner heutigen Presseerklärung gibt Red Hat den offiziellen Start des Red Hat Accelerators Programms bekannt.

Die Red Hat Accelerators sind eine einzigartige Gemeinschaft, bestehend aus Open Source IT-Enthusiasten. Ich bin stolz Mitglied dieser Gemeinschaft zu sein. Dadurch habe dich die Möglichkeit:

  • Mich mit Gleichgesinnten zu vernetzen
  • Frühzeitig einen Blick auf neue Technologien und Entwicklungen von Red Hat zu werfen
  • Mit Experten von Red Hat zu interagieren
  • Die Produktentwicklung mit zu beeinflussen

Wir sind Kunden und Partner, welche gern über IT-Themen diskutieren, uns austauschen und Red Hat ehrliches Feedback zur ihren Produkten zukommen lassen.

Und diese Möglichkeiten stehen auch Dir offen!

Wenn auch Du ein Teil dieser außergewöhnlichen Gemeinschaft werden möchtest, erfährst du alles notwendige für deine Bewerbung unter diesem Link.

Vielen Dank an Andi, Grace und Jeff, welche alles dafür geben, damit wir uns in diesem Programm wohlfühlen.

LinuxDay 2020 am 10. Oktober

Online GNU/LinuxDay in Vorarlberg – am 10. Okt. 2020

Wie so viele andere Veranstaltungen in diesem Jahr findet auch der LinuxDay in Vorarlberg dieses Jahr ausschließlich online statt.

Die Linux User Group (LUG) Vorarlberg schickt sich an, die Veranstaltung erstmals im Cyberspace und auf Basis von Open Source Software auszurichten. Ich denke sowohl die Veranstalter, Vortragende und Teilnehmer sind auf diese Premiere gespannt.

Das diesjährige Vortragsprogramm bietet insgesamt 12 Vorträge. Diese verteilen sich auf zwei Blöcke mit jeweils sechs Vorträgen. Von mir ist in diesem Jahr auch wieder ein Beitrag dabei. Um 11:00 Uhr werde ich euch zwei kleine Projekte vorstellen, mit denen sich ein Spiegelserver und ein Patch-Management für Red Hat Enterprise Linux realisieren lassen.

Ich persönlich finde es sehr schade, dass diese und viele weitere Veranstaltungen dieser Art in diesem und vermutlich auch im nächsten Jahr ausschließlich im Cyberspace abgehalten werden können. Die Gründe dafür verstehe ich und kann die Entscheidung nachvollziehen. Doch geht das, was ich an diesen Veranstaltungen am meisten schätze, derzeit verloren.

Für mich stellt der Besuch des LinuxDay eine willkommene Abwechslung zum Alltag dar. Die Vorfreude beginnt bereits Tage vor der Anreise. Auf diesen Veranstaltungen treffe ich Gleichgesinnte in lockerer und ungezwungener Atmosphäre. Einige Menschen treffe ich tatsächlich ausschließlich am Rande dieser Veranstaltungen. Bei Kaffee, Mate und Bier lässt sich fachsimpeln, über aktuelle Entwicklungen diskutieren und man fühlt sich verstanden. Dies alles geht bei reinen Online-Konferenzen in meinen Augen verloren. Daher hoffe ich, dass möglichst bald ein Impfstoff gegen das Corona-Virus gefunden wird und wir uns vielleicht schon 2022 vor Ort wiedersehen können.

tdps.service — Service-Unit für den TeamDrive Personal Server

Kaum eine Software verwende ich so lange wie TeamDrive. Die ersten Artikel dazu in diesem Blog stammen bereits aus dem Jahr 2011 [0], [1].

Nachdem ich den TeamDrive Personal Server schon auf einem NAS installiert und als Dienst konfiguriert habe, dokumentiere ich in diesem Artikel die Erstellung einer Systemd-Service-Unit. Dazu sei gesagt, dass ich kein Experte für Systemd-Units bin. Tatsächlich kenne ich mich nichtmal besonders gut damit aus. Folgende Lösung funktioniert auf meinem Server. Anregungen zur Verbesserung der Service-Unit nehme ich gern in den Kommentaren entgegen.

Installation des TeamDrive Personal Server

Zuerst muss der TeamDrive Personal Server heruntergeladen und installiert werden. Dabei hilft das dazugehörige Handbuch. Auch wenn dieses schon einige Jahre auf dem Buckel hat, sind die enthaltenen Informationen weiterhin aktuell.

Da die Installation hier im Blog bereits einmal beschrieben wurde, gehe ich hier im Detail nicht weiter darauf ein. Im vorliegenden Fall wurde die Software im Verzeichnis /opt/tdps installiert. Darüber hinaus wurde ein Benutzer tdps erstellt, welchem das Verzeichnis /opt/tdps und die darin enthaltenen Dateien gehören.

Systemd-Service-Unit tdps.service

Ich habe den TeamDrive Personal Server (TDPS) auf einem Debian 10 System installiert. Um diesen wie alle übrigen Dienste mit dem Programm systemctl verwalten zu können, habe ich die Datei /etc/systemd/system/tdps.service mit folgendem Inhalt erstellt:

[Unit]
Description="TeamDrive Personal Server"
After=network.target

[Service]
User=tdps
PIDFile=/opt/tdps/tdpsd.pid
ExecStart=/opt/tdps/tdpsd -c /opt/tdps/tdps.config -m /opt/tdps/mime.types -w /opt/tdps
ExecStop=/opt/tdps/stop-tdps -p /opt/tdps/tdpsd.pid
KillMode=process
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Im Abschnitt [Unit] findet sich eine kurze Beschreibung der Service-Unit. Die Option After=network.target gibt an, dass diese Unit erst gestartet werden soll, wenn das Netzwerk zur Verfügung steht. Dies ist Voraussetzung, um den Dienst über das Netzwerk nutzen zu können.

Die Zeile im letzten Abschnitt [Install] definiert, dass diese Unit Bestandteil des multi-user.target ist und mit diesem geladen wird.

Der Abschnitt [Service] definiert die für den Dienst relevanten Parameter. Die gewählten Optionen werde ich im Folgenden erläutern.

User= gibt den Namen des Benutzers an, mit dessen Rechten der Dienst ausgeführt werden soll. In diesem Fall wird der extra für diesen Zweck erstellte User tdps verwendet.

PIDFile= gibt den Pfad an, wo der Dienst seine PID speichert. Der Service-Manager liest die PID des Hauptprozess aus dieser Datei, nachdem der Service gestartet wurde.

ExecStart= gibt das Kommando mit allen notwendigen Argumenten an, um den Dienst zu starten. Ich habe hier ein wenig mit verschiedenen Aufrufen experimentiert. Dabei habe ich verschiedene Möglichkeiten gefunden, den Dienst erfolgreich zu starten. Worin die Unterschiede im Aufruf genau bestehen, kann ich leider nicht sagen. Am Ende habe ich mich für obige Kommandozeile entschieden, die ich im TeamDrive-Forum gefunden habe. Aus diesem Foren-Beitrag habe ich auch Stumpf die Option KillMode=process übernommen. Zur Option selbst kann ich (noch) nicht viel sagen. Dies änderst sich vielleicht noch, da ich mich noch etwas damit beschäftigen möchte.

Mit ExecStop= gibt man entsprechend an, wie der Dienst zu stoppen ist. Auch hier stammt die Kommandozeile aus oben verlinktem Foren-Thread.

Die nächsten drei Optionen PrivateTmp=, ProtectHome= und ProtectSystem= dienen dazu den Dienst zu härten. Durch PrivateTmp=yes erhält der gestartete Prozess einen eigenen Dateisystem-Namespace für /tmp und /var/tmp. So kann der Prozess nicht auf die Dateien anderer Prozesse und Benutzer in den normalen Verzeichnissen /tmp und /var/tmp zugreifen. Mit ProtectHome=yeswird der Zugriff des Dienstes auf die Verzeichnisse /home, /root und /run/user verhindert. ProtectSystem=full sorgt dafür, dass die Verzeichnisse /boot, /etc und /usr im Nur-Lese-Modus für den Prozess zur Verfügung stehen. Damit ist sichergestellt, dass der von dieser Unit gestartete Prozess keine Dateien innerhalb dieser Verzeichnisse verändern kann.

Die drei im vorhergehenden Abschnitt genannten Optionen stellen einen zusätzlichen Schutz dar. Zwar darf der Benutzer tdps schon aufgrund der Datei- und Verzeichnisberechtigungen nicht in den genannten Verzeichnissen schreiben und Dateien verändern bzw. diese überhaupt lesen, doch bieten diese Optionen einen zusätzlichen Schutz und greifen auch noch, wenn jemand Schindluder mit den Berechtigungen getrieben hat. Daher halte ich es für sinnvoll diese Optionen wenn möglich in allen Service-Units zu nutzen.

Neben den drei hier vorgestellten Optionen gibt es noch einige weitere, welche im englischsprachigen Artikel „Mastering systemd: Securing and sandboxing applications and services“ nachgelesen werden können. Ich finde diese so sinnvoll, dass ich mich ehrlich gesagt frage, warum die genannten Einstellungen nicht der Standard sind und man diese editieren muss, wenn man entsprechende Zugriffe explizit erlauben möchte.

Damit ist alles getan und dokumentiert. Der TDPS lässt sich mit oben beschriebener Service-Unit starten und stoppen. Den Status abfragen kann man selbstverständlich auch.

Es bleibt ein kleiner Schönheitsfehler. Wird der Dienst mittels sudo systemctl stop tdps.service gestoppt, endet die Unit im Status „failed“. Warum das so ist, habe ich noch nicht herausgefunden. Ich vermute, es hängt damit zusammen, dass der Dienst mittels SIGTERM beendet wird. Bin mir an dieser Stelle jedoch nicht sicher. Falls von euch jemand eine Idee dazu hat, freue ich mich über euren Kommentar.

Wie schreibt ihr eure Service-Units? Welche Optionen sollten eurer Meinung nach in keiner Unit fehlen? Wenn ihr mögt, lasst uns gerne in den Kommentaren darüber diskutieren.

Ältere Artikel zu TeamDrive in diesem Blog

Software-Pakete mit Ansible installieren

In diesem sehr kurzen Beitrag möchte ich euch zeigen, wie ihr mit Ansible einen definierten Satz an Software-Paketen auf euren Linux-Hosts installieren könnt. Dies ist z.B. dann nützlich, wenn ihr bei der Provisionierung neuer Systeme sicherstellen möchtet, dass ein bestimmter Satz an Paketen vorhanden ist.

Natürlich kann man diese Aufgabe auch auf verschiedenen anderen Wegen lösen. Dies ist halt der Ansible-Weg. ;-)

---
- hosts: all
  tasks:
  - name: Install package baseline
    yum:
      name:
        - bind-utils
        - net-tools
        - chrony
        - ed
        - yum-utils
        - vim-enhanced
        - man-pages
        - strace
        - lsof
        - tcpdump
        - setroubleshoot-server
        - setroubleshoot
        - bash-completion
      state: latest
      update_cache: yes

Das obige Playbook zeigt ein einfaches Beispiel, wie auf einem RHEL/CentOS 7 System eine Liste von Paketen installiert werden kann. Dazu wird das Ansible-Modul yum verwendet. Der Parameter ’state‘ gibt an, dass immer die jeweils akutellste Version eines Pakets installiert werden soll. Mit ‚update_cache‘ wird definiert, dass der lokale Cache aktualisiert wird, bevor ein Paket zur Installation ausgewählt wird.

Für auf Debian/Ubuntu basierende Systeme gibt es das Modul apt. Für Fedora und RHEL/CentOS ab Version 8 nutzt man das Modul dnf.

Darüber hinaus gibt es noch das generische Modul package. Bei diesem ist jedoch zu beachten, dass die unterschiedlichen Paketmanager wie YUM und APT zum Teil unterschiedliche Paketnamen verwenden. Da ‚package‘ diese nicht automatisch übersetzt ist eine Verwendung über verschiedene Distributionen hinweg nicht ohne weiteres möglich. Daher empfinde ich dieses Modul als nutzlos.

Konfiguration der Host-Firewall mit Ansible

In diesem kurzen Beitrag möchte ich euch zeigen, wie man mit Hilfe von Ansible die Host-Firewall (firewalld) konfigurieren kann. Dies ist z.B. dann nützlich, wenn man die identische Konfiguration auf mehreren Hosts ausbringen möchte.

Bevor es an die Freigabe spezifischer Ports und Services in der Host-Firewall geht, wird zuerst sichergestellt, dass der Dienst firewalld installiert, aktiviert und gestartet ist. Dazu dienen die Ansible-Module yum und service. Folgendes Playbook zeigt beispielhaft, wie diese genutzt werden können, um vorstehende Anforderungen zu erfüllen:

---
# Install, activate and start firewalld

- hosts: foo.example.com
  tasks:
  - name: Make sure firewalld is installed
    yum:
      name: firewalld
      state: latest

  - name: Activate and start firewalld service
    service:
      name: firewalld
      enabled: yes
      status: started

Bei Verwendung einer auf Debian basierenden Distribution ist statt yum das Modul apt zu verwenden.

Um jetzt z.B. die Services HTTP und HTTPS in der lokalen Host-Firewall freizugeben, kann obiges Playbook um die folgenden Abschnitte, unter Verwendung des Ansible-Moduls firewalld, ergänzt werden:

[...]
  - name: Enable immediate and permanent access to HTTP
    firewalld:
      service: http
      permanent: yes
      immediate: yes
      state: enabled

  - name: Enable immediate and permanent access to HTTPS
    firewalld:
      service: https
      permanent: yes
      immediate: yes
      state: enabled

Aktuell ist es leider noch nicht möglich dem Parameter ’service‘ eine Liste zu übergeben. Auf GitHub existiert jedoch bereits ein RFE für diese Funktion.

Persönliche Bewertung von Red Hat Insights

Dies ist der letzte Teil meiner Artikelserie „Einführung in Red Hat Insights“. An dieser Stelle schließe ich mit meinem Test ab, entferne die Systeme aus dem Cloud-Dienst und nehme eine persönliche Bewertung der SaaS-Anwendung vor.

Hinweis: Ich habe den Dienst im Rahmen meiner beruflichen Tätigkeit im Bielefelder IT-Service Zentrum (BITS) der Universität Bielefeld getestet. Dieser Artikel spiegelt meine persönliche Ansicht zu Red Hat Insights wieder. Des Weiteren weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community bin (siehe „Zu meiner Person“).

Systeme aus Insights entfernen

Im Einführungsartikel habe ich ein kleines Ansible-Playbook verwendet, um den insights-client und weitere benötigte Pakete auf den teilnehmenden Hosts zu installieren. Dieses wird nun angepasst und dazu genutzt, die Systeme aus Insights zu entfernen und die nicht mehr benötigten Pakete zu deinstallieren:

---
- hosts: rh-insights-poc # Gruppe aus dem Ansible-Inventory
  tasks:


  - name: Register insights-client
    command: insights-client --unregister

  - name: Make sure required packages are present
    yum:
      name:
        - openscap-scanner
        - scap-security-guide
        - insights-client
      state: absent

Nur wenige Minuten nach Ausführung des Playbooks sind die Systeme aus Insights gelöscht.

Abschließende Bewertung von Red Hat Insights

Meiner Ansicht nach ist es Red Hat mit Insights gelungen, einen nützlichen Dienst bereitzustellen, der einen deutlichen Mehrwert für bestehende Subskriptionen bietet. Und dies ohne Mehrkosten. Das Dashboard ist übersichtlich, gut strukturiert und lässt sich intuitiv bedienen. Es bietet von zentraler Stelle aus Zugriff auf vielfältige Informationen zu den eigenen Systemen und Artikeln in den Wissens- und Lösungs-Datenbanken von Red Hat und weiteren Unternehmen.

Insgesamt war mir die Erkundung von Insights eine Freude und hat einige neue Erkenntnisse zu Tage gefördert, die andernfalls vermutlich noch lange im Dunkeln verborgen geblieben wären. Dies gilt insbesondere für den Advisor und das Vulnerability Management. Diese beiden Komponenten stellen für mich die wertvollsten Bestandteile von Insights dar.

Auch die übrigen Komponenten Compliance, Patch und Drift machen einen guten Eindruck. Für Sysadmins, die Compliance nach gewissen Standards wie z.B PCI-DSS oder HIPAA nachweisen müssen, ist die gleichlautende Komponente ein hilfreiches Werkzeug. Patch und Drift sind nette Anwendungen, welche noch ein wenig Potenzial für Verbesserungen haben, den Dienst jedoch gut ergänzen.

Nicht näher betrachtet habe ich das Rollen- und Rechte-Konzept von Insights. Grundsätzlich werden die im Customer Portal existierenden Benutzer in die Insights-Benutzerverwaltung kopiert und dort als Standard-Benutzer berechtigt. Damit darf jeder Benutzer erstmal alles. Dies finde ich nicht ganz so geschickt. Auch wenn man die Rechte der einzelnen Nutzer mit vorhandenen Rollen anschließend beschränken kann, hätte ich mir hier einen anderen Ansatz gewünscht. Zum Beispiel hätte man einem Organisations-Administrator das Recht einräumen können, weitere Benutzerkonten zu importieren und entsprechend zu berechtigen. Vielleicht ist unter meinen Lesern jemand, der sich mit diesem Thema bereits intensiver beschäftigt hat. In diesem Fall freue ich mich, wenn Sie/Er die gemachten Erfahrungen mit uns teilt.

Doch wo Licht ist, gibt es meist auch Schatten. Denn für die Funktionsweise des Dienstes ist es notwendig, dass auf den angeschlossenen Systemen umfangreiche Informationen gesammelt und an den Cloud-Dienst übertragen werden. Dieser wird auf OpenShift innerhalb von AWS (US East) betrieben. Auch wenn der Dienst keine personenbezogenen Daten sammelt (oder dies zumindest zu vermeiden versucht), erhält der Dienstbetreiber detaillierte Informationen über vorhandene Schwachstellen und Konfigurationsfehler der eigenen Systeme. Aus den aggregierten Daten lässt sich eine Karte der eigenen IT-Infrastruktur mit ihren Schwachstellen und potenziellen Einfallstoren erstellen.

Ich persönlich tue mich deshalb schwer mit dem Gedanken, all unsere RHEL-Systeme an den Dienst anzubinden. Davon abgesehen bin ich kein Jurist und kann die rechtliche Seite einer möglichen Nutzung gar nicht abschließend beurteilen. Sysadmins sollten hier frühzeitig das Gespräch mit ihren Vorgesetzten, Informationssicherheits- und Datenschutzbeauftragten suchen, bevor sie sich bereits mit einem Test des Cloud-Dienstes in die Nesseln setzen.

Doch vielleicht erhört das Insights-Produkt-Team eines Tages das Flehen von mir und weiteren Kunden aus Deutschland bzw. Europa und stellt eine On-Premises-Variante des Dienstes, z.B. in Form einer virtuellen Appliance, bereit. Ohne zu wissen, wie meine Vorgesetzten dazu stehen, wäre mir diese sogar Geld wert. Bis es soweit ist, wird uns eine ausgedehnte Nutzung von Insights nicht möglich sein.

Red Hat Insights – Patch and Drift

Nein, dies ist nicht der Titel eines Kinofilms mit schnellen Autos. Dies ist der fünfte Artikel über meinen Test von Red Hat Insights. In diesem beschäftige ich mich mit den Anwendungen Patch und Drift.

Patch

So simpel wie der Name, ist auch die Funktion, die sich hinter diesem Menüpunkt verbirgt.

In Bild 1 würde man eine Übersicht der verfügbaren Red Hat Advisories sehen, welche auf den verbundenen Systemen noch nicht installiert sind. Da in diesem Fall alle angebundenen Systeme voll durchgepatcht sind, gibt es hier aktuell nichts zu sehen.

Bild 2 zeigt die verfügbaren Advisories pro Host. Auch hier gibt es aktuell nichts zu sehen, da die Systeme gerade aktualisiert wurden.

Ich habe vorstehend zwei Sätze gestrichen. Zwar waren meine Systeme durchgepatcht. Dass Patch keine Advisories anzeigt hat jedoch einen anderen Grund. Patch funktioniert nur dann korrekt, wenn die angebundenen Systeme die original RHEL-Upstream-Repos verwenden. In meinem Fall werden diese jedoch über einen lokalen Spiegelserver bereitgestellt. Obwohl dieser ebenfalls über sämtliche Erratas verfügt, werden diese von Patch nicht berücksichtigt. Siehe hierzu auch Bugzilla 1843860.

Diese Anwendung ist ganz nett, stellt allein aber keinen Grund für eine Nutzung von Insights dar. Zum einen können Errata-Informationen im Customer Portal per E-Mail abonniert werden und zum anderen kann auf jedem System mittels sudo yum updateinfo list geprüft werden, ob Advisories verfügbar sind. Und darüber hinaus funktioniert die Anwendung wie oben erwähnt in meiner Umgebung auch gar nicht.

In unserer Umgebung stellen wir mittels unseres Patch-Managements sicher, dass mindestens einmal im Monat alle verfügbaren Red Hat Security Advisories auf unseren Systemen installiert werden. Es schmerzt mich daher nicht, Patch nicht nutzen zu können.

Drift

Wer die Hostprofile von VMware kennt und schätzt, wird sich hier schnell wiederfinden. Unter diesem Punkt können Systeme miteinander verglichen und auf Unterschiede hin untersucht werden. Darüber hinaus ist die Erstellung von Baselines möglich, gegen die weitere Systeme geprüft und abgeglichen werden können.

Bild 3 zeigt den Vergleich zweier Systeme. Dabei wurde die Anzeige auf Unterschiede und unvollständige Datensätze gefiltert. So sieht man zum Beispiel, dass unzip nur auf einem der beiden Hosts installiert ist.

screenshot-drift-comparison.png
Bild 3: Gefilterte Ansicht von zwei Systemen in Drift Comparison

Darüber hinaus zeigt Bild 3, dass auf den beiden Systemen Pakete gleichen Namens jedoch für verschiedene Architekturen installiert sind. In diesem Fall trügt die Anzeige jedoch. Denn die drei genannten Pakete sind jeweils für i686 als auch für x86_64 auf beiden Systemen installiert.

In der getesteten Version bietet Drift noch keine Unterstützung multipler Werte für einen sogenannten fact. Es ist geplant diese Funktionalität in einem kommenden Release hinzuzufügen. Siehe dazu auch Bugzilla 1841561.

Ich tue mich ein wenig schwer damit, diese Anwendung zu bewerten. Auf der einen Seite bietet sie eine nette Möglichkeit Systeme miteinander zu vergleichen, auf der anderen Seite habe ich sie bis heute nicht vermisst. Für Vergleiche von Paketlisten und Konfigurationsdateien bevorzuge ich doch immer noch althergebrachte Kommandozeilen-Werkzeuge. Ich tendiere daher dazu — wie zuvor schon bei Patch — zu sagen: „Nette Zusatz-Funktion. Jedoch allein kein Grund Insights zu nutzen.“

Mit diesem Blick auf Patch und Drift endet meine Erkundung von Red Hat Insights. In einem folgenden Artikel werde ich schildern, wie die Systeme wieder aus Insights entfernt werden können und eine persönliche Bewertung vornehmen.

Red Hat Insights – Compliance

Dies ist der vierte Artikel in meiner Serie über Red Hat Insights. In diesem beschäftige ich mich mit der Möglichkeit meine Systeme auf Compliance prüfen zu können.

Hinweis: Um Systeme auf Compliance prüfen zu können, müssen neben dem insights-client auch die Pakete openscap-scanner und scap-security-guide auf den jeweiligen Systemen installiert sein.

Compliance Policy erstellen und Systeme zuweisen

Compliance bedeutet vereinfacht ausgedrückt, Regeln einzuhalten bzw. Vorgaben zu erfüllen. Demnach benötigt man eine Richtlinie mit einem Regelwerk gegen welches man seine Systeme abgleichen kann. Diese Regelwerke findet man häufig in Form von Standards wie z.B. PCI-DSS, HIPAA (en) oder SOX. Bevor man eine entsprechende Richtlinie (Policy) erstellt bzw. ausgewählt hat, gibt es daher im Insights-Dashboard auch noch nichts zu sehen (siehe Bild 1).

empty-rh-insights-compliance-menu.png
Bild 1: Einstieg in die Compliance-Funktion innerhalb von Red Hat Insights.

Als erstes ist daher eine Policy zu erstellen. Hierbei wird man von einem Assistenten durch die verschiedenen Dialoge geführt (siehe Bild 2-7). Für meinen Test habe ich eine SCAP-Policy für RHEL 7 Systeme mit dem „Standard System Security Profile for Red Hat Enterprise Linux 7“ erstellt (vgl. Bild 2 und 3). Selbstbewusst und ohne zu wissen, was mich erwartet, habe ich den Compliance Threshold auf 96 Prozent festgelegt (vgl. Bild 4). Im nächsten Schritt (Bild 5) werden die im Profil enthaltenen Regeln aufgelistet, mit der Möglichkeit sich zu jeder Regel eine detaillierte Beschreibung anzeigen lassen zu können. An dieser Stelle können einzelne Regeln deaktiviert werden, sofern man diese für unwichtig erachtet. Für diesen Test lasse ich alle Regeln aktiviert und bin auf das Ergebnis gespannt.

Bild 6 zeigt den Auswahldialog, in dem Systeme der zu erstellenden Policy zugewiesen werden. Grundsätzlich kann man verschiedene Policies für unterschiedliche Systeme verwenden oder einzelne Systeme nach mehren Policies auditieren lassen. Für diesen Test wurden alle 13 Systeme der aktuellen Policy zugewiesen.

Zum Abschluss des Assistenten wird noch einmal eine Zusammenfassung angezeigt (Bild 7), bevor die Policy erstellt wird. Anschließend kann man die soeben erstellte Policy in der Übersicht wiederfinden (vgl. Bild 8).

Compliance-Scan ausführen

In vorstehendem Abschnitt wurde eine SCAP-Policy erstellt und mit den vorhandenen Systemen verknüpft. Um die Systeme nun auf Compliance zu prüfen, ist der insights-client auf jedem System mit der Option --compliance zu starten. Der folgende Code-Block zeigt beispielhaft einen interaktiven Aufruf.

# insights-client --compliance
Running scan for xccdf_org.ssgproject.content_profile_standard... this may take a while
Uploading Insights data.
Successfully uploaded report for foo.example.com.
#

Möchte man seine Systeme regelmäßig mit dem Compliance-Scan prüfen, kann dies über einen Cronjob oder durch ein regelmäßig auszuführendes Ansible-Playbook gelöst werden.

Hinweis: Es handelt sich dabei nicht um den normalen Scan des insights-client, welcher täglich ausgeführt wird und Informationen an den SaaS-Dienst übermittelt.

Der hochgeladene Report ist wenige Minuten später im Compliance-Menü des Insights-Dashboards sichtbar.

Compliance-Reports im Insights-Dashboard

Das Insights-Dashboard bietet die aus den vorhergehenden Artikeln bekannte tabellarische Übersicht auch im Compliance-Menü. Hierüber gelangt man zu einer Ansicht, welche die Systeme mit ihrem jeweiligen Compliance-Score und der Anzahl nicht eingehaltener Regeln auflistet (siehe Bild 9).

Bild 10 zeigt einen Ausschnitt eines Reports für ein ausgewähltes System. Hier werden die Compliance-Regeln mit Name und ID aufgeführt. Darüber hinaus erkennt man auf einen Blick die Severity, ob der Test bestanden wurde und ob ein Ansible-Remediation-Playbook existiert.

In Bild 10 wurde eine Regel exemplarisch aufgeklappt, um die dahinter liegenden Informationen anzuzeigen. Diesen kann man entnehmen, welche Einstellungen vorhanden sein müssen, um diese konkrete Regel zu erfüllen. Man erhält an dieser Stelle daher nicht nur allgemeine Hinweise, sondern zudem explizite Handlungsempfehlungen. Darüber hinaus gibt es zu jeder Regel einen Hinweis, warum es sinnvoll erscheint, die empfohlenen Maßnahmen umzusetzen.

In diesem Test hat übrigens keines der 13 Systeme den vorgegebenen Compliance-Score erreicht. Dabei erreichten acht Systeme einen Score zwischen 80-85%, drei lagen bei 70-75% und zwei Systeme erreichten lediglich einen Score von 43-48%.

Das Ergebnis ist nun aber nicht so schlimm, wie es auf den ersten Blick aussieht. Denn einige der im verwendeten Profil geforderten Einstellungen sind in unserem Fall mitbestimmungspflichtig und müssen im Vorfeld einer möglichen Umsetzung mit dem Personalrat abgestimmt werden.

Fazit

Zwar sind unsere Systeme Stand heute an keine konkrete Policy gebunden, doch macht es in meinen Augen durchaus Sinn sich an einigen dieser Policies zu orientieren und deren sinnvoll erscheinenden Regeln einzuhalten. Ihnen blind zu folgen ist hingegen nicht sinnvoll. Oder wie mein Kollege sagte: „Man muss sich vielleicht nicht unbedingt wie eine Bank verhalten, wenn man keine Bank ist. :) „

Zur Erstellung von Compliance-Reports und der Ableitung einer Konfigurations-Baseline aus diesen hätte es des Insights-Dashboards nicht bedurft. Mit dem openscap-scanner und dem scap-security-guide können Reports für ausgewählte SCAP-Profile auch lokal auf jedem System erstellt und analysiert werden. Gerade bei der Erstellung einer Baseline lassen sich dabei Erkenntnisse von wenigen ausgewählten Systemen auf eine größere Gruppe von Hosts in der eigenen Infrastruktur übertragen.

Das Insights-Dashboard bietet an dieser Stelle den Mehrwert, alle relevanten Informationen an einer Stelle vorliegen bzw. verlinkt zu haben. Der Wechsel zwischen verschiedenen Anwendungen entfällt und Ergebnisse lassen sich leichter miteinander vergleichen.

Die verfügbaren Ansible-Remediation-Playbooks machen einen soliden Eindruck und sind geeignet, notwendige Einstellungen zu setzen, um eine konkrete Regel einzuhalten. Ich selbst führe diese jedoch nicht direkt in meiner Infrastruktur aus, sondern nutze sie lediglich als Ausgangspunkt für eigene Playbooks und Vorlagen. So fällt der Lerneffekt für mich persönlich größer aus.

Schwachstellen-Management mit Red Hat Insights

Nach der Einführung in Red Hat Insights und dem Blick auf den Advisor nehme ich in diesem Artikel das Schwachstellen-Management von Insights unter die Lupe.

shows-rh-insights-dashboard
Bild 1: Übersicht im Insights Dashboard

Bereits das Dasboard zeigt eine Box namens Vulnerability. Bild 1 zeigt, dass wir offensichtlich von 13 Schwachstellen betroffen sind. Diese sehen wir uns jetzt näher an. Dies geht wie üblich über den Link in der Box oder im Menü am linken Rand.

In der Vulnerability-Ansicht erwartet uns die gewohnte tabellarische Ansicht (vgl. Bild 2). Hier werden CVEs mit ihrer ID, dem Datum der Veröffentlichung, einer Bewertung des Impacts, dem CVSS base score und der Anzahl der betroffenen Systeme aufgeführt. Darüber hinaus hat man die Möglichkeit ein Business Risk und einen Status für ausgewählte oder alle CVEs zu vergeben (siehe gelbe Markierung in Bild 2).

rh-insights-vulnerability-view
Bild 2: Übersicht gefundener Schwachstellen mit Angabe von Impact, CVSS score und betroffener Systeme

Während man mit dem Business Risk festlegt, wie hoch man das Risiko einschätzt (vgl. Bild 3), hinterlegt man beim Status, wie mit der Behandlung der Schwachstelle(n) verfahren wird (siehe Bild 4).

edit-vulnerability-business-risk
Bild 3: Bewertung des Business Risk
rh-insights-edit-vulnerability-status
Bild 4: Mit Hilfe des Status kann der Bearbeitungsstand dokumentiert werden.

Wie im Advisor erhält man auch hier zu jeder CVE-ID eine Detailansicht mit Beschreibung des CVE, Bewertung und Übersicht der Angriffsvektoren (siehe Bild 5), sowie Verweisen zur Wissensdatenbank von Red Hat, wo ausführliche Informationen rund um den CVE und existierende Erratas zu finden sind.

rh-insights-cve-view-details
Bild 5: Detailansicht eines ausgewählten CVE

Bewertung des Schwachstellen-Managements

Stand heute betreiben wir kein aktives Schwachstellen-Management. Um ein gewisses Niveau an Sicherheit zu gewährleisten, nutzen wir ein Patchmanagement für RHEL, welches ich aus Bordmitteln unter Nutzung der Ansible Engine entwickelt habe. Dieses sorgt dafür, dass verfügbare Red Hat Security Advisories einmal im Monat auf allen RHEL-Systemen zwangsinstalliert werden, sofern diese noch fehlen.

Diesem Patch-Management ist es zu verdanken, dass auf den 13 angebundenen Testsystemen auch insgesamt nur 13 Schwachstellen gefunden wurden und darunter keine mit einem Score >= 8 gewesen ist.

Unter den im Dashboard aufgeführten Systemen waren Systeme einer Testinfrastruktur, die nicht an das zentrale Patchmanagement angebunden sind und nur unregelmäßig gepatcht werden. Insights hat mir hier vor Augen geführt, dass das Risiko viel zu groß ist, dass diese Systeme einfach vergessen werden. Deshalb wurden diese Hosts nun auch umgehend mit ins Patchmanagement aufgenommen.

Deutlich interessanter finde ich, dass mich Insights auf die CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 und CVE-2019-11091 aufmerksam gemacht hat.

Diese Schwachstellen haben gemeinsam, dass sie sich nicht einfach durch die Installation eines Updates schließen lassen. Da es sich um virtuelle Maschinen (VM) auf einem vSphere-Cluster handelt ist eine Kombination von Maßnahmen erforderlich, um die Schwachstellen zu mitigieren.

In diesem konkreten Fall müssen die betroffenen VMs lediglich einmal Aus- und wieder Eingeschaltet werden, da ein Teil der Mitigation in vSphere bereits vorhanden war. Dadurch werden neue CPU-Funktionen an das Gast-Betriebssystem propagiert und die Mitigation ist abgeschlossen.

Leider muss ich eingestehen, dass diese Schwachstellen ohne Insights noch lange Zeit unentdeckt geblieben wären.

Nun muss ich davon ausgehen, dass in unserer Umgebung noch weitere verwundbare Systeme existieren. Da ich diese nicht an Insights anbinden darf, werde ich diese mit einem von Red Hat bereitgestellten Skript ausfindig machen. Das Red Hat eben solche Skripte zur Verfügung stellt, um sich auch ohne Insights wirksam selbst helfen zu können, schätze ich an Red Hat sehr. Es gibt da draußen noch einige Unternehmen, die diesem Beispiel ruhig folgen dürfen.

Persönlich halte ich aktives Schwachstellen-Management für sinnvoll. Nur durch kontinuierliche Kontrolle können Schwachstellen gefunden, bewertet und entsprechend behandelt werden. Gleichzeitig dient es der Überprüfung, ob bzw. wie bereits getroffene Maßnahmen zur strukturellen Verbesserung des Sicherheits-Niveaus (z.B. ein Patchmanagement) wirken.

Bild 6: Alle erkannten Schwachstellen wurden geschlossen

Bild 6 zeigt, dass gegenwärtig keine offenen Schwachstellen mehr existieren. Dies sollte stets das Ziel sein.

Mir selbst hat der Test des Schwachstellen-Managements Freude bereitet und die gefundenen Schwachstellen konnten innerhalb kurzer Zeit geschlossen werden.

Der nächste Artikel dieser Reihe wird sich dem Compliance-Service widmen.