• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Webspace nicht beschreibbar

Kommt darauf an. Wenn du suPHP verwendest und versuchst, Dateien mit den Rechten rwxrwxrwx aufzurufen, erhälst du eine Fehlermeldung:
500 Internal Server Error
 
Moment, ich erklär's an einem Fallbeispiel. :D
Ich liege beim Hoster XYZ in /var/www/web1, ein anderer Kunde in /var/www/web2. PHP ist via open_basedir eingesperrt und alle Funktionen, mit denen ich ausbrechen könnte, sind deaktiviert. Jetzt setzt der Kunde web2 alles auf 777, meinetwegen hat sogar sein Verzeichnis selbst 777.
"Ihr" seht darin eine Sicherheitlücke, ich nicht.
 
Es kann durchaus gefährlich sein, Scripten die Rechte 777 zu geben.

Und übrigens, nun etwas allgemeiner formuliert: Selbst wenn OpenBaseDir gesetzt ist, bedeutet es noch lange nicht, dass beispielsweise hochgeladene Malware keinen Schaden anrichten kann. Denke an PHPShells oder SpamMailer. Oder Phishing. Das mag zwar lokal erstmal keine anderen User beeindrucken, aber wenn fremde hochgeladene Scripte dann den Server in die Knie zwingen, wirds schon etwas prickelnder :)
 
PHPShells
Eine PHP-Shell funktioniert mit entsprechenden deaktivierten PHP-Funktionen schlichtweg nicht.
Davon abgesehen: Was haben die 777er-Rechte damit zu tun?

SpamMailer
Die Mail-Funktion lässt sich ja durchaus beschränken, und man sollte bei Spamversand wohl auch Alarm vom Monitoring bekommen.
Hier zudem die gleiche Frage wie oben.

Spätestens hier sehe ich wirklich keinen Zusammenhang mehr mit chmod-Rechten. Klar, mit 000 kann man auch das effektiv verhindern. :rolleyes:

wenn fremde hochgeladene Scripte dann den Server in die Knie zwingen, wirds schon etwas prickelnder :)
Um Überlast mit PHP zu erzeugen, brauche ich weder deaktiviertes open_basedir, noch Funktionen wie shell_exec() geschweigedenn "dicke" chmod-Rechte.


Grüße
 
Davon abgesehen: Was haben die 777er-Rechte damit zu tun?
Nichts:
Und übrigens, nun etwas allgemeiner formuliert


Eine PHP-Shell funktioniert mit entsprechenden deaktivierten PHP-Funktionen schlichtweg nicht.
Welche "entsprechenden" deaktivierten Funktionen meinst du? Und welche Funktionen in der PHP-Shell funktionieren dann nicht mehr?

Die Mail-Funktion lässt sich ja durchaus beschränken, und man sollte bei Spamversand wohl auch Alarm vom Monitoring bekommen.
Hier sind wir wieder beim Thema: Viele Hoster haben keinerlei Beschränkungen eingerichtet. Und besonders kleinere Hoster reagieren nicht immer zeitnah aufs Monitoring. Was machst du als Kunde bei einem kleinen Hoster, dessen Server nachts in die Knie gehen? Meistens nur warten.

Spätestens hier sehe ich wirklich keinen Zusammenhang mehr mit chmod-Rechten. Klar, mit 000 kann man auch das effektiv verhindern.

Und wieder:
Und übrigens, nun etwas allgemeiner formuliert:

Nochmal etwas deutlicher:
Und übrigens, nun etwas allgemeiner formuliert: Selbst wenn OpenBaseDir gesetzt ist [...]
... soll dich darauf aufmerksam machen, dass Beschränkungen wie OpenBaseDir trotzdem nicht immer verhindern können, dass andere Kunden auf dem System leiden müssen.


Um Überlast mit PHP zu erzeugen, brauche ich weder deaktiviertes open_basedir, noch Funktionen wie shell_exec() geschweigedenn "dicke" chmod-Rechte.
Und wieder: Das hat niemand behauptet.

chmod 777 kann jedoch recht förderlich für potentielle Angreifer sein. Denke nur mal an irgendwelche Scripte, die mit den Rechten 777 ausgestattet wurden und durch eine Lücke das Einschleußen von Code erlauben. Oder Config-Dateien, die umgeschrieben werden.

PS: openbasedir() lies sich in PHP 4.2.1 und 4.3 durch das Anlegen von Symlinks umgehen.

PSS: In PHP 4.4.7 und 5.2.3 liesen sich diverse PHP-Settings ebenfalls überschreiben. Allerdings benötigt man hierzu bereits die Möglichkeit, über eine andere Lücke schreibend auf das Verzeichnis zuzugreifen.

