Schlagwort-Archive: Planet

Tag für den Ubuntuusers.de Planeten.

My 2 Cents on CentOS

In den letzten Tagen dreht sich meine Internet-Blase zu einem großen Teil rund um das nahende Ende von CentOS-Linux. Um nicht in mehreren Blogs die gleichen oder ähnliche Kommentare zu hinterlassen, habe ich mich entschieden, in diesem einen Artikel meinen Senf dazu zugeben.

Aus Transparenzgründen weise ich ausdrücklich darauf hin, dass ich Mitglied der Red Hat Accelerators bin (siehe „Zu meiner Person„). Meine Meinung ist jedoch grundsätzlich meine eigene. Diese kann mit den Ansichten von Red Hat übereinstimmen, muss es aber nicht und tut es auch nicht immer.

Die Meldungen, dass das Ende von CentOS Linux naht, haben mich weder überrascht, noch enttäuscht. Überrascht bin ich nicht, da ich mich schon bei der Ankündigung von CentOS Stream gefragt habe, wie lange beide Projekte parallel existieren können bzw. wann Red Hat die Unterstützung des einen Projekts zu Gunsten des anderen beendet. Und um enttäuscht zu sein, habe ich CentOS nicht lange genug verwendet und mich nicht in der Gemeinschaft organisiert. Freuen tut es mich allerdings auch nicht, wenn ein so robustes Projekt ein Ende hat.

Ziemlich unglücklich fand ich die Kommunikation durch Red Hat. Dabei ist denke ich mehr Porzellan kaputt gegangen, als nötig war. So ist es wenig verwunderlich, dass die CentOS-Community aufgebracht ist und sich in den Kommentarspalten in Rage schreibt.

So ist die Rede davon, dass Red Hat auf Weisung von IBM bei CentOS das Licht ausgemacht hat; dass CentOS auf dem Altar der Kommerzialisierung geopfert wird, um die Profite von Red Hat und IBM zu steigern. Ja, man könnte fast meinen, die Welt geht unter. Ich finde, das ist alles Quatsch.

Zumal ich nicht glaube, dass Nutzer des kostenlosen CentOS jetzt alle RHEL-Subkriptionen kaufen werden. Für viel wahrscheinlicher halte ich es, dass sich diese Nutzer den zukünftigen kostenlosen RHEL-Klonen zuwenden oder zu anderen kostenlosen Linux-Distributionen wechseln werden.

In meiner Wahrnehmung hat Red Hat bisher seine Eigenständigkeit nach dem Kauf durch IBM behalten. Ob IBM etwas mit der Entscheidung zu tun hatte, weiß ich nicht. Glauben tue ich es jedenfalls nicht. Letztendlich hat das CentOS-Projekt im hauseigenen Blog bekannt gegeben, den Fokus auf CentOS Stream zu verlagern. Übrigens sind nur 4 von 10 Sitzen im CentOS Governing Board von Red Hattern besetzt.

Etliche Kommentare hinterlassen bei mir den Eindruck, die dazugehörigen Autoren würden glauben, sie hätten ein Recht auf kostenlose Software der Enterprise-Klasse. Dabei beinhaltet Open Source nach meinem Verständnis die Freiheit der Quelltexte und das Recht, aus diesen ausführbare Programme zu erstellen. Eine Pflicht, dass ein Unternehmen für den ganzen Spaß bezahlt und diese Aufgabe für mich übernimmt, kann ich hingegen nicht daraus ableiten. Von daher kann ich die Empörung nur teilweise nachvollziehen.

Dabei ist die Binärkompatibilität von CentOS, Oracle Linux, CloudLinux OS, Centos Stream und evtl. bald Rocky Linux zu RHEL doch auch ein Vorteil. Sollten sich Anwendungen, die auf einer dieser Distributionen laufen, sich doch selbst im Binärformat ohne großen Aufwand auf die jeweils anderen übertragen lassen. Ganz ehrlich, einen Wechsel von Debian zu OpenSUSE stelle ich mich schwieriger vor.

In meinen Augen stehen ausreichend gute und stabile Alternativen für Menschen zur Verfügung, die es sich nicht leisten können, für Enterprise-Software zu bezahlen.

