Shell für lokale Benutzer - Sicherheitsrisiko



C

ChrisServer

New Member
Die meisten Shared-Hosting Provider bieten Ihren Usern keinen Shell-Zugang an.

Inwiefern stellen lokale Benutzer ein Sicherheitsrisiko dar? Klar, sie können lokale Sicherheitslücken, falls vorhanden, ausnutzen. Außerdem können sie auf einem Standard Debian-System ein Großteil der Konfiguration lesen. Angenommen ich habe selbst nicht irgendwelche Sicherheitslöcher aufgerissen :eek: wie schätzt ihr das Risiko ein?
 
Wie Du schon richtig beschrieben hast,können sie einen Großteil der cfg´s einsehen.Mit dem Wissen kann man bestimmt gezielt irgendwelche scripte laufen lassen,um dann Root-Rechte zu erlangen.

Man kann doch bestimmt eine Chroot-umgebung schaffen,aus der der Ssh-User dann nicht raus kann.

Abgesehen davon würde ich sowieso keinem Ssh-zugang geben,ohne ausnahme.

gruss s.b.
 
Die meisten Anbieter chrooten meines Wissens, ja.
Gibt so einige, die SSH-Zugang mit anbieten (was ich ebenfalls sehr schätze).
 
Noch mal zurück zu den Sicherheitsrisiken: Der Linux-Kernel hatte in der jüngsten Vergangenheit immer mal wieder Sicherheitslücken, die eine local privilege escalation erlaubten. Auf solche Dinge muss man natürlich verstärkt achten, sobald nur eingeschränkt vertrauenswürdige User Shell-Zugang bekommen sollen.

Als mögliche Maßnahme wurde chroot angegeben - das alleine ist aber unzureichend. Aus einer chroot-Umgebung kann man verhältnismäßig einfach ausbrechen. Ein (bei den meisten Providern vorhandener) Perl-Interpreter reicht dafür bereits aus, ansonsten kann man auch den chdir()-Syscall in etwas manipulierter Form ausführen.

Um einen Ausbruch aus einer chroot-Umgebung zu verhindern, kann man den Linux-Kernel mit geeigneten Patches wie grsecurity oder RSBAC härten - kombiniert z. B. mit Trusted Path Execution wird's auch für ambitionierte Hobby-Hacker schwierig, mit einer Shell etwas anderes anzustellen, als der Admin explizit erlaubt.
 
Zum Thema Sicherheit: Große Hoster haben meist eine verteilte Architektur, wie sie im angefügten Bild beispielhaft angegeben ist.

Der SSH-Host ist eine minimalistische Maschine, die außer SSH nix weiter hat, Benutzerdatenbank und die eigentlichen Webroots liegen auf einem externen Storage bzw. SAN und sind von außen herangemountet.

Ähnlich geht man mit FTP vor - und die Webserverfarm ist sowieso ein ganzer Haufen Server, die in einem internen RFC1918-Netzwerk (ohne nennenswerte Möglichkeit zu Außenkontakt) stehen und nur über einen Loadbalancer angesprochen werden.

Dadurch minimiert man gleich mehrere Angriffsvektoren. Auf den Webspace hochgeladene bösartige Scripte können nach außen hin nur wenig anstellen (insbesondere beschränkt sich ihre Möglichkeit zur Kontaktaufnahme mit der Außenwelt auf den laufenden HTTP-Request und wenige interne Services wie z.B. Datenbanken).
Die einzelnen Maschinen sind nur mit minimalen Configs versehen (der Webserver braucht z.B. kein FTP, der SSH-Server dagegen kein HTTP).

Zudem kann man durch das externe SAN die Datenzugriffe schön monitoren, versionieren und parallel Backups fahren.
 

Attachments

  • 800_strato_plattform_architektur_rz.jpg
    800_strato_plattform_architektur_rz.jpg
    131 KB · Views: 166
Danke für eure ausführlichen Antworten.

Ich denke ein weiterer Aspekt, den man nicht unterschätzen darf, ist für die Provider aber auch schlicht und einfach der Support-Aufwand. Bietet man "DAUs" Shell-Zugang an, hat man gleich deutlich mehr Support-Anfragen. Datenverlust, Serverüberlastung usw.
 
You must log in or register to reply here.
Back
Top