Product SiteDocumentation Site

4.11. Den Benutzerzugang absichern

4.11.1. Benutzerauthentifizierung: PAM

PAM (Pluggable Authentication Modules) erlaubt Systemadministratoren, auszuwählen, wie Anwendungen Benutzer authentifizieren. Beachten Sie, dass PAM nichts machen kann, solange die Anwendung nicht mit Unterstützung für PAM kompiliert wurde. Die meisten Anwendungen, die mit Debian geliefert werden, haben diese Unterstützung eingebaut. Vor Version 2.2 hatte Debian keine Unterstützung für PAM. Die derzeitige Standardkonfiguration für jeden Dienst, der PAM benutzt, ist es, UNIX-Authentifizierung zu emulieren (lesen Sie /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz, um mehr darüber zu erfahren, wie PAM-Dienste unter Debian arbeiten sollten).
Jede Anwendung mit PAM-Unterstützung stellt eine Konfigurationsdatei unter /etc/pam.d/ zur Verfügung, in welcher Sie ihr Verhalten einstellen können:
  • welches Verfahren zur Authentifizierung benutzt wird
  • welches Verfahren innerhalb einer Sitzung benutzt wird
  • wie Passwörter überprüft werden
The following description is far from complete, for more information you might want to read the Linux-PAM Guides as a reference. This documentation is available in the system if you install the libpam-doc at /usr/share/doc/libpam-doc/html/.
PAM bieten Ihnen die Möglichkeit, durch mehrere Authentifizierungsschritte auf einmal zu gehen, ohne dass der Benutzer es weiß. Sie können gegen eine Berkeley-Datenbank und gegen die normale passwd-Datei authentifizieren, und der Benutzer kann sich nur anmelden, wenn er beide Male korrekt authentifiziert wurde. Sie können mit PAM viel einschränken, genauso wie Sie Ihr System weit öffnen können. Seien Sie also vorsichtig. Eine typische Konfigurationszeile hat ein Steuerfeld als zweites Element. Generell sollte es auf requisite gesetzt werden, so wird ein Anmeldefehler erzeugt, wenn eines der Module versagt.

4.11.2. Passwortsicherheit in PAM

Sehen Sie sich /etc/pam.d/common-password an, die von /etc/pam.d/passwd eingebunden wird. [23] Andere Dateien in /etc/pam.d/ lesen diese Datei ein, um die Verwendung eines Passworts durch Programme, die einen Zugriff auf das System erlauben, wie etwa das Konsolen-Login (Login), grafische Login-Manager (z.B. Gdm oder Lightdm) und Login aus der Ferne (etwa mit Sshd), zu definieren.
Sie müssen sicherstellen, dass das Modul pam_unix.so die Option »sha512« verwendet, damit die Passwörter verschlüsselt werden. In Debian Squeeze ist dies standardmäßig eingerichtet.
Die Zeile mit der Konfiguration des Moduls pam_unix sollte etwa so aussehen:
  password   [success=1 default=ignore]      pam_unix.so nullok obscure minlen=8 sha512
Dieser Ausdruck
  • erzwingt die Verschlüsselung von Passwörtern mit der Hashfunktion SHA-512, wenn sie gespeichert werden (Option sha512),
  • aktiviert die Überprüfung der Komplexität eines Passworts, wie sie in der Handbuchseite pam_unix(8) beschrieben wird (Option obscure),
  • erfordert, dass das Passwort mindestens acht Zeichen lang ist (Option min).
Sie müssen sicherstellen, dass in PAM-Anwendungen verschlüsselte Passwörter verwendet werden, weil dies Wörterbuchangriffe erschwert. Zugleich wird es dadurch möglich, Passwörter mit mehr als acht Zeichen einzusetzen.
Da mit diesem Modul auch definiert wird, wie Passwörter geändert werden, weil es von Chpasswd eingebunden wird, können Sie die Passwortsicherheit Ihres Systems erhöhen, indem sie libpam-cracklib installieren und folgenden Ausdruck in die Konfigurationsdatei /etc/pam.d/common-password eintragen:
  # Gehen Sie sicher, dass Sie libpam-cracklib zuerst installiert haben,
  # sonst werden Sie sich nicht einloggen können
  password   required     pam_cracklib.so retry=3 minlen=12 difok=3
  password   [success=1 default=ignore]      pam_unix.so obscure minlen=8 sha512 use_authok
Also, was macht diese Beschwörungsformel nun genau? Die erste Zeile lädt das PAM-Modul cracklib, welches einen Passwort-Sicherheitscheck bereitstellt. Es fragt nach einem neuen Passwort mit mindestens zwölf Zeichen [24], einer Differenz von mindestens drei Zeichen zum alten Passwort und erlaubt drei Versuche. Cracklib benötigt ein Paket mit Wörterlisten (wie wngerman, wenglish, wspanish, ...). Stellen Sie also sicher, dass Sie ein passendes Paket für Ihre Sprache installiert haben. Ansonsten ist Cracklib nicht verwendbar.
Die zweite Zeile (mit dem Module pam_unix.so) ist – wie oben beschrieben – der Standard in Debian mit Ausnahme der Option use_authok. Diese Option ist notwendig, wenn pam_unix.so nach pam_cracklib.so aufgerufen wird, damit das Passwort vom zuerst aufgerufenen Modul weitergereicht wird. Anderenfalls muss der Benutzer sein Passwort zweimal eingegeben.
Weitere Informationen über die Konfiguration von Cracklib finden Sie in der Handbuchseite pam_cracklib(8) und dem Artikel http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html von Hal Pomeranz.
Mit dem PAM-Modul Cracklib richten Sie eine Richtlinie ein, welche die Verwendung guter Passwörter erzwingt.
Als Alternative können Sie auch PAM-Module einsetzen, die eine Zwei-Faktor-Authentifizierung verwenden, wie z.B. libpam-barada, libpam-google-authenticator, libpam-oath, libpam-otpw, libpam-poldi, libpam-usb oder libpam-yubico. Diese Module ermöglichen es, sich mit einer externen Authentifizierungsmethode am System anzumelden, etwa mit einer Chipkarte, einem USB-Stick oder Einmal-Passwörtern, die mit einer externen Anwendung, z.B. auf einem Mobiltelefon, erzeugt wurden.
Denken Sie daran, dass diese Einschränkungen alle Benutzer betreffen außer Änderungen von Passwörtern, die der Benutzer Root vornimmt. Dieser kann unabhängig von den eingerichteten Beschränkungen jedes Passwort (in Hinblick auf Länge oder Komplexität) für sich oder andere Benutzer vergeben.