Also CentOS, mach es gut. Es war schön mit dir. Mit deinen Nachfolgern wird es sicherlich auch wieder viel zu erleben geben.

Links und Quellen zum Thema

SSH ForwardAgent ja oder nein?

In diesem Artikel möchte ich diskutieren, ob die Nutzung der SSH-Client-Option ForwardAgent sicher und sinnvoll ist. Wie so häufig bei Themen der IT-Sicherheit geht es auch hier um die Abwägung zwischen Sicherheit und Bequemlichkeit.

Der SSH-Agent nimmt den privaten SSH-Schlüssel auf und stellt diesen für SSH-Verbindungen bereit, so dass nicht bei jeder neuen SSH-Verbindung die Passphrase eingegeben werden muss.

Dabei wird ein UNIX-Socket erstellt und in der Variablen SSH_AUTH_SOCK gespeichert. Der folgende Code zeigt dies beispielhaft:

$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh

In der ssh_config(5) findet sich die Option ForwardAgent, mit deren Hilfe der SSH-Agent auf einen entfernten Rechner weitergeleitet werden kann. Ist diese Funktionalität aktiv, kann man sich mit dem im SSH-Agenten gespeicherten privaten SSH-Schlüssel zu einem entfernten Rechner verbinden und von dort aus unter Nutzung des gleichen Schlüssels Verbindungen zu weiteren Rechnern aufbauen.

In den meisten Linux-Distributionen ist diese Option standardmäßig deaktiviert, da sie ein potenzielles Sicherheitsrisiko darstellt. Gelingt es einem Benutzer, die Dateiberechtigungen auf dem entfernten Rechner zu umgehen, kann er den lokalen Agenten benutzen, um Operationen durchzuführen, die nur mit dem im SSH-Agenten gespeicherten SSH-Schlüssel möglich sind. Ich möchte dies im Folgenden an einem Beispiel veranschaulichen.

Die Umgebung

Für den Versuch kommen die drei Linux-Rechner host-a, host-b und host-c zum Einsatz. Auf allen drei Hosts existiert der User foo, welcher mittels sudo zum root werden kann. Darüber hinaus existiert auf host-b User bar, welcher ebenfalls mittels sudo zum root werden darf.

Gezeigt wird, wie bar durch Wechsel in den Kontext des Users root die Dateiberechtigungen für den Unix-Socket des SSH-Agenten von foo umgehen kann, um mit dessen Informationen eine SSH-Verbindung zu host-c herzustellen, was ihm sonst nicht gestattet ist.

Der Versuchsablauf

In diesem Abschnitt wird der Ablauf wiedergegeben, der dazu führt, dass bar Zugriff als foo auf host-c bekommt.

host-a

Auf host-a existiert ein Unix-Socket für den SSH-Agenten. Der User foo nutzt diesen, um eine Verbindung zu host-b aufzubauen. Dabei wird die Option ForwardAgent aktiviert:

foo@host-a:~$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh
foo@host-a:~$ ssh -o ForwardAgent=yes  host-b
[...]
foo@host-b:~$

host-b

Wir sind jetzt via SSH als User foo auf dem host-b eingeloggt. Da wir die Weiterleitung des SSH-Agenten aktiviert haben, existiert jetzt auch hier ein entsprechender Unix-Socket. Die Dateiberechtigungen sind so gesetzt, dass nur foo darauf zugreifen darf. Der folgende Codeblock veranschaulicht dies.

foo@host-b:~$ echo $SSH_AUTH_SOCK
/tmp/ssh-fxwQXNlZrS/agent.32579
foo@host-b:~$ ls -ld /tmp/ssh-fxwQXNlZrS
drwx------ 2 foo foo 4096 Nov 24 14:47 /tmp/ssh-fxwQXNlZrS
foo@host-b:~$ ls -l /tmp/ssh-fxwQXNlZrS/agent.32579
srwxr-xr-x 1 foo foo 0 Nov 24 14:47 /tmp/ssh-fxwQXNlZrS/agent.32579

