Product SiteDocumentation Site

Kapitel 5. Absichern von Diensten, die auf Ihrem System laufen

5.1. Absichern von ssh
5.1.1. SSH in ein Chroot-Gefngnis einsperren
5.1.2. Ssh-Clients
5.1.3. Verbieten der bertragung von Dateien
5.1.4. Beschrnkung des Zugangs auf Dateientransfers
5.2. Absichern von Squid
5.3. Absichern von FTP
5.4. Zugriff auf das X-Window-System absichern
5.4.1. berprfen Ihres Display-Managers
5.5. Absichern des Druckerzugriffs (die lpd- und lprng-Problematik)
5.6. Absichern des Mail-Dienstes
5.6.1. Konfiguration eines Nullmailers
5.6.2. Anbieten eines sicheren Zugangs zu Mailboxen
5.6.3. Sicherer Empfang von Mails
5.7. Absichern von BIND
5.7.1. Bind-Konfiguration um Missbrauch zu verhindern
5.7.2. ndern des BIND-Benutzers
5.7.3. Chroot-Gefngnis fr den Name-Server
5.8. Absichern von Apache
5.8.1. Verhindern, dass Benutzer Web-Inhalte verffentlichen
5.8.2. Rechte der Protokolldateien
5.8.3. Verffentlichte Web-Dateien
5.9. Absichern von Finger
5.10. Allgemeine chroot- und suid-Paranoia
5.10.1. Automatisches Erstellen von Chroot-Umgebungen
5.11. Allgemeine Klartextpasswort-Paranoia
5.12. NIS deaktivieren
5.13. Absichern von RPC-Diensten
5.13.1. Vollstndiges Deaktivieren von RPC-Diensten
5.13.2. Einschrnken des Zugriffs auf RPC-Dienste
5.14. Hinzufgen von Firewall-Fhigkeiten
5.14.1. Firewallen des lokalen Systems
5.14.2. Schtzen anderer Systeme durch eine Firewall
5.14.3. Aufsetzen einer Firewall
Dienste knnen auf zwei Arten in einem laufenden System abgesichert werden:
  • Sie so einstellen, dass auf sie nur von Zugangspunkten (Interfaces) zugegriffen werden kann, von denen es ntig ist.
  • Sie so konfigurieren, dass sie nur von legitimierten Benutzern auf autorisierte Art und Weise benutzt werden knnen.
Dienste knnen durch Zugriffsbeschrnkungen auf Kernel-Ebene (durch eine Firewall) eingeschrnkt werden, so dass auf sie nur von bestimmten Orten aus zugegriffen werden kann. Konfigurieren Sie sie, so dass sie nur auf einer bestimmten Schnittstelle horchen (einige Dienste bieten diese Fhigkeiten nicht). Oder verwenden Sie eine andere Methode, zum Beispiel den Linux-vserver-Patch (fr 2.4.16), mit dem Prozesse an eine bestimmte Schnittstelle gebunden werden knnen.
Was die Dienste angeht, die von inetd aufgerufen werden (telnet, ftp, finger, pop3, ...), so ist es wert zu erwhnen, dass inetd so konfiguriert werden kann, dass er nur auf eine bestimmte Schnittstelle reagiert (unter Verwendung der service@ip-Syntax). Dies ist jedoch eine nicht dokumentierte Eigenschaft. Ein Ersatz, der Meta-Daemon xinetd, kennt eine bind-Option nur fr diesen Zweck. Lesen Sie dazu bitte ixnetd.conf(5).
service nntp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = news
        group           = news
        server          = /usr/bin/env
        server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
        bind            = 127.0.0.1
}
Die folgenden Abschnitte gehen detaillierter darauf ein, wie bestimmte Dienste abhngig von der beabsichtigten Benutzung passend konfiguriert werden.

5.1. Absichern von ssh

