Schlagwortarchiv: Planet

Tag für den Ubuntuusers.de Planeten.

Erkundung von Red Hat Insights — Advisor

3 Antworten

In der Einführung in Red Hat Insights habe ich kurz umrissen, worum es sich bei dieser SaaS-Anwendung handelt und wie man RHEL-Systeme einrichtet, um den Dienst nutzen zu können. Dieser Artikel widmet sich dem Menüpunkt „Advisor“ im Insights-Dashboard.

Das Insights-Dashboard ist erreichbar unter der URL: https://cloud.redhat.com/insights/dashboard

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

Das Dashboard gibt einen Überblick darüber, wie viele Systeme aktuell in Insights eingebunden sind, ob es Probleme mit bekannten Systemen gibt, den Patch-Status, Schwachstellen, Compliance-Status, durchgeführte Remediations und Advisor recommendations. Letztere sind Gegenstand dieses Artikels und werden im Folgenden einer genauen Betrachtung unterzogen.

Advisor recommendations bedeutet auf Deutsch soviel wie „Empfehlungen eines Ratgebers“. Der Ratgeber (Advisor) ist in diesem Fall die Firma Red Hat, welche mit Machine Learning Algorithmen, ihrer Erfahrung und dem aus Kunden-Support-Fällen gesammelten Wissen, Ratschläge zur Systemkonfiguration und Hinweise auf Konfigurationsfehler unterbreitet.

Das Dashboard in Bild 1 zeigt, dass Insights für die 13 verbundenen Systeme insgesamt 5 Empfehlungen bereithält, mit denen die Systemkonfiguration verbessert werden kann.

Über das Menü am linken Rand oder den Link im Feld der Advisor recommendations gelangt man auf die Unterseite des Ratgebers, welcher die Empfehlungen in einer Übersicht mit Bewertung darstellt (siehe Bild 2).

Show Advisor recommendations view
Bild 2: Übersicht der Advisor Recommendations

Die tabellarische Übersicht in Bild 2 zeigt die Empfehlungen mit einer kurzen Beschreibung, seit wann diese Empfehlung im Insights existiert, eine Risikobewertung, wie viele Systeme davon betroffen sind und ob ein Ansible-Playbook existiert, mit dem das beschriebene Problem in der eigenen Infrastruktur behoben werden kann.

Auf die einzelnen Funktionen der Seite aus Bild 2 werde ich im Folgenden näher eingehen, während ich eine Bewertung der angezeigten Empfehlungen vornehme.

Als erstes sticht mir der zweite Punkt ins Auge. Mit einem Klick auf den Pfeil vor der Beschreibung werden weitere Details eingeblendet (siehe Bild 3). Hier erfährt man, dass es vermutlich kein Problem darstellt, wenn man zum jetzigen Zeitpunkt kein In-Place-Upgrade auf RHEL 8 durchführt und dass ein Upgrade vermutlich ein Wartungsfenster mit Downtime benötigt. Weitere Informationen bietet der verlinkte Knowledge-Base-Artikel.

Zeigt wie ein Eintrag deaktiviert werden kann
Bild 3: Detailansicht eines Eintrags und Funktion zum Deaktivieren dieser Empfehlung

Ich persönlich bewerte die in Bild 3 ausgewählte Empfehlung als unnütz. RHEL 7 ist immer noch ein Release unter Wartung, welches Sicherheits-Aktualisierungen erhält. Dass RHEL 8 inzwischen in Version 8.2 erschienen ist und mit neuen Funktionen und Verbesserungen aufwartet, ist bekannt, aber kein Grund für übereilte Upgrades. Darüber hinaus führen wir im BITS in der Regel keine In-Place-Upgrades durch. Stattdessen installieren wir eine neue virtuelle Maschine (VM), migrieren Daten und Dienste und schalten anschließend den alten Host ab.

Zum Glück muss man sich von unbedeutenden Meldungen nicht ewig nerven lassen. Wie in Bild 3 zu sehen, bietet Insights die Möglichkeit, Meldungen einfach zu deaktivieren. Sehr schön empfinde ich dabei, dass man einen Grund angeben kann (siehe Bild 4). So wird man auch nach Wochen oder gar Monaten daran erinnert, warum man einen Eintrag deaktiviert hat.

Shows justification note dialog
Bild 4: Insights bietet die Möglichkeit einen Grund für die Deaktivierung einer Empfehlung anzugeben

Anschließend wird der Eintrag in der Übersicht nicht mehr angezeigt (vgl. Bild 5).

Show only enabled recommendations
Bild 5: Mit dem automatisch aktivierten Filter werden nur noch aktive Einträge angezeigt. Deaktivierte Elemente werden ausgeblendet.

Nach dem Deaktivieren eines Eintrags kam mir sofort die Frage in den Sinn, wo ich diese denn wohl wiederfinden kann. Dies ist über die Filtereinstellungen im oberen Bereich der Seite möglich (siehe Bild 6).

Show disabled recommendations
Bild 6: Anzeige der deaktivierten Elemente

An dieser Stelle möchte ich erwähnen, dass das Insights-Team die entsprechende Empfehlung nach meiner Rückmeldung komplett aus Insights entfernt hat. Schön, dass man als Kunde hier Gehör findet.

Bewertung der weiteren Empfehlungen

