Nichts für Weicheier

von Martin Loschwitz

Unzählige Möglichkeiten existieren, um die Benutzerverwaltung von Linux-Systemen abzusichern – ganz gleich, ob zentrale Verzeichnisse zum Einsatz kommen oder die Verwaltung der User lokal erfolgt. Auf den allermeisten Systemen liegt ein Gros der Optionen für sichere Zugänge jedoch brach. Ablaufende Passwörter finden sich ebenso wenig wie ablaufende Accounts, und vielerorts funktioniert sogar der Login als Systemverwalter "root" per SSH noch. Der Artikel zeigt, wie Admins mit einfachen Bordmitteln die Benutzerverwaltung ihrer Systeme schützen.

Dass Sicherheit ein zentrales Thema in der IT darstellt, wenn nicht gar das wichtigste, ist mittlerweile zwar eine lästige Plattitüde, deshalb aber nicht weniger richtig. Und gerade KMU benötigen ein besonders hohes Maß an zuverlässiger und guter Sicherheit, haben oft genug aber nicht die Ressourcen, um es zu implementieren.

Die Verwaltung von Benutzern auf Linux-Systemen ist dafür ein gutes Beispiel. Große Konzerne betreiben ein zentrales LDAP, koppeln ihre Systeme an dieses und sorgen so für viel automatisierte Sicherheit. Kündigt beispielsweise ein Kollege, deaktiviert die hausinterne IT dessen Account im LDAP oder im Active Directory und unterbindet so implizit die Gefahr eventueller Racheakte. In kleinen Firmen hingegen kommt den Admins nicht selten die Aufgabe zu, die Zugänge einzelner Benutzer auf den Systemen händisch zu deaktivieren. Das ist weder besonders zuverlässig noch sehr effizient. Was regelmäßig auffällt: Viele Systeme werden so administriert, dass die eigentlich in die Standard-Benutzerverwaltung integrierten Sicherheitsfunktionen vollständig brachliegen. Obendrein ließen sich vielerorts mit einfachsten Mitteln der Automatisierung auch ohne zentrale Benutzerverzeichnisse viel bessere Ergebnisse erreichen, als es dort augenblicklich der Fall ist.

Unser Artikel geht auf einige dieser Funktionen im Detail ein und verrät, wie Admins ihre Systeme im Hinblick auf deren Benutzerverwaltung sinnvoll abhärten. Das zentrale Ziel ist dabei stets, Einbrüche zu verhindern oder den durch sie entstehenden Schaden so gut wie möglich einzudämmen.

Der Systemverwalter "root"

Als der Autor dieser Zeilen vor über 25 Jahren seine Linux-Reise begann, galt es bereits als verpönt, mit den Rechten des Systemadministrators "root" zu arbeiten. Wer sich an einem Linux-System mit KDE seinerzeit als "root" anmeldete, erhielt etwa eine fette rote Warnmeldung auf dem Desktop, dass dies unsicher sei.

Trotzdem gibt es selbst im Jahr 2022 noch immer Organisationen, bei denen die Verwendung von "root" zum alltäglichen Geschäft gehört. Red Hat hat hier einen traurigen Beitrag geleistet, denn der direkte Login als "root" per SSH war in allen Versionen von Red Hat Enterprise Linux (RHEL) bis einschließlich Version 8 ab Werk erlaubt.

Erst das aktuelle RHEL 9 bereitete dem bunten Treiben ein Ende. So oder so sollten Administratoren unter allen Umständen darauf achten, dass für SSH mittels der Zeile "PermitRootLogin no" in der Konfiguration von "sshd" der Login als "root" ausgeschlossen ist (Bild 1).

Ebenso als Binsenweisheit gilt heute, dass SSH auf Passwörter grundsätzlich komplett verzichten sollte. SSH-Schlüssel sind bei entsprechender Länge (2048 Bit oder stärker) praktisch unknackbar, und ein privater, mit gutem Passwort abgesicherter SSH-Schlüssel ist deutlich weniger gefährdet als ein auf vielen Systemen vorhandener Benutzer-Account mit simplem Passwort. Indes gilt: ein Benutzerzugang, auf den Gauner erst gar keinen Zugriff bekommen, lässt sich von diesen auch nicht missbrauchen. Wenn Admins auf ihren Systemen also den SSH-Login als "root" unterbinden, sollten sie zudem gleich den Einsatz von Passwörtern beim Login per SSH verbieten.