Wenn Sie immer noch telnet statt ssh benutzen, sollten Sie dieses Handbuch kurz beiseitelegen und dies ndern. Ssh sollte anstelle von telnet fr alle Anmeldungen aus der Ferne benutzt werden. In einer Zeit, in der es leicht ist, Internet-Verkehr mitzuschnffeln und an Klartext-Passwrter heranzukommen, sollten Sie lediglich Protokolle verwenden, die Verschlsselung benutzen. Also fhren Sie sofort ein apt-get install ssh auf Ihrem System aus.
Ermuntern Sie alle Benutzer Ihres Systems, ssh anstelle von telnet zu benutzen, oder noch besser: deinstallieren Sie telnet/telnetd. Zustzlich sollten Sie es vermeiden, sich mit ssh als Root einzuloggen, und lieber andere Methoden benutzen, um Root zu werden. Wie zum Beispiel su oder sudo. Schlielich sollten Sie noch die Datei /etc/ssh/sshd_config fr mehr Sicherheit modifizieren:
  • Lassen Sie ssh nur auf einer bestimmten Schnittstelle lauschen, falls Sie mehrere haben (und ssh nicht auf allen verfgbar sein soll) oder Sie in Zukunft eine neue Netzwerkkarte einbauen werden (und keine ssh-Verbindungen auf ihr erlauben wollen).
  • Versuchen Sie so wenige Anmeldungen als Root wie mglich zu erlauben. Wenn nun jemand Root werden will, bentigt er zwei Anmeldungen. So kann das Root-Passwort nicht so leicht ausgetestet werden.
  • Port 666 oder ListenAddress 192.168.0.1:666 verändern Sie den Port, auf dem ssh lauscht, so dass ein Eindringling nicht wirklich sicher sein kann, ob ein sshd-Daemon läuft (aber beachten Sie, dass dies lediglich »Sicherheit durch Verschleierung« ist).
  • PermitEmptyPasswords no Nicht gesetzte Passwörter spotten jeglicher Systemsicherheit.
  • Erlauben Sie nur bestimmten Benutzern sich via ssh auf der Maschine anzumelden. benutzer@host kann auch verwendet werden, um einen bestimmten Benutzer dazu zu zwingen, nur von einem bestimmten Host aus zuzugreifen.
  • Erlauben Sie nur bestimmten Gruppenmitgliedern sich via ssh auf der Maschine einzuloggen. AllowGroups und AllowUsers haben quivalente Verfahrensweisen, um den Zugang zu der Maschine zu verwehren. Es wird nicht berraschen, dass es sich hierbei um DenyUsers und DenyGroups handelt.
  • Es ist allein Ihre Wahl, was Sie hier eintragen. Es ist sicherer, Zugriff nur Benutzern zu erlauben, die ssh-Schlssel in der Datei ~/.ssh/authorized_keys haben. Wenn Sie dies wollen, setzen Sie es auf no.
  • Schalten Sie jede Art der Authentifizierung ab, die Sie nicht wirklich bentigen, zum Beispiel RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication oder RhostsAuthentication. Sie sollten sie abschalten, auch wenn sie es standardmig bereits sind (siehe dazu die Handbuch-Seite sshd_config(5)).
  • Deaktivieren Sie die Protokollversion 1, da diese einige Designschwächen hat, die es einfacher zu machen, Passwörter zu knacken. Für weitere Informationen lesen Sie http://earthops.net/ssh-timing.pdf oder das http://xforce.iss.net/static/6449.php.
  • Fgen Sie einen Bannertext (er wird aus der Datei bezogen) fr Benutzer, die sich mit dem ssh-Server verbinden, hinzu. In einigen Lndern sollte das Senden einer Warnung ber unautorisierten Zugriff oder Benutzerberwachung vor dem Zugriff zu einem bestimmten System erfolgen, um sich rechtlich abzusichern.