Es bleiben noch vier weitere Empfehlungen, die ich im Folgenden für meine konkrete Umgebung bewerten will. Alle vier haben gemein, dass ich vermutlich nie bewusst nach diesen Konfigurationseinstellungen gesucht hätte. Und zumindest zwei sind dabei, bei denen ein genauerer Blick lohnt. Und mit diesen fange ich an.

OS boot failure occurs due to uncertain disk discovery order when /dev/sdN format device names are used in /etc/fstab

Hier wird auf eine Konfiguration hingewiesen, die im ungünstigsten Fall den Bootvorgang eines Hosts verhindert. Eine Einstufung als „Important“ ist daher nachvollziehbar. Lässt ein System, das nicht startet, doch regelmäßig den Puls und Adrenalinspiegel eines Sysadmin steigen.

Um mir das (mögliche) Problem näher erläutern zu lassen, rufe ich aus der Detailansicht den dort verlinkten Knowledge-Base-Artikel auf. Dabei fällt mir auf, dass, obwohl ich ausschließlich RHEL 7 Systeme verwende, auf einen Artikel verlinkt wird, der nur für RHEL 6 gilt. Immerhin findet sich in diesem eine Referenz zum entsprechenden Artikel für RHEL 7. Hier hätte man gleich passend verlinken können.

Wie ist dieser Eintrag nun für uns zu bewerten?

Die beiden betroffenen Systeme sind schon einige Zeit in Betrieb und haben bereits mehrere Neustarts ohne Probleme überstanden. Das potenzielle Problem scheint sich zumindest in unserer Umgebung nicht negativ auszuwirken.

Insights bietet für diesen Fall die Erstellung eines Ansible-Remediation-Playbooks an, mit welchem das Konfigurationsproblem behoben werden kann. Da ich in diesem Fall nicht der System-Betreiber für die beiden aufgeführten Systeme bin, kann ich dies jedoch nicht ohne Rücksprache mit dem entsprechenden Kollegen zur Ausführung bringen.

Ich habe den entsprechenden System-Betreiber über dieses Ereignis benachrichtigt, ihm die mögliche Lösung weitergeleitet und ihm die Entscheidung überlassen, wie er weiter damit verfahren möchte. Dieser hat sich für den Hinweis bedankt und das Problem sofort behoben.

In einem späteren Artikel werde ich mich noch damit beschäftigen, wie ich Kollegen Zugriff auf das Insights-Dashboard gewähren kann, so dass diese ihre Systeme darin selbst verwalten und untersuchen können.

Traffic occurs or services are allowed unexpectedly when firewall zone drifting is enabled

Dies ist aus meiner Sicht wirklich ein interessanter Fund. Denn er weist darauf hin, dass womöglich Kommunikation durch die lokale Host-Firewall erlaubt wird, obwohl dies nicht beabsichtigt ist (vgl. Bild 7).

Show further details of a recommendation
Bild 7: Recommendations lassen sich über den Pfeil am Anfang einer Zeile aufklappen, um weitere Informationen zu sehen.

Auch hier liefert der verlinkte Knowledge-Base-Artikel ausführliche Informationen.

Ich werde diesen Punkt auf jeden Fall mit dem betroffenen Kollegen thematisieren. Ich denke, dass hier ein kleiner Wissenstransfer angebracht ist, da nach meiner Einschätzung auch weitere Kollegen sich des konkreten Verhaltens nicht bewusst sind. Von daher bewerte ich diesen Ratschlag als gut und sinnvoll.

Ein Punkt übrigens, der mir am Insights-Dashboard allgemein gut gefällt, ist, dass ich jederzeit anzeigen lassen kann, wie viele Systeme betroffen sind und noch wichtiger, welche dies sind (siehe Bild 8).

Show affected systems
Bild 8: Ansicht der betroffenen Systeme

Decreased security: httpd serving unencrypted (HTTP) traffic

Dies ist eine Meldung mit niedriger Risiko-Einstufung und so werden wir sie auch behandeln. Bei den betroffenen Systemen handelt es sich um Test-Systeme. Der System-Betreiber hat hier bewusst auf die Implementierung von TLS/SSL verzichtet.

Decreased security: Yum GPG verification disabled (third-party repos)

Dieser Punkt stellt sich wider Erwarten als interessant heraus. Wir betreiben eigene Repositories, welche nur innerhalb unserer Einrichtung verwendet werden. Um den Aufwand zu minimieren, verzichten wir bei diesen auf die Signierung der Pakete.

Überraschend ist jedoch der Umstand, dass bei einigen Hosts auch die GPG-Signatur-Überprüfung für ein gespiegeltes RHEL-Repo deaktiviert ist. Um dies herauszufinden, muss man sich nicht erst zu einem betroffenen System verbinden und dies untersuchen. Es genügt ein Klick auf den Hostnamen in der Liste der betroffenen Systeme (vgl. Bild 8), um zu einer Ansicht zu gelangen, die neben einer ausführlichen Beschreibung auch einen Lösungsweg anbietet.

Insights bietet nicht nur Unterstützung dabei herauszufinden, was falsch ist, sondern auch wie man das Problem abstellt. Ich werde im Laufe des Tests fortlaufend überprüfen, wie häufig Insights hier mit sinnvollen Lösungen aufwarten kann.

Slow system boot when storage devices do not support WRITE SAME command

Neu hinzugekommen und daher in obigen Bildern noch nicht enthalten ist dieser Hinweis auf ein Problem, welches die Leistung des Systems beim Bootvorgang reduzieren kann.

