Kunden SSH Zugriff gibt im Root rechte?

S

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

  • 15.png
    15.png
    94.2 KB · Views: 243
Last edited:
SFTP kann man auch in einen chroot einsperren, ich weiß aber nicht, ob das jemals sicher gewesen ist :D

adminforge.de

Chroot SFTP mit OpenSSH ohne Shell Zugang - adminForge

Zu Beginn muss OpenSSH mitgeteilt werden, dass Benutzer der Gruppe sftp anders behandelt werden sollen. Hierzu nehmen wir in der Datei /etc/ssh/sshd_config
adminforge.de adminforge.de
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.
 
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.
 
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.
 
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...
 
marce said:
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.
Click to expand...
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.

marce said:
Das Problem ist hier aber nicht das chroot / kein chroot sondern daß der TE keine Ahnung hat
Click to expand...
Ich mache mich mal unbeliebt und habe das Zitat gekürzt.
 
PHP-Friends said:
Die da wären?
Click to expand...
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...
 
marce said:
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.
Click to expand...
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.
 
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.
 
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...
 
Fangen wir mit https://deepsec.net/docs/Slides/2015/Chw00t_How_To_Break Out_from_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...
Click to expand...
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.
Click to expand...
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]
 
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.
 
You must log in or register to reply here.
Back
Top