Neben foo ist auch User bar auf host-b eingeloggt. Die Variable SSH_AUTH_SOCK dieses Users ist leer und bar wird beim Versuch, sich mit host-c zu verbinden, zur Eingabe eines Passworts aufgefordert.

bar@host-b:~$ echo $SSH_AUTH_SOCK

bar@host-b:~$ ssh foo@host-c
foo@host-c's password:

bar@host-b:~$ ls -l /tmp
drwx------ 2 foo   foo   4096 Nov 24 14:56 ssh-fxwQXNlZrS
bar@host-b:~$ ls -l /tmp/ssh-fxwQXNlZrS
ls: cannot open directory '/tmp/ssh-fxwQXNlZrS/': Permission denied

Da bar das Kennwort von foo unbekannt ist, geht es auf diesem Weg nicht weiter. Jedoch kann bar erkennen, dass auf dem System ein Unix-Socket mit einem SSH-Agenten für foo existiert. Der nun folgende Codeblock zeigt, wie bar über einen Umweg den SSH-Agenten von foo nutzt, um sich mit host-c zu verbinden.

bar@host-b:~$ sudo -i
[sudo] password for bar:
root@host-b:~# ssh foo@host-c
foo@host-c's password:

root@host-b:~# SSH_AUTH_SOCK=/tmp/ssh-fxwQXNlZrS/agent.32579
root@host-b:~# export SSH_AUTH_SOCK
root@host-b:~# ssh foo@host-c
[...]
foo@host-c:~$

Der User bar hat es geschafft, sich als foo an host-c zu authentifizieren. Das ist foobar!

Schlussfolgerung

Der hier durchgeführte Versuch zeigt, dass die Option ForwardAgent ein Sicherheitsrisiko birgt, wenn es auf einem entfernten System Benutzer gibt, welche die Dateiberechtigungen, wie in diesem Artikel gezeigt, umgehen können.

Ich empfinde es daher als gut und sinnvoll, dass diese Option standardmäßig deaktiviert ist.

Kann man jedoch ausschließen, dass die Dateiberechtigungen umgangen werden, z. B. weil keine weiteren Nutzer auf dem entfernten Rechner existieren bzw. auf diesen zugreifen können, spricht in meinen Augen nichts dagegen, diese Option zu nutzen und sich den Alltag etwas komfortabler zu gestalten.

Let’s Encrypt: Nutzung des DNS-Alias-Modus mit dem acme.sh-Client

Dieses Tutorial erklärt, wie der Let’s Encrypt Client (LE-Client) acme.sh mit dem Plugin dns_nsupdate auf einem Linux-System installiert und zur Nutzung der „DNS-01 challenge“ im DNS-Alias-Modus konfiguriert werden kann.

Um dem Tutorial folgen zu können, sollte man den grundlegenden Umgang mit einem Terminal und einer weitgehend POSIX-kompatiblen Shell beherrschen. Grundlegende Kenntnisse der Funktion von DNS und Resource Records sind hilfreich, jedoch nicht erforderlich und können im Zweifel unter den verlinkten Seiten erworben werden.

In diesem Tutorial werden nicht die Vor- und Nachteile der „DNS-01 challenge“ diskutiert. Diese können unter vorstehendem Link nachgelesen werden.

Die Begriffe SSL-Zertifikat, TLS-Zertifikat oder nur Zertifikat werden in diesem Tutorial synonym verwendet. Der zum Zertifikat gehörende Schlüssel wird als Private-Key bezeichnet.

Umfeld

Im Folgenden werden die Begriffe Subdomain und Zone synonym verwendet. Es sei darauf hingewiesen, dass diese Begriffe in einem anderen Kontext eine unterschiedliche Bedeutung haben können.

Als Beispiel-Domain wird example.org mit den beiden Subdomains foo.example.org und bar.example.org verwendet. Um dem acme.sh-Client keinen direkten Zugriff auf diese DNS-Zonen geben zu müssen, hat der DNS-Anbieter die DNS-Zone acme.foo.example.org definiert, welche für den Zweck der DNS-Challenge verwendet wird.

Der Nameserver für alle in diesem Tutorial verwendeten Domains lautet ns.example.org.