PSSS: Was denkst du was passiert, wenn jemand auf einmal zu Perl greift?
 
PSSS: Was denkst du was passiert, wenn jemand auf einmal zu Perl greift?
Enter mpm_peruser oder mpm_itk_chroot

Es gibt fuer alle Sicherheitsprobleme auf Userebene eine Loesung auf Serverebene, allerdings sind diese oft von kleinen (< 1000 Webspaces) Webhoster oft gar nicht oder nur sehr unzureichend eingepflegt.

Die chmod-Rechte schuetzen uebrigens nach einem erfolgreichen PHP-Exploit nicht da sich diese per PHP einfach umaendern lassen...
Gegen Serverueberlastung durch User helfen nur kernelbasierte Schwergewichte wie libcg - und das auch nur begrenzt
 
Last edited by a moderator:
PHP ist via open_basedir eingesperrt

Schlechtes Beispiel. Zum einen gilt das ganze nur für PHP, andere Sprachen wie Perl interessiert es nicht (und Perl ist bei vielen Hostern auch verbreitet). Zum anderen muß der Hosten auch einiges an Befehlen deaktivieren, denn sonst hat man auch die Möglichkeit, recht einfach aus dem Openbase-Dir auszubrechen. Und Openbasedir hatte in der Vergangenheit Lücken.
Einen sinnvollen Schutz bieten Mechnismen wie Suexec und entsprechend gesetzte Verzeichnisrechte - aber die lassen sich ändern, z.B. von Usern, die meinen, daß sie besser wissen, wie die Rechte ihres Home-Verzeichnis stehen müssen (ja, da spreche ich aus Erfahrung...)
 
Die Rechte eines ORDNERS zu ändern hat erstmal nichts damit zu tun, welche Rechte die Dateien IN diesem Ordner dann für Rechte haben. Dazu muss man schon eine rekursive Rechteänderung durchführen.

Welche Rechte bei welchem Provider richtig sind, ist schwierig zu sagen, denn die Konfiguration in welcher Gruppe der Webserver und in welcher der Nutzer ist, der die Files hochgeladen hat, kann variieren.
 
Letzte Frage (hoffentlich) :D
Einige Dateien haben ja verschiedene Rechte. Nun wollte ich alles so wie von euch empfohlen ändern aber zur Sicherheit die alten Werte kennen, sollte irgendwas schief gehen.

Alles notieren wäre viel zu umständlich. Ich hatte heute ein Backup geladen und wollte mal fragen, ob auch die Rechte gespeichert wurden oder den alten Standardwert angenommen haben? Geändert hatte ich alle Ordner und Dateien mit Filezilla.
 
Kommt auf die Sicherungsmethode an. Wenn du ganz klassisch tar einsetzt, werden sie mit ins Tar-Archiv geschrieben.
 
Ähm die Datenbank ist als .sql.gz gespeichert und der Rest (Dateien und Ordner) hatte ich einfach von Filezilla in einen Ordner kopiert.

Ach ich merke schon...ohne geht nicht. Habe jetzt ein Script gefunden, dass die Schreibrechte in eine Datei kopiert und wieder eingespielt werden kann. Mal schauen ob es auch klappt.
 
Also das Script funktioniert super. Habe jetzt alle Dateien und Ordner auf 644 bzw. 755 umgestellt aber viele Dateien bzw. Ordner ließen sich gar nicht verändern. :confused: Das obwohl ich ja Admin bin.

So weit ich jetzt alles geändert habe funktioniert auch noch alles aber das Plugin funktioniert immer noch nicht.

Ich glaube langsam, dass die Rechte des Hauptverzeichnisses schuld sind. Die kann ich nicht ändern, auch nicht im Kundencenter und da gab es schon mal Probleme mit. Was sind denn standard Rechte für das Hauptverzeichnis?
 
Ändere BLOSS NICHT die Rechte des Server Rootverzeichnisses :eek:, wenn Dir die Lauffähigkeit Deines Servers lieb ist. Wenn Du, womöglich noch rekursiv die Rechte von "/" änderst, kann es gut sein, dass Du dem System "lebenswichtige" Ordner und Dateien vorenthältst.
 
Hallo nochmals, ich hatte jetzt nochmal separat Wordpress und SMF auf dem selben Webspace installiert aber beide CMS in extra Ordner gelegt. Das Plugin lässt sich immer noch nicht installieren. :mad:
Das Problem muss doch am Webspace liegen. :mad:
Meint ihr ich könnte meinen Hoster anschreiben, das Problem kurz schildern und auf eine erweitere Freigabe hoffen?
 
Richtig aber außer Wordpress Path is not writable kann ich auch nicht sagen. Oder könntet ihr damit etwas anfangen.
 
Back
Top