19.02.2006
777-Saftyalert — Post vom Provider
Das Sicherheitsrisiko CHMOD 777 — das bedeutet, dass verschiedene Nutzer, die bestimmte Eigenschaften erfüllen, alles auf dem Server tun dürfen (lesen, schreiben, ausführen) — veranlasst so manchen Provider, dieses erst gar nicht zuzulassen. Doch habe ich bislang noch keinen Hinweis gefunden, warum Provider behaupten, dass weitere Kunden durch diese Rechtevergabe auf Ordner und Dateien gefährdet sind.
Was muss gegeben sein, dass CHMOD 777 zur Plage wird?
Es muss ein Script offen auf dem Server liegen, von dem aus auf den Server geschrieben werden kann, es muss ein offener FTP existieren, mit dem Dateien überschrieben werden können. CHMOD 777 alleine nützt soweit ich bislang rechieren konnte, niemandem etwas. Ich muss zunächst noch eine zweite Tür aufmachen, über die dann die durch CHMOD 777 geöffnete Räume umgestellt, ausgeräumt oder mit weiteren ungebetenen Skripten befüllt werden kann.
Das dieses Thema etwas heikel ist und Provider hier ein wenig empfindlich reagieren, ist sicherlich verständlich, denn es erfordert, dass Traffik kontrolliert werden muss. Nicht alle Provider bieten ein Monitoring und die Traffikbremse an. Wozu braucht man diese Traffikbremse. Nehmen wir an, jemand impft durch ein fehlerhaftes Skript auf Ihrem Server ein Skript mit dem von Ihrem Server aus eine Tauschbörse eingerichtet wird. Anschließend wird auf den Infoservern der Anbieter dieser Dienste mit viel Werbeeinnahmen wieder eine Liste rausgegeben, welche Server zur Verfügung stehen, eventuell gibt es sogar auf dem Infoserver ein Skript, das prüft, welche der so illegal geschaffenen Tauschbörsen-Server noch aktiv sind und welche schon vom Nutzer oder vom Provider wieder geschlossen wurden.
Doch dass so ein Modus 777 zur Falle werden kann, und man ein illegales Skript auf den Server setzen kann braucht es zunächst einmal eine offene Tür in Form eines Scriptes, dessen sich solche typen bedienen können.
Provider überbuchen ihre Server. Das heißt, würden alle auf dem Server ihre eingekauftes Nutzungsrecht bis zur Neige ausschöpfen, wäre der Server sehr schnell am Ende. Wie stark so ein Server überbucht ist und wie die Hostingprovider Backup-Systeme einsetzen, um Spitzen aufzufangen, wenn einmal auf zu vielen der gehosteten Plätze der Bär abgeht, ist von Provider zu Provider verschieden und an der Geschwindigkeit und Erreichbarkeit trennt sich die Spreu vom Weizen.
CHMOD 777 ist sogesehen für mich immer noch ein Feature und keine Sicherheitsrisiko. Das Sicherheitsrisiko ist das unsichere Skript. Wenn ich meine Schlüssel im offenen Wagen stecken lasse, wird mein Auto nicht unsicherer. Ich risikiere allerdings, dass nicht autorisierte Personen mein Fahrzeug nutzen. Tun sie das, wenn ich es ohnehin nicht nutze und fahren damit in eine Stau und verstopfen die Straßen noch mehr, sehe ich das nicht wirklich als mein Problem an, sondern eher als das Problem des Verkehrsleitsystem. Ich habe nur das Problem, dass ich den Sprit bezahlen muss und die Autosteuer.
Nimmt jemand das Fahrzeug, der damit in eine Fußgänger-Zone rauscht und zig Menschen tötet, dann ist das zwar denkbar, aber nicht wirklich wahrscheinlich. Wahrscheinlicher ist, dass ein jugendlicher Rabauke die Gelegenheit nutzt und dadurch ein erhöhtes Risiko entsteht. Mein Auto ist deswegen weder gefährlicher geworden, gefährlicher ist die Nutzungsmöglichkeit.
Ich muss also wenn ich darauf wert lege, dass ich jederzeit mit und ohne Hosentaschen für einen Autoschlüssel mein Fahrzeug bewegen kann, dafür sorgen, dass andere Sicherungsmaßnahmen greifen.
Zurück zu meinem Server und Sicherungsmaßnahmen. Wenn ich per CHMOD 777 sicherstellen möchte, dass mein FTP-User alles das kann, was auch der User WWWRUN darf (wwwrun heißt in der Regel der User, der die Rechte innehält, wenn ein Skript auf dem Server innerhalb eines Redaktionssystems), dann sollte ich sicherstellen, dass nur diejenigen das dürfen, die sich vorher auf andere Weise autorisiert haben und ich sollte für menschliche oder technische Unzulänglichkeit Routinen entwickeln, die die Daten davor schützen, dass diese versehentlich durch einen anderen User überschrieben werden. Im FTP geschieht das durch das Login. Man sollte den FTP nicht länger offen lassen als nötig. Und auch Skripte die Schreibfunktionen enthalten, sollten stets hinter Sicherheitstüren in Form eines Logins per htaccess gepackt werden.
Das nächste Sicherheitsrisiko ist das Browserfenster und Spyware auf Ihrem Rechner. Doch sowohl das Spionieren via Browserfenster, dass z.B. ein Script dafür sorgt, dass Sie die nächsten Seiten in einer Unterinstanz öffnen oder Malware, die jedes Bit und Byte protokollieren sind generell eine Gefahr und haben mit dem Risiko CHMOD 777 soviel zu tun wie der Dietrich oder das Brecheisen des Autodiebs mit dem Beispiel des Schlüssels im offenen Fahrzeug.
Ich lasse mich in der Angelegenheit Sicherheitsrisiko 777 gerne belehren. Doch ich sehe in 777 alleine kein Sicherheitsrisiko. Es sind wenige Zusatzsicherungen, die man beachten muss und sind in ähnlicher Weise zu sehen, wie die Funktion von Mailfunktionen in Programmiersprachen, die insbesondere in PHP in den letzten Wochen zu massiven Spamproblemen geführt haben. Hier wurden PHP-Mailformulare mit Skripten geimpft und zahlreiche Formulare mussten nachgrüstet werden mit Abfragen und Filtern um auszuschließen, dass Spammer via CC und BCC ihre Spammails in die Welt blasen.
Meine Empfehlung für Kunden von Providern, die kein 777 zulassen. Provider wechseln, denn zumindest ich genieße die Bequemlichkeit via FTP und HTTP auf Daten und Ordner frei zugreifen zu können. Welche Skripte aber in nicht durch htaccess geschützte Ordner kommen, sollte man dann doch ein wenig sorgsamer sein, bzw. selbst auf ein Monitoring des eigenen Webspaces zu achten, so dass man weiß, ob und wann sich Ungewöhnliches ereignet und ob das vielleicht an einem unsicheren Skript an falscher Stelle liegen könnte.
Filed under: Programmierung, Seitentypen
6 Comments
February 20th, 2006 at 23:53
[...] Dieser Artikel ist eine Antwort auf den Blogeintrag “777-Saftyalert — Post vom Provider” im Templaterie Blog. Der Artikel stellt die Frage, warum manche Provider es verbieten, die Zugriffsrechte von Dateien auf “777″ zu setzten. “Ich lasse mich in der Angelegenheit Sicherheitsrisiko 777 gerne belehren…” [...]
February 20th, 2006 at 23:58
Auch wenn es vielleicht nicht ganz stimmt, wenn Provider “777″ deshalb sperren um andere Nutzer zu schützen, so finde ich es trotzdem verantwortungsvoll. Außerdem, wer sagt, dass Deine und meine “krimilelle Energie†ausreicht, entsprechende Szenarien zu ersinnen. Vielleicht sind wir zu brav…
Ich habe mir dazu auf meinem Blog Gedanken gemacht >>
Die wirklich bösen Jungs und Mädels könnten sich noch viel schlimmere Dinge ausdenken…
March 5th, 2006 at 13:29
lies Dir mal folgenden Link durch und wenn Du dann noch ruhig bei 777 schlafen kannst, dann gute Nacht! http://www.linux-magazin.de/Artikel/ausgabe/2004/10/php/php.html amu
March 5th, 2006 at 15:33
[...] Ich wollte wissen, wie sicher oder unsicher CHMOD 777 ist. Ich hatte trotzt einiger Stunden kruschteln in Google und Foren und einiger heißer Diskussionen nichts erhellendes gefunden, was ich nicht schon gewußt hätte und was mir CHMOD777 allein schon als untragbares Risiko erscheinen ließ. Jetzt ist in den Kommentaren zum Beitrag ein Link beigetragen worden, der es verdient hat, weiter nach vorne zur Lektüre-Empfehlung zur Kenntnis gebracht zu werden: [...]
March 7th, 2007 at 19:58
Leider hab ich auch so ne Leuchte von Provider.
Joomla bekam erst Schreibrechte, nachdem ich chmod 777 benutzte. Nur den Benutzer oder die Gruppe reichte nicht.
Liegt wohl an den Richtlinien des Servers. Und da habe ich keine Chance etwas zu tun. htaccess wird ignoriert, egal was ich da reinschreibe.
Also läuft jetzt alles unter Total-Freigabe. ab dem http/ Ordner.
Es ist zwar sehr bedenklich, doch wie Silke schon sagte, es braucht noch einen weiteren Schritt damit jemand von Aussen die Daten verändern kann. z.B. Eine Sicherheitslücke im Script.
Jetzt lassen wir alles auf gut Glück mal laufen. Gibt es Probleme, wechseln wir den Provider.
March 7th, 2007 at 21:00
Vorsicht. CHMOD 777 und kein htaccess ist en Rezept zum Missbrauch. Es ist kein Scriptfehler, wenn Joomla den Upload von Daten gestatten.
CHMOD 777 oder 755, ein offenes Redaktionssystem , das ist wie ein offenes Fahrzeug mit Schlüssel auf einer italienischen Piazza. Es ist nicht eine Frage, dass das Auto gestohlen wird, nur eine Frage wann.
Ein Redaktionssystem benötigt Schreibrechte auf dem Server um die Texte zu ändern. In der Regel haben diese Programme eine wirklich sinnvolle Option, um Daten auf den Rechner zu laden. Das heißt, Redaktionssysteme können nur dort eingesetzt werden, wo auch die Möglichkeit besteht, Userrechte einzuschränken. Dies passiert entweder über die Skripte selbst, besser noch durch htaccess.
Gelegentlich können diese Einschränkungen der Nutzungsrechte nur über die Administration, die die Provider zur Verfügung stellen, eingerichtet werden. Sollte das auch nicht der Fall sein, bleibt nur das Paket bzw. den Provider zu wechseln. Es würde mich aber sehr wundern, wenn ein Provider A 777 zu lässt und B die Beschränkung der Nutzungsrechte unterbindet.