Passwort-Sicherheit steuern unter Linux

Sicherheit, ob nun physisch oder virtuell, ist ein so breit gefächertes Thema, dass sich eine ganze Industrie darum gebildet hat. Es wurden bereits hunderte Verfahren zur Sicherung von Systemen und Netzwerken verfasst, und als Benutzer von Linux ist es unumgänglich zu verstehen, wie du dich gegen Angreifer und Eindringlinge schützen kannst.

Im folgenden Blog will ich euch in das Thema einführen und aufzeigen, welche Massnahmen auf Linux-Systemen zur Erhöhung der Sicherheit umgesetzt werden sollten. Linux, bzw. alle unixoiden Systeme gelten per se als sicher, doch kann diese Ansicht dazu führen, das Thema «Security» etwas stiefmütterlich zu behandeln.

In diesem und den folgenden Blogs möchte ich zeigen wie, wir Linux-Systeme effektiv und mit wenig Aufwand sicher betreiben können. Ein Linux-Server im Internet zu betreiben ist heute mit wenigen Mausklicks über einen Hoster freier Wahl und für wenig Geld möglich. Nutzen wir also solche Angebote und schauen uns die Möglichkeiten an, die uns Linux bietet, ein solches System auch sicher zu betreiben.

Es geht um

• Lokale Sicherheit, Benutzer, Gruppen, Passworte, PAM
• sudo
• Einmalpassworte
• Dienste on Demand (inetd, systemd socket)
• OpenSSH
• OpenSSL
• VPN mit Ipsec
• …

Wir müssen

• die Vertraulichkeit, Integrität und Verfügbarkeit von Informationssystemen gewährleisten
• unseren Kunden und Benutzer gewährleisten, dass ihre Daten geschützt sind
• Bedrohungen verstehen, erkennen und uns dagegen verteidigen
• uns Bewusst sein das Angriffe aus verschiedensten Motiven erfolgen werden – von script-kiddies bis Industriespionage

Mit Linux haben wir aber schon mal eine gute Basis geschaffen. Jetzt noch etwas Feinabstimmung und wir sind auf einem guten Weg.

Als erstes befassen wir uns damit, die Hürden zu einem Benutzerkonto zu erhöhen.

Checklisten

Um sicherzustellen, dass spezifische Arbeiten wie z.B. Benutzer anlegen/löschen, Softwareinstallationen, periodische Sicherheitschecks, Updates etc., immer gleich ausgeführt werden, sind Checklisten und Regeln ein gutes Hilfsmittel. Sie dienen dazu, Veränderungen und das Vorgehen zu dokumentieren.

Anmeldungen am System verhindern

Ein guter Ausgangspunkt für die Absicherung des Systems ist die Prüfung der Benutzerkonten. Stelle sicher, dass root ein starkes Passwort besitzt und dass dieses Passwort nicht weitergegeben wird. Deaktiviere Konten, die keinen Zugang zum System benötigen. Wird ein Konto nicht mehr benötigt, Fachperson verlässt Team/Organisation, ist es zu sperren. Wissen wir ab wann das Konto nicht mehr benötigt wird setzen wir ein Ablaufdatum. Eine Checkliste zu so einem Prozess leistet gute Dienste.

Es existieren zwei Methoden, um die Anmeldung über ein Benutzerkonto zu verweigern. Die erste Methode ist, das Konto zu sperren. Dieses Beispiel sperrt das Benutzerkonto donald:

# passwd -l donald

Bei der zweiten Methode wird der Anmeldevorgang verhindert, indem die Shell auf /usr/sbin/nologin gesetzt wird. Nur der Superuser kann die Shell für andere Benutzer ändern:

# chsh -s /usr/sbin/nologin donald

Die zweite Methode kann für Benutzer, welche Zugang zum System über einen Dienst wie z.B. ftp benötigen gesetzt werden. Für Systemaccounts können natürlich beide Methoden angewendet werden. Verlässt ein Benutzer die Firma/Organisation sollte sein Account sofort gesperrt werden.

Um einem Konto ein Ablaufdatum zu setzen verwenden wir “usermod” und ein Datum in der Form YYYY-MM-DD:

# usermod -e 2020-09-30 donald

Für temporäre Fachkräfte kann das Ablaufdatum gleich beim anlegen des Kontos gesetzt werden → useradd -e 2019-12-31 …

Tipp: Das GNU-date-Kommando kann ein Datum berechnen:

# usermod -e $(date -d '+30 days' +%Y-%m-%d) donald

Gemeinsam genutzte Benutzerkonten

Eigentlich sollte dies vermieden werden. Es muss möglichst immer eine Person hinter dem Konto stehen, um diese eindeutig zu identifizieren. Sonderrechte können dem Benutzer über seine Gruppenzugehörigkeit und sudo auf elegante Weise eingerichtet werden:

# groupaddwebadmin

# usermod -a -G webadmin hugo

# visudo
...
%webadmin ALL=(ALL) /usr/sbin/service apache2 *

Damit dürfen alle Mitglieder der Gruppe webadmin den Service apache2 starten/stoppen/restarten/… Eine geschickte sudo-Konfiguration via Gruppen erlaubt es dem Administrator, privilegierte Kommandos gezielt an Gruppen zuzulassen. Wir werden sudo zu einem späteren Zeitpunkt noch genauer betrachten.

