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