Sie knnen den Zugriff auf den ssh-Server auch mittels pam_listfile oder pam_wheel in der PAM-Kontrolldatei beschrnken. Zum Beispiel knnen Sie jeden abhalten, der nicht in der Datei /etc/loginusers aufgelistet ist, durch Hinzufgen folgender Zeile zu /etc/pam.d/ssh:
auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers
Abschlieend beachten Sie bitte, dass diese Direktiven von einer OpenSSH-Konfigurationsdatei stammen. Derzeit gibt es drei weit verbreitete ssh-Daemonen: ssh1, ssh2 und OpenSSH von den OpenBSD-Leuten. Ssh1 war der erste verfgbare ssh-Daemon und er ist noch der weit verbreitetste (Gerchten zufolge gibt es sogar eine Windows-Version). Ssh2 hat gegenber ssh1 viele Vorteile, abgesehen davon, dass es unter einer unfreien Lizenz verffentlicht wurde. OpenSSH ist ein vllig freier ssh-Daemon, der sowohl ssh1 als auch ssh2 untersttzt. OpenSSH ist die Version, die installiert wird, wenn Sie auf Debian das Paket ssh auswhlen.
You can read more information on how to set up SSH with PAM support in the http://lists.debian.org/debian-security/2001/11/msg00395.html.

5.1.1. SSH in ein Chroot-Gefngnis einsperren

Zurzeit bietet OpenSSH keine Mglichkeit, automatisch Benutzer bei der Verbindung in ein Chroot-Gefngnis einzusperren (die kommerzielle Version bietet diese Funktionalitt). Wie dem auch sei, es gibt auch ein Projekt, das diese Funktionalitt fr OpenSSH anbietet, vergleiche http://chrootssh.sourceforge.net. Es ist aber aktuell noch nicht als Debianpaket verfgbar. Sie sollten stattdessen das pam_chroot-Modul, wie in Abschnitt 4.11.15, „Den Benutzerzugang einschränken“ beschrieben, verwenden.
In Abschnitt B.7, „Chroot-Umgebung für SSH knnen Sie verschiedene Optionen finden, um Chroot-Umgebungen fr SSH zu erstellen.

5.1.2. Ssh-Clients

Wenn Sie einen SSH-Client mit einem SSH-Server verwenden, mssen Sie sicherstellen, dass er die selben Protokolle, die vom Server erzwungen werden, untersttzt. Wenn Sie beispielsweise das Paket mindterm verwenden, untersttzt dies nur Protokollversion 1. Jedoch ist der sshd-Server standardmig so konfiguriert, nur Version 2 (aus Sicherheitsgrnden) zu akzeptieren.

5.1.3. Verbieten der bertragung von Dateien

Wenn Sie nicht mchten, das Benutzer Dateien zum und vom ssh-Server bertragen, mssen Sie den Zugang zu sftp-server und zu scp einschrnken. Sie knnen dies fr sftp-server tun, indem Sie den korrekten Subsystem-Wert in /etc/ssh/sshd_config eintragen.
Sie knnen auch Benutzer mittels libpam-chroot in eine Chroot-Umgebung einsperren, so dass sie, selbst wenn Dateitransfers erlaubt sind, auf eine bestimmte Umgebung festgelegt sind, die keine Systemdateien enthlt.

5.1.4. Beschrnkung des Zugangs auf Dateientransfers

Sie knnen den Zugang von Benutzern der Gestalt beschrnken, dass sie nur Dateien bertragen knnen, aber keine interaktive Shell erhalten. Dies knnen Sie mit den folgenden Methoden erreichen:
  • den Benutzern verbieten, sich auf dem ssh-Server einzuloggen (wie oben beschrieben entweder durch die Konfigurationsdatei oder die PAM-Konfiguration), oder
  • den Benutzern nur eine eingeschrnkte Shell wie scponly oder rssh zuweisen. Diese Shells schrnken die Befehle ein, die den Benutzern zur Verfgung stehen, so dass sie auf dem entfernten Rechner keine Befehle ausfhren knnen.