Kunden SSH Zugriff gibt im Root rechte?

Shorty

Registered User
Hallo,
sorry das ich mal wider nerve aber ich verstehe da etwas nicht,bei mir gibt es Zwei Kunden/Domains bei denen lassen sich die FTP Zugriffs rechte nicht einschränken,sprich der Kunde bekommt Trotz das bin/bash(chrooted) und bin/bash eingestellt ist zugriff auf Root ordner normal sollte der zugriff über FTP erst bei httpdocs beginnen.

Ich habe noch Zwei Domains wenn ich es bei denen mache ist es wie es sein soll deren zugriff beginnt bei httpdocs ,alle haben die selbe Einstellung das selbe Abonoment usw,was könnte das sein und wie kann ich das beheben?
 

Attachments

Last edited:

DeaD_EyE

Blog Benutzer
SFTP kann man auch in einen chroot einsperren, ich weiß aber nicht, ob das jemals sicher gewesen ist :D

Um den Plesk-Spezifischen Kram musst du dich aber selbst kümmern. Ich denke mal, dass durch Plesk die sshd_config stark angepasst worden ist.
 

danton

Debian User
Chroot bei SSH hat einige Nachteile, einer wird im oben verlinkten Howto schon genannt. Wenn ein User den SSH-Zugriff wirklich benötigt, gibt es beim chroot große Einschränkungen (z.b. müssen alle zu nutzenden Programme im chroot bereitgestellt werden). Außerdem geht das o.g. Howto davon aus, dass der SSh-Zugriff nicht benötigt wird, sondern nur sftp - und da gibt es eine Alternative in Form von ftps/ftpes über einen FTP-Daemon wie proftpd.
 

PHP-Friends

Blog Benutzer
verifizierter Anbieter
Allgemein ist ein chroot kein Plus an Sicherheit. Das Berechtigungssystem von Linux funktioniert (grundsätzlich) hervorragend und zu wissen, dass es noch andere Verzeichnisse etc. gibt, stellt keine Sicherheitslücke dar.
 

marce

Well-Known Member
Würde ich widersprechen - eine gut konfigurierte chroot-Umgebung nimmt dem User schon sehr viele Möglichkeiten "Unsinn anzustellen", die er im restlichen System sonst hätte.
Zugegeben ist eine saubere Konfiguration von chroots über div. Services hinweg nicht trivial und macht ggf. auch keinen Spaß - richtig eingesetzt ist chroot aber ein sehr effektives Mittel.

Das Problem ist hier aber nicht das chroot / kein chroot sondern daß der TE keine Ahnung hat, warum ein chroot in ftp völlig problemlos funktioniert hat und er via sftp plötzlich keines mehr vorfindet. Er hat ja nicht mal bemerkt, daß er sich über verschiedene Protokolle am System anmeldet und damit völlig unterschiedliche Services anspricht. Daß die von ihm gefundene "Lösung" mit dem eigentlichen Problem nichts zu tun hat läuft da als Goodie nur neben her mit...
 

PHP-Friends

Blog Benutzer
verifizierter Anbieter
Würde ich widersprechen - eine gut konfigurierte chroot-Umgebung nimmt dem User schon sehr viele Möglichkeiten "Unsinn anzustellen", die er im restlichen System sonst hätte.
Die da wären? Wenn die sonstigen Berechtigungen nicht korrekt konfiguriert sind, wird man aus dem chroot auch ausbrechen können, außer es ist wirklich komplett leer, dann wird's schon eng. Aber ansonsten ist das meines Erachtens im weitesten Sinne Security by Obscurity.

Das Problem ist hier aber nicht das chroot / kein chroot sondern daß der TE keine Ahnung hat
Ich mache mich mal unbeliebt und habe das Zitat gekürzt.
 

marce

Well-Known Member
Die da wären?
Im chroot hat der User ein def. Toolset zur Verfügung - klar, das kann er sich selbst erweitern, die Hürde an sich ist aber erst mal größer.

Das Toolset, welches eine klassische Distribution zur Verfügung stellt ist da wesentlich umfangreicher und bietet da wesentlich mehr Möglichkeiten.
Klar, das kann man alles bei der Installation weglassen - das ist aber was, was man auch ded. machen müsste und da sehe ich bei den meisten Hobby-Server-Hostern noch viel Luft nach oben.
Für manche Tools ist's schlicht auch mehr oder weniger unmöglich, die wegzulassen oder nur so zugreifbar zu machen, daß der klassische Benutzer eben kein r-x hat...
 

danton

Debian User
Im chroot hat der User ein def. Toolset zur Verfügung - klar, das kann er sich selbst erweitern, die Hürde an sich ist aber erst mal größer.
Genau, es wird eine kleine Hürde aufgebaut, aber chroot ist nicht als Sicherheitsfeature ausgelegt. chroot fällt für mich in die Rubrik Security by Obscurity. In der Manpage zu chroot wird auch explizit darauf hingewiesen, dass man es nicht aus Security-Gründen einsetzen sollte.
 