4.11.3. Steuerung des Benutzerzugangs in PAM

Um sicher zu stellen, dass sich der Benutzer Root nur an lokalen Terminals anmelden kann, sollten Sie die folgende Zeile in /etc/pam.d/login einfügen:
  auth     requisite  pam_securetty.so
Danach sollten Sie die Liste der Terminals in /etc/securetty ändern, auf denen sich Root unmittelbar anmelden darf (wie in Abschnitt 4.7, „Einschränkung der Anmeldemöglichkeiten an der Konsole“ beschrieben). Alternativ dazu können Sie auch das pam_access-Modul aktivieren und /etc/security/access.conf bearbeiten. Dieses Vorgehen erlaubt eine allgemeinere und feiner abgestimmte Zugangssteuerung, leider fehlen aber vernünftige Protokollmeldungen (diese sind in PAM nicht standardisiert und sind ein besonders unbefriedigendes Problem). Wir werden zu access.conf in Kürze zurückkehren.

4.11.4. Höchstgrenzen für Benutzer in PAM

Die folgende Zeile sollte in /etc/pam.d/login aktiviert werden, um den Benutzern Grenzen ihrer Systemressourcen zu setzen.
  session  required   pam_limits.so
Dies schränkt die Systemressourcen ein, die ein Benutzer nutzen darf (siehe Abschnitt 4.11.8, „Ressourcen-Nutzung begrenzen: Die Datei limits.conf weiter unten). Sie können zum Beispiel die Anzahl der Logins, die man haben kann, einschränken (für eine Gruppe von Benutzern oder systemweit), die Anzahl der Prozesse, den belegten Speicher etc.

4.11.5. Steuerung von su in PAM

Wenn Sie Su schützen möchten, so dass nur manche Leute es benutzen können, um Root auf Ihrem System zu werden, müssen Sie eine neue Gruppe »wheel« zu Ihrem System hinzufügen (das ist der sauberste Weg, da keine Datei solche Gruppenrechte bisher benutzt). Fügen Sie Root und die anderen Benutzer, die zu Root suen können sollen, zu dieser Gruppe hinzu. Ergänzen Sie anschließend /etc/pam.d/su/ um die folgende Zeile:
  auth        requisite   pam_wheel.so group=wheel debug
Dies stellt sicher, dass nur Personen aus der Gruppe »wheel« su benutzen können, um Root zu werden. Andere Benutzer wird es nicht möglich sein, Root zu werden. Tatsächlich werden sie eine ablehnende Nachricht bekommen, wenn sie versuchen, Root zu werden.
Wenn Sie es nur bestimmten Benutzern erlauben wollen, sich bei einem PAM-Dienst zu authentifizieren, ist dies sehr leicht zu erreichen, indem Sie Dateien benutzen, in denen die Benutzer, denen es erlaubt ist, sich anzumelden (oder nicht), gespeichert sind. Stellen Sie sich vor, Sie möchten lediglich dem Benutzer »ref« erlauben, sich mittels ssh anzumelden. Sie schreiben ihn also in eine Datei /etc/ssh-users-allowed und schreiben das Folgende in /etc/pam.d/ssh:
  auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

4.11.6. Temporäre Verzeichnisse in PAM