Und apropos: Unsichere Passwörter gelten bis heute als ein Haupteinfalltor für Menschen mit bösen Absichten. Wer regelmäßig in die Logs seiner Server mit nach außen offenem SSH-Port schaut, sieht dort vermutlich relativ viele fehlgeschlagene Logins mit sehr generisch wirkenden Benutzernamen. Tatsächlich existieren im Netz Millionen von Bots, die IP-Addressräume nach offenen Ports absuchen und dann per Wörterbuchattacke versuchen, Zugriff zu erhalten. Wer den passwortbasierten SSH-Login deaktiviert, sorgt dafür, dass etwaige Versuche von vornherein erfolglos bleiben.

Eingebaute Features der Benutzerverwaltung

Wer den Luxus einer zentralen Benutzerverwaltung mittels LDAP oder Active Directory hat, muss sich um das Aktivieren oder das Deaktivieren von Accounts und um Ablaufdaten von Passwörtern in der Regel keine Sorgen machen. Wer auf diese Annehmlichkeit verzichten muss, findet in der klassischen Benutzerverwaltung aller gängigen Linux-Distributionen ein Füllhorn an Features, die vergleichbare Funktionalität ermöglichen.

So ist es etwa durchaus möglich, beliebige Benutzerzugänge auf Systemen mit einem Ablaufdatum zu versehen – oder zumindest deren Passwort. Wie das im Detail funktioniert, verrät die Dokumentation des jeweiligen Systems; dabei unterstützt der Hilfstext von "usermod", denn mit eben diesem Werkzeug lassen sich Ablaufdaten für Accounts sowie deren Passwörter festlegen.

Wie wir es allerdings drehen und wenden: Vorhandene Benutzerzugänge bleiben eine potenzielle Gefahr, und ihre Wartung ist manuell eine große Herausforderung. Jeder Admin, der schon einmal User-Konten auf Systemen zeitnah deaktivieren musste, kennt das Problem. Besonders in Stresssituationen kreisen die Gedanken um mehrere Dinge zur selben Zeit, sodass es im Eifer des Gefechts durchaus vorkommen kann, einzelne Systeme zu vergessen.

Automatisierung als Verzeichnisersatz

Einmal mehr schickt sich Automatisierung allerdings an, dem Administrator in eben solchen Situationen den Tag zu retten – selbst wenn manche Admins das womöglich nicht gern hören und bis heute argumentieren, die Einführung von Automatisierung sei angesichts der Größe des Umgebung zu viel Aufwand.

Haltbar ist eine solche Argumentation allerdings schon seit einigen Jahren nicht mehr. Denn wenn heute von Automatisierung die Rede ist, sind damit nicht zwangsläufig komplexe Konstrukte auf Basis von Puppet oder Chef oder Salt gemeint. Ansible als eine Art "SSH on steroids" reicht völlig aus, um die Benutzerverwaltung der meisten aktuell existierenden Systeme viel robuster zu machen, als sie es augenblicklich ist.

Ein paar praktische Beispiele machen das schnell deutlich. So kommt Ansible ab Werk mit einem Modul, das sich um das Anlegen und Verwalten von Benutzern kümmert und dabei auch Spezialitäten wie das Hinterlegen eines öffentlichen SSH-Schlüssels und das Setzen eines Passworts erlaubt. Für eine mittelgroße Anzahl an Nutzern lässt sich ein zentrales Benutzerverzeichnis damit gut simulieren – denn das Modul kann Benutzer nicht nur anlegen, sondern auch deaktivieren und sicherstellen, dass somit der Login nicht länger funktioniert.

Panik vor überbordender Komplexität auf der Ansible-Seite ist dabei unbegründet, denn Ansible gibt sich mit relativ wenig Vorarbeit zufrieden: Eine Inventardatei aller zu bearbeitender Hosts so wie ein einzelnes Playbook, das die Anweisungen für das "user"-Modul enthält, sind ausreichend (Bild 2). Aus Gründen der Übersicht hat es sich heute eingebürgert, die Benutzer in eine separate Rolle auszulagern – denn so lassen sich aus einem Playbook heraus mehrere Rollen aufrufen. Obendrein besteht die Möglichkeit, Aufgaben in einer Rolle auf unterschiedliche Dateien zu verteilen, was der Übersicht weiter zuträglich ist. Notwendig ist das aber nicht. Wer also sein Ansible-Setup auf so wenige Dateien wie möglich verteilen möchte, schreibt alle Anweisungen für das Benutzermodul direkt in dieses.