Vom DNS-Anbieter wird ein sogenannter TSIG-Schlüssel bereitgestellt, welcher berechtigt ist TXT-Ressource-Records in der oben genannten DNS-Zone acme.foo.example.org anlegen zu können. In diesem Tutorial werden folgender Name und Wert für einen TSIG-Schlüssel angenommen:

  • TSIG-NAME: acme-key
  • TSIG-WERT: SuperGeheim1111elf==
  • TSIG-Algorithmus: hmac-sha512

Das Ziel soll nun sein, ein Zertifikat ausgestellt zu bekommen, welches für die beiden folgenden Hostnamen gültig ist:

  • host.foo.example.org
  • mein-schoener-host.bar.example.org

In diesem Tutorial wird als Webserver Apache in der Distribution RHEL 7 verwendet. Die entsprechende Service-Unit lautet demnach httpd.service. Wird ein anderer Webserver oder eine andere Distribution verwendet, ist der Name der Service-Unit entsprechend anzupassen (z.B. nginx.service).

Sinn und Zweck des DNS-Alias-Modus

Der DNS-Alias-Modus kann verwendet werden, wenn man einem Programm wie dem acme.sh-Client keinen direkten API-Zugriff auf die DNS-Zonen der eigenen Domain geben möchte. In diesem Abschnitt werde ich beispielhaft erklären, warum eine Nutzung dieses Modus angeraten erscheint.

Bevor Let’s Encrypt ein Zertifikat ausstellt, muss der anfragende Client beweisen, dass er die administrative Kontrolle über die Domain hat. Im Falle der DNS-Challenge geschieht dies indem ein TXT-Record in der jeweiligen DNS-Zone erstellt wird. Der LE-Client benötigt somit Zugriff mit Schreibberechtigung auf die entsprechenden DNS-Zonen. Dies kann jedoch verheerende Folgen haben, wenn der Host mit dem LE-Client kompromittiert wird. Ein Angreifer könnte hierdurch API-Zugang erlangen und die Informationen einer (oder mehrere) DNS-Zonen löschen. Oder noch schlimmer, die Einträge manipulieren bzw. eigene Einträge hinzufügen.

In unserer Organisation hat daher nur autorisiertes Personal mit personalisierten Zugangsdaten Zugriff auf ausgewählte Zonen.

Eine wichtige Eigenschaft von personalisierten Zugangsdaten ist, dass diese nur von der Person verwendet werden, an die sie ausgehändigt wurden. Diese sollten tunlichst nicht in einen LE-Client eingetragen werden, den man anschließend für Monate oder Jahre sich selbst überlässt.

Der DNS-Alias-Modus funktioniert so, dass der DNS-Anbieter eine Zone einrichtet, in der dynamische Updates durch LE-Clients gestattet sind. Die Authentifizierung und Autorisierung kann mittels sogenannter TSIG-Schlüssel durchgeführt werden.

Als Sysadmin erstellt man nun einen CNAME-Eintrag in der eigentlichen DNS-Zone, z.B. foo.example.org welcher auf die Zone acme.foo.example.org zeigt. Der LE-Client legt während der DNS-Alias-Challenge eine TXT-Record in der Zone acme.foo.example.org an. Let’s Encrypt kann nun über den CNAME den erstellten TXT-Record validieren. Anschließend wird das Zertifikat an den LE-Client ausgestellt.

Wird der LE-Client kompromittiert, sind damit zwar auch die auf ihm gespeicherten Private-Keys kompromittiert (was schon schlimm genug ist), es kann jedoch darüber hinaus nur die sogenannte DNS-Alias-Zone manipuliert werden. Eine Manipulation der eigentlichen Zone bleibt ausgeschlossen.

Installation des acme.sh-Clients

Um ein neu ausgestelltes bzw. erneuertes Zertifikat und den dazugehörigen Private-Key in einem Webserver zu verwenden, muss die Webserver-Konfiguration neu geladen werden. Dazu sind meist Root/sudoer-Rechte erforderlich. In diesem Tutorial wird der acme.sh-Client unter einem User mit sudo-Berechtigung installiert.