Insights hat diesen Incident erkannt, nachdem das betroffene System neugestartet wurde, der insights-client erneut gelaufen ist und Insights eine entsprechende Meldung in /var/log/messages gefunden hat.

Das Problem selbst ist uns seit langem bekannt. Es fällt allerdings in die Kategorie: „Gucken wir uns an, wenn wir mal Zeit haben.“ Also vermutlich nie. Zum Glück booten unsere VMs innerhalb weniger Sekunden und es wird hier kein Problem wahrgenommen.

Zwischenfazit

Ich stehe noch am Anfang unseres Tests. Die bisherigen Erkenntnisse lassen daher noch keine abschließende Bewertung zu, ob ein dauerhafter und ausgedehnter Einsatz von Insights gerechtfertigt ist.

Als erster Eindruck bleibt eine benutzerfreundliche Oberfläche, welche eine intuitive Bedienung gestattet. Der Advisor enthält bis jetzt neben einigen belanglosen Empfehlungen auch interessante Hinweise.

Artikel aus dieser Serie

  1. Einführung in Red Hat Insights
  2. Erkundung von Red Hat Insights — Advisor
  3. Schwachstellen-Management mit Red Hat Insights
  4. Red Hat Insights — Compliance
  5. Red Hat Insights — Patch and Drift
  6. Persönliche Bewertung von Red Hat Insights

Einführung in Red Hat Insights

6 Antworten

Bei Red Hat Insights handelt es sich um eine SaaS-Anwendung, welche Nutzern von RHEL-Subskriptionen kostenlos zur Verfügung steht.

Dieser Artikel bietet eine kurze Einführung in Red Hat Insights, zeigt, wie RHEL-Systeme in den Cloud-Dienst eingebunden werden und führt wichtige Dokumente und Quellen zum Dienst auf.

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

Was ist Red Hat Insights?

Red Hat Insights, im folgenden Text auch kurz Insights genannt, ist ein von der Firma Red Hat angebotener Cloud-Service, welcher der proaktiven Analyse von Umgebungen mit Red Hat Enterprise Linux (RHEL) dient. Als Ergebnis dieser proaktiven Analyse erhält der Systemadministrator Hinweise auf vorhandene Konfigurationsprobleme, Sicherheitslücken und Schwachstellen sowie Handlungsempfehlungen, wie diese behoben werden können.

An Insights angebundene Systeme werden vom lokal installierten Insights-Client gescannt und gegen ein Regelwerk abgeglichen, um potenzielle Risiken in Bezug auf die System-Leistung, Skalierbarkeit, Verfügbarkeit und Sicherheit zu identifizieren und zu melden. Red Hat ist dabei bestrebt, die Sammlung persönlicher Daten zu vermeiden.

Neben dem Reporting können über diesen Service auch Ansible-Playbooks zur Mitigation erkannter Probleme generiert und von einer on-premise vorhandenen Ansible Engine ausgeführt werden. Das Regelwerk wird von der Firma Red Hat gepflegt und stetig erweitert.

Seit 2019 ist Insights in allen aktiven RHEL-Subskriptionen enthalten. Somit entstehen keine zusätzlichen Kosten durch die Nutzung des Dienstes.
Insights kann in RHEL-Installation verwendet werden, unabhängig davon, ob diese on-premise, in privaten oder öffentlichen Clouds betrieben werden.

Die Produktdokumentation und eine FAQ-Sektion finden sich unter den folgenden URLs:

Wer noch keine Zugangsdaten für die vorstehend verlinkten Seiten besitzt, kann sich für eine kostenlose Red Hat Developer Subscription registrieren. Mit dieser erhält man auch Zugriff zur Red Hat Wissensdatenbank.

Ob Red Hat Insights den Mehrwert bietet, den es verspricht, versuche ich gerade in einem zeitlich und vom Umfang her begrenzten Test herauszufinden. Mit den folgenden Schritten könnt ihr euch auch selbst ein Bild davon machen.

Datenschutz und Datensicherheit

Für uns ist die Nutzung eines SaaS-Dienstes wie Insights nicht ganz unproblematisch. Wer die vorstehend verlinkte Dokumentation liest, wird schnell feststellen, dass zur Erbringung des Dienstes jeder angebundene Host eine Menge Daten sammelt und an den Cloud-Dienst überträgt. Dies ist einerseits erforderlich, damit der Service funktioniert. Denn ohne zu analysierende Daten kann es keine Hinweise und Empfehlungen geben. Anderseits kann man anhand der übertragenen Daten eine ziemlich genaue Karte der Netzwerkinfrastruktur zeichnen.

Insights selbst wird auf OpenShift Dedicated in AWS (US East) gehostet. Aktuell gibt es keinerlei Pläne, den Dienst in weiteren Regionen zu hosten.

Der insights-client bietet mit den Optionen --no-upload bzw. --offline die Möglichkeit, Daten lokal zu sammeln, ohne diese an den Cloud-Dienst zu übertragen. Als Sysadmin hat man so die Möglichkeit, im Vorfeld zu inspizieren, welche Daten gesammelt wurden. Dazu gibt es die Möglichkeit, eine Blacklist zu pflegen und zu spezifizieren, welche Daten von der Sammlung und Übertragung auszuschließen sind.