In Summe sollte das Herstellen einer solchen Ansible-Umgebung selbst bei relativ vielen Anwendern kaum mehr als zwei Stunden in Anspruch nehmen. Der größte Teil der Arbeit ist ohnehin Fleißarbeit – nämlich das Übernehmen der eventuell auf den jeweiligen Systemen bereits vorhandenen Accounts. Auch nachträglich lässt sich die vorhandene Benutzerverwaltung mit Ansible noch automatisieren, was zweifelsfrei ein weiterer Vorteil dieses Ansatzes ist.

Und selbst für Eventualitäten ist gesorgt: Wer beispielsweise auf unterschiedlichen Systemen aus Policy-Gründen mehrere Accounts benötigt, unterteilt die jeweiligen Systeme in der Inventardatei in Gruppen und wendet die zutreffenden Playbooks nur auf diese Gruppen an. Denkbar wäre etwa eine Gruppe "admins", die auf allen Systemen hinterlegt ist, und eine Gruppe "users", die nur auf spezielle Systeme Zugriff bekommt.

Die praktischen Implikationen dieser simplen Automatisierungsform sind kaum hoch genug einzuschätzen. Das Beispiel des Kollegen, der im Streit die Firma verlässt, macht das wieder deutlich: Muss der Administrator im Falle eines Falles bloß noch in seinem Ansible-Playbook für den betroffenen Account das "disabled"-Flag setzen und danach einmal Ansible aufrufen, ist der Job in wenigen Sekunden nach einem Durchlauf von Ansible erledigt. Und obendrein deutlich zuverlässiger – denn Ansible kümmert sich ausnahmslos um alle Systeme im Inventar, während es dem Administrator im Stress passieren kann, einzelne Systeme zu vergessen.

sudo sinnvoll einsetzen

Eine Konsequenz aus dem eingangs erwähnten Umstand, dass der Login als "root" heute auf sämtlichen Systemen deaktiviert sein sollte, ist die Notwendigkeit zur Benutzung von "su" oder besser noch "sudo". Den meisten Admins ist das durchaus klar, und doch verweigern sich viele diesem Ansatz auch heute noch immer aus Bequemlichkeit. Regelmäßig findet sich beispielsweise die "sudo"-Konfiguration, die einer bestimmten Gruppe (oft "wheel") "root"-Rechte ohne Passworteingabe ermöglicht.

Gehört ein Account zu dieser Gruppe – auch das lässt sich mit Ansible übrigens ganz wunderbar steuern – genügt ein einfaches sudo -i, um "root" zu werden. Fällt ein solcher Account in die falschen Hände, hilft nur noch eine Reinstallation des Systems. Selbst wenn es lästig sein mag, tun Unternehmen deshalb gut daran, die Verwendung von "sudo" für einzelne Befehle zu erzwingen. Wer es ganz stimmig haben will, kann spezifische Befehle für einzelne Benutzer erlauben, etwa "/usr/ sbin/traceroute", während andere Befehle beim Aufruf mit "sudo" nur eine Fehlermeldung anzeigen.

Auch bei der Verwaltung von "sudo" auf Systemen leistet Ansible übrigens allerbeste Dienste. Im Community-Paket existiert etwa ein "sudoers"-Modul [1], mit dem sich nach Belieben Einträge in "sudoers" auf Basis der üblichen Ansible-Syntax erstellen lassen. Sogar Elemente, die nicht vorhanden sein sollen, nimmt das "sudoers"-Modul über seine Konfiguration auf und erzwingt ihr Fehlen auf den Zielsystemen.

Mandatory Access Control