Hinweis: Das Projekt empfiehlt die Nutzung von sudo ausdrücklich nicht. Weitere Informationen finden sich unter dem Link: https://github.com/acmesh-official/acme.sh/wiki/sudo

Da ich glaube, zu wissen, was ich tue, werde ich hier optional die Einrichtung unter einem User mit sudo-Berechtigung dokumentieren. Befehle sind entsprechend mit oder ohne sudo auszuführen, je nachdem welcher User verwendet wird.

Zur Installation führt man folgende Kommandos aus (Quelle):

git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install

Durch die Installationsroutine werden folgende drei Aktionen durchgeführt:

  1. Erstellen und Kopieren von acme.sh in das HOME-Verzeichnis ($HOME): ~/.acme.sh/. Unterhalb dieses Verzeichnisses werden die ausgestellten Zertifikate abgelegt.
  2. Erstellen eines Alias für: acme.sh=~/.acme.sh/acme.sh.
  3. Erstellen eines täglichen cron job, welcher die Restlaufzeit der Zertifikate prüft und diese ggf. verlängert.

Beispiel eines Cron-Jobs:

1 0 * * * "/home/alice/.acme.sh"/acme.sh --cron --home "/home/alice/.acme.sh" > /dev/null

Nach der Installation meldet man sich am besten einmal neu an, damit der Alias für acme.sh genutzt werden kann.

Anlegen der CNAME-Records

Nun legen wir die CNAME-Records an, welche für den DNS-Alias-Mode benötigt werden (Quelle).

_acme-challenge.host.foo.example.org IN CNAME acme.foo.example.org
_acme-challenge.mein-schoener-host.bar.example.org IN CNAME acme.foo.example.org

Der vom DNS-Anbieter bereitgestellte TSIG-Schlüssel ist ausschließlich zum Erstellen von Records in der Zone acme.foo.example.org berechtigt. Mit dem CNAME-Record weisen wir quasi nach, dass wir die Kontrolle über die DNS-Zone haben und dort Ressource-Records erstellen dürfen, während der acme.sh-Client nur berechtigt ist Einträge in jenen Zonen zu erstellen, auf welche die CNAME-Records verweisen.

Dies geschieht aus Sicherheitsaspekten. Auf diese Art und Weise wird verhindert, dass ein kompromittierter Host mit acme.sh-Client die wichtigen Zonen überschreiben kann.

Beantragung, Ausstellen und Installation eines Zertifikats

Die Überschrift deutet bereits an, dass der folgende Prozess aus drei Schritten besteht. Ich beginne mit einem optionalen Schritt, in dem ich die notwendige Konfiguration für einen sudo-User erkläre.

Optional: Konfiguration für non-root-User

Wer den acme.sh-Client unter dem User root installiert hat, kann diesen Abschnitt überspringen. An dieser Stelle wird die Konfiguration eines sudo-Users beschrieben.

Verwendet wird dabei ein Useraccount, der bereits über sudo-Berechtigungen verfügt, sich bei der Verwendung von sudo jedoch mit einem Passwort authentisieren muss. Im Folgenden nennen wir diesen Useraccount Alice.

Anpassung der sudoers-Datei

Da für die Installation des Let’s Encrypt Zertifikats in einem Webserver ein Reload der Konfiguration des Webservers erforderlich ist und dies später automatisch (ohne Passworteingabe) geschehen soll, ist eine Anpassung der sudoers-Datei von Alice erforderlich.

Die sudoers-Datei von Alice (/etc/sudoers.d/alice) sieht zu Beginn wie folgt aus:

alice  ALL=(ALL) ALL

Um Alice nun das Recht zu geben, die Webserver-Konfiguration ohne Passworteingabe neu zu laden, wird folgende Zeile hinzugefügt. Dabei ist die Reihenfolge der Zeilen zu beachten (siehe sudoers(5)). Die Bearbeitung der Datei wird mit dem Kommando sudo visudo -f /etc/sudoers.d/alice durchgeführt.

alice  ALL=(ALL) ALL
alice  ALL=(ALL) NOPASSWD: /bin/systemctl reload httpd.service

