Kero

Root Zugriff via ssh ist generell zu vermeiden, aber ab und an geht es nicht anders. Dabei hilft dann z. B. ein

AllowUsers root@123.123.123.123/32

in der /etc/ssh/sshd_config oder falls nur keys erlaubt sind ein

from="123.123.123.123" ssh-rsa AAAAB3Nkrickekrackelsagtderdackel...

in die /root/.ssh/authorized_keys. Beides bei Multiusersystemen nicht optimal, aber ausbaufaehig.

Chroot ist gut, so einfach ist das. Multiusersysteme ohne chroot bieten ein grosses Sicherheitsrisiko. Dieses Risiko entsteht in der Regel durch falsch gesetzte Dateirechte. Leider kann mit vertretbaren Mitteln nicht ueberall eine chroot Umgebung aufgebaut werden. Generell sollte man sich immer Fragen: Braucht der Benutzer ueberhaupt eine Shell? Nehmen wir einen standard Webserver mit mehreren virtuellen Webservern und unterschiedlichen Benutzern als Beispiel. Der Benutzer will Daten auf den Webserver packen, die darueber bereitgestellt werden, mehr nicht. Eine Shell ist dabei voellig ueberfluessig und erhoeht nur das Risiko eines potentiellen Einbruchs und der Datenmanipulation (und und und).  Falsch gesetzte Dateirechte sind in einer chroot Umgebung nur "halb so schlimm". Nehmen wir z. B. die beliebte

-rw-r--r-- 1 thomas thomas 0 2011-07-15 10:22 config.php

Natuerlich kann und muss der Webserver die Datei lesen koennen, aber der Benutzer Satans101 kann die Datei auch lesen und ein teuflisches Werk damit treiben. Nutzt man chroot, schuetzt man primaer die Benutzer voreinander. Ein Einbruch mit ergattern eines Shell Zugangs und Zugriff auf andere Benutzerdaten  ist so nicht ohne weiteres moeglich (ich erspare mir Sachen wie  how-to-get-shell-acces-in-no-mans-land). Ein hervorragender Weg ist dabei die sftp chroot Umgebung von ssh zu nutzen. Vorteil ist man muss keine extra Software installieren und nutzt die Moeglichkeiten von ssh. Ganz kurz sieht das in der /etc/ssh/sshd_config etwa so aus:

AllowGroups ssh-allow sftp-allow
Subsystem sftp internal-sftp
match group sftp-allow
ChrootDirectory /user/home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

Wichtig dabei ist

chown root:root /user/home/username

Das Userhome muss root gehoeren.
Das ssh-allow ist natuerlich nur Beiwerk aber sinnig. Dies ist nur eines der Werkzeuge um die Sicherheit zu erhoehen, tools wie chmod g+s, rkhunter, iwatch, aide, tiger, clamav, limits.conf, quota, fail2ban, open_basedir, portchange, diverse selbst geschrieben Skripte usw. helfen dabei auch weiter.

Ganz grob einige Vorteile von croot mit sftp dabei

• Benutzer sieht Daten anderer Benutzer nicht
• Benutzer kann keine Prozesse laufen lassen -> Benutzerprozesses fallen sofort auf
• Geklaute Accounts haben nur einen begrenzten Nutzen fuer Einbrecher
• Unerfahrene Benutzer irren nicht durch das gesamte Dateisystem (ja tatsaechlich)
• ...

Nachteile

• sind zu vernachlaessigen

Chroot im Zusammenhang mit sftp nutze ich nun seit ueber 2 Jahren mit mehreren 100 Benutzern und meine Erfahrungen sind durchweg positiv. Der optimale client dabei ist sshfs. Programme wie fireftp, filezilla, sftp und winscp gehen natuerlich auch. Empfehlen kann ich auch eine strickte Trennung der Dienste auf unterschiedliche Systeme, aber wem erzaehl ich das, weiss man doch alles.

links: OpenSSH SFTP chroot() with ChrootDirectory