Kapitel 18. Systemsicherheit
Zurück | 18.2 Securing Debian HOWTO | Weiter

## 18.2 Securing Debian HOWTO

Im „Securing Debian HOWTO“ (http://www.debian.org/doc/manuals/securing-debian-howto/index.de.htmldas englische Original finden Sie unterhttp://www.debian.org/doc/manuals/securing-debian-howto/index.en.html) finden sich Informationen darüber, an welchen Stellen ein Debian-System noch sicherer gemacht werden kann. Daher soll an dieser Stelle nur auf einige grundlegende Dinge hingewiesen werden.

Zunächst müssen Sie sich darüber im Klaren sein, dass ein System nur dann hundertprozentig sicher ist, wenn keinerlei Dienste auf diesem nach außen hin über das Netzwerk angeboten werden oder sogar gar keine Verbindung zu einem Netzwerk besteht. Dies ist heutzutage in der Realität natürlich unsinnig und nicht durchsetzbar; das System würde so nicht sinnvoll benutzbar sein.

Sie sollten sich auch darüber im Klaren sein, dass die Anforderungen an die Sicherheit stark vom Einsatz des Systems abhängig sind. Ein Privatnutzer wird deutlich andere Anforderungen stellen als der Administrator eines Firewall-Systems. Viele Einstellungen, die die Sicherheit eines Systems erhöhen, vereinfachen den Gebrauch nicht unbedingt; auch hier ist zwischen Benutzbarkeit und Paranoia abzuwägen.

Die softwareseitigen Einstellungen an einem Debian-System, die zur Verbesserung der Sicherheit dienen, können nicht den physikalischen Zugriff auf das System verhindern. Wenn von Systemsicherheit die Rede ist, muss auch bedacht werden, dass zu einem völlig sicheren System auch gehört, dass der Zugriff auf die Hardware unterbunden wird. Ein Angreifer, der Zugriff auf die Hardware hat, kann beispielsweise über eine Boot-CD oder -Diskette Zugriff auf das System erlangen. Auch ein BIOS- oder LILO-Passwort kann den Diebstahl der Festplatte nicht verhindern. Ein völlig sicheres System gehört also hinter gut verschlossene Türen. Doch Betrachtungen zur Hardwaresicherung sollen an dieser Stelle nicht weiter verfolgt werden.

Allgemein formuliert sollten folgende Punkte beachtet werden:

1. Entscheiden Sie, welche Dienste auf dem System benötigt werden, und beschränken Sie den Einsatz genau auf diese Dienste - nicht mehr und nicht weniger. Nicht benötigte Dienste sollten auf dem System nicht installiert oder zumindest deaktiviert sein. Weiterhin sollten die benutzten Ports durch eine Firewall auf dem System freigegeben bzw. sollten die Ports von nicht genutzten Diensten über die Firewall gesperrt werden.

2. Verwendete Dienste sind abzusichern, so dass bei einem erfolgreichen Angriff auf diesen Dienst nicht das gesamte System kompromittiert wird (beispielsweise durch die Verwendung einer chroot-Umgebung).

3. Auf dem System sollten nur die notwendigen Benutzerkonten angelegt und aktiviert sein. Aktive Benutzerkonten sind durch entsprechende Beschränkungen (Unix-Zugriffsrechte, Quota, ACLs) abzusichern.

4. Setzen Sie Programme ein, die einen unbefugten Zugriff auf das System erkennen und melden, so dass geeignete Gegenmaßnahmen ergriffen werden können.

### 18.2.1 Vor und während der Installation

Bereits vor der Installation können einige Maßnahmen zur Sicherheit des Systems getroffen werden. Das Debian-Installationsprogramm enthält ebenfalls einige Punkte, an denen die Sicherheit des Systems verbessert werden kann.

#### 18.2.1.1 BIOS-Einstellungen

Bevor ein Betriebssystem auf einem neuen Computer installiert wird, sollte ein BIOS-Passwort gesetzt werden, und die Booteinstellungen sollten so gewählt werden, dass ein Systemstart von Diskette nicht möglich ist. Nach der Installation sollte darauf geachtet werden, dass so schnell wie möglich auch der Start von CD-ROM abgeschaltet wird.

Ein weiterer Vorteil dieser Einstellungen zeigt sich, wenn das System als Server in einem Rechenzentrum betrieben wird. Es wäre nicht das erste Mal, dass eine vergessene Diskette im Laufwerk einen erfolgreichen Reboot eines Systems verhindert; und das wird sehr ärgerlich, wenn ein direkter Zugriff auf das System nur mit einer längeren Anfahrt möglich ist.

#### 18.2.1.2 Festplattenpartitionen

Die Einteilung des verfügbaren Festplattenplatzes hängt von der Verwendung des Systems ab. Hierzu sollten Sie einige Dinge beachten:

- Jede Partition, auf die die Benutzer des Systems Schreibzugriff haben, sollte auf einer eigenen Partition liegen, beispielsweise in den Bereichen `/home` und `/tmp`. Dies verhindert, dass ein Benutzer das Root-Dateisystem ( `/`) unbenutzbar macht und das gesamte System in einen instabilen Zustand bringt. Es bleibt natürlich ein gewisser Platz (meist 5%, dieser Wert kann mit `tunefs` angepasst werden) für den Administrator reserviert, doch kann so anderen Benutzern das Arbeiten mit dem System unmöglich gemacht werden.

- Es sollte für jeden Bereich, der automatisch mit Daten gefüllt wird (beispielsweise `/var` und hier insbesondere das Verzeichnis `/var/log`), eine eigene Partition vorgesehen werden. Auf Debian-Systemen sollte `/var` großzügiger bemessen werden, da unter `/var/cache/apt/archives` Pakete temporär abgelegt werden, wenn die Installation über das Netz erfolgt. Weiterhin finden sich unter `/var/lib/dpkg` viele Dateien, die für das Paketmanagement benötigt werden.

- Wenn Software installiert werden soll, die nicht in der Debian-Distribution enthalten ist, sollten auch diese Bereiche auf eigenen Partitionen liegen; diese werden dann bei einer Neuinstallation des Systems nicht überschrieben. Nach dem „File Hierarchy Standard“ (FHS) sind dies `/opt` oder `/usr/local`.

#### 18.2.1.3 Administrator-Passwort

Während der Installation wird nach einem Passwort für den Administrator (root) gefragt. Zusätzlich kann ein Konto für einen „normalen“Benutzer dem System hinzugefügt werden; auch für diesen ist dann ein Passwort einzugeben. Auch wenn es möglich ist, hier ein sehr einfaches Passwort zu verwenden, so ist dies natürlich nicht empfehlenswert. Die Auswahl eines guten Passworts ist auf vielen Webseiten im Netz beschrieben, es sind dabei nur einige einfache Regeln zu beachten. Eine Suche nach „auswahl gutes passwort“ mittels Google führt schnell zum Erfolg.

Grundsätzlich sollte auf jedem System neben dem Zugangskonto für den Administrator auch mindestens ein solches Konto für einen Benutzer angelegt werden, das nicht über alle Rechte verfügt. Dieses Benutzerkonto sollte für grundsätzlich alle Logins bzw. Arbeiten auf dem System verwendet werden. Nur wenn für eine bestimmte Aufgabe die Zugriffsrechte nicht ausreichend sind, sollten Sie mit dem Kommando `su` die Identität wechseln. Nach Beendigung der Arbeiten als Administrator sollten Sie sich umgehend wieder als „normaler“ Benutzer im System bewegen.

#### 18.2.1.4 Shadow- und MD5-Passwörter

Während der Installation erfolgt eine Abfrage, ob „Shadow Passwords“ aktiviert werden sollen. Wenn die Frage positiv beantwortet wird, werden die Passwörter in der Datei `/etc/shadow` verschlüsselt gespeichert. Diese Datei kann nur vom Administrator und der Gruppe „shadow“ gelesen werden; somit kann kein Benutzer des Systems die verschlüsselten Passwörter lesen und versuchen, diese mit Hilfe einer Software zu entschlüsseln. Diese Einstellung kann später mit dem Programm `shadowconfig` rückgängig gemacht werden.

Weiterhin besteht die Möglichkeit, die Passwörter mit einer MD5-Verschlüsselung zu speichern; dies ist generell eine gute Idee, da so ein Angriff weiterhin erschwert wird und längere Passwörter möglich sind.

#### 18.2.1.5 Aktivierte Dienste

Wie bereits beschrieben, sollten nur die absolut notwendigen Dienste auf einem System aktiviert werden. Jeder neue Dienst schafft möglicherweise ein neues Sicherheitsloch, das vielleicht erst später zu einem Problem wird. Werden bestimmte Dienste nur selten benötigt, so können diese über die `update`-Kommandos (beispielsweise `update-inetd`) gezielt aktiviert und deaktiviert werden.

#### 18.2.1.6 Mailinglisten

Lesen Sie die Debian-Security-Mailinglisten. Informationen zu den verfügbaren Listen finden Sie unter http://lists.debian.org/debian-security-announce/. Dort ist auch beschrieben, wie Sie sich an einer solchen Liste an- und abmelden. Relevant sind in diesem Zusammenhang `debian-security-announce`, dort werden Sicherheitslücken bekannt gegeben, und Sie werden über Bugfixes dagegen informiert. Eine weitere Mailingliste zum Thema ist `debian-security@lists.debian.org`, dort werden alle Sicherheitsthemen rund um Debian behandelt.

Wenn Sie Meldungen über Sicherheitsupdates per E-Mail bekommen wollen, so senden Sie eine Mail an: debian-security-announce-request@lists.debian.org mit dem Wort „subscribe“ im Betreff der Mail. Die Anmeldung an dieser Mailingliste ist auch über die Webseite http://www.debian.org/MailingLists/subscribe möglich.

Auf dieser Mailingliste erhalten Sie nur sehr wenige Mails, Sie werden dort aber sehr schnell über Probleme mit Paketen informiert und erfahren eine Internet-Adresse, unter der eine fehlerbereinigte Version des Pakets zur Verfügung steht.

### 18.2.2 Nach der Installation

Nachdem das System mit allen benötigten Programmen eingerichtet ist, kann mit einigen weiteren Aktionen die Sicherheit des Systems weiter erhöht werden.

#### 18.2.2.1 Absicherung des Bootloaders

Jede Person, die Zugang zur Tastatur des Systems hat, kann eine Administrator-Shell bekommen und beispielsweise alle Passwörter ändern, indem am Bootprompt `dateiname-des-bootkernels init=/bin/sh` eingegeben wird. Um dies zu verhindern, kann ein Passwort für den Boot-Loader gesetzt werden. Dies kann global für alle Boot-Images geschehen oder individuell für jedes einzelne.

Wenn Lilo als Bootloader verwendet wird, muss die Datei `/etc/lilo.conf` um die Einträge `password` und `restricted` erweitert werden:

    image=/boot/2.2.14-vmlinuz
       label=Linux
       read-only
       password=hackme
       restricted

Danach muss `lilo` noch einmal aufgerufen werden. Sorgen Sie dafür, dass die Datei `/etc/lilo.conf` nur vom Administrator gelesen werden kann, da das Passwort unverschlüsselt in der Konfigurationsdatei steht; dies erreichen Sie mit dem Kommando `chmod 600 /etc/lilo.conf`. Die Option `restricted` bewirkt, dass nur nach einem Passwort gefragt wird, wenn der Benutzer versucht, zusätzliche Parameter am Bootprompt anzugeben. Die Auswahl verschiedener, bereits in der Konfiguration eingetragener Kernel ist weiterhin möglich. Wird der Eintrag `restricted` weggelassen, fragt Lilo in jedem Fall nach einem Passwort.

Die genannten Einträge können am Anfang der Konfigurationsdatei allgemein gültig für alle Kernel in der Konfiguration angegeben werden oder aber innerhalb eines Abschnitts der Konfigurationsdatei nur für bestimmte Kernel.

Wird auf dem System GRUB verwendet, so müssen folgende Zeilen der Datei `/boot/grub/menu.lst` hinzugefügt werden:

    timeout 3
    password hackme

Die Option `timeout` sorgt nach der angegebenen Zeit dafür, dass der Standardeintrag gebootet wird.

#### 18.2.2.2 Starten von Diskette

Der von Debian-Versionen vor 2.2 installierte MBR (Master Boot Record) wurde mit einer Option installiert, die es erlaubte, von Diskette zu booten, auch wenn dies sonst abgeschaltet war. Ob ein solcher MBR installiert ist, lässt sich wie folgt prüfen:

- Drücken Sie während des Startvorgangs die SHIFT-Taste; der MBR-Prompt sollte erscheinen.

- Drücken Sie nun f, und das System startet von Diskette. Mit dieser kann ein Administratorzugang zum System erreicht werden.

Dieses Verhalten kann wie folgt verändert werden:

    lilo -b /dev/hda

(wobei `hda` dem entsprechenden Devicenamen Ihres Systems angepasst werden muss).

Die Bootdisketten ab Debian-Version 2.2 installieren lilo direkt in den MBR; hier tritt diese Lücke nicht auf.

#### 18.2.2.3 Mounten von Dateisystemen

Beim Mounten (Einhängen in das Dateisystem) von `ext2`-Partitionen gibt es diverse Optionen, die dem Kommando `mount` übergeben werden oder die direkt in die Datei `/etc/fstab` eingetragen werden können. Ein solcher Eintrag könnte beispielsweise wie folgt aussehen:

    /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2

Die Optionen finden sich in der vierten Spalte. Die Option `nosuid` ignoriert gesetzte SUID- und GUID-Bits auf dieser Partition. Eine gesetzte Option `noexec` verhindert, dass auf dieser Partition befindliche Programme ausgeführt werden können, und `nodev` ignoriert Device-Dateien. Dabei ist zu beachten:

- Dies bezieht sich nur auf `ext2`-Dateisysteme.

- Auch solche Optionen können relativ leicht umgangen werden.

Hierzu ein Beispiel:

    fr@sushi:/tmp# mount | grep tmp
    /dev/hda3 on /tmp type ext2 (rw,noexec,nosuid,nodev)
    fr@sushi:/tmp# ./date
    bash: ./date: Keine Berechtigung
    fr@sushi:/tmp# /lib/ld-linux.so.2 ./date
    Sun Jul 29 14:40:32 CEST 2001

Ab der Kernelversion 2.6 ist die oben beschriebene Angriffsmöglichkeit nicht mehr gegeben.

Viele Tools, die von Hackern benutzt werden, versuchen im Verzeichnis `/tmp` Dateien anzulegen und diese auszuführen. Mit der Option `noexec` kann man dem Angreifer zumindest das Leben etwas schwerer machen.

#### 18.2.2.4 Debian-Sicherheitsupdates

Sobald eine neue Sicherheitslücke in einem Debian-Paket oder einer Software dieses Pakets bekannt wird, wird von den Paket-Maintainern innerhalb weniger Stunden oder Tage ein Update der betroffenen Pakete bereitgestellt. Das aktualisierte Paket wird unter http://security.debian.org zur Verfügung gestellt.

Um auch die Sicherheitsupdates bei jeder Aktualisierung des Systems automatisch durchzuführen, muss folgende Zeile in die Datei `/etc/apt/sources.list` eingefügt werden:

    deb http://security.debian.org/debian-security stable/updates \
     main contrib non-free

In Ländern, die den Import von kryptographischer Software nicht verbieten, kann zusätzlich folgende Zeile hinzugefügt werden:

    deb http://security.debian.org/debian-non-US stable/non-US \
     main contrib non-free

Natürlich können auch die entsprechenden „ `deb-src` “ Zeilen hinzugefügt werden, wenn auch der Zugriff auf die Sourcen gewährleistet sein soll. Danach ist nur noch ein `apt-get update`, gefolgt von einem `apt-get upgrade`, nötig, um das System auf den neuesten Stand zu bringen.

#### 18.2.2.5 Pluggable Authentication Modules (PAM)

PAM erlauben es dem Systemadministrator auszuwählen, auf welche Weise die verschiedenen Programme eine Authentifizierung durchführen sollen. Hierzu muss jedes Programm an die Verwendung von PAM angepasst sein; dies ist seit Debian 2.2 für die meisten Programme der Fall. Ältere Versionen von Debian benutzen noch keine Authentifizierung über PAM. Für jedes Programm existiert im Verzeichnis `/etc/pam.d` eine eigene Konfigurationsdatei.

Mit PAM bietet sich die Möglichkeit, mehrere Authentifizierungsschritte vom Benutzer unbemerkt durchzuführen. Beispielsweise kann eine Authentifizierung sowohl gegen eine Datenbank als auch gegen die Datei `/etc/passwd` erfolgen.

Über PAM können viele Restriktionen auferlegt werden; genauso gut ist es aber möglich, das System weit zu öffnen und so Sicherheitslücken zu schaffen. Wenn Sie Einstellungen von PAM verändern, sollten Sie also größte Vorsicht walten lassen. Eine typische Konfigurationszeile enthält in der zweiten Spalte ein Kontrollfeld. Dieses sollte auf den Wert „required“ gesetzt werden, so dass bei einem Fehler in einem Modul ein Login verhindert wird.

Zuerst sollte die Unterstützung für MD5-verschlüsselte Passwörter aktiviert werden, um zu verhindern, dass ein Passwort leicht von einem Programm über eine Datenbank ermittelt werden kann. Auf Systemen vor der Debian Release „Sarge“ müssen die folgenden Zeilen in allen Dateien in `/etc/pam.d/` hinzugefügt werden, die Zugang zu dem System erlauben. Ab der Debian Version „Sarge“ existiert die Datei `/etc/pam.d/common-password` in der bereits die notwendigen Zeilen vorhanden sind, bei diesen Zeilen muss lediglich das Kommentarzeichen entfernt werden.

Auf älteren Systemen sind beispielsweise die Dateien `login` und `ssh` anzupassen.

    password   required     pam_cracklib.so retry=3 minlen=12 difok=3
    password   required     pam_unix.so use_authtok nullok md5

Der erste Eintrag lädt das Cracklib-PAM-Modul, das strengere Anforderungen an das verwendete Passwort stellt. Passwörter müssen mit diesem Modul mindestens 12 Zeichen haben; bei einer Passwortänderung müssen mindestens drei Zeichen verändert werden. Weiterhin werden nur drei Login-Versuche erlaubt.

Die zweite Zeile benutzt die Standard-Authentifizierung des Unix-Systems mit einer MD5-Verschlüsselung und erlaubt auch leere Passwörter. Die `use_authtok` Option wird benötigt, um das Passwort vom vorhergehenden Modul zu übernehmen.

Um den Zugriff so zu beschränken, dass der Benutzer `root` sich lediglich an einem lokalen Terminal anmelden kann, muss die folgende Zeile in der Datei `/etc/pam.d/login` aktiviert werden:

    auth     requisite  pam_securetty.so

Weiterhin müssen die Terminals, von denen dem Benutzer `root` der Zugriff auf das System gewährt werden soll, in die Datei `/etc/security/access.conf` eingetragen werden. Um auch die eigentlichen Benutzer des Systems zu beschränken, beispielsweise in der Anzahl der gleichzeitigen Logins, muss noch die folgende Zeile aktiviert werden:

    session  required   pam_limits.so

In der Datei `/etc/pam.d/passwd` ist nun noch die erste Zeile zu verändern. Dort muss die Option „md5“ eingetragen werden, um mit MD5 verschlüsselte Passwörter zu benutzen. Weiterhin kann die minimale Passwortlänge beispielsweise von 4 auf 6 Zeichen erhöht werden. Ebenso kann eine maximale Länge gesetzt werden, falls dies gewünscht ist. Schlussendlich sollte die Zeile in etwa wie folgt aussehen:

    password   required   pam_unix.so nullok obscure min=6 max=11 md5

Wenn das Kommando `su` so geschützt werden soll, dass es nur von bestimmten Benutzern ausgeführt werden kann, muss zunächst eine neue Gruppe dem System hinzugefügt werden. Üblich ist es, hierzu die Gruppe „wheel“ zu verwenden, da diese üblicherweise noch nicht existiert und es somit unwahrscheinlich ist, dass bereits Dateien zu dieser Gruppe gehören. Dieser Gruppe fügen Sie das Benutzerkonto `root` sowie alle Benutzerkonten hinzu, die das Kommando `su` ausführen können sollen. In der Datei `/etc/pam/su` ist dann folgender Eintrag zu ergänzen:

    auth        requisite   pam_wheel.so group=wheel debug

Somit wird sichergestellt, dass nur Benutzer, die der Gruppe „wheel“ angehören, das Kommando `su` ausführen können. Alle anderen Benutzer bekommen eine entsprechende Meldung, wenn sie versuchen, dieses Kommando auszuführen.

Wenn nur bestimmten Benutzern eine Authentifizierung über PAM erlaubt werden soll, so ist dies relativ einfach über Dateien zu erreichen, in denen die Benutzer aufgeführt sind, denen der Login erlaubt oder verboten werden soll. Wenn beispielsweise nur dem Benutzer „fr“ der Login über `ssh` erlaubt werden soll, so muss dieser in die Datei `/etc/sshusers-allowed` eingetragen werden, und folgender Eintrag muss der Datei `/etc/pam.d/ssh` hinzugefügt werden:

    auth        required    pam_listfile.so item=user sense=allow \
     file=/etc/sshusers-allowed onerr=fail

Zu guter Letzt sind folgende Einträge der Datei `/etc/pam.d/other` hinzuzufügen:

    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 Voreinstellungen sind erst einmal eine sinnvolle Vorgabe, denn es werden grundsätzlich erstmal alle PAM-Zugriffe verweigert.

Sie sollten auch einen aufmerksamen Blick in die Datei `/etc/security/limits.conf` werfen. Hier werden Ressourcen für die Benutzer des Systems festgelegt.

#### 18.2.2.6 Anpassungen der Datei `/etc/inetd.conf`

Generell sollten alle nicht benötigten Dienste auf einem System deaktiviert werden. Jeder laufende, nicht unbedingt benötigte Dienst stellt ein potenzielles Risiko dar. Dies betrifft beispielsweise die Dienste `echo`, `charges`, `discard`, `daytime`, `time`, `talk`, `ntalk` sowie die extrem unsicheren „r“-Kommandos wie `rsh`, `rlogin` und `rcp`. Für letztere ist es in jedem Fall besser, die Kommandos `ssh` und `scp` zu benutzen.

Nachdem die nicht benötigten Dienste deaktiviert sind, sollte geprüft werden, ob der Dienst inetd überhaupt noch benötigt wird. Dienste können natürlich auch als Daemon gestartet werden, statt inetd zu benutzen. „Denial of Service“-(DoS-)Angriffe können auch auf den inetd als Ziel ausgeführt werden und so beispielsweise die Systemlast eines Rechners in die Höhe treiben. Wenn Sie trotzdem nicht auf den Einsatz eines solchen Dienstes verzichten können, so sollten Sie unter Umständen eine Alternative zu inetd einsetzen, die vielfältiger konfiguriert werden kann, beispielsweise den xinetd oder den rlinetd.

Veränderungen an der Datei `/etec/inetd.conf` können von Hand vorgenommen werden. Debian bietet aber eine einfach zu benutzende Alternative dazu: Mit dem Programm `update-inetd` können einzelne Dienste verändert werden.

Beispiel:

    /usr/sbin/update-inetd --disable telnet
    /etc/init.d/inetd restart

Nach jeder Änderung ist der inetd noch neu zu starten.

Das Kommando `update-inetd` kennt noch viele andere Optionen, beispielsweise auch, um Einträge zu löschen:

    sushi:/home/fr# update-inetd
    Usage: update-inetd [OPTION] MODE ARGUMENT

    Options:
      --version                       output version information and exit
      --help                          display this help and exit
      --verbose                       explain what is being done
      --debug                         enables debugging mode
      --multi                         allow multiple removes/disables
      --file FILENAME                 use FILENAME instead of /etc/inetd.conf
      --group GROUPNAME               add entry to section GROUPNAME
      --comment-chars CHARACTERS      use CHARACTERS as comment characters
      --pattern PATTERN               use PATTERN to select a service

    Modes:
      --add ENTRY                     add ENTRY to /etc/inetd.conf
      --remove ENTRY                  remove ENTRY (regular expression)
      --enable SERVICE                enable SERVICE in /etc/inetd.conf
      --disable SERVICE               disable SERVICE in /etc/inetd.conf

    In order to prevent the shell from changing your ENTRY definition
    you have to quote the ENTRY using single or double quotes. You can
    use tabs (the tab character or \t) and spaces to separate the fields
    of the ENTRY. If you want to enable/disable more than one SERVICE you
    can use a comma separated list of services (no whitespace characters
    allowed).

#### 18.2.2.7 Die Datei `/etc/login.defs`

Hier sollten einige Einstellungen zum Benutzer-Login und zur grundsätzlichen Konfiguration vorgenommen werden.

    FAIL_DELAY          10

Diese Variable sollte auf einen höheren Wert gesetzt werden, um „Brute-Force“-Angriffe auf einem Terminal zu erschweren. Wenn ein falsches Passwort eingegeben wird, muss der Benutzer 10 Sekunden warten, bis ein neuer Login-Versuch gestartet werden kann. Dies frisst einiges an Zeit, wenn versucht wird, ein Passwort zu erraten. Diese Einstellung gilt nur, wenn `getty` benutzt wird; bei `mingetty` beispielsweise ist diese Einstellung ohne Wirkung.

    FAILLOG_ENAB        yes

Mit dieser Variablen werden fehlgeschlagene Logins im Logfile verzeichnet. Dies ist wichtig, wenn „Brute-Force“-Angriffe aufgezeichnet werden sollen.

    LOG_UNKFAIL_ENAB    yes

Wenn die Variable `FAILLOG_ENAB` auf `yes` gesetzt wird, so sollte auch diese Variable auf `yes` gesetzt werden. Diese Einstellung schreibt auch unbekannte Benutzernamen bei einem Loginversuch ins Logfile. Es ist darauf zu achten, dass die entsprechende Logdatei nicht von allen Benutzern gelesen werden kann, da Benutzer häufig anstelle des Benutzernamens das Passwort eingeben. Damit andere Benutzer die Logdatei nicht lesen können, sind die Zugriffsrechte beispielsweise auf `640` zu setzen.

    SYSLOG_SU_ENAB      yes

Diese Einstellung verzeichnet die Benutzung des Kommandos `su` im Syslog.

    SYSLOG_SG_ENAB      yes

Diese Einstellung erfüllt die gleiche Funktion wie die vorhergehende, jedoch für das Kommando `sg` (Ausführen eines Kommandos mit der ID einer anderen Benutzergruppe).

    MD5_CRYPT_ENAB      yes

Wie schon beschrieben, reduzieren MD5-verschlüsselte Passwörter die Gefahr des Erschleichens eines Passwortes durch entsprechende Software. Wenn auf dem System noch „slink“ (Debian 2.1) eingesetzt wird, sollten Sie vor dem Aktivieren dieser Option einen Blick in die Dokumentation werfen. Ansonsten wird diese Einstellung über PAM realisiert.

    PASS_MAX_LEN        50

Wenn MD5-Passwörter in der PAM-Konfiguration aktiviert sind, so sollte diese Variable auf den gleichen Wert wie dort gesetzt werden.

#### 18.2.2.8 Die Datei `/etc/ftpusers`

Diese Datei enthält eine Liste der Benutzer, die sich nicht per FTP-Protokoll einloggen dürfen. Benutzen Sie diese Datei nur, wenn Sie wirklich sicher sind, dass auf dem System auch tatsächlich ein FTP-Server laufen soll, da per FTP der Benutzername und das Passwort immer im Klartext übertragen werden. Wenn der benutzte FTP-Daemon PAM unterstützt, so können auch dort die Benutzer zugelassen oder ausgeschlossen werden.

#### 18.2.2.9 Einsatz eines TCP-Wrappers

TCP-Wrapper wurden entwickelt, als noch keine echten Paketfilter verfügbar waren, aber trotzdem eine Kontrolle notwendig wurde. Ein TCP-Wrapper erlaubt oder verbietet einem Rechner oder einer Domäne das Nutzen eines Dienstes. Nähere Informationen finden Sie in der Manpage `hosts_access(5)`.

Im Folgenden sehen Sie vielleicht das kleinste System, um Einbruchsversuche zu registrieren. Auf alle Fälle sollte auf jedem System eine Firewall installiert sein, zusätzlich zu diesem TCP-Wrapper. Dieser kleine Eintrag in die Datei `/etc/hosts.deny` schickt bei jedem verweigerten Zugriff auf einen Service eine Mail an den Administrator.

    ALL: ALL: spawn ( \
      echo -e "\n\
      TCP Wrappers\: Connection refused\n\
      By\: $(uname -n)\n\
      Process\: %d (pid %p)\n\
      User\: %u\n\
      Host\: %c\n\
      Date\: $(date)\n\
    " | /bin/mail -s "Connection to %d blocked" root)

Natürlich ist dieses Beispiel nicht perfekt: Bei vielen Verbindungen innerhalb einer kurzen Zeit werden natürlich auch entsprechend viele E-Mails gesendet, was wiederum einem DoS-Angriff gleichkommt.

#### 18.2.2.10 Benutzung von `su`

Sollte es einmal notwendig sein, Arbeiten am System als Administrator durchzuführen, so kann das Kommando `su` benutzt werden, um die benötigten Rechte zu erlangen. Versuchen Sie, allen Benutzern klarzumachen, dass Arbeiten als Administrator nur in Ausnahmefällen gestattet sind. In jedem Fall ist ein Login als root zu vermeiden und stattdessen das Kommando `su` zu benutzen. Noch besser ist es jedoch, das Kommando `su` komplett zu entfernen und stattdessen das Kommando `sudo` zu benutzen, das eine ganze Reihe weiterer Funktionen bietet. Der Befehl `su` ist aber weithin bekannt, da er auch auf vielen anderen Unix-Systemen eingesetzt wird.

#### 18.2.2.11 Benutzung von `sudo`

`sudo` erlaubt einem Benutzer, Kommandos unter der ID eines anderen Benutzers auszuführen, gegebenenfalls auch als Administrator. Wenn der Benutzer in der Datei `/etc/sudoers` aufgeführt ist und sich authentifiziert hat, können Kommandos ausgeführt werden, die ebenfalls in dieser Datei aufgeführt sind. Verletzungen dieser Regel, wie beispielsweise ein falsches Passwort oder die versuchte Ausführung eines unerlaubten Programms, werden aufgezeichnet und per E-Mail an den Administrator (root) geschickt.

#### 18.2.2.12 Benutzung von `chroot`

Der Befehl `chroot` ist eine leistungsfähige Möglichkeit, um ein Programm oder einen Daemon oder einen Benutzer zu beschränken. Man kann sich das wie in einem Gefängnis vorstellen, aus dem ein Ausbruch unmöglich ist (normalerweise... aber einige Leute schaffen es ja doch manchmal...). Wenn einem Benutzer nicht vollkommen vertraut wird, so kann für diesen eine `chroot`-Umgebung eingerichtet werden. Dies kann einiges an Festplattenplatz beanspruchen, wenn alle benötigten Binaries und Bibliotheken in diese Umgebung kopiert werden müssen. Aber wenn es dem Benutzer gelingt, Schaden anzurichten, so bleibt dieser auf die durch das Kommando `chroot` definierte Umgebung beschränkt.

Ein gutes Beispiel für eine solche Anwendung ist folgende: Die Authentifizierung erfolgt nicht gegen die Datei `/etc/passwd`, sondern gegen LDAP oder/und eine MySQL-Datenbank. Ein verwendeter FTP-Daemon benötigt das Binary und ein paar Bibliotheken. Hier bildet eine `chroot`-Umgebung eine exzellente Verbesserung der Sicherheit, falls eine Sicherheitslücke in diesem FTP-Daemon auftaucht. In diesem Fall ist lediglich die Benutzer-ID des FTP-Daemons betroffen und keine anderen Benutzer des Systems. Natürlich können auch viele andere Dienste von solch einer Umgebung profitieren.

Als Hinweis: Bisher wird bei keiner Debian-Version eine `chroot`-Umgebung für die Dienste und Server verwendet.

#### 18.2.2.13 Kernel-Features

Viele Funktionen des Kernels können während der Laufzeit verändert werden, beispielsweise indem mit dem Kommando `echo` ein Wert in die entsprechende Datei geschrieben wird, oder mit dem Kommando `sysctl`. Mit dem Kommando `sysctl -A` kann angezeigt werden, welche Einstellungen verändert werden können und welche Optionen verfügbar sind. In seltenen Fällen muss etwas verändert werden, aber auf diesem Weg kann die Sicherheit des Systems erhöht werden.

    /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts = 0

Wird diese Variable auf den Wert 1 gesetzt, so verhält sich das System nach außen wie ein Windows-System, wenn ein Broadcast-ping-Kommando das System erreicht.

    /proc/sys/net/ipv4/icmp_echo_ignore_all = 0

Wenn ICMP-Pakete auf der vorgeschalteten Firewall nicht geblockt werden sollen, so ist diese Variable auf den Wert 0 zu setzen.

    /proc/sys/net/ipv4/tcp_syncookies = 1

Diese Option ist ein zweischneidiges Schwert: Einerseits schützt sie gegen „Syn-Flooding“-Attacken, andererseits entspricht dies nicht den RFCs. Diese Option beschäftigt die angreifende Seite ebenso mit „Syn-Floods“, so dass diese gleichermaßen beschäftigt ist. Diese Option kann auch in `/etc/network/options` verändert werden, indem die Option `syncookies` auf `yes` gesetzt wird.

    /proc/sys/net/ipv4/conf/all/log_martians = 1

Mit dieser Option werden Pakete mit unerlaubten Adressen, beispielsweise wegen eines fehlerhaften Routings, im Netzwerk protokolliert.

#### 18.2.2.14 Benutzung der `svgalib`

SVGAlib ist eine schöne Einrichtung für Liebhaber der Konsole. In der Vergangenheit sind jedoch immer wieder Sicherheitslücken bekannt geworden. So wurden Sicherheitslücken in `zgv` bekannt, mit denen Administratorrechte erlangt werden konnten. Wenn möglich, sollten Sie auf die Verwendung der SVGAlib verzichten.

#### 18.2.2.15 Sichere Übertragung von Dateien

Die Übertragung zwischen zwei Rechnern sollte auf keinen Fall mit Programmen wie `ftp` oder `rcp` erfolgen, da diese den Benutzernamen und das Passwort unverschlüsselt übertragen. Als sichere Alternative steht das Programm `scp` zur Verfügung, das im Paket `ssh` enthalten ist. Hier werden sowohl der Benutzername als auch das Passwort und auch die Daten selbst in verschlüsselter Form übertragen.

#### 18.2.2.16 Benutzung von Quota

Eine saubere Definition von Benutzerquota ist wichtig, um zu verhindern, dass Benutzer ein komplettes Dateisystem mit Daten füllen können.

Es können grundsätzlich zwei verschiedens Quota-Systeme eingesetzt werden: benutzer- oder gruppenorientierte Quota. Dies ist bei der Planung zu berücksichtigen.

Einige Punkte sind bei der Benutzung von Quota zu beachten:

- Quota sollten in der Summe so klein gewählt werden, dass nicht der gesamte Festplattenplatz belegt werden kann.

- Quota sollten so groß gewählt werden, dass die Benutzer nicht bei der Arbeit behindert werden. Beispielsweise sollte das Spoolverzeichnis für Mail nicht zu knapp bemessen werden.

- Quota müssen auf allen von Benutzern beschreibbaren Bereichen eingerichtet werden, beispielsweise `/home` und `/tmp`.

Für jede Partition bzw. jedes Verzeichnis, auf die bzw. das Benutzer Schreibzugriff haben, sollten Quota aktiviert werden. Für diese Bereiche ist ein sinnvoller Wert zu errechnen, der eine Balance zwischen Sicherheit und Benutzbarkeit des Systems schafft.

Doch nun zur Benutzung von Quota: Zunächst müssen Sie prüfen, ob die Quota-Unterstützung im Kernel aktiviert ist. Wenn dies nicht der Fall ist, muss ein neuer Kernel erzeugt werden. Danach ist sicherzustellen, dass das Paket `quota` installiert ist.

Quota werden aktiviert, indem in der Datei `/etc/fstab` der Eintrag für das entsprechende Dateisystem in der Spalte „Options“ um den Eintrag `usrquota` erweitert wird. Wenn statt Benutzer-Quota Gruppen-Quota benutzt werden sollen, lautet der Eintrag `grpquota`. Natürlich können auch beide gleichzeitig verwendet werden. Nun müssen im Root-Verzeichnis des Dateisystems leere Dateien `quota.user` und/oder `quota.group` erzeugt werden.

Das Quota-System muss nun neu gestartet werden. Dies geschieht durch die Kommandos `/etc/init.d/quota stop` und `/etc/init.d/quota start`. Nun können die gewünschten Grenzwerte gesetzt werden.

Um Quota für einen Benutzer (beispielsweise `fr`) zu setzen, wird das Kommando `edquota -u fr` benutzt. Gruppen-Quota werden mit dem Kommando `edquota -g gruppe` gesetzt. Nun können die Grenzwerte für „soft“ und „hard“ sowie für die Inodes gesetzt werden.

#### 18.2.2.17 Zugriffsrechte von Logdateien

Einige Logdateien sind nach der Installation nicht perfekt. Zunächst ist es nicht notwendig, dass die Dateien `/var/log/lastlog` und `/var/log/faillog` von jedem Benutzer gelesen werden können. In der Datei `lastlog` sind Benutzer verzeichnet, die sich in der letzten Zeit am System angemeldet haben; in der Datei `faillog` finden sich fehlgeschlagene Loginversuche. Bei beiden Dateien sollten die Zugriffsrechte auf `660` verändert werden. Prüfen Sie genau, ob Logdateien mit unnötigen Zugriffsrechten versehen sind. Meist sind Lese- und Schreibrechte für den Administrator und für die Gruppe `adm` oder `root` ausreichend.

#### 18.2.2.18 `setuid`-Überprüfungen

Debian wird mit einem täglichen Cronjob installiert, der in `/etc/cron.daily/standard` zu finden ist. Der Aufruf von `/usr/sbin/checksecurity` führt eine Überprüfung des Systems auf Änderungen des Flags `setuid` an allen Dateien auf dem System durch.

Um diese Überprüfung zu aktivieren, muss die Variable `CHECKSECURITY_DISABLE` in der Datei `/etc/checksecurity.conf` auf `FALSE` gesetzt sein. Dies ist auch die Voreinstellung, so dass hier eigentlich keine Änderungen erforderlich sind.

#### 18.2.2.19 `chattr` / `lsattr`

Diese beiden Kommandos sind auf einem ext2-Dateisystem sehr sinnvoll. Die Attribute einer Datei können mit `lsattr` angezeigt und mit `chattr` verändert werden. Attribute unterscheiden sich von Zugriffsrechten! Es gibt viele verschiedene Attribute, hier werden nur die sicherheitsrelevanten aufgeführt. Zwei Attribute können nur vom Administrator gesetzt werden.

Zunächst wäre das „a“-Flag zu nennen. Wenn dieses Attribut gesetzt ist, können an die entsprechende Datei nur Daten angehängt (append) werden. Dieses Attribut kann auf einige Dateien in `/var/log/` angewendet werden; beachten Sie jedoch, dass einige Dateien von Zeit zu Zeit „rotiert“ werden (unter „rotieren“ versteht man das tägliche Umkopieren und Umbenennen von Logdateien. Dabei werden Dateien vom Vortag komprimiert. Nach einer bestimmten Zeit, meist eine Woche, werden ältere Dateien gelöscht).

Das zweite wichtige Flag ist „i“, das für „immutable“ steht. Wenn dieses Flag gesetzt wird, kann eine Datei weder verändert noch gelöscht oder umbenannt werden. Auch kann kein Link auf diese Datei erzeugt werden. Wenn Benutzern die Einsicht in Logdateien verwehrt werden soll, so können Sie dieses Flag setzen und die Leserechte entfernen. Dies bietet auch eine etwas höhere Sicherheit gegen Eindringlinge, da diese sich sicher darüber wundern, dass die Datei nicht gelöscht werden kann. Trotzdem sollten Sie sich nicht darauf verlassen, dass ein Eindringling diese Funktion nicht kennt. In jedem Fall ist es ihm zu diesem Zeitpunkt bereits gelungen, in das System einzudringen...

#### 18.2.2.20 Integrität des Dateisystems

Sind Sie sicher, dass die auf einem bereits seit Wochen oder Monaten ans Internet angeschlossenen System installierten Programme noch die urspünglichen sind? Oder kann es sein, dass bereits das Programm `/bin/login` durch eine veränderte Variante ersetzt wurde, die einen unbemerkten Login als Administrator erlaubt...?

Die einzige Methode, ein System gegen solche Veränderungen zu schützen, ist, die installierten Dateien täglich, wöchentlich oder beispielsweise monatlich (je häufiger dieser Test durchgeführt wird, umso weniger Zeit bleibt einem Eindringling, auf dem System zu agieren) mittels einer Checksumme zu dokumentieren und diese mit vorab gespeicherten Werten zu vergleichen.

Pakete, die einen regelmäßigen Check der installierten Pakete ermöglichen, sind: sXid, AIDE (Advanced Intrusion Detection Environment) und Tripwire (die aktuelle Version befindet sich im Bereich non-free, eine der nächsten Versionen wird unter der GPL stehen).

Mit dem Paket `debsums` können alle MD5-Checksummen der installierten Pakete mit den Original-Checksummen der Dateien in den Ursprungspaketen der Distribution verglichen werden.

Mittels `debsums -a` können die Checksummen aller Pakete des Systems verglichen werden, wogegen Sie mit `debsums <paketname>` die Checksummen bestimmter Pakete vergleichen. Hierbei ist zu beachten, dass es einem versierten Eindringling durchaus möglich ist, auch diese Kontrolle der Checksummen zu beeinflussen. Die ursprünglichen Checksummen der Pakete liegen in den Dateien `/var/lib/dpkg/info/<paketname>.md5sums` und können vom Angreifer auch angepasst werden. Eine höhere Sicherheit bietet das Paket Tripwire.

#### 18.2.2.21 `locate` und `slocate`

Um die Sicherheit des Programms `locate` zu erhöhen, kann alternativ das Programm `slocate` verwendet werden. `slocate` ist eine verbesserte Version von `locate` aus dem GNU-Projekt. Wenn `slocate` verwendet wird, werden dem Benutzer nur Dateien angezeigt, auf die dieser Benutzer auch tatsächlich Zugriff hat. Weiterhin können per Konfiguration auch Dateien und Verzeichnisse gezielt ausgeschlossen werden, so dass diese nicht von `locate` in der Datenbank erfasst werden.

### 18.2.3 Sichere Dienste

#### 18.2.3.1 Secure Shell (SSH)

SSH sollte generell für alle Remote-Logins auf einem System eingesetzt werden. Wenn Sie noch `telnetd` einsetzen, so ändern Sie dies jetzt sofort. Heutzutage ist es sehr einfach, den Netzwerkverkehr mitzuschneiden und so an unverschlüsselte Benutzernamen und Passwörter zu gelangen. Die Verwendung von Programmen, die keine verschlüsselte Kommunikation erlauben, verbietet sich somit von selbst. Auch der Einsatz von hochwertigen Netzwerkkompenenten wie Switches erlaubt Angreifern das „Mitlauschen“ auf den angeschlossenen Ports! Die meisten Switches schalten bei zu hoher Last einfach das „Switching“ ab und arbeiten wie ein normaler Hub! Verlassen Sie sich nie auf diese Komponenten, sondern sorgen Sie selbst für Sicherheit! Das Paket `ssh` kann mit dem Kommando `apt-get install ssh` schnell und einfach installiert werden.

Nun sollten alle Benutzer angewiesen werden, ausschließlich `ssh` und keinesfalls `telnet` zu benutzen. Deinstallieren Sie `telnet` nach Möglichkeit. Auch sollte ein Login als Administrator unmöglich gemacht werden. Um Administrator-Rechte zu erlangen, können die Kommandos `su` oder besser `sudo` benutzt werden.

Auch die Konfiguration des ssh-Daemons kann zur Erhöhung der Sicherheit noch verbessert werden. In der Datei `/etc/ssh/sshd_config` verbietet folgende Zeile einen Login via ssh als Administrator:

    PermitRootLogin No

Dies verhindert, dass per Brute-Force-Angriff ein Login als Administrator möglich ist, da kein Login als Administrator erlaubt wird. Es sind nun zwei Login-Vorgänge notwendig (zunächst als Benutzer, dieser muss dann noch Administrator werden):

    Listen 666

Wenn der Port, auf dem der ssh-Daemon läuft, verändert wird, so kann dies einen potenziellen Angreifer auch etwas beschäftigen. Es stehen aber verschiedene Netzwerktools zur Verfügung, mit deren Hilfe schnell und einfach ermittelt werden kann, auf welchem Port ein Dienst läuft. Verwenden Sie hier nicht zu viel Ehrgeiz...

    PermitEmptyPasswords no

Leere Passwörter sollten ebenfalls verhindert werden.

    AllowUsers alex bea fr

Mit dieser Option wird nur bestimmten Benutzern der Login via ssh erlaubt.

    AllowGroups wheel admin

Gleichermaßen wird mit dieser Direktive nur bestimmten Gruppen der Zugriff per ssh erlaubt.

Um Benutzern oder Gruppen explizit den Zugriff zu verbieten, stehen die Optionen `DenyUsers` und `DenyGroups` zur Verfügung.

    PasswordAuthentication no

Wird diese Option auf „no“ gesetzt, so ist der Login nur Benutzern gestattet, deren ssh-Key der Datei `~/.ssh/authorized_keys` hinzugefügt wurde. Diese Einstellung ist sehr empfehlenswert! Bei Verwendung eines Keys wird das Passwort nicht mehr vom Client zum Server übermittelt. Die Autorisierung wird anhand eines Hash-Wertes geprüft, und der Client erhält lediglich die Freigabe für den Server - oder auch nicht.

Weiterhin ist der ssh-Daemon so einzustellen, dass auschließlich das Protokoll der Version 2 verwendet wird. Die Protokollversion 1 ist nach aktuellem Kenntnisstand als angreifbar anzusehen und sollte nicht mehr verwendet werden.

Alle diese Optionen beziehen sich auf die Konfigurationsdateien von OpenSSH. Momentan sind drei ssh-Pakete im Umlauf: ssh1, ssh2 und OpenSSH, das vom OpenBSD-Team entwickelt wurde. OpenSSH ist eine komplett freie Implementation eines ssh-Daemons, die sowohl ssh1 als auch ssh2 unterstützt. Wenn das Paket „ssh“ installiert wird, so wird das Paket OpenSSH gewählt.

#### 18.2.3.2 FTP

Wenn auf dem System tatsächlich ein FTP-Server installiert werden muss, so ist sicherzustellen, dass die Benutzer sich in einer „chroot“-Umgebung bewegen. Diese hält den Benutzer in seinem Homeverzeichnis gefangen; ansonsten könnte er sich frei im Dateisystem bewegen.

Mit der Option

    DefaultRoot ~

im globalen Abschnitt der Datei `/etc/proftpd.conf` kann dies sichergestellt werden. Danach ist der Server mit `/etc/init.d/proftpd restart` von der Veränderung der Konfiguration zu unterrichten.

#### 18.2.3.3 X-Anwendungen im Netz

Um X-Anwendungen von einem Server aus auf einem Client darzustellen, ist zunächst auf dem Client das Öffnen der Anwendung durch den Server zu erlauben. Vielfach ist zu lesen, dass dies durch das Kommando „ `xhost +` “ geschieht. Dies ist auch prinzipiell nicht falsch, erlaubt jedoch jedem System den Zugriff auf das X-Display. Besser ist es, den Zugriff nur von den gewünschten Systemen aus zu erlauben, indem der entsprechende Rechnername dem Kommando als Option mitgegeben wird, also beispielsweise `xhost +sushi`.

Eine deutlich sicherere Lösung ist es allerdings, die komplette Sitzung über ssh - und damit verschlüsselt - zu tunneln. Dies erfolgt automatisch, wenn eine ssh-Verbindung zu einem System aufgebaut wird. Soll diese Funktion abgeschaltet werden, so ist die Option `X11Forwarding` in der ssh-Konfiguration anzupassen. In Zeiten von ssh sollte auf die Verwendung von `xhost` komplett verzichtet werden.

Wenn keinerlei Zugriff auf den X-Server von anderen Systemen im Netz erlaubt werden soll, so ist es das Sicherste, dies bereits beim Start von X zu verhindern, indem der TCP-Port 6000 deaktiviert wird. Wenn X über das Kommando `startx` gestartet wird, so kann dies mit `startx -- -nolisten tcp` geschehen.

#### 18.2.3.4 Display-Manager

Wenn der Display-Manager (das Programm, das einen grafischen Login bereitstellt, beispielsweise XDM, KDM oder GDM) nur auf dem lokalen System benötigt wird, so ist sicherzustellen, dass XDMCP (X Display Manager Control Protocol) deaktiviert ist. Wenn das Programm `xdm` benutzt wird, kann dies durch die Zeile

    DisplayManager.requestPort:     0

in der Datei `/etc/X11/xdm/xdm-config` geschehen.

Die XDMCP-Unterstützung ist bei der Grundinstallation aller Display Manager unter Debian deaktiviert.

#### 18.2.3.5 E-Mail

Das Lesen bzw. Empfangen von E-Mail mittels POP3 ist das am häufigsten eingesetzte Protokoll ohne Verschlüsselung. Unabhängig davon, ob POP3 oder IMAP als Protokoll verwendet wird - beide benutzen Benutzernamen und Passwörter im Klartext, und auch die Daten werden unverschlüsselt übertragen. Als Alternative kann auch hier `ssh` verwendet werden, falls ein Shell-Account auf dem Mail-Server vorhanden ist.

Mittels `fetchmail` kann über `ssh` eine verschlüsselte Verbindung aufgebaut werden; hierzu eine entsprechende `~/.fetchmailrc`:

    poll my-imap-mailserver.org via "localhost"
      with proto IMAP port 1236
          user "ref" there with password "hackme" is alex here warnings 3600
        folders
          .Mail/debian
        preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
         my-imap-mailserver.org sleep 15 < /dev/null > /dev/null'

Die wichtigste Zeile ist der „preconnect“-Eintrag. Dieser startet eine `ssh`-Session und installiert einen Tunnel, der automatisch die Verbindungen zum IMAP-Server auf Port 1236 weiterreicht, verschlüsselt. Dies nur als ein Beispiel, normalerweise sind einfachere Konfigurationen ausreichend. Alternativ kann fetchmail auch mit SSL benutzt werden.

Wenn verschlüsselte IMAP- und POP3-Server zur Verfügung gestellt werden sollen, so ist das Paket `stunnel` zu installieren. Die Daemons müssen dann über `stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd` gestartet werden, wobei `-l` den gewünschten Daemon und `-d` den Port beschreibt. Die Option `-p` setzt das SSL-Zertifikat.

Mittlerweile sind auch POP- und IMAP-Server verfügbar, die über Verschlüsselungsfunktionen mittels SSL verfügen. Als Server-Programm für das POP-Protokoll wäre hier `apop` zu nennen.

#### 18.2.3.6 Loghost - ein Server für Logdateien

Ein „Loghost“ ist ein zentraler Rechner, auf dem Daten aus dem Syslog-Daemon verschiedener Rechner gespeichert werden. Wenn ein Eindringling ein System geknackt hat, so ist es ihm unmöglich, die Spuren aus den Logdateien zu entfernen, außer er knackt auch noch den Loghost. Somit sollte speziell ein solcher Loghost gut abgesichert sein. Um ein System in einen Loghost umzuwandeln, muss lediglich der syslog-Daemon mit der Option `-r` gestartet werden. Natürlich muss aber auch auf allen Rechnern, die nun die Daten auf diesem Loghost abliefern sollen, eine Anpassung erfolgen. Auf diesen Systemem sind in der Datei `/etc/syslog.conf` Einträge in der folgenden Form hinzuzufügen:

    <facility>.<level>            @<loghost>

Das Feld <facility> kann dabei einen Werte `authpriv`, `cron`, `daemon`, `kern`, `lpr`, `mail`, `news`, `syslog`, `user`, `uucp` oder `local1` bis `local7` annehmen. Als <level> kann `alert`, `crit`, `err`, `warning`, `notice` oder `info` angegeben werden. Hinter dem Zeichen „@“ ist der Hostname des Loghosts anzugeben.

Wenn generell alle Einträge auf dem entfernten System protokolliert werden sollen, so führt folgende Zeile zum Erfolg:

    *.*                       @loghost

Im Idealfall wird man die Logdateien sowohl auf dem lokalen System als auch auf dem Loghost speichern, um durch Vergleichen der Dateien schneller zu einem Ergebnis zu kommen. Weitere Informationen finden Sie in den Manpages zu `syslog(3)`, `syslogd(8)` und `syslog.conf(5)`.

#### 18.2.3.7 BIND

Auf einem unveränderten System läuft der Nameserver BIND nach der Installation mit den Rechten des Benutzers und der Gruppe „root“. BIND kann sehr leicht umkonfiguriert werden, so dass der Dienst unter einem anderen Benutzerkonto läuft. Leider kann er dann nicht mehr automatisch neue Netzwerkgeräte erkennen, die während des laufenden Betriebs hinzugefügt wurden, beispielsweise eine PCMCIA-Netzwerkkarte in einem Notebook oder auch virtuelle Netzwerkdevices.

In der Datei `README.Debian` des Nameservers finden Sie weitere Informationen darüber, wie Sie BIND unter einem anderen Benutzerkonto zum Laufen bringen können. Wenn möglich, sollten Sie darauf verzichten, BIND mit Administratorrechten zu benutzen.

Um BIND mit einer anderen Benutzer-ID zu starten, muss zunächst ein neuer Benutzer und eine entsprechende Gruppe angelegt werden. Es kann beispielsweise als Benutzername und Gruppe der Name „named“ benutzt werden.

Hierzu sind folgende Kommandos notwendig:

    addgroup named
    adduser --system --ingroup named named

Nun muss in der Datei `/etc/init.d/bind` der Eintrag

    start-stop-daemon --start

in

    start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

geändert werden.

Natürlich ist BIND nun noch mit `/etc/init.d/bind stop` und `/etc/init.d/bind start` neu zu starten. Dabei sollten im Syslog (`/var/log/syslog`) in etwa folgende Einträge auftauchen:

    Jul  8 23:21:01 sushi named[12432]: group = named
    Jul  8 23:21:01 sushi named[12432]: user = named

Damit ist die Umstellung abgeschlossen. Idealerweise kann BIND nun noch in einer „chroot“-Umgebung betrieben werden.

#### 18.2.3.8 Snort

Snort ist ein flexibler Packet-Sniffer, der verschiedenste Angriffe ermitteln kann. Hierzu gehören Buffer-Overflows, CGI-Angriffe, SMB-Angriffe und vieles mehr. Snort kann Alarmierungen in Echtzeit durchführen. Dieses Programm sollte auf jedem Router installiert sein, um jederzeit das Netzwerk zu überwachen. Die Installation erfolgt mit einem `apt-get install snort`; beantworten Sie die Fragen, und werfen Sie dann einen Blick auf die Logdateien.

### 18.2.4 Vor einem Einbruch

#### 18.2.4.1 Debian-Sicherheits-Updates

Unmittelbar nach jeder neuen Debian-GNU-Installation, beispielsweise von CD, sollten die neuesten verfügbaren Security-Updates installiert werden. Durch die notwendigen Vorlaufzeiten bei der Produktion von CDs sind diese natürlich nicht immer auf dem neuesten Stand. Natürlich ist es nicht ausreichend, ein solches Update einmalig auszuführen, vielmehr müssen diese Updates in regelmäßigen Abständen durchgeführt werden. Dies verhindert, dass Software mit bekannten Sicherheitslücken über längere Zeit im laufenden Betrieb verwendet wird.

#### 18.2.4.2 Austausch von Software

Zunächst sollten alle Netzwerkdienste, deren Passwörter im Klartext übertragen werden, deaktiviert bzw. gegen Versionen mit verschlüsselter Kommunikation ausgetauscht werden. Dies betrifft Dienste wie FTP, Telnet, NIS, RPC usw.

Auch sollten Sie auf die Verwendung von NIS (Network Information Service) verzichten. Bei einer fehlerhaften Konfiguration kann es leicht zu Sicherheitslücken kommen.

Auch sollten Sie RPC deaktivieren, sofern es möglich ist. Für diesen Dienst sind eine ganze Reihe von Sicherheitslücken bekannt. Natürlich wird gerade NFS häufig verwendet und stellt in vielen Netzen einen wichtigen Basisdienst dar. Hier gilt es, einen Kompromiss zwischen Sicherheit und Benutzbarkeit der Netzwerkdienste zu finden. Viele DDoS-(Distributed Denial of Service-)Angriffe benutzen RPC-Sicherheitslücken, um Systeme in so genannte „Agents“ oder „Handler“ umzuwandeln.

Das Deaktivieren des Portmappers ist relativ einfach. Wie für jede Lösung gibt es auch hier verschiedene Wege. Auf einem Debian-System ist der einfachste Weg sicherlich ein `update-rc.d portmap remove`. Dieses Kommando löscht jeden symbolischen Link auf den Portmapper in `/etc/rc${runlevel}.d/`. Dies kann natürlich auch auf herkömmlichem Wege von Hand erledigt werden. Eine weitere, nicht ganz elegante Möglichkeit ist es, die Zugriffsrechte so zu ändern, dass das Skript nicht mehr ausführbar ist. Dazu verwenden Sie `chmod 644 /etc/init.d/portmap`. Dies würde jedoch zu einer Fehlermeldung beim Start des Systems führen.

Natürlich ergibt es nur wenig Sinn, lediglich einen Teil der Dienste von unverschlüsselter auf verschlüsselte Kommunikation umzustellen; hier sollte der Systemadministrator konsequent durchgreifen. Generell sollten die Dienste `ftp`, `telnet`, `pop`, `imap` und `http` entfernt und durch die entsprechenden Dienste mit verschlüsselter Kommunikation ( `ftp-ssl`, `telnet-ssl`, `pop-ssl`, `https`) ersetzt werden.

#### 18.2.4.3 Kernel-Patches

Im Netz sind einige Kernel-Patches verfügbar, die nicht Bestandteil des Standard-Linux-Kernels sind, dessen Sicherheit aber verbessern. Vor dem Einsatz ist im Einzelfall zu prüfen, ob der gewünschte Patch nicht schon in den benutzten Kernel eingeflossen ist. Auch erhebt die folgende Auflistung natürlich keinerlei Anspruch auf Vollständigkeit.

- OpenWall Patch von „Solar Designer“. Eine Sammlung von Patches, die beispielsweise Links beschränken, FIFOs in `/tmp/` unterbinden, das `/proc`-Dateisystem schützen, die Behandlung von Datei-Deskriptoren ändern und einiges andere verändern. Momentan werden Kernel der Serien 2.0, 2.2 und 2.4 unterstützt. Detaillierte Informationen finden Sie auf der Homepage http://www.openwall.com/linux/.

- LIDS - Linux intrusion detection system von Huagang Xie und Philippe Biondi. Dieser Patch vereinfacht die Sicherung eines Linux-Systems. Jeder Prozess kann beschränkt werden, indem Lese- und Schreibberechtigungen auf Dateien vergeben werden können. Weiterhin können je Prozess „Capabilities“ gesetzt werden. Zum Einsatz von LIDS auf Debian-GNU-Systemen gibt es eine spezielle Seite im Netz unter http://netzwurm.cc/computer/lids.html. Dort findet sich neben einem vorkonfigurierten Kernel auch ein Paket mit dem Administrationstool. Dieser Patch findet sich auf der Homepage des Projekts unter http://www.lids.org.

- POSIX Access Control Lists (ACLs) für Linux. Dieser Patch erweitert den Kernel um Access Control Lists (ACLs), eine Methode, die es gestattet, den Zugriff auf Dateien detaillierter zu beschränken, als es mit den üblichen Schemata möglich ist. http://acl.bestbits.at.

- Linux trustees. Mit diesem Patch wird ein erweitertes System mit Zugriffsrechten zum Kernel hinzugefügt. Alle Objekte werden im Kernel-Speicher gehalten, so dass ein schneller Zugriff möglich ist. Homepage: http://www.braysystems.com/linux/trustees.html.

- International kernel patch. Dieser Patch implementiert kryptographische Dateisysteme im Kernel. Es sind in einigen Ländern die entsprechenden Gesetze zu beachten. Homepage: http://www.kerneli.org.

- UserIPAcct. Dieser Patch bezieht sich nicht direkt auf die Sicherheit eines Systems, erhöht aber die Kontrolle über die unberechenbaren Benutzer. Hiermit können Quota, bezogen auf den Benutzer, für den Netzwerkverkehr vergeben werden. Statistiken sind ebenfalls verfügbar. Homepage: http://rsmeyers.3ti.org/useripacct.

- FreeS/WAN. Um IPSec zusammen mit dem Linux-Kernel verwenden zu können, wird dieser Patch benötigt. Hiermit können VPNs (Virtual Private Networks) sehr leicht aufgesetzt werden, zur Not auch mit Windows-Rechnern auf der Gegenseite. IPSec ist der für VPNs eingebürgerte Standard. Homepage: http://www.freeswan.org.

#### 18.2.4.4 Cruft

Eine wichtige Aufgabe des Systemadministrators ist die regelmäßige Überwachung aller Dateien im System. Ein Eindringling kann es nicht nur auf den Diebstahl von Daten abgesehen haben, auch das Verändern von Systemdateien (beispielsweise um neue Benutzer anzulegen) oder von Programmdateien (Austausch von Binaries durch veränderte Versionen) kann ein Ziel sein. Das Auffinden dieser Veränderungen ist nur möglich, wenn der Stand vor der Veränderung bekannt ist.

Debian unterstützt durch das ausgefeilte Paketsystem die Überprüfung der installierten Dateien. Als erster Einstieg kann das Programm `cruft` dienen.

`cruft` untersucht das komplette Dateisystem nach Dateien, die eigentlich nicht vorhanden sein sollten, beziehungsweise nach Dateien, die sich nicht mehr im Dateisystem finden lassen. Hierzu wird im Wesentlichen auf die Informationen aus den Dateien im Verzeichnis `/var/lib/dpkg/info/` zugegriffen. `cruft` überwacht aber auch darüber hinausgehende Informationen wie beispielsweise die „alternatives“-Informationen, die `lost+found`-Verzeichnisse in einem ext2-Dateisystem und auch die Heimatverzeichnisse der Benutzer.

Zurück | Nach oben | Weiter
Kapitel 18. Systemsicherheit | Zum Anfang | 18.3 Weitere Möglichkeiten

© 1999-2006 Frank Ronneburg - Dieser Inhalt ist unter einem Creative Commons Namensnennung - Nicht-kommerziell - Keine Bearbeitung Lizenzvertrag lizenziert (creativecommons.org/licenses/by-nc-nd/2.0/de/legalcode).