Da es eine Reihe von Sicherheitslücken mit so genannten unsicheren temporären Dateien zum Beispiel in Thttpd (vgl. http://www.debian.org/security/2005/dsa-883) gab, lohnt es sich, das Paket libpam-tmpdir zu installieren. Sie müssen dann lediglich Folgendes zu /etc/pam.d/common-session hinzuzufügen:
 session    optional     pam_tmpdir.so
Es gab auch eine Diskussion, dies standardmäßig in Debian einzufügen. Sehen Sie sich http://lists.debian.org/debian-devel/2005/11/msg00297.html für weitere Informationen an.

4.11.7. Konfiguration für nicht definierte PAM-Anwendungen

Zuletzt, aber nicht am unwichtigsten, erstellen Sie /etc/pam.d/other mit den folgenden Zeilen:
  auth     required       pam_securetty.so
  auth     required       pam_unix_auth.so
  auth     required       pam_warn.so
  auth     required       pam_deny.so
  account  required       pam_unix_acct.so
  account  required       pam_warn.so
  account  required       pam_deny.so
  password required       pam_unix_passwd.so
  password required       pam_warn.so
  password required       pam_deny.so
  session  required       pam_unix_session.so
  session  required       pam_warn.so
  session  required       pam_deny.so
Diese Zeilen stellen für alle Anwendungen, die PAM unterstützen, eine gute Standardkonfiguration dar (Zugriff wird standardmäßig verweigert).

4.11.8. Ressourcen-Nutzung begrenzen: Die Datei limits.conf

Sie sollten sich wirklich ernsthaft mit dieser Datei beschäftigen. Hier können Sie Ihren Benutzern Ressourcengrenzen vorgeben. In alten Veröffentlichungen war die Konfigurationsdatei /etc/limits.conf. Aber in neueren Versionen (mit PAM) sollte stattdessen die Konfigurationsdatei /etc/security/limits.conf benutzt werden.
Wenn Sie die Ressourcennutzung nicht einschränken, kann jeder Benutzer mit einer gültigen Shell auf Ihrem System (oder sogar ein Einbrecher, der das System durch einen Dienst kompromittierte, oder ein außer Kontrolle geratener Daemon) so viel CPU, Speicher, Stack etc. benutzen, wie das System zur Verfügung stellen kann. Dieses Problem der Überbeanspruchung von Ressourcen kann mit der Nutzung von PAM gelöst werden.
Es gibt einen Weg, Ressourcengrenzen zu manchen Shells hinzuzufügen (zum Beispiel hat Bash ulimit, siehe bash(1)). Aber da nicht alle die gleichen Höchstgrenzen zur Verfügung stellen und der Benutzer seine Shell ändern kann (siehe chsh(1)), ist es besser, die Höchstgrenzen in den PAM-Modulen zu platzieren, da diese unabhängig von der verwendeten Shell Anwendung finden und auch PAM-Module betreffen, die nicht shellorientiert sind.
Ressourcengrenzen werden vom Kernel verhängt, aber sie müssen durch limits.conf konfiguriert werden und die PAM-Konfiguration der verschiedenen Dienste muss das passende PAM laden. Sie können herausfinden, welche Dienste Höchstgrenzen durchsetzen, indem Sie Folgendes ausführen:
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
Für gewöhnlich setzen Login, Ssh und die grafischen Sitzungsmanager (Gdm, Kdm und Xdm) Benutzerhöchstgrenzen durch, aber Sie sollte dies auch in anderen Konfigurationsdateien für PAM wie für Cron vornehmen, um zu verhindern, dass System-Daemons alle Systemressourcen aufbrauchen.
Die konkreten Begrenzungen, die Sie festlegen wollen, hängt von den Ressourcen Ihres Systems ab. Das ist einer der Hauptgründe, warum keine Höchstgrenzen in der Standardinstallation enthalten sind.
So setzt die Konfiguration im Beispiel unten eine Begrenzung von 100 Prozessen für alle Benutzer (um Fork-Bomben [25] zu vermeiden), eine Begrenzung auf 10 MB Speicher pro Prozess und ein Höchstgrenze von 10 gleichzeitigen Logins durch. Benutzer in der Gruppe adm haben höhere Begrenzungen und können Dateien mit einem Speicherabbild schreiben, wenn sie das wollen (es gibt also nur eine weiche Begrenzung).
*              soft    core            0
*              hard    core            0
*              hard    rss             1000
*              hard    memlock         1000
*              hard    nproc           100
*              -       maxlogins       1
*              hard    data            102400
*              hard    fsize           2048
@adm           hard    core            100000
@adm           hard    rss             100000
@adm           soft    nproc           2000
@adm           hard    nproc           3000
@adm           hard    fsize           100000
@adm           -       maxlogins       10
Dies könnten die Höchstgrenzen eines Standardbenutzers (einschließlich der System-Daemons) sein:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 2048
max locked memory     (kbytes, -l) 10000
max memory size       (kbytes, -m) 10000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 100
virtual memory        (kbytes, -v) unlimited
Und dies die Höchstgrenzen für einen Administrator:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 100000
max locked memory     (kbytes, -l) 100000
max memory size       (kbytes, -m) 100000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 2000
virtual memory        (kbytes, -v) unlimited
Lesen Sie für weitere Informationen:

4.11.9. Aktionen bei der Benutzeranmeldung: Bearbeiten von /etc/login.defs

Der nächste Schritt ist es, die grundlegende Konfiguration und die Aktionen bei der Benutzeranmeldung zu bearbeiten. Beachten Sie, dass diese Datei kein Bestandteil der PAM-Konfiguration ist. Sie ist eine Konfigurationsdatei, die von den Programmen Login und Su berücksichtigt wird. Es ist also wenig sinnvoll, sie auf Fälle abzustimmen, in denen keines der beiden Programme wenigstens indirekt aufgerufen wird (Das Programm Getty, welches auf der Konsole läuft und die anfängliche Anmeldeaufforderung zu Verfügung stellt, ruft Login auf).
  FAILLOG_ENAB        yes
Wenn Sie diese Variable einschalten, werden fehlgeschlagene Anmeldeversuche protokolliert. Es ist wichtig, hier auf dem Laufendem zu bleiben, um jemanden zu ermitteln, der einen Brute-Force-Angriff versucht.
  LOG_UNKFAIL_ENAB    no
Wenn Sie diese Variable auf »yes« setzen, werden unbekannte Benutzernamen protokolliert, wenn eine Anmeldung scheitert. Es ist zu empfehlen, sie auf »no« (den Standard) zu belassen, da anderenfalls das Passwort eines Benutzers aufgezeichnet werden könnte (falls er nämlich versehentlich anstatt seines Benutzernames sein Passwort eingibt). Falls Sie sie dennoch auf »yes« setzen, müssen Sie sicherstellen, dass die Protokolldateien angemessene Zugriffsrechte haben (zum Beispiel 640, mit einer passenden Gruppenzugehörigkeit wie adm).
  SYSLOG_SU_ENAB      yes
Dies schaltet das Mitprotokollieren von su-Versuchen im Syslog ein. Sehr wichtig auf ernsthaft betriebenen Maschinen, aber beachten Sie, dass dies auch die Privatsphäre verletzen kann.
  SYSLOG_SG_ENAB      yes
Das gleiche wie bei SYSLOG_SU_ENAB, aber für das Programm Sg.
  ENCRYPT_METHOD  SHA512
Wie bereits erklärt, reduziert eine Verschlüsselung von Passwörtern die Gefahr von Wörterbuchangriffen erheblich, da Sie längere Passwörter benutzen können. Diese Definition muss mit dem Wert in /etc/pam.d/common-password übereinstimmen.

4.11.10. Aktionen bei der Benutzeranmeldung: /etc/pam.d/login bearbeiten

Sie können die Datei zur Konfiguration des Anmeldevorgangs anpassen, um eine strengere Richtlinie festzuschreiben. Zum Beispiel können Sie die Wartezeit zwischen zwei Anmeldeversuchen im Vergleich zur Standardkonfiguration erhöhen. Diese Standardvorgabe setzt eine Wartezeit von drei Sekunden:
auth       optional   pam_faildelay.so  delay=3000000
Wenn Sie den Wert von delay erhöhen, wird es schwieriger, sich durch bloßes Ausprobieren von Passwörtern (brute force) erfolgreich am Terminal anzumelden. Wenn ein falsches Passwort eingegeben wird, muss ein möglicher Angreifer (oder ein normaler Benutzer!) viele Sekunden warten, bis er wieder eine Eingabeaufforderung erhält, wodurch das Durchprobieren von Passwörtern sehr zeitaufwendig werden kann. So müssen etwa Benutzer bei delay=10000000 zehn Sekunden warten, wenn sie das falsche Passwort eingeben.
In dieser Datei können Sie auch einrichten, dass das System dem Benutzer vor einer Anmeldung eine Nachricht anzeigt. Standardmäßig ist dies deaktiviert, wie Sie hier sehen können:
# auth       required   pam_issue.so issue=/etc/issue
Falls es Ihre Sicherheitsrichtlinie erfordert, können Sie mit dieser Datei eine Standardnachricht, dass der Zugang zum System beschränkt und der Benutzerzugang protokolliert wird, anzeigen lassen. Ein solcher Hinweis kann in bestimmten Regionen und nach der jeweiligen Rechtsprechung notwendig sein. Um dies zu aktivieren, müssen Sie nur die entsprechende Mitteilung in die Datei /etc/issue [26] eintragen und das Kommentarzeichen in der Zeile in /etc/pam.d/login entfernen, um das Modul pam_issue.so zu aktivieren. In dieser Datei können Sie weitere Einstellungen vornehmen, die für Ihre Sicherheit relevant sein könnten, wie zum Beispiel:
  • Regeln erstellen, welcher Benutzer zu welchen Zeiten auf das System zugreifen kann, indem Sie das Modul pam_time.so aktivieren und /etc/security/time.conf entsprechend konfigurieren (standardmäßig deaktiviert),
  • den Anmeldevorgang so einrichten, dass Benutzerbegrenzungen, die in /etc/security/limits.conf definiert sind, verwendet werden (standardmäßig aktiviert),
  • dem Benutzer Informationen über die vorangegangene Anmeldung anzeigen (standardmäßig aktiviert),
  • nach erfolgter Anmeldung den Benutzern eine Nachricht (/etc/motd und /run/motd.dynamic) anzeigen (standardmäßig aktiviert).

4.11.11. Ftp einschränken: bearbeiten von /etc/ftpusers

Die Datei /etc/ftpusers enthält eine Liste von allen Benutzern, denen es nicht erlaubt ist, sich auf dem Rechner mit Ftp einzuloggen. Benutzen Sie diese Datei nur, wenn Sie wirklich Ftp erlauben wollen (wozu im Allgemeinen nicht geraten wird, da es Klartext-Passwörter benutzt). Wenn Ihr Ftp-Daemon PAM unterstützt, können Sie dies ebenfalls benutzen, um Benutzern bestimmte Dienste zu erlauben oder zu verbieten.
FIXME (FEHLER): Ist es ein Fehler, dass ftpusers in Debian standardmäßig nicht die Benutzer mit Administratorenrecht (in base-passwd) beinhaltet?
Folgender Befehl ist ein bequemer Weg, alle Systemkonten zu /etc/ftpusers hinzuzufügen:
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers

4.11.12. Verwendung von Su

Wenn es wirklich benötigt wird, dass Benutzer der Super-User (also Root, d.Ü.) auf Ihrem System werden, zum Beispiel um Pakete zu installieren oder neue Benutzer anzulegen, können Sie das Programm Su benutzen, um Ihre Identität zu wechseln. Sie sollten jeden Login als Benutzer Root vermeiden und stattdessen das Programm Su benutzen. Eigentlich ist die beste Lösung, Su zu entfernen und zu Sudo zu wechseln, da es eine feinere Steuerung und mehr Möglichkeiten bietet als Su. Wie auch immer, Su ist verbreiteter und wird auf vielen Unices eingesetzt.

4.11.13. Verwendung von Sudo

Sudo erlaubt es dem Benutzer, bestimmte Befehle unter einer anderen Benutzeridentität auszuführen, sogar als Root. Wenn der Benutzer zu /etc/sudoers hinzugefügt ist und sich korrekt authentifiziert, ist er in der Lage, Befehle, die in /etc/sudoers definiert wurden, auszuführen. Sicherheitsverletzungen, wie ein inkorrektes Passwort oder der Versuch ein Programm auszuführen, für das die Rechte nicht ausreichen, werden protokolliert und an Root gemailt.

4.11.14. Administrativen Fernzugriff verweigern

Sie sollten /etc/security/access.conf ebenfalls so verändern, dass ein Login aus der Ferne in ein administratives Konto nicht erlaubt wird. Auf diese Weise müssen Benutzer das Programm Su (oder Sudo) aufrufen, um Administratorenrechte zu bekommen, so dass es immer eine nachprüfbare Spur gibt.
Sie müssen die folgende Zeile zu Ihrer /etc/security/access.conf hinzufügen, in Debians Standardkonfigurationsdatei ist ein Beispiel auskommentiert:
   -:wheel:ALL EXCEPT LOCAL
Vergessen Sie nicht, in /etc/pam.d/ das pam_access-Module für jeden Dienst (oder die Standardkonfiguration) anzuschalten, wenn Sie wollen, dass Ihre Änderungen an /etc/security/access.conf berücksichtigt werden.

4.11.15. Den Benutzerzugang einschränken

Manchmal werden Sie denken, dass Sie einen Benutzer auf Ihrem System erstellen müssen, um einen bestimmten Dienst (Pop3-E-Mail-Server oder Ftp) anzubieten. Bevor Sie dies tun, denken Sie zuerst daran, dass die PAM-Implementierung in Debian GNU/Linux Ihnen erlaubt, Benutzer mit einer breiten Auswahl von externen Verzeichnisdiensten (Radius, LDAP etc.) zu überprüfen. Dies wird vom Paket libpam bewerkstelligt.
Wenn Sie einen Benutzer anlegen müssen und auf Ihr System aus der Ferne zugegriffen werden kann, beachten Sie, dass es Benutzern möglich sein wird, sich anzumelden. Sie können dies beheben, indem Sie diesen Benutzern Null (/dev/null) als Shell (sie muss in /etc/shells aufgelistet sein) zuweisen. Wenn Sie den Benutzern erlauben wollen, auf das System zuzugreifen, aber ihre Bewegungen einschränken wollen, können Sie /bin/rbash benutzen. Dies hat das gleiche Ergebnis, wie wenn Sie die Option -r der Bash (RESTRICTED SHELL, siehe bash(1)) verwendet hätten. Beachten Sie bitte, dass sogar mit einer beschränkten Shell ein Benutzer, der auf ein interaktives Programm zugreifen kann (das ihm erlaubt, eine Subshell auszuführen), diese Limitierung der Shell umgehen kann.
Debian bietet zurzeit in seiner Unstable-Veröffentlichung (und wird es vielleicht der nächsten Stable-Veröffentlichung hinzufügen) das Modul pam_chroot (in libpam-chroot) an. Eine Alternative hierzu ist es, die Dienste, die eine Fernanmeldung ermöglichen (Ssh und Telnet), in einer Chroot-Umgebung laufen zu lassen. [27]
Wenn Sie einschränken wollen, wann ein Benutzer auf das System zugreifen kann, müssen Sie /etc/security/access.conf an Ihre Bedürfnisse anpassen.
Informationen, wie man Benutzer, die auf das System mittels des Dienstes Ssh zugreifen, in eine Chroot-Umgebung einsperrt, wird in Abschnitt B.7, „Chroot-Umgebung für SSH beschrieben.

4.11.16. Überprüfen der Benutzer

Wenn Sie wirklich paranoid sind, sollten Sie eine systemweite Einrichtung verwenden, um zu überwachen, was die Benutzer auf Ihrem System tun. In diesem Abschnitt werden einige Tipps vorgestellt, wie Sie verschiedene Werkzeuge verwenden.

4.11.16.1. Überwachung von Ein- und Ausgabe mittels eines Skripts

Um sowohl die von den Benutzern ausgeführten Programme als auch deren Ergebnisse zu überwachen, können Sie den Befehl script verwenden. Sie können script nicht als eine Shell einsetzen (auch dann nicht, wenn Sie es zu /etc/shells hinzufügen). Aber Sie können in die Datei, welche den Startvorgang der Shell steuert, folgendes eintragen:
umask 077
exec script -q -a "/var/log/sessions/$USER"
Wenn Sie dies systemweit vornehmen, bedeutet dies natürlich, dass die Shell die weiteren persönlichen Startdateien nicht abarbeitet (weil die Shell von script überschrieben wird). Eine Alternative ist, dies in den Startdateien des Benutzers vorzunehmen (dann kann der Benutzer aber dies entfernen, vgl. dazu die Anmerkungen unten).
Sie müssen auch die Dateien im Überwachungsverzeichnis (im Beispiel /var/log/sessions/) so einrichten, dass die Benutzer in sie schreiben, sie aber nicht löschen können. Dies kann zum Beispiel bewerkstelligt werden, indem die Sitzungsdateien der Benutzer vorab erstellt und mit chattr auf append-only (nur anfügen) gesetzt werden.
Eine sinnvolle Alternative für Systemadministratoren, die auch Zeitinformationen enthält, ist:
umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

4.11.16.2. Die Chronikdatei der Shell benutzen

Wenn Sie auswerten wollen, was die Benutzer in die Shell eingeben (aber nicht was das Ergebnis ist), können Sie eine systemweite /etc/profile so einrichten, dass alle Befehle in einer Chronikdatei gespeichert werden. Die systemweite Einstellung muss so eingerichtet werden, dass Benutzer die Überwachungsfähigkeit nicht aus ihrer Shell entfernen können. Ob dies möglich ist, hängt von der Art der Shell ab. Sie müssen also sicherstellen, dass alle Benutzer eine Shell verwenden, die das unterstützt.
Für die Bash zum Beispiel könnte /etc/profile folgendermaßen aufgebaut werden [28]:
  HISTFILE=~/.bash_history
  HISTSIZE=10000
  HISTFILESIZE=999999
  # Verhindert, dass Benutzer Befehle eintragen,
  # die in die Verlaufsdatei ignoriert werden
  HISTIGNORE=""
  HISTCONTROL=""
  readonly HISTFILE
  readonly HISTSIZE
  readonly HISTFILESIZE
  readonly HISTIGNORE
  readonly HISTCONTROL
  export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
Damit dies funktioniert, dürfen die Benutzer nur Informationen zur .bash_history-Datei hinzufügen. Sie müssen daher zusätzlich die Option append-only (nur anfügen) mittels des Programms Chattr für die .bash_history aller Benutzer setzen [29].
Beachten Sie, dass Sie obige Konfiguration auch in .profile des Benutzers eintragen können. Dann müssten Sie aber die Rechte korrekt vergeben, so dass der Benutzer daran gehindert ist, diese Datei zu verändern. Dies schließt ein, dass das Home-Verzeichnis des Benutzers diesem nicht gehört (sonst könnte er die Datei einfach löschen). Gleichzeitig müsste ihm ermöglicht werden, die Konfigurationsdatei .profile zu lesen und in .bash_history zu schreiben. Falls Sie diese Variante wählen wollen, wäre es auch gut, den Schalter immutable (unveränderbar) für .profile zu setzen (auch dazu verwenden Sie Chattr).

4.11.16.3. Vervollständigung der Benutzerüberwachung durch Accounting-Werkzeuge

Die vorherigen Beispiele stellen eine einfache Art dar, um die Überwachung von Benutzern einzurichten. Sie eignen sich aber nicht unbedingt für komplexe Systeme oder für solche, auf denen die Benutzer überhaupt keine (oder ausschließlich) Shells am Laufen haben. Sollte dies der Fall sein, schauen Sie sich das Paket acct an, das Werkzeuge zur Auswertung (accounting utilities) enthält. Diese werden alle Befehle, die ein Benutzer oder ein Prozess auf dem System ausführt, – auf die Kosten von Plattenplatz – aufzeichnen.
Wenn Sie diese Auswertung aktivieren, werden alle Informationen über Prozesse und Benutzer unter /var/account/ gespeichert, genauer gesagt in pacct. Das Accounting-Paket enthält einige Werkzeuge (Sa, Ac und Lastcomm) zur Analyse dieser Daten.

4.11.16.4. Andere Methoden zur Benutzerüberwachung

If you are completely paranoid and want to audit every user's command, you could take bash source code, edit it and have it send all that the user typed into another file. Or have ttysnoop constantly monitor any new ttys [30] and dump the output into a file. Other useful program is snoopy (see also github: https://github.com/a2o/snoopy) which is a user-transparent program that hooks in as a library providing a wrapper around execve() calls, any command executed is logged to syslogd using the authpriv facility (usually stored at /var/log/auth.log).

4.11.17. Nachprüfung der Benutzerprofile

Wenn Sie sehen wollen, was Benutzer tatsächlich tun, wenn sie sich am System anmelden, können Sie die wtmp-Datenbank benutzen, die alle Anmeldeinformationen enthält. Diese Datei kann mit verschiedenen Werkzeugen weiterverarbeitet werden, unter ihnen Sac, das ein Profil für jeden Benutzer ausgeben kann und zeigt, in welchem Zeitfenster sie sich für gewöhnlich auf dem System anmelden.
Für den Fall, dass Sie Accounting aktiviert haben, können Sie auch die mitgelieferten Werkzeuge verwenden, um festzustellen, wann Benutzer auf das System zugreifen und was sie ausführen.

4.11.18. Umasks der Benutzer einstellen

Abhängig von Ihren Benutzerrichtlinien möchten Sie ändern, wie Benutzer Informationen gemeinsam benutzen können. Dabei geht es um die Standardrechte von neu erstellten Dateien.
Das Standardwert von Umask ist in Debian 022. Das bedeutet, dass die Gruppe des Benutzers und alle anderen Benutzers auf dem System die Dateien (und Verzeichnisse) lesen und darauf zugreifen kann. Dieser Wert wird in der Standardkonfigurationsdatei /etc/profile gesetzt, die von allen Shells verwendet wird.
Wenn die Standardwerte von Debian für Ihr System zu großzügig sind, müssen Sie die Umask-Einstellungen für alle Shells ändern. Strengere Umask-Einstellungen sind 027 (kein Zugriff der Gruppe other auf neue Dateien, dazu zählen andere Benutzer auf dem System) oder 077 (kein Zugriff der Mitglieder der Gruppe des Benutzers). Debian erzeugt (standardmäßig[31]) für jeden Benutzer eine eigene Gruppe, so dass das einzige Gruppenmitglied der Benutzer selbst ist. Daher ergibt sich zwischen 027 und 077 kein Unterschied, da die Benutzergruppe nur den Benutzer selbst enthält.
Dies ändern Sie, indem Sie eine passende Umask für alle Benutzer einstellen. Dazu müssen Sie einen umask-Aufruf in den Konfigurationsdateien aller Shells einfügen: /etc/profile (wird von allen Shells beachtet, die kompatibel mit Bourne sind), /etc/csh.cshrc, /etc/csh.login, /etc/zshrc und wahrscheinlich noch ein paar andere (je nachdem, welche Shells Sie auf Ihrem System installiert haben). Sie können auch die UMASK-Einstellung in /etc/login.defs verändern. Von all diesen Dateien erlangt die letzte, die von der Shell geladen wird, Vorrang. Die Reihenfolge lautet: die Standard-Systemkonfiguration für die Shell des Benutzers (d.h. /etc/profile und andere systemweite Konfigurationsdateien), dann die Shell des Benutzers (seine ~/.profile) und ~/.bash_profile etc.). Allerdings können einige Shells mit dem nologin-Wert ausgeführt werden, was verhindern kann, dass einige dieser Dateien ausgewertet werden. Sehen Sie in der Handbuchseite Ihrer Shell für weitere Informationen nach.
Bei Anmeldungen, die von Login Gebrauch machen, erhält die UMASK-Festlegung in /etc/login.defs Vorrang vor allen anderen Einstellungen. Dieser Wert wird aber nicht von Anwendungen des Benutzers beachtet, die nicht Login verwenden, wie z.B. solche, die durch Su, Cron oder Ssh ausgeführt werden.
Vergessen Sie nicht, die Dateien unter /etc/skel/ zu überprüfen und gegebenenfalls anzupassen, da dort die Standards für Benutzer festgelegt werden, die mit dem Befehl adduser erstellt werden. Standardmäßig enthalten die Dateien in Debian keinen Aufruf von umask. Wenn sich aber ein solcher in Konfigurationsdateien befindet, sind neue Benutzer eher geneigt, ihn ihren Bedürfnissen anzupassen.
Beachten Sie allerdings, dass ein Benutzer seine Umask-Einstellung ändern kann, wenn er es möchte, um sie großzügiger oder einschränkender zu machen, indem er seine Konfigurationsdateien verändert.
Das Paket libpam-umask passt die Standard-Umask eines Benutzers mit Hilfe von PAM an. Nachdem Sie das Paket installiert haben, tragen Sie Folgendes in /etc/pam.d/common-session ein:
session    optional     pam_umask.so umask=077
Zu guter Letzt sollte Sie in Betracht ziehen, die Standard-Umask von Root (022, wird in /root/.bashrc festgelegt) auf einen strengeren Wert zu verändern. Damit kann verhindert werden, dass der Systemadministrator als Root sensible Dateien in von allen lesbaren Verzeichnissen (wie z.B. /tmp) ablegt und sie so dem Durchschnittsbenutzer zugänglich macht.