Die folgende Datei beinhaltet eine Baumansicht der Dateien und Informationen, die ein insights-client auf einem System mit installiertem MediaWiki gesammelt hat. Darunter befinden sich z.B. diverse Konfigurationsdateien und mit Hilfe verschiedener Kommandos gesammelte Informationen.

inights-foo.example.com-20200604055128.txtHerunterladen

Stellt man sich den Betrieb von 100 RHEL-Servern vor, welche verschiedenste Dienste erbringen, wird jedoch deutlich, dass eine manuelle Kontrolle und Pflege individueller Blacklists für alle Systeme nicht leistbar ist. Zumal sich das Regelwerk, welches die zu sammelnden Daten bestimmt, dynamisch ändert und eine Prüfung vor jedem Upload erfolgen müsste.

Leider existiert Stand heute keine on-premise Appliance, welche die Nutzung des Dienstes innerhalb des eigenen Perimeters ermöglichen würde. Auch eine Whitelist für den insights-client existiert (noch) nicht. Letzteres würde dem Nutzer noch mehr Kontrolle über die Daten-Sammlung/-Übertragung geben. So könnte er einmal definieren, was übertragen werden darf und müsste nicht fürchten, dass bereits einige Tage später weitere Daten ohne sein Wissen gesammelt und übertragen werden.

Sowohl den Wunsch nach einer on-premise Appliance, als auch den Vorschlag zur Einführung einer Whitelist, habe ich dem Insights-Team gemeldet. Die Meldung wurde nach meinem Empfinden konstruktiv aufgenommen. Und auch wenn mein größter Wunsch nach der Appliance kurz- und mittelfristig nicht realisiert werden wird, fühle ich mich als Nutzer ernst genommen und habe das Gefühl, dass mein Feedback willkommen ist.

Red Hat beschreibt in oben verlinkter Dokumentation, dass der Dienst keine persönlichen Daten sammelt. So sind /etc/{passwd,group,shadow} sowie /home nicht in den gesammelten Daten enthalten. Auch werden keine vollständigen Logdateien an den Dienst übertragen. Generell legt Red Hat sehr viele Informationen über den Dienst offen und handelt hier sehr transparent. Das Unternehmen verhält sich in dieser Hinsicht vorbildlich.

Wenn ein Client keine Daten mehr übermittelt, werden die zuletzt von ihm empfangenen Daten nach 14 Tagen automatisch gelöscht. Wird ein Client aus Insights entfernt, werden die für diesen Client gespeicherten Daten ebenfalls gelöscht.

Nichtsdestotrotz verliert man die Gewalt über einmal übertragene Daten. Man muss dem Anbieter wie bei jedem SaaS-Dienst vertrauen, dass er sich an die eigenen Zusicherungen und Versprechen hält.

Möchtet ihr Insights in eurer Dienststelle oder eurem Betrieb testen, rate ich euch deshalb, sprecht zuerst mit der/dem Informationssicherheitsbeauftragten und Datenschutzbeauftragten und eurer/eurem Vorgesetzten über das Thema.

Trotz aller Bedenken bietet Insights die Chance, Kenntnis über Probleme und Schwachstellen zu erlangen, die bisher unbekannt sind und ein größeres Sicherheitsrisiko darstellen als die regelmäßige Datenübertragung an Insights. Ob der Nutzen überwiegt, muss allerdings jede Organisation für sich selbst beurteilen.

Einrichtung von Red Hat Insights auf Red Hat Enterprise Linux

Die folgenden Schritte setzen voraus, dass die verwendeten RHEL-Systeme registriert sind und über eine gültige Subskription verfügen.

Manuelle Einrichtung

Um den vollen Funktionsumfang von Insights nutzen zu können, werden die folgenden Pakete installiert:

$ sudo yum -y install openscap-scanner scap-security-guide insights-client

Die Installation des OpenSCAP-Scanners und des SCAP-Security-Guides sind optional. Diese Pakete sind erforderlich, um den Compliance Service nutzen zu können. Da der insights-client in RHEL 8 bereits integriert ist, muss dieser hier nicht gesondert installiert werden.

Um die Einrichtung des insights-client abzuschließen und gesammelte Daten an den SaaS-Dienst zu übertragen, genügt es, das folgende Kommando auszuführen:

$ sudo insights-client --register

Automatisierte Einrichtung mit Ansible

Um die notwendigen Schritte zur Einrichtung nicht auf jedem Host manuell ausführen zu müssen, kann folgendes Ansible-Playbook verwendet werden.

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

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

  - name: Register insights-client
    command: insights-client --register

Für meine Zwecke reicht obiges Playbook. Alternativ gibt es auf Ansible Galaxy eine Rolle mit deutlich größerem Funktionsumfang: redhatinsights.insights-client

Sind die Systeme eingerichtet und registriert, ist es an der Zeit, sich unter der URL https://cloud.redhat.com einzuloggen und das Insights Dashboard zu erkunden.

Startseite unter https://cloud.redhat.com

An dieser Stelle lasse ich euch vorerst mit dem Dashboard allein. Im nächsten Artikel dieser kleinen Reihe werde ich mich mit dem Inisghts Advisor befassen.

Artikel aus dieser Serie

  1. Einführung in Red Hat Insights
  2. Erkundung von Red Hat Insights — Advisor
  3. Schwachstellen-Management mit Red Hat Insights
  4. Red Hat Insights — Compliance
  5. Red Hat Insights — Patch and Drift
  6. Persönliche Bewertung von Red Hat Insights

