Die (Un-)Sicherheit mit chmod 777

Achtung: Diese Seite ist nur noch Teil eines Archivs und wird in Zukunft entfernt.

Jeder, der selbst einen Webspace hat, sollte das Wort "chmod" schon einmal gehört haben. Gemeint sind damit die Berechtigungseinstellungen von Ordnern und Dateien. Diese setzen sich meistens über die Zahlen 4, 5, 6 und 7 zusammen, so z.B. 777. Genauere Erklärungen gibt es zuhauf im Web, darauf werde ich nun nicht genauer eingehen.

Worauf ich aber eingehen werde, ist die Tatsache, dass man häufig böse Blicke oder Bemerkungen erhält, sofern man vielen Dateien und Ordnern chmod 777 geben soll, also volle Berechtigungen aller Benutzer.
Hier ist es für viele ganz eindeutig: Man lässt zu, dass wirklich jeder Benutzer, sprich wir, jede Datei und jeden Ordner beliebig ändern kann. Das ist aber eine grobe Fehleinschätzung von Benutzern, die den chmod nicht richtig verstanden haben. Ja, es ist durchaus so, dass jeder Benutzer dir Dateien und Ordner abändern kann, allerdings bezieht sich der chmod auf Systembenutzer, die im System selbst angelegt sind. Ein Benutzer, wie es häufig verstanden wird, also ein Internetnutzer, kann erst dann die Dateien ändern, wenn er Zugriff auf einen Systembenutzer hat. Ist es schon so weit gekommen, ist der chmod praktisch egal, da man dann den chmod umgehen kann.

Dass Sicherheitslücken durch den chmod 777 geöffnet werden, stimmt. So kann wirklich jeder Systembenutzer die Dateien beliebig bearbeiten. Angriffe werden jedoch zumeist so durchgeführt, dass der Einbrecher bereits mit dem Systembenutzer in das System eindringt, welchem die Dateien gehören. Damit wäre dann jeglicher anderer chmod egal.

Hat man z.B. für den Webserver und den FTP-Server den gleichen Systembenutzer, so kann man auch allen Dateien chmod 644 und allen Ordnern chmod 755 geben und alles würde funktionieren. Es kommt lediglich auf die Konfiguration der Systembenutzer an, nicht auf die Benutzer, die man auf dem Server auch als Besucher der Website z.B. betrachtet.
Über den Autor
Ich bin Webentwickler in Stuttgart und administriere Server seit vielen Jahren. In diesem Blog erstelle ich hauptsächlich Tutorials für andere Webentwickler, Webdesigner und Serveradministratoren.
-------------------------------------------------------------------------------------------------------------------------------------
I’m a web developer in Stuttgart, Germany, and server administrator since many years. This blog mainly contains a tutorial set for other web developer, web designer and server administrators.

5.686 mal gelesen