Passworte

Passworte sind unter Linux standarmässig MD5 oder SHA512 verschlüsselt und stehen zusammen mit weiteren Angaben zur “Alterung” des Passwortes in der Datei “/etc/shadow” in der Form:

# grep ^hugo /etc/passwd
hugo:<--- Passwort-Hash --->:18191:7:5::

Werden diese Werte beim Anlegen des Kontos nicht angegeben, gelten die Default-Werte aus der Datei «/etc/login.defs»:

# grep ^PASS /etc/login.defs
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_WARN_AGE 7

Passworte regelmässig zu ändern, macht Sinn, 90 – 120 Tage sind ein guter Ansatz. Wie obiges Beispiel zeigt, sind die Default-Werte grosszügig gesetzt. Mittels PASS_MIN_DAYS wird vermieden, dass ein oberschlauer Benutzer ein neues Passwort setzt und dann wieder auf das alte Pw zurücksetzen kann. Wir werden gleich sehen, dass dies auch noch auf andere Weise vermieden werden kann.

PAM

Das Plugable Authentication Module kümmert sich um Zugriffe auf Benutzerkonten. Die Konfigurations-dateien von PAM finden sich unter «/etc/pam.d/». Die Namen der Dateien varieren zwischen den Distributionen. PAM regelt von wo root-Logins möglich sind (securetty), die Passwort-komplexität, Überwachung der Loginversuche, welche Gruppe das su-Kommando anwenden kann, etc.
Mittels des PAM und seinen Modulen kann sich dein Linux auch in LDAP oder ADS authentifizieren, biometrische Daten verlangen und vieles mehr. Schauen wir uns ein paar nützliche Module an.

Passwortkomplexität

Schlechte Passworte sind nichts Wert, d.h. einfach zu erraten. Um zu vermeiden, dass unser Benutzer hugo auf die Idee kommt «hugo123» als Passwort zu verwenden, setzen wir mittels pam_cracklib die Passwortkomplexität.

Ein Passwort wie z.B. «A2_qT3rg~9» ist nicht schlecht, aber wie soll sich der Benutzer dies merken? Etwas wie: «Dp=dCm0Ple» → Digicomp = digital Competence made 0f People – kann ich mir herleiten (0 statt O).

Auf RPM-basierten Systemen wird die Komplexität des Passwortes in «/etc/pam.d/system-auth (/etc/pam.d/common-password» auf «.deb» basierten Systemen) konfiguriert:

password requisite pam_cracklib.so retry=3 minlen=8 difok=3 ocredit=-1 dcredit=-1 ucredit=-1

Die PAM-Library «pam_cracklib» prüft ein Passwort auf einfach zu erraten, bekannte Muster, Benutzername im Passwort, …

Obige Zeile konfiguriert ein Passwort mit:

• 3 Versuche ein neues Passwort zu erzeugen: retry=3
• Mindestens 8 Zeichen: minlen=8
• Min. 3 Zeichen Differenz zum alten Passwort: difok=3
• Min. 1 Grossbuchstabe: ucredit=-1
• Min. 1 Kleinbuchstabe: lcredit=-1
• Min. 1 Sonderzzeichen: ocredit=-1

Passwort Geschichte

Die PAM-Library «pam_unix» kann verhindern, dass alte Passworte wiederverwendet werden können. Dazu legen wir zuerst eine eine Datei “/etc/security/opasswd” an:

# > /etc/security/opasswd
# chown root:root /etc/security/opasswd
# chmod 600 /etc/security/opasswd

Die Credentials der Datei entsprechen «/etc/shadow».

Mittels der Zeile:

password required pam_unix.so md5 remember=3 use_auttok

werden die letzten 5 Passworte in der History gespeichert und dürfen nicht verwendet werden.

Failed Logins

Füge folgende Zeile in der Datei «/etc/pam.d/login» ein:

auth required pam_tally2.so deny=4 even_deny_root unlock_time=1200

Sperrt den Benutzer für 20 Minuten bei vier Falscheingaben des Passwortes.

su-Kommando einschränken

Um das su-Kommando nur Mitgliedern der Gruppe «wheel» zu erlauben, kann diese Zeile in der Datei «/etc/pam.d/su» eingefügt werden:

auth required pam_wheel.so group=wheel

root Login nur via Securetty

Die PAM-Library «pam_securetty» regelt von wo (welchen Terminals) ein root-Login möglich ist. Dies betrifft aber keine SSH-Logins. Im Idealfall kann root nur an der Konsole einloggen.

Alle Logins blockieren

Die PAM-Library «pam_nologin» lässt temporär keine Logins ausser «root» an den mittels pam_securetty definierten Terminals zu, indem eine leere Datei «/etc/nologin» erstellt wird. Diesen Mechanismus verwendet auch das «shutdown»-Kommando, um keine Logins mehr zuzulassen. Wird «/etc/nologin» entfernt, sind Logins wieder möglich.

Ausblick

• Sichere Passworte, Sichere Passworte, Sichere Passworte, Sichere Passworte, Sichere Passworte
• Systeme welche im Internet sichtbar sind werden angegriffen
• Unsere Linux-Server müssen Benutzerkonten anbieten (Konsolen, SSH-Zugang)
• Linux bietet gute Werkzeuge um die Konten zu verwalten und sichere Zugänge zu gewährleisten