marce

Well-Known Member
Klein ist die Hürde nicht gerade, aus einem chroot auszubrechen.

Auf welchen Satz in der Man-Page beziehst Du dich? Ich habe es (beim grob überfliegen) nicht gefunden. Eher im Gegenteil, chroot wird seit Jahrzehnten als eine der Möglichkeiten angesehen, User effizient einzusperren und ihm nur die Möglichkeiten zu geben, die er braucht.

So oder so - SecByObs ist etwas anderes - chroot bietet, wenn sauber eingerichtet, wesentlich mehr als nur reines "verbergen" von Angriffsvektoren.
 

Joe User

Zentrum der Macht
Fangen wir mit https://deepsec.net/docs/Slides/201..._Various_Chroot_Solutions_-_Bucsay_Balazs.pdf an, dann http://pentestmonkey.net/blog/chroot-breakout-perl und dann gehen wir https://www.google.com/search?num=100&newwindow=1&hl=en&source=hp&q=chroot+breakout weiter durch...

Dazu kommen dann noch ein paar Bugs, welche Ausbrüche ermöglichen und in etlichen POCs/Malware auf einschlägigen Websites zu finden sind.

chroot ist definitiv kein Security-Feature und ist es auch nie gewesen.
Etwas besser fährt man da mit BSD-Jails/Solaris-Zones, wobei auch diese nicht völlig ausbruchssicher sind, aber immerhin geht es hier nur mit root-Rechten.
Container und andere Linux-Lösungen liegen allesamt irgendwo zwischen chroot und BSD-Jails/Solaris-Zones und sollten somit sehr sorgsam ausgewählt und angewendet werden. Falsch angewendet können sie teilweise so gar unsicherer als chroot sein, also Nix für Anfänger...
 

d4f

Müder Benutzer
Generell brauchen alle Ausbruchtechniken bei einem korrekt konfigurierten chroot und Umgebung ohne Sicherheitslöcher einen root-Benutzer. Damit ist chroot generell eine effektive Technik den Benutzer in seinen Home ein zu sperren. ABER: das bedeutet nicht dass der Benutzer damit zwingend sicherer ist - in einem korrekt konfigurierten System kann der Benutzer eh nur seine eigenen oder (technisch) unkritische Systemdateien sehen...
Natürlich sind Exploits bei diesem Statement aussen vor - wie immer. Was jemand wie der BND kann oder nicht kann, kannst du vermutlich besser einschätzen als ich ;)

chroot ist also eher sinnvoll um
a) Alle Benutzerdateien garantiert an einem Ort zu haben
b) den Container transportabel und interoperabel zu halten
c) Libraries und Anforderungen zwischen Host und Applikation zu trennen (Docker bevor es Docker gab)
d) administrative Kritikalität (Einsehen anderer Benutzer, Domains, ...) zu unterbinden
In genau diese Lücke spielen für bspw für Vereinfachung Docker oder für Ressourcentrennung Cloudlinux.

etwas besser fährt man da mit BSD-Jails/Solaris-Zones, wobei auch diese nicht völlig ausbruchssicher sind, aber immerhin geht es hier nur mit root-Rechten.
Um alle Grossen zu nennen fehlt AIX WPAR auch wenn ich bislang sowas nicht im realen Einsatz gesehen habe sondern nur (D)LPAR :p
Zumindest AIX WPAR und Solaris Zonen sind aber doch definitiv mehr als ein schnöder Chroot und imho auf technisch ca gleicher Funktionsebene wie Linux LXC oder OpenVz (rip...).



Um aber mal die Originalfrage auf zu greifen: du redest zuerst über FTP und dann über SSHkeys. Verwechselst du nicht SFTP (SSH-FTP) mit FTPS (FTP over SSL/TLS)? Ersteres ist ein SSH-Zugang welcher für Dateien benutzt wird, letzterer ist FTP über eine verschlüsselte Verbindung und braucht kein systemseitiges chroot.

Am Rande: ist eigentlich der Webserver auch chroot "gesichert"? Oder reden wir grade über das Absichern einer SCP Verbindung während PHP gemütlich quer durch das ganze System spazieren kann? :p[/quote]
 

DeaD_EyE

Blog Benutzer
Naja, man könnte auch einen mldonkey im Chroot installieren und den dann ganz bequem via Remote steuern.
Die GUIs kann man sich sogar aussuchen. Man braucht keine Root-Rechte, um einem Betreiber und sich selbst Probleme zu verschaffen.

Klar, die geben das einfach weiter, war ja der Kunde. Den Stress hat aber zuerst der Betreiber.
Je nachdem welches Clientel man bedient, würde ich SSH nicht anbieten.
 
Top