Sicherheitslücke bei SSH-Benutzern [GELÖST]

[daubehosting]

Hallo,

bei meiner Testinstallation ist mir eine schwere Sicherheitslücke aufgefallen, wenn der Benutzer SSH-Rechte hat.

Die Kundenverzeichnisse werden bei mir wie folgt angelegt.

Code: Select all

drwxr-xr-x 7 root root 4096 Okt 30 21:14 web1
drwxr-xr-x 7 root root 4096 Okt 30 21:20 web2

Das bedeutet, jeder kann per SSH in jedes Verzeichnis rein. Wäre eventuell noch in Ordnung, da im Unterverzeichnis direkt ja keine Kundendaten liegen.

Das Kundenverzeichnis selbst (Auszug):

Code: Select all

drwxr-xr-x 2 www-data www-data 4096 Okt 30 21:15 logs
drwxr-xr-x 2 web1     www-data 4096 Okt 30 21:14 www

Hier kann jeder Kunden ebenfalls per SSH rein. Dies halte ich gerade beim www für eine riesen Lücke, da hier die php-Dateien mit Passwörter offen liegen.

Lösung wäre eventuell die Kundenverzeichnisse (in meinem Fall web1 / web2) mit chown root:www-data und 750 anzulegen.

[select name from me;]

SSH insgesamt ist imho noch ein wenig Baustelle. Ein SSH Jail steht aber schon auf der Wunschliste, wenn ich mich nicht irre.

Zudem wäre es auch sinnvoll, dass man als SSH User mit ps, top etc. nur seine eigenen Prozesse sieht. Gerade bei mysql und mysqldump Prozessen werden gerne man Kennwörter mit übergeben.

[Martin]

Hallo,

SSH ist aktuell nicht gejailed, wie select name from me; korrekt bemerkte ist dies noch auf der ToDo Liste. Sofern ein Nutzer SSH Rechte erhält, hat dieser damit einen vollwertigen SSH Nutzer. Eine Aktivierung von SSH sollte entsprechend nur bei hinreichend vertrauenswürdigen Nutzern erfolgen.
Eine Sicherheitslücke im eigentlichen Sinne sehe ich hier allerdings nicht.

[Jolinar]

Eine Sicherheitslücke im eigentlichen Sinne sehe ich hier allerdings nicht.

Wenn überhaupt, ist es eher "Broken by Design". Denn standardmäßig werden die Flags o+rx beim Anlegen von Folders und o+r beim Anlegen von Files gesetzt.

Ergänzung:
Wobei man hier (als Workaround) die umask für die einzelnen Benutzer auf 0027 setzen könnte. Systemweit ginge zwar theoretisch auch, aber ich hatte in der Vergangenheit schon Probleme damit.

[daubehosting]

Denn standardmäßig werden die Flags o+rx beim Anlegen von Folders und o+r beim Anlegen von Files gesetzt.

... und genau dies sollte man ändern, damit die Sicherheitslücke gar nicht erst entsteht

[Jolinar]

... und genau dies sollte man ändern, damit die Sicherheitslücke gar nicht erst entsteht

Siehe Ergänzung in meinem letzten Post.

[select name from me;]

Ich glaube, eine umask löst das Problem nicht weit genug. Man kann im Shared Hosting Bereich nicht erwarten, dass jeder User Linux Rechte versteht.

Wie lösen große Provider das? Dort ist z.B. bei php open_basedir nicht gesetzt und man kann trotzdem nicht auf fremde Dateien zugreifen.

[Jolinar]

Ich glaube, eine umask löst das Problem nicht weit genug. Man kann im Shared Hosting Bereich nicht erwarten, dass jeder User Linux Rechte versteht.

Deswegen habe ich das ja auch nur als möglichen Workaround vorgeschlagen, bis die Isolierung der einzelnen User vollständig implementiert ist.

Wie lösen große Provider das? Dort ist z.B. bei php open_basedir nicht gesetzt und man kann trotzdem nicht auf fremde Dateien zugreifen.

Da gibt es verschieden Ansätze...Von Chroots und Jails über ACL's bis hin zu diversen Apache-Modulen und auch Kombinationen verschiedener Möglichkeiten. Das macht jeder Hoster ein bissel anders, denn das ist z.T. auch abhängig von der eingesetzten Infrastruktur, den verwendeten Virtualisierungslösungen u.ä.m.

[Martin]

Hallo,

für PHP Dateien mit z.B. SQL Zugangsdaten kann man diese auch mit CHMOD 600 oder 400 versehen, da hier nur PHP selbst (im Kontext des Users) Zugriff haben muss.

[daubehosting]

Lösung wäre eventuell die Kundenverzeichnisse (in meinem Fall web1 / web2) mit chown root:www-data und 750 anzulegen.

Ist dies nicht umsetzbar oder übersehe ich etwas ?

[Jolinar]

Lösung wäre eventuell die Kundenverzeichnisse (in meinem Fall web1 / web2) mit chown root:www-data und 750 anzulegen.

Ist dies nicht umsetzbar oder übersehe ich etwas ?

Wenn du es so setzt, sperrst du den User aus seinem eigenen Folder aus, denn Eigentümer wäre dann root mit Flag u+rwx und Gruppe www-data mit Flag g+rx. Der Rest hätte Flag o-rwx. Aktuell betritt der User seinen Folder über das Flag o+rx.

Sinnvoller wäre es, wenn du innerhalb des Userfolders (also innerhalb von web1 oder web2) das Flag o-rwx setzt (theoretisch wäre auch ein chown des Userfolders auf den User in Kombination mit Setzen des Flags o-rwx auf den Userfolder denkbar. Aber dazu rate ich im Moment nicht, da ich mir die übrigen Rechteabhängigkeiten noch nicht genauer angeschaut habe).

[select name from me;]

Wie lösen große Provider das? Dort ist z.B. bei php open_basedir nicht gesetzt und man kann trotzdem nicht auf fremde Dateien zugreifen.

Da gibt es verschieden Ansätze...Von Chroots und Jails über ACL's bis hin zu diversen Apache-Modulen und auch Kombinationen verschiedener Möglichkeiten. Das macht jeder Hoster ein bissel anders, denn das ist z.T. auch abhängig von der eingesetzten Infrastruktur, den verwendeten Virtualisierungslösungen u.ä.m.

Interessant. Danke für die Info.