CVE — Ist mein RHEL-System betroffen? Was kann ich tun?

Schreibe eine Antwort

Regelmäßig berichtet die IT-Fachpresse über neue Common Vulnerabilities and Exposures (CVE). Dieser Artikel möchte euch eine kleine Hilfestellung geben, um herauszufinden, ob euer RHEL-System von einem CVE betroffen ist.

In unserem Rechenzentrum betreibe ich ein Patchmanagement mit Ansible für unsere RHEL-Systeme. Dieses stellt sicher, dass einmal im Monat verfügbare Red Hat Security Advisories (RHSA) auf allen RHEL-Systemen installiert werden. Damit gewährleisten wir ein Mindestmaß an Sicherheit. Selbstverständlich können darüber hinaus alle System-Betreiber*innen zu jeder Zeit verfügbare Updates auf den von ihnen betreuten Servern installieren.

Wie eingangs erwähnt berichtet in der Regel die IT-Fachpresse über neue Sicherheitslücken und Schwachstellen. Diese Meldungen enthalten häufig auch die sogenannten CVE-Nummern, welche eine Schwachstelle/Sicherheitslücke eindeutig identifizieren. Mit Hilfe dieser Nummer könnt ihr feststellen, ob euer RHEL-System verwundbar ist und ob ggf. schon ein Patch existiert, welcher das Problem behebt.

Für diesen Text habe ich exemplarisch zwei Schwachstellen ausgewählt:

Nutzung der Red Hat CVE-Datenbank

Red Hat betreibt eine CVE-Datenbank unter der URL: https://access.redhat.com/security/security-updates/#/cve

Hier kann man nach einer CVE-Nummer suchen und zu weiterführenden Informationen zu einer Schwachstelle gelangen (siehe Abb. 1). Hinter dem Link in der Tabelle verbirgt sich eine Detail-Seite für den jeweiligen CVE.

screenshot-cve-database.png
Abb. 1: Screenshot der Red Hat CVE-Datenbank für CVE-2020-0543

Liefert eine Suche keine Treffer zurück, kann dies verschiedene Ursachen haben (siehe Abb. 2).

screenshot-rh-cve-2020-0595.png
Abb. 2: Red Hat CVE-Datenbank liefert nicht zu jeder CVE-Nummer einen Treffer

Nutzung des Paket-Managers auf der Kommandozeile

Mit Hilfe des Paket-Managers YUM kann für jedes System individuell geprüft werden, ob für einen CVE ein entsprechender Fix existiert. Der folgende Codeblock veranschaulicht dies:

$ sudo yum updateinfo list --cve CVE-2020-0543                                
[...]
RHSA-2020:2432 Moderate/Sec. microcode_ctl-2:2.1-61.6.el7_8.x86_64
updateinfo list done
$
$ sudo yum updateinfo list --cve CVE-2020-13777
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
updateinfo list done
$

Die erste Abfrage nach CVE-2020-0543 zeigt, dass es ein Security-Advisory für ein installiertes Paket gibt, welches von der Schwachstelle betroffen ist. Gegen CVE-2020-13777 ist das System hingegen nicht verwundbar. Dies ist in diesem Fall der Tatsache geschuldet, dass GnuTLS auf dem genutzten System nicht installiert ist.

Mit Hilfe des folgenden Befehls lassen sich auch auf der Kommandozeile weitere Informationen zu einem CVE abrufen:

$ sudo yum updateinfo info --cve CVE-2020-0543 
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager

===============================================================================
  Moderate: microcode_ctl security, bug fix and enhancement update
===============================================================================
  Update ID : RHSA-2020:2432
    Release : 0
       Type : security
     Status : final
     Issued : 2020-06-09 18:20:28 UTC
       Bugs : 1788786 - CVE-2020-0548 hw: Vector Register Data Sampling
	    : 1788788 - CVE-2020-0549 hw: L1D Cache Eviction Sampling
	    : 1827165 - CVE-2020-0543 hw: Special Register Buffer Data Sampling (SRBDS)
       CVEs : CVE-2020-0543
	    : CVE-2020-0548
	    : CVE-2020-0549
Description : Security Fix(es):
            : 
            : * hw: Special Register Buffer Data Sampling
            :   (SRBDS) (CVE-2020-0543)
            : 
            : * hw: L1D Cache Eviction Sampling (CVE-2020-0549)
            : 
            : * hw: Vector Register Data Sampling
            :   (CVE-2020-0548)
            : 
            : For more details about the security issue(s),
            : including the impact, a CVSS score,
            : acknowledgments, and other related information,
            : refer to the CVE page(s) listed in the References
            : section.
            : 
            : Bug Fix(es):
            : 
            : * Update Intel CPU microcode to microcode-20200602
            :   release, addresses:
            :   - Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0)
            :     microcode from revision 0x61f up to 0x621;
[...]

CVE durch Update schließen

Ich persönlich empfehle in der Regel, das gesamte System mittels sudo yum -y upgrade zu aktualisieren und so alle installierten Pakete auf den aktuellsten Stand zu bringen. Es ist jedoch auch möglich, nur die Updates zu installieren, die notwendig sind, um eine spezielle Schwachstelle zu schließen. Auch hierfür wird wieder die CVE-Nummer genutzt:

