SFTP und PKT

[xenolf]

SFTP und PrivKeys

Hallo liebe Forengemeinde!

Ich versuche gerade meinen Server komplett von FTP auf SFTP umzustellen, das klappt soweit auch super.
Also SFTP only Benutzer haben keinen zugang auf eine Shell und können sich auch per normalem SSH nicht auf dem Server einloggen.

Zur Zeit läuft die Authentifizierung über PubKeys und das möchte ich eigentlich auch so beibehehalten, mit einer Ausnahme.
Und das führt mich jetzt auch zu meiner Frage: Ist es möglich, normalen SSH Benutzern den Zugriff nur per PubKey zu erlauben,
den SFTP only Benutzern aber mit Passwort-prompt? Da PubKeys ja leider nicht wirklich praktikabel einsetzbar sind bei mehreren wechselnden Usern.

Das nächste was mich interessieren würde ist, ist es empfehlenswert den Apache-Prozess zu chrooten? (Auf einem RSBAC gepatchten System) Oder reichen die Apache eigenen mods da aus? (suExec, suhosin, php über fast cgi und mod_evasive / mod_security installiert)

grüße
xen

 

[Roger Wilco]

Ist es möglich, normalen SSH Benutzern den Zugriff nur per PubKey zu erlauben, den SFTP only Benutzern aber mit Passwort-prompt?

Ja, schau dir die Direktive Match in sshd_config(5) an.

Das nächste was mich interessieren würde ist, ist es empfehlenswert den Apache-Prozess zu chrooten?

Um was genau zu erreichen? Bitte merken: chroot(2) ist kein Sicherheitsfeature!

 

[xenolf]

Um was genau zu erreichen? Bitte merken: chroot(2) ist kein Sicherheitsfeature!

Ja, ist es nicht... aber soweit ich gelesen habe kann es doch auch zur Sicherheit beitragen da es mit einem RSBAC gepachten Kernel ja noch schwerer wird aus dem chroot auszubrechen.

Oder irre ich mich da?

 

[Roger Wilco]

aber soweit ich gelesen habe kann es doch auch zur Sicherheit beitragen da es mit einem RSBAC gepachten Kernel ja noch schwerer wird aus dem chroot auszubrechen.

Das je nach Konfiguration schon, aber was willst du konkret erreichen?

Die dynamischen Inhalte werden von dem unter dem (dank SuExec) jeweiligen Benutzer laufenden PHP-Interpreter ausgeführt. Es würde also prinzipiell reichen, diese in eine chroot-Umgebung zu stecken.

 

[xenolf]

Ich möchte das ein erfolgreicher Angriff auf ein Webscript dem Angreifer keinen Prozess zur verfügung stellt der sich wild auf meinem Server austoben kann. Und der Weg das zu erreichen ist wohl ein chroot jail für den angreifbaren Prozess... oder ist das ein Holzweg?

 

[Roger Wilco]

Ich möchte das ein erfolgreicher Angriff auf ein Webscript dem Angreifer keinen Prozess zur verfügung stellt der sich wild auf meinem Server austoben kann.

Wie schon erwähnt: chroot(2) ist kein Sicherheitsfeature und die Skripte werden vom PHP-Interpreter in einem anderen Benutzerkontext ausgeführt.

 

[xenolf]

Also werden die Scripte durch suExec mit den Rechten des Besitzers der Files ausgeführt? Also wenn der in der /httpdocs chroot sitzt kann das Script auch net raus?

 

[Roger Wilco]

Also werden die Scripte durch suExec mit den Rechten des Besitzers der Files ausgeführt? Also wenn der in der /httpdocs chroot sitzt kann das Script auch net raus?

Das Wurzelverzeichnis für den Apache httpd wäre dann aber vermutlich /var/www/ bzw. /srv/www/ und dadurch könnte der Angreifer ggf. trotzdem noch alle anderen Webseiten verändern. Wenn die PHP-Interpreter selbst in eine chroot-Umgebung gesteckt werden, kann das Wurzelverzeichnis je nach VirtualHost/Benutzer gewählt werden und schränkt so die Angriffsfläche ein.

 

[xenolf]

Das klingt doch sehr interessant, die einzelnen jails werden in den vhost configs vergeben oder?

 

[dev]

Wenn Du den Document-Root meinst - ja.

Ansonsten kannst Du php noch per open_basedir-Direktive in ein Verzeichnis "sperren" und den safe_mode aktivieren.