Kommentare 11

  • Black Rider -

    Alles klar! Ich werde die genannte Aussage so gut es geht entschärfen. Danke für den Feedback!

  • Chasil -

    Wir brauchen bald einen Chat...

    Kernaussage, die ich treffen möchte, ist folgende:
    "Dass aber Sicherheitslücken durch den chmod 777 geöffnet werden, stimmt definitiv nicht." Diese Aussage ist falsch und ein unerfahrener Leser wird das eventuell glauben. Gibt man jedem Systemuser Schreibrechte, erhöht man automatisch das Risiko, egal wie gering es sein mag, und hat dadurch eine potentielle Sicherheitslücke geschaffen.

    Wenn du mit User X eine Datei im Verzeichnis von Y anlegst (was genau das Problem ist), ist klar, dass User Y das löschen kann. Es ist ja sein Ordner, in dem du da geschrieben hast. Dein Szenario sollte so aussehen, dass User Y eine Datei von X im Verzeichnis von X löscht oder bearbeitet. Wenn das geht, ist was falsch. Außer du möchtest, dass Y das darf und das sollte dann über die Gruppenregelung laufen und nicht über die Others-Regel -> 775.

    Moderne Software bietet meist mehrere Möglichkeiten an, um das Schreiben zu ermöglichen. Man muss nicht zwingend den Webserver berechtigen. Es gibt auch gute und sichere Methoden, PHP im CGI/FastCGI zu betreiben, sodass Scripte nur als der User ausgeführt werden (suexec), dem sie gehören. Dadurch ermöglicht man Schreibzugriffe, verhindert mit passender Berechtigung aber die Datenmanipulation von anderen System-Usern. Dadurch lässt sich sogar eine 700 Berechtigung realisieren, sodass wirklich kein anderer User Daten auch nur auslesen kann. (Kein weiterer Schutz für PHP-Scripte notwendig)

    Genug der vielen Worte im Rahmen von Kommentaren. Ich habe einiges zusammen geschrieben und kann nur hoffen, dass nicht zu großzügig mit Berechtigungen umgegangen wird. Wir sind schon sehr im Detail und werden die Leser dadurch abhängen, die sich eben nicht mit der Materie auskennen (und genau die sollen gewarnt sein). Sichere Konfiguration ist kein Hexenwerk, bedarf oftmals einfach nur etwas mehr Zeitaufwand als eine unsichere Konfiguration. Jeder muss selbst wissen, wie viel Aufwand ein sicherer Server wert ist.

  • Black Rider -

    Dann stell ich mir aber die Frage, wie genau du derlei Updates bei chmod 755 installieren willst, wenn Apache unter Benutzer X läuft, die Dateien aber Benutzer Y gehören. Damit hat der Apache keine Schreibrechte und kann damit auch keine eigenen Dateien anlegen. Das wird aber ebenfalls von vielerlei Software zu Zwecken des Cachings benötigt.

    Ich glaube kaum, dass du keine Ahnung hast, denn sonst hättest du dich gar nicht zu dieser Diskussion hinreißen lassen.

    Bisher ist es zudem auch aus diversen Gründen viel leichter, sich über FTP Zugriff zu holen und dann wäre man praktisch schon der Benutzer, dem die Dateien gehören und kann sie beliebig bearbeiten.

    Letztendlich kommt es meiner Meinung nach eher darauf an, das System soweit abzusichern, dass ein Einbrecher gar nicht die Möglichkeit hat, ein Systembenutzer zu werden.

    Ist man erst einmal im System, kann man in eigenen Verzeichnissen dennoch Dateien löschen. Eben in einem Testszenario ausprobiert:
    Mit Benutzer X eine Datei test.file in Verzeichnis /xv von Benutzer Y erstellt. Selbige mit chmod 700 ausgestattet. Eigentümer: Benutzer X:Gruppe X
    Mit Benutzer Y eingeloggt und einfach per "rm" die Datei gelöscht. Das einzige Hindernis ist eine Abfrage, ob man die schreibgeschützte Datei wirklich löschen will. Das muss man lediglich bestätigen.

    Wenn demnach, wie es oft der Fall ist, ein Ordner vom Webserver angelegt wurde und sich darin Kundendateien befinden, kann der Einbrecher, sobald er Zugriff auf den Webserver hat, jegliche Dateien darin löschen, egal wie deren chmod ist.

    Und da eine Software, sollte sie nicht über FastCGI und damit eventuell mit einem anderen Benutzer laufen, fügt ihre eigenen Ordner immer mit dem Webserver-Benutzer hinzu.

  • Chasil -

    Sicherlich gibt es Leute, die mehr Ahnung haben. Aber trotzdem glaube ich, dass ich noch genug habe, um das zu beurteilen. Ich betreibe komplexere Serversysteme beruflich und habe auch den ein oder anderen Root-Server im Zugriff, auf dem ich mich um solche Themen kümmere. ;)

    Ich will garnicht abstreiten, dass Leserechte und Ausführungsrechte notwendig sind. Aber eine 777 Vergabe ist dann nunmal falsch, da diese auch Schreibrechte beinhaltet. Ein korrekt konfigurierter Apache ist durchaus in der Lage auch ohne eine 777 Vergabe Updates zu installieren. Wenn es nicht geht, ist die Software falsch konfiguriert. Eine 777 Vergabe hilft, ist aber nun mal falsch, da es nur ein Workaround ist und man damit Tür und Tor öffnet.

    Im Worst-Case bin ich in der Lage bei deinem Provider eine Domain zu registrieren und lande auch noch auf der Büchse, auf der deine Domain läuft. Je nach Konfiguration kann ich aus meinem Home-Folder via PHP-Script ausbrechen und vll. sogar in dein Verzeichnis kommen. Dort komme ich dann vll. auch noch an diverse Files und kann diese auch noch mit meinen Scripten überschreiben, da die Berechtigung von 777 mir das nun mal auch erlaubt. Mir ist schon klar, dass das viele "Wenns" beinhaltet. Aber denkbar ist so ein Angriffsszenario. Und dafür musste ich dann vll. nur eine 2Euro-Domain registrieren.

    Es gibt immer mehr Cyber-Kriminalität und je komplexer die Technik wird, desto mehr potentielle Sicherheitslücken gibt es. Da braucht man es dem Hacker doch nicht noch einfacher machen.

    777 ist unsicher! Wer was anderes behauptet, kennt sich nicht aus. Und als Author ist man eine Art "Vorbild" für den Leser und sollte sicher keine unsicheren Konfigurationen befürworten und deren Sicherheitsrisiko unterbewerten. Selbst wenn es Software gibt, die das wirklich braucht: Es ist ein Risiko. Wie man mit diesem Risiko umgeht ist allerdings jedem selbst überlassen.

  • Black Rider -

    Dann scheint mir aber, dass du heutige auf Webspaces betriebene Software nicht mehr kennst. Bei diesen ist es kaum noch möglich, eine derart restriktive Rechteeinstellung zu nutzen, ohne dass die Software dabei Funktionen verliert.

    Allein für die Nutzung sind Lesen und Ausführen oftmals notwendig. Will man dann auch noch funktionierende Updates o.ä., benötigt man auch zwingend Schreibrechte.

    So wie du sagst, soll alles unter anderen Benutzern laufen, was durchaus richtig ist. Das Problem ist dann jedoch, dass nicht jeder Benutzer auf die Dateien zugreifen könnte, es aber sollte.

  • Chasil -

    Hi!

    Leider ist das nicht ganz richtig.

    Ein Hacker ist nicht in der Lage sich kurzer Hand Rechte auf dem System anzueignen (Außer es gibt auch hierfür Sicherheitslücken im System). Es ist eine Sache in ein System über Schwachstellen einzusteigen und eine ganz andere sich dann Rechte anzueignen.

    Der Apache sollte nach Empfehlungen unter einem User laufen, der keinerlei Rechte hat. Sollte der Angreifer irgendwie den Apache (und damit PHP) übernehmen, besteht keine Gefahr, da der Apache einem User A gehört, allerding mit einem User B betrieben wird (Der keine Rechte hat) und dadurch nichts am System anstellen kann.

    Der FTP sollte so eingestellt sein, dass er wieder über einen anderen System-User läuft. Das hat ja erstmal nichts damit zu tun, wer den FTP nutzen kann. Der Apache wiederum braucht lediglich Leserechte um die abgelegten Daten ausliefern zu können.

    Ich verstehe, dass eine Berechtigung von 777 einiges vereinfacht und es für den ein oder anderen so aussieht, als wäre dies die einzige Möglichkeit. Dem ist aber nicht so. Es ist auf keinen Fall Ratsam eine Berechtigung auf 777 zu setzen!

    I.d.R. reicht es aus, wenn der User Schreibrechte hat. 755 verhindert zumindest, dass nicht jeder die Daten manipulieren kann. Hat man Passwörter oder etwas anderes wichtiges in seinen PHP-Daten gespeichert, sollte es eher so 750, wenn nicht gar so 700 aussehen.

    Ich vergleiche das gerne mit einem Mehrfamilienhaus. Nur weil der Flur abgeschlossen ist, müssen nicht alle Wohnungstüren offen stehen. Der Einbrecher wohnt zwar nicht im selben Haus, aber sollte er doch mal durch ein offenes Fenster in eine der Wohnungen einsteigen können, kann er auch gleich in alle anderen Wohnungen rein. Wären die Türen abgeschlossen, hätte der Einbrecher wahrscheinlich nur eine Wohnung leer geräumt.

    Sorry für den langen Text, aber Sicherheit sollte man wirklich nicht auf die leichte Schulter nehmen. Ich meins nur gut ;)

    Gruß

  • Black Rider -

    Das Problem bei unterschiedlichen Benutzern für Webserver, PHP etc. ist jedoch, dass hier ein entsprechend hoher chmod benötigt wird, damit die Software auch ihre Dateien lesen kann.

    Hat man dann auch noch einen zusätzlichen FTP-Benutzer, braucht dieser auch noch die richtigen Berechtigungen, um etwas mit den Daten anfangen zu können.

    Daher ist es kaum möglich, mit einem kleineren chmod zu arbeiten, auch wenn es wünschenswert ist.

    Letztendlich ist es für einen Hacker, der einmal auf dem System ist, aber auch nicht wirklich weiter schwer, sich entsprechende Rechte anzueignen, um die Dateien beliebig zu manipulieren. ;)

  • Chasil -

    Hi!

    Dir ist aber schon bewusst, dass eine Berechtigung von 777 durchaus Sicherheitslücken öffnet? Ein ordentliches Userkonzept auf Systemebene setze ich voraus.

    Sollte sowieso jeder Service über den gleichen User arbeiten, gebe ich dir recht: chmod 777 macht da garnichts, denn wenn ein Hacker oder sonst wer einbricht, ist es eh zu spät. Verschiedene Dienste/Services sollten nicht unter dem gleichen User betrieben werden.

    Hat man ein ordentliches Userkonzept und ein Hacker dringt in einen der Systemuser ein, bleiben zumindest die Daten der anderen User weiter geschützt, sofern man keine 777-Vergabe hat.

    Jeder User, also auch Leser des Blogs, nutzen den Systemuser des Webservers. Sollte es also eine Schwachstelle im Webauftritt geben, durch den der Leser den Systemuser ausnutzen kann, kann er selbstverständlich auch alle Daten manipulieren, wenn man zu großzügig mit seinen Berechtigungen umgegangen ist.

    Regel: So wenig wie möglich, so viel wie nötig!

    Gruß

  • Lantash (Martouf) -

    Moin, danke muss sagen hatte denselben Gedanken bezüglich Sicherheit. Schön zu wissen das es genau andersrum ist.

  • Black Rider -

    Gerne doch ;)
    Ich habe es jetzt so oft schon immer wieder mal im WoltLab Support Forum gelesen, dass sich Leute beschwerten, da musste ich es mal aufschreiben :D

  • kurtextrem -

    Danke für die Aufklärung ;)