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:

Die folgende Beschreibung ist weit davon entfernt, vollständig zu sein. Für weitere Informationen können Sie die http://www.linux-pam.org/Linux-PAM-html/ lesen. Diese Dokumentation ist auf Ihrem System unter /usr/share/doc/libpam-doc/html/ verfügbar, wenn Sie libpam-doc installieren.

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.

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

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.

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.

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.

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

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.

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).

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:

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.

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:

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

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.

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.

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.

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.

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.

umask 077
exec script -q -a "/var/log/sessions/$USER"

umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

  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

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.

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.

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:

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.

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.

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).

Ein Administrator kann john oder crack (beide benutzen Brute-Force (rohe Gewalt) zum Knacken von Passwörtern) zusammen mit einer passenden Wörterliste verwenden, um die Passwörter der Benutzer zu überprüfen, und falls ein schlechtes Passwort entdeckt wird, geeignete Schritte unternehmen. Sie können mit apt-cache search wordlist nach Debian/GNU-Paketen suchen, die Wörterlisten enthalten, oder Sie besuchen die klassischen Internetseiten mit Wörterlisten wie ftp://ftp.ox.ac.uk/pub/wordlists oder ftp://ftp.cerias.purdue.edu/pub/dict.

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:

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:

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.