Seite 2: Schlüssel mit Passwort schützen

Schlüssel mit Passwort schützen

Das SSH-Schlüsselpaar besteht aus dem Public Key id_dsa.pub und dem Private Key id_dsa. Der öffentliche Schlüssel gehört in das Homeverzeichnis des Anwenders auf der entfernten Maschine – und zwar angehängt an bestehende Schlüssel mittels cat id_dsa.pub >> ~/.ssh/authorized_keys. Wer diese Datei nur kopiert und nicht anhängt, kann die Schlüssel anderer Benutzer überschreiben und damit schlimmstenfalls den Administrator von seinem Server aussperren.

Es folgen das Testen des neuen Zugangs und das Konfigurieren von OpenSSH (siehe Kasten "Konfigurationsdatei …"). Dazu sind einige Änderungen nötig, um eine Authentifizierung mittels Passwort zu unterbinden. Erst dann ist das System immun gegen Brute-Force-Angriffe. Manchmal bleibt die Passwortauthentifizierung notwendig – ein Fall für "Pluggable Authentication Modules" (PAM), ursprünglich von Sun entwickelt und heute für alle Unix- und Linux-Versionen verfügbar. Das PAM-Framework stellt verschiedene "Low-Level"-Authentifizierungen unter einer "High-Level"-API für Systemwerkzeuge zur Verfügung. Mit seiner Hilfe lassen sich Erweiterungsmodule mit diversen Regeln für alle Anwender einbinden.

Das Modul pam_abl (Auto-Blacklisting) von Andy Armstrong etwa kann den Account oder die IP-Adresse eines Clientrechners automatisch sperren, wenn von dort mehrere Login-Fehlversuche ausgehen. Erst nach einer gewissen Zeit darf er es erneut versuchen.

Fein abgestuftes Blacklisting

Da das Modul nur im Quelltext zur Verfügung steht, muss es der Host-Admin zunächst kompilieren. Es setzt die Entwicklungspakete und Header für PAM und Berkeley DB 4.3 oder 4.2 voraus. In einem Test mit DB4.2.53 von Debian 3.1 lief es ohne Probleme. Nach dem Installieren folgt die Anpassung der PAM-Datei von SSH. Damit SSH auch PAM benutzt, muss "UsePAM yes" gesetzt sein.

pam_abl installiert die Konfigurationsdatei /etc/security/pam_abl.conf, die der Administrator mit seinem Lieblingseditor anpassen kann. Darin geben host_purge und user_purge an, wie lange ein auffälliges Login-Verhalten zur Zwangssperre des Hosts oder Benutzers führt (im Format "s,m,h,d" für Sekunden, Minuten, Stunden und Tage). Nach diesem Zeitintervall steht der Host wieder für Logins von der betreffenden IP-Adresse oder unter diesem Account-Namen zur Verfügung.

# PAM configuration for the Secure Shell service
# Disallow non-root logins when /etc/nologin exists.
auth required pam_nologin.so
auth required pam_abl.so config=/etc/security/pam_abl.conf
# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth required pam_env.so # [1]
# Standard Un*x authentication.
# Standard Un*x authorization.
# Standard Un*x session setup and teardown.
# Print the message of the day upon successful login.
session optional pam_motd.so # [1]
# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
# Standard Un*x password updating.a

Damit eine Sperre automatisch greifen kann, muss die host_rule oder user_rule definieren, wer sich wie oft falsch einloggen darf. Hinzu kommen Ausnahmeregeln für Benutzer, die nicht automatisch gesperrt werden sollen. Ein "*" besagt, dass alle User für diese Regel gültig sind, ein "!" klammert den Betreffenden aus und mit "|" lässt sich eine Benutzerliste abbilden. Ein Beispiel:

user_rule=*:5/1h
root/ssh|admin/*|dba/*:3/1h,8/1d

bedeutet, dass der normale Benutzer sich maximal fünfmal pro Stunde falsch einloggen darf, dann wird er gesperrt. root, admin und dba dürfen sich maximal dreimal pro Stunde und nicht häufiger als achtmal pro Tag falsch einloggen \u2013 sonst sind diese Benutzer gesperrt. Der Host blockiert dabei nur den Service ssh, da sonst auch andere Daemons wie cron, die ebenfalls bisweilen PAM benutzen, den User root ablehnen würden. Mit dem Kommandozeilentool pam_abl kann sich der Administrator einen Überblick über die derzeit aktive Blacklist verschaffen.

Das Risiko, dass ein Angreifer sofort das richtige Passwort eingibt, kann auch das automatische Blacklisting nicht ausschließen. Aber wenn der Angreifer aufs Raten angewiesen ist und ihm nur wenige Versuche bleiben, bevor er auf der schwarzen Liste landet, sind zumindest Brute-Force-Angriffe ausgeschlossen.

# /etc/security/pam_abl.conf
debug
host_db=/var/lib/abl/hosts.db
host_purge=2d
host_rule=*:10/1h,30/1d
user_db=/var/lib/abl/users.db
user_purge=2d
user_rule=!root:10/1h,30/1dt

Wie jedes Sicherheitskonzept sollte auch dieses mehrstufig ausgelegt sein. Sichere Passwörter, eine automatische Blacklist sowie vernünftige Login-Limits steigern die Sicherheit des Systems. Wenn eine Stufe versagt, sollten die übrigen Mechanismen das Eindringen eines Angreifers verhindern können.

Als weitere Stufe kommt eine Reihe von im Internet verfügbaren Werkzeugen in Frage, die aus dem Syslog oder Authlog die Fehlversuche auslesen und daraus Firewall-Regeln erstellen. Dieses Konzept krankt jedoch an einer relativ langsamen Reaktion. Zudem kann es die Systemlast hochtreiben, da permanent Log-Dateien zu analysieren sind.