Quasi ein ewiger Zankapfel in Sachen Benutzerverwaltung ist "Mandatory Access Control" (MAC), den meisten Admins eher unter den Produktnamen "AppArmor" oder "SELinux" bekannt. MAC dreht die Zugriffslogik auf Systemen um: Erlaubt ist der Zugriff bloß noch auf jene Programme, für die eine valide Policy existiert, die den jeweiligen Zugriff erlaubt. Das hegt einerseits amoklaufende Programme ein, sorgt andererseits aber auch dafür, dass einzelne Accounts keinen Zugang zu Diensten oder Dateien bekommen, die nicht zu ihren Angelegenheiten zählen.

Bei vielen Administratoren ist Mandatory Access Control indes ausgesprochen unbeliebt. Zugegeben: Weder AppArmor noch SELinux glänzen mit Einfachheit in der Handhabung oder niedrigen Einstiegshürden. Nicht wenige Linux-Administratoren lernen das auf die harte Tour, nämlich dann, wenn Programme mit zum Teil kryptischen, kaum nachvollziehbaren Fehlermeldungen nicht funktionieren und sich letztlich SELinux oder AppArmor als verantwortlich entpuppen. Viel mehr Admins allerdings verzichten auf diese Erfahrung und schalten die Tools ab.

Das ist indes eine ausgewiesen schlechte Idee – denn in der Logik der Verteidigung eines Systems ist Mandatory Access Control so etwas wie die zweite Verteidigungslinie. Selbst wenn es Angreifern gelingt, sich unautorisiert Zugriff zu einem Benutzerzugang zu verschaffen, verhindert MAC den unautorisierten Zugriff auf alle Systemdateien. Hier verbirgt sich übrigens noch ein weiterer Grund dafür, warum passwortloses "sudo" für die Rechte von "root" keine herausragend gute Idee ist. Wer MAC deaktiviert, schreibt also ein mächtiges Werkzeug ab, um Systeme gegen Einbrecher zu verteidigen.

Sinnvoller wäre es, sich ausgiebig mit SELinux oder AppArmor zu befassen und eventuelle Probleme konsequent zu debuggen und zu reparieren. Eine Position übrigens, die sowohl AppArmor-Erfinder Canonical als auch SELinux-Haupterfinder Red Hat genau so vertreten und zunehmend konsequenter erzwingen. RHEL 9 etwa macht es deutlich schwieriger als bisherige Releases, SELinux vollständig abzuschalten – das geht dort nur noch per Kernel-Parameter, während zuvor ein Konfigurationseintrag in "/etc/sysconfig/ selinux" genügte. So oder so: Wer MAC deaktiviert, beraubt sich eines mächtigen Werkzeugs im Kampf gegen Ganoven.

Externe Werkzeuge

Am Markt existieren viele Werkzeuge, die die objektive Sicherheit eines Systems erhöhen. Neben viel Schlangenöl bietet beispielsweise Teleport echten Mehrwert – und es erweitert die klassische Benutzerverwaltung in Linux sogar extern um mehrere Features, die diese üblicherweise nicht beherrscht (Bild 3).

Vereinfacht gesagt ist Teleport eine Managementsoftware mit Proxy-Funktion. Die Idee hinter dem Programm ist simpel: Weil Anwender und Administratoren es heute mit immer mehr Systemen und verschiedenen Interfaces und Diensten zu tun haben, bündelt Teleport die verschiedenen Zugangsinformationen und fungiert als Vermittler – selbst wenn seine eigene Marketingbezeichnung als "Access Control Plane" deutlich vornehmer klingt.

Das Programm kommt in mehreren Formen daher und besteht aus mehreren Komponenten, die in einem Setup diverse Aufgaben sinnvoll erledigen. Und während Teleport früher SSH-zentristisch war, beherrscht es heute auch den Umgang mit anderen Diensten.

SSH ist allerdings bis heute so etwas wie das Teleport-Steckenpferd geblieben, und das ist dem Werkzeug deutlich anzumerken. So bietet Teleport für SSH beispielsweise eine Alternative zu händisch angelegten und verwalteten SSH-Schlüsseln, indem es eine eigene Verwaltung für X509-Zertifikate mitbringt und auf den Zielservern ausrollen kann. Passwörter sind bei einem solchen Konstrukt komplett außen vor, und Teleport erweitert SSH sogar um Funktionen, die es ab Werk gar nicht beherrscht – etwa die Zweifaktor-Authentifizierung mittels Zertifikat und Access-Code aus dem Google Authenticator. Hier ist offensichtlich, dass Teleport dem Login auf Basis von bloßen Passwörtern haushoch überlegen ist.