4.11.19. Beschränken, was Benutzer sehen und worauf sie zugreifen können

FIXME: Inhalt benötigt. Aufzeigen der Folgen beim Upgraden, wenn die Paketrechte verändert werden, falls nicht dpkg-statoverride verwendet wird (übrigens sollte ein derartig paranoider Administrator seine Benutzer in eine Chroot-Umgebung einsperren).
Wenn Sie einem Benutzer Zugriff auf das System mit einer Shell gewähren müssen, sollten Sie vorsichtig sein. Ein Benutzer kann normalerweise, wenn er sich nicht in einer streng abgeschirmten Umgebung befindet (z.B. in einem Chroot-Gefängnis), ziemlich viel Informationen über Ihr System sammeln. Darunter fallen:
  • Einige Konfigurationsdateien unter /etc. Jedoch werden Debians Standardrechte für sensible Dateien (die zum Beispiel Passwörter enthalten könnten) den Zugriff auf kritische Informationen verhindern. Um zu sehen, auf welche Dateien nur der Root-Benutzer zugreifen kann, führen Sie zum Beispiel find /etc -type f -a -perm 600 -a -uid 0 als Superuser aus.
    find /etc -type f -a -perm 600 -a -uid 0
    als Superuser aus.
  • Ihre installierten Pakete. Indem entweder die Paketdatenbank und das Verzeichnis /usr/share/doc/ angesehen wird oder indem versucht wird, dies durch Anschauen der auf Ihrem System installierten Programme und Bibliotheken zu raten.
  • Einige Protokolle unter /var/log. Beachten Sie, dass auf einige Protokolle nur Root und die adm-Gruppe zugreifen kann (versuchen Sie
    find /var/log -type f -a -perm 640
    ) Manche sind sogar ausschließlich für Root verfügbar (sehen Sie sich
    find /var/log -type f -a -perm
        600 -a -uid 0 an
    ).