$ sudo yum upgrade --cve CVE-2020-0543
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
 --> mock-2.2-1.el7.noarch from @epel removed (updateinfo)
 --> unbound-libs-1.6.6-3.el7.x86_64 from @rhel-7-server-rpms removed (updateinfo)
 --> mock-2.3-1.el7.noarch from epel removed (updateinfo)
 --> unbound-libs-1.6.6-4.el7_8.x86_64 from rhel-7-server-rpms removed (updateinfo)
1 package(s) needed (+0 related) for security, out of 3 available
Resolving Dependencies
--> Running transaction check
---> Package microcode_ctl.x86_64 2:2.1-61.el7 will be updated
---> Package microcode_ctl.x86_64 2:2.1-61.6.el7_8 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================================
 Package                              Arch                          Version                                   Repository                                 Size
==============================================================================================================================================================
Updating:
 microcode_ctl                        x86_64                        2:2.1-61.6.el7_8                          rhel-7-server-rpms                        2.6 M

Transaction Summary
==============================================================================================================================================================
Upgrade  1 Package

Total size: 2.6 M
Is this ok [y/d/N]:

Obigem Code-Block ist zu entnehmen, dass Updates für insgesamt drei Pakete zur Verfügung stehen. Um CVE-2020-0543 zu schließen, wird jedoch nur das Paket microcode_ctl aktualisiert. Die beiden anderen Pakete werden nicht verändert.

Weitere Informationsquellen zu diesem Thema

Thunderbird-Daten auf neue Rechner/Installationen übertragen

1 Antwort

Es ist so einfach und doch suche ich jedes Mal erneut. Darum verlinke ich hier die deutschsprachige Anleitung von Mozilla: Thunderbird-Daten auf einen neuen Rechner übertragen

Ergänzend zu obiger Anleitung dokumentiere ich an dieser Stelle, wie die Einstellungen des Add-Ons Enigmail zur Übertragung auf einen neuen Rechner gesichert werden können.

Dazu geht man in die Add-On-Einstellungen von Enigmail und öffnet die Registerkarte „Einstellungen übertragen“. Anschließend lässt man sich vom Export-Assistenten durch den Prozess führen.

  • Einstellungen übertragen
  • Export-Datei angeben
  • Fertigstellen

Firefox-Profil auf neue Rechner/Installationen umziehen

Schreibe eine Antwort

Es ist eigentlich so einfach und doch suche ich jedes Mal erneut danach. Deshalb möchte ich hier kurz die Links zu den deutschsprachigen Mozilla-Artikeln festhalten, welche den Umgang und Umzug von Firefox-Profilen erläutern.

tmux und tmux-xpanes

3 Antworten

Die beiden genannten Anwendungen ergänzen erst seit kurzer Zeit meine SysAdmin-Werkzeugsammlung und werden im folgenden kurz vorgestellt.

Um Programme auch nach dem Beenden einer SSH-Sitzung weiterlaufen lassen zu können, habe ich in der Vergangenheit unter verschiedenen Distributionen das Programm screen verwendet. Mit dem Release von RHEL 7.6 (en) ist screen deprecated (en). Da es somit in RHEL 8 nicht mehr enthalten ist, wurde es Zeit, sich nach einer Alternative umzusehen, welche ich in tmux gefunden habe.

Mit tmux werden die gleichen Anforderungen erfüllt, welche ich an screen gestellt habe und ermöglicht es darüber hinaus, innerhalb eines Terminals oder einer Terminalemulation verschiedene virtuelle Konsolensitzungen zu erzeugen und zu verwalten. Sitzungen können getrennt („detach“) und später weitergeführt werden („attach“). Auch die Möglichkeit, ein Fenster vertikal und horizontal in mehrere „panes“ zu unterteilen, finde ich sehr praktisch.

Die Möglichkeit, ein tmux-Fenster in verschiedene Bereiche zu unterteilen, brachte mich zu der Frage, ob es damit nicht auch möglich ist ein weiteres Werkzeug aus meiner Sammlung abzulösen.

Cluster SSH (en) ermöglicht es, auf einfache Weise parallele SSH-Sitzungen zu mehreren Hosts aufzubauen. Für jeden Host wird dabei ein eigenes xterm-Fenster geöffnet und Befehle können zeitgleich an alle verbundenen Hosts gesendet werden.

Zwar bietet auch tmux mit der Option „synchronize-panes on“ die Möglichkeit, Befehle gleichzeitig an mehrere „panes“ zu senden, doch müssen diese und die SSH-Sitzungen darin zuvor manuell hergestellt werden, was sich als recht umständlich erwies.

Hier betritt nun tmux-xpanes (en) von Yasuhiro Yamada die Bühne, welches diesen Arbeitsschritt enorm erleichtert.

Ich pflege recht umfangreiche ssh_config(5)-Dateien, welche sich hervorragend durch tmux-xpanes nutzen lassen. Folgendes Bild soll die Anwendungsmöglichkeiten veranschaulichen:

Quelle: https://raw.githubusercontent.com/wiki/greymd/tmux-xpanes/img/movie_v4.gif

Eine umfassende Beschreibung der hier vorgestellten Werkzeuge würde den Umfang eines Artikels sprengen. Daher sei für weiterführende Informationen auf die folgende Linksammlung verwiesen.

Linksammlung zu tmux und tmux-xpanes

Erfahrungsbericht zum Deployment meines Blogs mit Ansible

Schreibe eine Antwort