Nicht zu unterschätzen ist dabei, dass Teleport sich um das Ausrollen von Zertifikaten auf den Zielsystemen selber kümmert. Im Falle eines Falles lassen sich Zertifikate also an zentraler Stelle ad hoc deaktivieren. Weil zudem eine Teleport- Komponente auf jedem Server einer Teleport-Plane läuft, bietet der Dienst obendrein die Möglichkeit, Benutzer durch verschiedene Stufen eines Setups hindurch zu navigieren – also eine Art SSH-Jumphost mit eingebautem, automatischem Routing.

Wie beschrieben lassen sich mit Teleport mittlerweile allerdings auch Passwörter für andere Dienste verwenden. Das ist besonders für Desktopanwender praktisch, denn die sind bisweilen mit deutlich mehr Passwörtern konfrontiert, als es zuerst den Anschein hat. Weil Teleport aber als eine Art Credentials-Manager zur Verfügung steht, wächst der Anreiz, nicht dasselbe Passwort quer durch die Bank für sämtliche Dienste zu nutzen – einmal davon abgesehen, dass Teleport immer auf X509-Zertifikate setzt, wenn der jeweilige Zieldienst diese Funktion beherrscht. In Summe zeigt sich Teleport also als Bereicherung für die Sicherheit von Benutzerdaten.

Erst das Konzept, dann die Aktion

Bis hierhin hat der Artikel mehrere Maßnahmen und Werkzeuge vorgestellt, die aus einer löchrigen Benutzerverwaltung ein stabiles Fundament der Benutzerverwaltung machen. Vielen Administratoren stellt sich nach der bisherigen Lektüre vielleicht die Frage, welche Möglichkeiten sich für bestehende Systeme ergeben, die Benutzerverwaltung abzuhärten. Hier hat sich in der Praxis vor allem bewährt, im ersten Schritt das gewünschte Konzept zu Ende zu denken, also: Den Status zu beschreiben, den die Benutzerverwaltung – unter Einbeziehung aller Werkzeuge und Einstellungen – haben sollte.

Der Vergleich mit dem Status Quo offenbart dann sehr schnell, wo Arbeit notwendig ist. Und wie beschrieben lässt diese sich meist mit einfachen Automatisieren wie Ansible gut abwickeln. Der Ansatz hat zudem den äußerst eleganten Vorteil, dass ein entsprechendes Konzept als Checkliste ex post fungieren kann – es lässt sich zu jedem Zeitpunkt schnell überprüfen, ob sämtliche Einstellungen wie gewünscht gegeben sind. Ob das händisch oder automatisiert mittels eines Werkzeugs wie InSpec (Bild 4) von Chef passiert, ist dabei eher schon in der Kategorie "Detail" zu verorten.

Last but not least lässt sich ein mögliches Konzept für die Sicherheit von Benutzerzugängen zudem spielend leicht in die Dokumentation einer Umgebung in Sachen Compliance integrieren – das freut die Auditoren.

Fazit

Es ist nicht schwer, die Sicherheit von Benutzerzugängen auf Linux-Systemen mit wenigen Handgriffen elementar zu erhöhen – verglichen mit dem, was die meisten Distributoren ab Werk "zuliefern". Einmal mehr entpuppt sich Automatisierung auf Basis von Ansible als ausgesprochen nützlich gerade für jene Umgebungen, die auf kein zentrales Verzeichnis wie LDAP oder Active Directory zugreifen können.

Neben den eigentlichen Benutzerzugängen sollte der Admin stets die Konfiguration von Diensten im Auge behalten, die den Zugriff ermöglichen, etwa OpenSSH. Auch hier resultieren wenige Konfigurationsänderungen in erheblichen Verbesserungen bei der Sicherheit. Externe Werkzeuge wie Teleport schließlich bieten neuartige Funktionalität, die vielerorts ausgesprochen hilfreich sein dürfte. Die Sicherheit von Benutzerzugängen ist also kein Einzelthema und lässt sich nicht durch eine einzelne Maßnahme erreichen. Stattdessen ist ein Konzept notwendig – und je früher dieses existiert, desto besser schläft der Admin.

Benutzerverwaltung in Linux abhärten