Was kann ein Benutzer von Ihrem System sehen? Wahrscheinlich ziemlich viele Sachen, versuchen Sie mal Folgendes (und jetzt tief durchatmen):
  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null
Was Sie sehen, ist eine Liste von allen Dateien, die ein Benutzer einsehen kann, und von den Verzeichnissen, auf die er Zugriff hat.

4.11.19.1. Begrenzung des Zugangs zu Informationen anderer Benutzer

Wenn Sie immer noch Benutzern einen Shellzugang zur Verfügung stellen wollen, sollten Sie die Informationen begrenzen, die man über anderen Benutzern einholen kann. Benutzer mit einer Shell haben die Neigung, eine ziemlich große Anzahl von Dateien in ihrem $HOME zu erstellen: Mailboxen, persönliche Daten, Konfigurationen für X/GNOME/KDE-Anwendungen ...
Unter Debian wird jeder Benutzer mit einer zugehörigen Gruppe erstellt. Verschiedene Benutzer gehören dabei nie zur selben Gruppe. Folgendes ist das Standardverhalten: Wenn ein Benutzerkonto angelegt wird, wird auch eine Gruppe mit dem gleichen Namen erstellt. Dieser Gruppe wird der Benutzer zugewiesen. Damit wird die Idee einer allgemeinen users-Gruppe überflüssig, die es Benutzern erschweren könnte, Informationen vor anderen Benutzern zu verstecken.
Allerdings wird das $HOME-Verzeichnis der Benutzer mit 0755-Rechten (lesbar von der Gruppe, lesbar von der Welt) erstellt. Die Rechte für die Gruppe sind kein Thema, da nur der Benutzer zu dieser Gruppe gehört. Allerdings könnten die Rechte für die Welt ein Problem darstellen, wobei dies von Ihren lokalen Richtlinien abhängt.
Sie können dieses Verhalten so abändern, dass das Erstellen eines Benutzers andere Rechte für $HOME liefert. Um dieses Verhalten für neue Benutzer zu ändern, wenn sie erstellt werden, ändern Sie in der Konfigurationsdatei /etc/adduser.conf DIR_MODE auf 0750 (nicht lesbar für die Welt) ab.
Benutzer können immer noch Informationen austauschen, aber nicht mehr unmittelbar in ihrem $HOME-Verzeichnis, es sei denn, dass sie dessen Recht verändert haben.
Wenn Sie den Lesezugriff auf die Home-Verzeichnisse für die Welt verhindert, sollten Sie beachten, dass dann Benutzer ihre persönlichen Webseiten nicht unter ~/public_html erstellen können, da der Webserver einen Teil des Pfads nicht lesen kann – und zwar das $HOME-Verzeichnis. Wenn Sie es Benutzern erlauben wollen, ihre HTML-Seiten in ihrem ~/public_html zu veröffentlichen, sollten Sie DIR_MODE auf 0751 setzen. Das ermöglicht dem Webserver Zugriff auf das eigentliche public_html-Verzeichnis (welches selbst die Rechte 0755 haben sollte). So kann er den von den Benutzern veröffentlichten Inhalt anbieten. Natürlich sprechen wir hier nur über die Standardeinstellung. Benutzer können grundsätzlich die Rechte für ihre eigenen Dateien nach ihrem Gutdünken vergeben. Oder Sie können die Dinge, die für das Web bestimmt sind, in einem getrennten Ort ablegen, der kein Unterverzeichnis vom $HOME-Verzeichnis des Benutzers ist.