Vor ziemlich genau zwei Jahren habe ich in „Konzept zum Deployment meines Blogs mit Ansible“ geschrieben, wie ich diesen Blog mit Hilfe von Ansible ausgehend von einem bestehenden Backup auf einen neuen Server deployen bzw. wiederherstellen möchte.

Seither habe ich das dort beschriebene Verfahren mehrfach angewendet und möchte heute an dieser Stelle meine Erfahrungen mit euch teilen.

Umgebung

Wie schon vor zwei Jahren basiert mein Ansible Control Node auf einer RHEL 7 VM. Im Unterschied zu damals kommt heute statt Ansible in der Version 2.4.2 eine aktuell unterstützte Version 2.9.6 zum Einsatz.

Das Zielsystem war damals Ubuntu Bionic Beaver. Zwischendurch habe ich diesen Blog nach dem Konzept bereits auf CentOS/RHEL 7 sowie Debian 10 eingerichtet.

Die weiteren Rahmenbedingungen entsprechen der Testumgebung aus 2018. Auch verwende ich heute noch die gleichen Module wie vor zwei Jahren:

ModulStatusVerwendung
aptstableinterfaceVerwaltet APT-Pakete
unarchivepreviewEntpackt Archiv-Dateien und kopiert sie ggf. vorher auf das Zielsystem
copystableinterfaceKopiert Dateien auf entfernte Rechner
filestableinterfaceErstellt Dateien, Verzeichnisse, symbolische Links und setzt deren Attribute
mysql_dbpreviewHinzufügen von MySQL-Datenbanken (aus Backup)
mysql_userpreviewHinzufügen (und Entfernen) von Benutzern in MySQL-Datenbanken

In der Tabelle ist zu erkennen, dass jene Module, die 2018 den Status preview hatten, diesen auch heute noch besitzen. Ich persönlich finde es schade, dass es keines dieser Module innerhalb von zwei Jahren zu einem stableinterface gebracht hat.

Darüber hinaus schleppen einige Module wie mysql_db noch ein paar ziemlich alte Bugs mit sich herum. Darunter z.B. dieser aus dem Jahre 2016. Zwar kann ich nicht mit Sicherheit sagen, ob dieser seit 2.4.2 bereits gefixt wurde. In Version 2.9.6 ist er jedenfalls vorhanden. Als Workaround habe ich den MySQL-Dump zuvor entpackt und dann im Modul verwendet, wodurch eine erheblich größere Datenmenge über das Netzwerk übertragen werden muss.

Erfahrungen der letzten zwei Jahre

Am Status der Module hat sich leider nichts geändert. Positiv sei hier jedoch angemerkt, dass sämtliche Module noch existieren und weiterhin genutzt werden können. So hatte ich zumindest keinen Aufwand, mir zwischenzeitlich neue Module suchen zu müssen, um die gestellte Aufgabe erledigen zu können.

Grundsätzlich klappt das Deployment bzw. die Wiederherstellung meines Blogs aus einem Backup mittels der Ansible-Rolle gut. Je nach verwendetem Zielsystem sind kleinere Anpassungen notwendig, da einige Pakete in CentOS anders benannt sind als in Debian, oder sich der Name in einer neueren Version der Distribution leicht geändert hat. Dieser Umstand ist jedoch nicht Ansible anzulasten, sondern rührt von den jeweiligen Paketnamen der unterschiedlichen Distributionen her.

Was mir persönlich überhaupt nicht gefällt, ist dass Ansible bei Minor-Release-Upgrades (z.B. von 2.9 auf 2.10) teilweise nicht abwärtskompatible Änderungen an der Syntax vornimmt. Dies sollte nach den Richtlinien des Semantic Versioning nicht so sein und geht in meinen Augen gar nicht. Darunter finden sich Dinge wie die Art und Weise, wie Paketnamen an ein Modul wie apt oder yum zu übergeben sind oder dass plötzlich der Bindestrich (-) in Gruppennamen nicht mehr zulässig ist. Änderungen wie diese machen sehr häufig Anpassungen am Inventory, den Playbooks und Rollen erforderlich. In meinem Fall ist der Aufwand noch überschaubar. In größeren Organisationen mit einigen hundert oder gar tausenden von Playbooks sieht die Sache schnell anders aus und wird auch nicht von allen Kunden gut aufgenommen.

Fazit

Es gibt einige Punkte, die mir an Ansible nicht so gut gefallen und bei denen ich auch keine schnelle Besserung erwarte. Auch sind von Zeit zu Zeit Anpassungen notwendig, um den Blog zu deployen bzw. wiederherstellen zu können. Jedoch hält sich der Aufwand dafür in Grenzen und ist deutlich geringer, als bspw. bei der ausschließlichen Verwendung von Bash-Skripten.

Verglichen zur manuellen Vorgehensweise (vgl. Testinstanz für einen WordPress Blog erstellen) erspart mir Ansible sogar eine Menge Zeit, welche ich z.B. mit meiner Familie verbringen kann. Daher bleibt Ansible für mich weiterhin gesetzt.

Welche Erfahrungen habt ihr mit Ansible gemacht? Und wie beurteilt ihr dieses heute im Vergleich zu den Vorjahren? Eure Berichte sind jederzeit willkommen.

RPM-Paket-Abhängigkeiten anzeigen

Schreibe eine Antwort