Verzeichnis für TLS-Zertifikate und Private-Keys erstellen

Zur weiteren Nutzung durch den Webserver, sollen die Zertifikate und Private-Keys in einem Verzeichnis gespeichert werden, auf das Alice Schreibrechte hat. Der Verzeichnisname kann dabei abweichend vom folgenden Beispiel frei gewählt werden. Im Beispiel wird die Gruppe apache verwendet. Diese ist ggf. an das eigene System anzupassen:

sudo mkdir -m 750 /etc/letsencrypt
sudo chown alice.apache /etc/letsencrypt

Die folgenden Schritte sind für root und alice gleich. Nur muss alice einige Befehle halt mit sudo auführen. Diese sind entsprechend gekennzeichnet. root lässt ein führendes sudo einfach weg.

Zertifikat beantragen und austellen

Wie eingangs erwähnt, wird ein TSIG-Schlüssel und das Plugin dns_nsupdate genutzt, um dynamische Zonen-Updates auf dem Nameserver durchzuführen. Um den acme.sh-Client entsprechend zu konfigurieren, wird zuerst eine Key-Datei erstellt, welche den TSIG-Schlüssel in JSON-Notation enthält (vgl. Abschnitt Umfeld).

Wichtig: Der TSIG-Schlüssel erlaubt dynamische Zonen-Updates im DNS. Er ist geheim zu halten und bestmöglich zu schützen.

Der Name der Datei ist dabei frei wählbar. Ich empfehle die Datei im HOME-Verzeichnis des Users abzulegen, welcher den acme.sh-Client ausführt und die Datei nur für diesen User lesbar zu machen (chmod 0400 DATEINAME). Beispiel:

cat ~/.nsupdate.key
key "acme-key" {
  algorithm hmac-sha512;
  secret "SuperGeheim1111elf==";
};

chmod 0400 ~/.nsupdate.key

Als nächstes werden notwendige Informationen über den Nameserver und unseren TSIG-Key verfügbar gemacht. Die folgenden Kommandos sind einmalig auszuführen. Die Werte werden vom acme.sh-Client später automatisch in ~/.acme.sh/account.conf gespeichert (Quelle).

export NSUPDATE_SERVER="ns.example.org"
export NSUPDATE_KEY="/home/alice/.nsupdate.key"

Nun ist es endlich soweit, dass ein Zertifikat ausgestellt werden kann. Für die in diesem Tutorial verwendeten Werte lautet der Befehl dazu wie folgt:

acme.sh --issue --dns dns_nsupdate -d host.foo.example.org -d mein-schoener-host.bar.example.org --challenge-alias acme.foo.example.org

Der folgende Code-Block zeigt ein konkretes Beispiel unter Verwendung der Staging-Umgebung.

acme.sh --issue --staging --dns dns_nsupdate -d host.foo.example.org -d mein-schoener-host.bar.example.org --challenge-alias acme.foo.example.org