4.11.20. Erstellen von Benutzerpasswörtern

In vielen Fällen muss ein Administrator viele Benutzerkonten erstellen und alle mit Passwörtern ausstatten. Der Administrator könnte natürlich einfach als Passwort den Namen des Benutzerkontos vergeben. Dies wäre aber unter Sicherheitsgesichtspunkten nicht sehr klug. Ein besseres Vorgehen ist es, ein Programm zur Erzeugung von Passwörtern zu verwenden. Debian stellt die Pakete makepasswd, apg und pwgen zur Verfügung, die Programme liefern (deren Name ist der gleiche wie der des Pakets), die zu diesem Zweck verwendet werden können. Makepasswd erzeugt wirklich zufällige Passwörter, gibt also der Sicherheit gegenüber der Aussprechbarkeit den Vorzug. Dagegen versucht pwgen, bedeutungslose, aber aussprechbare Passwörter herzustellen (dies hängt natürlich auch von Ihrer Muttersprache ab). Apg liefert Algorithmen für beide Möglichkeiten (Es gibt auch eine Client/Server-Version dieses Programms. Diese befindet sich aber nicht im Debian-Paket).
Passwd erlaubt nur die interaktive Zuweisung von Passwörtern (da es direkt den tty-Zugang benutzt). Wenn Sie Passwörter ändern wollen, wenn Sie eine große Anzahl von Benutzern erstellen, können Sie diese unter der Verwendung von adduser mit der --disabled-login-Option erstellen, und danach usermod oder chpasswd [32] benutzen (beide Programme stammen aus dem passwd-Paket. Sie haben sie also schon installiert). Wenn Sie lieber eine Datei verwenden, die alle Informationen zur Erstellung von Benutzern als Batch-Prozess enthält, sind Sie vielleicht mit newusers besser dran.

