Schlagwort-Archive: Insights

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 wider. 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.

Erkundung von Red Hat Insights — Advisor

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.

Einführung in Red Hat Insights

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.

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.