[Fr 4. Sep 09:52:41 CEST 2020] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory
[Fr 4. Sep 09:52:42 CEST 2020] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory
[Fr 4. Sep 09:52:42 CEST 2020] Create account key ok.
[Fr 4. Sep 09:52:42 CEST 2020] Registering account: https://acme-staging-v02.api.letsencrypt.org/directory
[Fr 4. Sep 09:52:43 CEST 2020] Registered
[...]
[Fr 4. Sep 09:52:43 CEST 2020] Creating domain key
[Fr 4. Sep 09:52:44 CEST 2020] The domain key is here: /home/alice/.acme.sh/host.foo.example.org/host.foo.example.org
.key
[Fr 4. Sep 09:52:44 CEST 2020] Multi domain='DNS:host.foo.example.org,DNS:mein-schoener-host.bar.example.org'
[Fr 4. Sep 09:52:44 CEST 2020] Getting domain auth token for each domain
[Fr 4. Sep 09:52:46 CEST 2020] Getting webroot for domain='host.foo.example.org'
[Fr 4. Sep 09:52:46 CEST 2020] Getting webroot for domain='mein-schoener-host.bar.example.org'                                             
[Fr 4. Sep 09:52:46 CEST 2020] Adding txt value: 2tG2NCvV23KGUNCSGeVO3P_UVaOVAG4t0ehbv1cJbtY for domain:  _acme-challenge.acme.foo.example.org
[Fr 4. Sep 09:52:46 CEST 2020] adding _acme-challenge.acme.foo.example.org. 60 in txt "2tG2NCvV23KGUNCSGeVO3P_UVaOVAG4t0ehbv1cJbtY"
[Fr 4. Sep 09:52:46 CEST 2020] The txt record is added: Success.
[Fr 4. Sep 09:52:46 CEST 2020] Adding txt value: yFbL8EF6xQre3v3RfYiCYQ8X4KH0gykagD9_oRfIvgA for domain:  _acme-challenge.acme.foo.example.org
[Fr 4. Sep 09:52:46 CEST 2020] adding _acme-challenge.acme.foo.example.org. 60 in txt "yFbL8EF6xQre3v3RfYiCYQ8X4KH0gykagD9_oRfIvgA"
[Fr 4. Sep 09:52:46 CEST 2020] The txt record is added: Success.
[Fr 4. Sep 09:52:46 CEST 2020] Let's check each DNS record now. Sleep 20 seconds first.
[Fr 4. Sep 09:53:07 CEST 2020] Checking host.foo.example.org for _acme-challenge.acme.foo.example.org                       
[Fr 4. Sep 09:53:07 CEST 2020] Not valid yet, let's wait 10 seconds and check next one.
[Fr 4. Sep 09:53:20 CEST 2020] Checking mein-schoener-host.bar.example.org for _acme-challenge.acme.foo.example.org
[Fr 4. Sep 09:53:21 CEST 2020] Domain mein-schoener-host.bar.example.org '_acme-challenge.acme.foo.example.org' success.
[Fr 4. Sep 09:53:21 CEST 2020] Let's wait 10 seconds and check again.
[Fr 4. Sep 09:53:32 CEST 2020] Checking host.foo.example.org for _acme-challenge.acme.foo.example.org
[Fr 4. Sep 09:53:32 CEST 2020] Domain host.foo.example.org '_acme-challenge.acme.foo.example.org' success.
[Fr 4. Sep 09:53:32 CEST 2020] Checking mein-schoener-host.bar.example.org for _acme-challenge.acme.foo.example.org
[Fr 4. Sep 09:53:32 CEST 2020] Already success, continue next one.                                                                          
[Fr 4. Sep 09:53:32 CEST 2020] All success, let's return
[Fr 4. Sep 09:53:32 CEST 2020] Verifying: host.foo.example.org
[Fr 4. Sep 09:53:35 CEST 2020] Pending
[Fr 4. Sep 09:53:38 CEST 2020] Success
[Fr 4. Sep 09:53:38 CEST 2020] Verifying: mein-schoener-host.bar.example.org                                                               
[Fr 4. Sep 09:53:41 CEST 2020] Success
[Fr 4. Sep 09:53:41 CEST 2020] Removing DNS records.
[...]
[Fr 4. Sep 09:53:41 CEST 2020] Removed: Success
[Fr 4. Sep 09:53:41 CEST 2020] Verify finished, start to sign.
[Fr 4. Sep 09:53:41 CEST 2020] Lets finalize the order.
[Fr 4. Sep 09:53:41 CEST 2020] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/15482274/142528495'
[Fr 4. Sep 09:53:42 CEST 2020] Downloading cert.
[Fr 4. Sep 09:53:42 CEST 2020] Le_LinkCert='https://acme-staging-v02.api.letsencrypt.org/acme/cert/fa6e5a9922acccb49619cc8808f6f0916dc0'
[Fr 4. Sep 09:53:43 CEST 2020] Cert success.
[...]
[Fr 4. Sep 09:53:43 CEST 2020] Your cert is in  /home/alice/.acme.sh/host.foo.example.org/host.foo.example.org.cer
[Fr 4. Sep 09:53:43 CEST 2020] Your cert key is in  /home/alice/.acme.sh/host.foo.example.org/host.foo.example.org.key
[Fr 4. Sep 09:53:43 CEST 2020] The intermediate CA cert is in /home/alice/.acme.sh/host.foo.example.org/ca.cer
[Fr 4. Sep 09:53:43 CEST 2020] And the full chain certs is there:  /home/alice/.acme.sh/host.foo.example.org/fullchain.cer