4.11.21. Überprüfung der Benutzerpasswörter

Die Passwörter der Benutzer sind manchmal die schwächste Stelle der Sicherheit eines Systems. Das liegt daran, dass manche Benutzer schwache Passwörter für ihr Konto wählen (und je mehr Benutzer Zugang zum System haben, umso größer die Chance, dass das passiert). Selbst wenn Sie Überprüfungen mit dem PAM-Module cracklib und Grenzen für Passwörter einsetzen, wie in Abschnitt 4.11.1, „Benutzerauthentifizierung: PAM“ beschrieben wird, ist es Benutzern immer noch möglich, schwache Passwörter zu verwenden. Da der Zugang der Benutzer auch den Zugang aus der Ferne (hoffentlich über Ssh) umfassen kann, ist es wichtig, dass das Erraten von Passwörtern für Angreifer aus der Ferne so schwierig wie möglich ist. Dies gilt insbesondere dann, wenn es ihnen gelungen sein sollte, Zugriff auf wichtigen Informationen wie den Benutzernamen oder sogar den Dateien passwd und shadow selbst zu bekommen.
Ein Systemadministrator muss bei einer großen Anzahl von Benutzern überprüfen, ob deren Passwörter mit den lokalen Sicherheitsrichtlinien in Einklang stehen. Und wie überprüft man das? Indem man versucht, sie wie ein Angreifer zu knacken, der Zugriff auf die gehashten Passwörter hat (also auf die Datei /etc/shadow).
An administrator can use john or crack (both are brute force password crackers) together with an appropriate wordlist to check users' passwords and take appropriate action when a weak password is detected. You can search for Debian GNU packages that contain word lists using apt-cache search wordlist, or visit some Internet wordlist sites.