An dieser Stelle möchte ich kurz notieren, wie man sich die Abhängigkeiten eines RPM-Pakets anzeigen lassen kann zusammen mit den RPM-Paket-Namen, welche diese Abhängigkeiten erfüllen.

Dies geht mit dem Kommando repoquery aus dem Paket yum-utils bzw. dnf-utils. Der Aufruf erfolgt nach dem Muster:

$ repoquery --deplist PAKETNAME

Das folgende Listing zeigt dies beispielhaft für das Paket tmux:

$ repoquery --deplist tmux
Failed to set locale, defaulting to C.UTF-8
Not root, Subscription Management repositories not updated
Last metadata expiration check: 0:29:24 ago on Sat Jan 11 19:28:10 2020.
package: tmux-2.7-1.el8.x86_64
  dependency: /bin/sh
   provider: bash-4.4.19-10.el8.x86_64
  dependency: libc.so.6()(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.14)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.2.5)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.25)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.26)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.27)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.3)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.3.4)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.4)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libc.so.6(GLIBC_2.8)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libevent-2.1.so.6()(64bit)
   provider: libevent-2.1.8-5.el8.x86_64
  dependency: libresolv.so.2()(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libresolv.so.2(GLIBC_2.2.5)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libtinfo.so.6()(64bit)
   provider: ncurses-libs-6.1-7.20180224.el8.x86_64
  dependency: libutil.so.1()(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: libutil.so.1(GLIBC_2.2.5)(64bit)
   provider: glibc-2.28-72.el8.x86_64
  dependency: rtld(GNU_HASH)
   provider: glibc-2.28-72.el8.i686
   provider: glibc-2.28-72.el8.x86_64

Darüber hinaus kann repoquery euch auch das Changelog eines RPM-Pakets zeigen und welche Dateien es enthält.

In RPM-Paket enthaltene Dateien anzeigen

Schreibe eine Antwort

Neulich fragte mich ein Kollege, wie man sich anzeigen lassen kann, welche Dateien ein RPM-Paket enthält, bevor man dieses installiert. Dazu eignet sich das Programm repoquery aus dem Paket yum-utils bzw. dnf-utils.

Der Aufruf erfolgt nach dem Muster:

$ repoquery -l PAKETNAME

Das folgende Listing zeigt beispielhaft die Dateien im Paket tmux:

$ repoquery -l tmux
Failed to set locale, defaulting to C.UTF-8
Not root, Subscription Management repositories not updated
Last metadata expiration check: 0:10:46 ago on Sat Jan 11 19:28:10 2020.
/usr/bin/tmux
/usr/lib/.build-id
/usr/lib/.build-id/0e
/usr/lib/.build-id/0e/cd3ead12aab3291beeaacf69559804011eee9c
/usr/share/bash-completion/completions/tmux
/usr/share/doc/tmux
/usr/share/doc/tmux/CHANGES
/usr/share/doc/tmux/TODO
/usr/share/man/man1/tmux.1.gz

Darüber hinaus kann man sich mit repoquery auch das Changelog eines RPM-Pakets anzeigen lassen, ohne das Paket zuvor installieren zu müssen.

Ist das zu betrachtende Paket bereits installiert, kann man sich die darin enthaltenen Dateien auch mit dem folgenden Kommando anzeigen lassen:

$ rpm -ql PAKETNAME

Geänderte Größe logischer Blockgeräte unter Linux ohne Neustart erkennen

Schreibe eine Antwort

Wird die Größe einer per iSCSI oder Fibre Channel eingebundenen LUN geändert, oder in einer virtualisierten Umgebung die Größe der virtuellen Festplatte (VMDK, VDI, VHD, qcow2, etc.) angepasst, kann man den Linux-Kernel auffordern die entsprechenden Blockgeräte auf Änderungen hin zu prüfen, ohne dafür das Betriebssystem neustarten zu müssen.

Die im folgenden genannten bzw. verlinkten Kommandos wurden unter RHEL 7 mit VMDK-Dateien und iSCSI-Disks getestet. Sie sollten jedoch für Linux im Allgemeinen gelten.

Änderungen an bestehenden Blockgeräten erkennen

Um Änderungen an Blockgeräten zu erkennen, welche dem Kernel bereits bekannt sind, wird folgender Befehl mit root-Rechten ausgeführt:

# echo 1 > /sys/class/block/sdX/device/rescan

Dabei ist sdX durch die Bezeichnung des konkreten Blockgeräts wie z.B. sda oder sdb etc. zu ersetzen. Statt dem genannten Bezeichner kann auch die SCSI-Nummer des entsprechenden Gerätes verwendet werden. Der Befehl lautet dann wie folgt (wobei X:X:X:X durch die jeweilige SCSI-Nummer zu ersetzen ist):

# echo 1 > /sys/class/scsi_device/X:X:X:X/device/block/device/rescan

Update 2019-12-15: Ist das Paket parted installiert, kann man den Kernel auch mit dem Kommando partprobe über die Änderungen informieren:

# partprobe /dev/sdX

Danke an Dirk für diesen Tipp.

Neue Blockgeräte erkennen

Wie neu hinzugefügte Blockgeräte erkannt werden können, habe ich bereits im Artikel Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen beschrieben.

Quellen und weiterführende Hinweise

  1. How to rescan disk in Linux after extending vmware disk
  2. How to map Linux disk to vmware disk
  3. Red Hat Storage Administration Guide: Sec. 37.2. Resizing an iSCSI Logical Unit