Damit liegen alle benötigten Dateien auf unserem Host. Im nächsten Schritt werden diese in die korrekte Lokation installiert.

Installation der Zertifikate für Apache

Das folgende Beispiel gilt für den Webserver Apache und ist der Dokumentation des acme.sh-Clients entnommen. Auf der verlinkten Seite findet sich ein weiteres Beispiel für den Webserver NGINX.

Das Kommando im folgenden Beispiel enthält am Ende den Parameter --reloadcmd "sudo systemctl reload httpd.service. Das sudo ist notwendig, wenn man einen User mit sudo-Berechtigungen wie z.B. Alice nutzt (siehe oben). Als root lässt man sudo einfach weg. Ggf. muss der Name der Service-Unit an das eigene System angepasst werden.

acme.sh --install-cert -d host.foo.example.org --cert-file /etc/letsencrypt/host.foo.example.org.cer --key-file /etc/letsencrypt/host.foo.example.org.key --fullchain-file /etc/letsencrypt/host.foo.example.org.fullchain.cer --reloadcmd "sudo systemctl reload httpd.service"

Hat alles funktioniert, erzeugt obiger Befehl folgende Ausgabe:

[Fr 4. Sep 12:36:22 CEST 2020] Installing cert to:/etc/letsencrypt/host.foo.example.org.cer
[Fr 4. Sep 12:36:22 CEST 2020] Installing key to:/etc/letsencrypt/host.foo.example.org.key
[Fr 4. Sep 12:36:22 CEST 2020] Installing full chain to:/etc/letsencrypt/host.foo.example.org.fullchain.cer
[Fr 4. Sep 12:36:22 CEST 2020] Run reload cmd: sudo systemctl reload httpd.service
[Fr 4. Sep 12:36:22 CEST 2020] Reload success

Hinweis: Der Webserver bzw. VirtualHost des Webservers muss so konfiguriert werden, dass die Zertifikate aus dem entsprechenden Pfad auch verwendet werden. Diese Konfiguration ist nicht Gegenstand dieses Tutorials. Es wird hierzu auf die Dokumentation des genutzten Webservers verwiesen.

Die Dateiberechtigungen für oben installierte Dateien sind nach der Installation einmalig zu korrigieren und ggf. mit chown und chmod so zu konfigurieren, dass nur Alice und der Webserver-User Zugriff darauf haben. Wichtig: Der Private-Key darf unter keinen Umständen von allen Usern gelesen werden dürfen. Folgender Code-Block zeigt eine mögliche Berechtigung:

ls -l /etc/letsencrypt/
total 12
-rw-r-----. 1 alice apache 1964  4. Sep 15:09 host.foo.example.org.cer
-rw-r-----. 1 alice apache 3644  4. Sep 15:09 host.foo.example.org.fullchain.cer
-rw-r-----. 1 alice apache 1679  4. Sep 15:09 host.foo.example.org.key

Die Dateiberechtigungen bleiben bei einer Erneuerung des Zertifikats und beim Überschreiben der existierenden Dateien erhalten.

Die vorgenommenen Einstellungen und Befehle werden in der Datei ~/.acme.sh/account.conf gespeichert. In der Standard-Einstellung wird das Zertifikat automatisch alle 60 Tage erneuert, in den angegebenen Pfaden installiert und ein Neustart des Webservers durchgeführt.

Weiterführende Quellen und Links

  1. A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation
  2. How-to install acme.sh: https://github.com/acmesh-official/acme.sh/wiki/How-to-install
  3. Install from Git: https://github.com/acmesh-official/acme.sh#2-or-install-from-git
  4. Set up Let’s Encrypt certificate using acme.sh as non-root user: https://gist.github.com/Greelan/28a46a33140b65c9a045573ca460f044
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.

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.