Autor: 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 überall 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 ablegen, die darüber bereitgestellt werden, mehr nicht. Eine Shell ist dabei voellig unnötig und erhöht 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

Natürlich kann und muss der Webserver die Datei lesen können, aber der Benutzer Satans101 kann die Datei auch lesen und sein teuflisches Werk damit treiben. Nutzt man chroot, schützt man primär die Benutzer voreinander. Ein Einbruch mit ergattern eines Shell Zugangs und Zugriff auf andere Benutzerdaten,  ist so nicht ohne weiteres möglich (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 Möglichkeiten 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
Match

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 für Einbrecher
• Unerfahrene Benutzer irren nicht durch das gesamte Dateisystem (ja tun sie tatsächlich)
• …

Nachteile

• sind zu vernachlässigen

Chroot im Zusammenhang mit sftp nutze ich nun seit über 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 natürlich auch. Empfehlen kann ich auch eine strickte Trennung der Dienste auf unterschiedliche Systeme, aber wem erzähl ich das, weiß man doch alles.

links: OpenSSH SFTP chroot() with ChrootDirectory