4.11.22. Abmelden von untätigen Benutzern

Untätige (idle) Benutzer stellen für gewöhnlich ein Sicherheitsproblem dar. Ein Benutzer kann untätig sein, da er Mittagessen ist, oder weil eine Verbindung aus der Ferne hängen blieb und nicht wieder hergestellt wurde. Unabhängig von den Gründen können untätige Benutzer zu einer Kompromittierung führen:
  • weil die Konsole des Benutzers vielleicht nicht verriegelt ist und damit ein Eindringling darauf zugreifen kann.
  • weil ein Angreifer an eine schon beendete Netzwerkverbindung anknüpfen und Befehle an die Shell in der Ferne schicken kann (das ist ziemlich einfach, wenn die Shell in der Ferne, wie bei Telnet, nicht verschlüsselt ist).
In einige Systeme in der Ferne wurde sogar schon durch ein untätiges (und abgelöstes) Screen eingedrungen.
Die automatische Trennung von untätigen Benutzern ist gewöhnlich ein Teil der lokalen Sicherheitsrichtlinie, die durchgesetzt werden muss. Es gibt mehrere Arten, dies zu erreichen:
  • Wenn die Shell des Benutzers die Bash ist, kann ein Systemadministrator TMOUT einen Standardwert zuweisen (vergleich bash(1)). Das hat zur Folge, dass die Shell automatisch untätige Benutzer aus der Ferne abmeldet. Beachten Sie, dass der Wert mit der Option -o gesetzt werden muss. Ansonsten ist es den Benutzern möglich, ihn zu verändern (oder zu löschen).
  • Installieren Sie Timeoutd und konfigurieren Sie /etc/timeouts passend zu Ihren lokalen Sicherheitsrichtlinien. Der Daemon achtet auf untätige Benutzer und beendet entsprechend ihre Shells.
  • Installieren Sie Autolog und richten Sie es so ein, dass es untätige Benutzer entfernt.
Vorzugswürdige Methoden sind die Daemonen Timeoutd oder Autolog, da letzten Endes die Benutzer ihre Standardshell ändern können oder zu einer anderen (unbeschränkten) Shell wechseln können, nachdem sie ihre Standardshell gestartet haben.


[23] In früheren Debian-Veröffentlichungen befand sich die Konfiguration der Module direkt in /etc/pam.d/passwd.
[24] Die Option minlen ist nicht auf Anhieb völlig verständlich, weil sie nicht die genaue Anzahl der Zeichen eines Passworts ist. Ein Kompromiss zwischen Komplexität und Länge eines Passworts kann mit dem Parameter »credit« für verschiedene Arten von Zeichen erreicht werden. Weitere Informationen finden Sie in der Handbuchseite pam_cracklib(8).
[25] Programme, die immer mehr Prozesse erzeugen, um so das System zum Absturz zu bringen, d.Ü.
[26] Der Standardinhalt dieser Datei enthält Informationen über das Betriebssystem und dessen Version, die Sie möglicherweise unbekannten Benutzern nicht mitteilen möchten.
[27] libpam-chroot wurden noch nicht vollständig getestet. Es funktioniert mit Login, aber es dürfte nicht leicht sein, diese Umgebung für andere Programme einzurichten.
[28] Wenn HISTSIZE eine sehr große Zahl zugewiesen wird, kann dies bei einigen Shells zu Problemen führen, da der Verlauf für jede Sitzung eines Benutzers im Speicher abgelegt wird. Sie sind auf der sichereren Seite, wenn Sie HISTSIZE auf einen ausreichend großen Wert setzen und eine Kopie der Chronikdatei des Benutzers anlegen (falls Sie aus irgendwelchen Gründen den ganzen Verlauf von einem Benutzer benötigen).
[29] Ohne das Append-Only-Flag wäre es den Benutzern möglich, den Inhalt des Verlaufs zu löschen, indem sie > .bash_history ausführen.
[30] Ttys are spawned for local logins and remote logins through ssh and telnet
[31] Wird in /etc/adduser.conf festgelegt (USERGROUPS=yes). Sie ändern dieses Verhalten, wenn Sie den Wert auf »no« setzen. Dies wird aber nicht empfohlen.
[32] Chpasswd kann keine MD5-Passwörter erzeugen. Daher muss ihm das Passwort in verschlüsselter Form mit der Option
-e
übergeben werden.