Hosting-Optionen
Bei den Hosting-Optionen für eine Website-Site handelt es sich im Allgemeinen um eine der folgenden Optionen:
- dedizierter Server
- Virtual Private Server (VPS)
- Shared Hosting
Mit einem dedizierten Server wird nur ein Standort auf einem physischen Computer gehostet, und die Konfiguration ist so sicher wie der Computer selbst.
Mit einem VPS wird Ihre Software auf demselben physischen Computer ausgeführt wie die virtuellen Maschinen anderer Benutzer. Es entspricht jedoch funktional einem dedizierten Server. Am wichtigsten ist, dass ein VPS die Privatsphäre und Sicherheit eines dedizierten Servers hat.
Mit Shared Hosting befindet sich Ihre Website in einem Dateisystem, das für andere Benutzer freigegeben ist. Dies macht es leider weniger sicher als auf einem dedizierten Server oder VPS. Der Rest dieses Artikels beschreibt die Sicherheit eines WCMS in einer gemeinsam genutzten Hosting-Umgebung.
Umgebung
Eine gemeinsam genutzte Hosting-Umgebung besteht aus einem Webserver, einem Dateisystem, einer Einstellungsdatei, einer Datenbank und einigen Benutzern.
In den folgenden Beispielen wird davon ausgegangen, dass das Besitzerkonto "tom" lautet und die Einstellungsdatei (die die Anmeldeinformationen der Datenbank enthält) den Namen "settings.php" trägt.
Der Webserverprozess kann je nach Konfiguration mit den Benutzerberechtigungen des Besitzerkontos "tom" oder mit den Gruppenberechtigungen der Gruppe "www" ausgeführt werden.
Außerdem wird eine Gnu / Linux- oder Unix-Standardumgebung vorausgesetzt, und es wird davon ausgegangen, dass der Leser das Unix-Zugriffskontrollsystem mit separaten Lese-, Schreib- und Ausführungs- / Zugriffsberechtigungen für Verzeichnisse (x) versteht, die in drei Blöcke unterteilt sind (Benutzer, Gruppe, andere).
Bevor ich auf bestimmte Einstellungen eingehe, kann es hilfreich sein, die Bedingungen aufzulisten, die wir erfüllen möchten:
- Damit eine Website funktionsfähig ist, muss der Webserver Lesezugriff auf alle Dateien haben, aus denen die Website besteht, und muss auf Verzeichniszugriff auf alle Verzeichnisse zugreifen, aus denen die Website besteht.
- Für einen sicheren Betrieb darf der Webserver keinen Schreibzugriff auf die von ihm verarbeiteten Dateien haben.
- Für einen sicheren Betrieb darf ein von einem betrügerischen Benutzer ausgeführtes Web-Skript keinen Lesezugriff auf die Dateien eines anderen Benutzers haben.
- Damit der Eigentümer mit der CLI auf seiner eigenen Website arbeiten kann, muss der Benutzer über Lese- und Schreibzugriff auf seine eigenen Dateien verfügen .
- Um zu verhindern, dass andere Benutzer über die CLI auf die Dateien zugreifen, sollten für den Block "other" keine Berechtigungen festgelegt sein.
Leider können Sie auf einem gemeinsam genutzten Host nur 4 von 5 haben. Ich weiß nicht, wie Sie alle fünf Bedingungen auf einem gemeinsam genutzten Host erfüllen können .
Soweit ich weiß, werden von Anbietern gemeinsam genutzter Hosts zwei verschiedene Konfigurationen verwendet. Beide werden im Folgenden erläutert, zusammen mit den Berechtigungen, mit denen Dateien und Verzeichnisse am besten geschützt werden können, und der Bedingung, die die Konfiguration nicht erfüllt.
Konfig 1: Webserver läuft als Eigentümer
Dies ist AFAIK die am häufigsten verwendete Konfiguration. Der Webserver wird als Eigentümer der Dateien ausgeführt. Dies bedeutet, dass ein betrügerischer Benutzer seinen Webserver-Benutzer nicht zum Ausführen eines Skripts zum Lesen der Dateien eines anderen Benutzers verwenden kann. Diese Art der Konfiguration schützt Benutzer in der CLI auch voreinander.
Dies bedeutet jedoch auch, dass wir keine separaten Berechtigungen für den Eigentümer und den Webserver haben können. Um die Bedingung 2 bei dieser Art der Einrichtung zu erfüllen, müssen Sie die Schreibberechtigungen für den Eigentümer einschränken, um den Schreibzugriff für den Webserver auf alles außer dem Upload-Verzeichnis zu verhindern.
Berechtigungen:
Directories: 500 r-x --- --- tom.tom
Files: 400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.: 700 rwx --- --- tom.tom
Dies bedeutet leider, dass die Bedingung 4 nicht erfüllt werden kann. Dh die Site kann nicht über die CLI gewartet werden. Der Eigentümer ist gezwungen, für den Zugriff auf die Site ein webbasiertes Dashboard zu verwenden (meine Empfehlung lautet, dass der Eigentümer eine Kopie auf einem Staging-Server mit uneingeschränktem Zugriff verwaltet und die auf dem Staging-Server vorgenommenen Änderungen auf den freigegebenen Host spiegelt ).
Config 2: Der Webserver wird als Mitglied der WWW-Gruppe ausgeführt
Diese Konfiguration wird von einigen (IMHO) weniger professionellen Anbietern einer gemeinsam genutzten Host-Lösung verwendet. Der Webserver wird als Mitglied der WWW-Gruppe ausgeführt und erhält den erforderlichen Lesezugriff über den Gruppenblock:
Berechtigungen:
Directories: 750 rwx r-x --- tom.www
Files: 640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.: 770 rwx rwx --- tom.www
Diese Einstellungen bieten den Vorteil, dass der Besitzer über die CLI uneingeschränkten Zugriff auf seine Dateien hat und der Webserver nur über Lesezugriff verfügt.
Es wird jedoch auch die Bedingung 3 nicht erfüllt. Das heißt, ein betrügerischer Benutzer auf dem gemeinsam genutzten Host (oder ein Hacker, der die Site eines anderen Benutzers, der den Host gemeinsam nutzt, kompromittiert hat) kann ein Skript ausführen, um alle Dateien zu lesen, die vom gelesen werden können Webserver. Dies gibt dem Schurken-Skript Zugriff auf die Datei settings.php mit den Datenbankanmeldeinformationen, was es trivial macht, die Site vollständig zu übernehmen.
Meine Empfehlung ist, diese Art der Konfiguration zu vermeiden.
Nachtrag: Wie gefährlich ist die Verwendung eines gemeinsam genutzten Hosts?
Ich würde auf keinen Fall sensible Daten wie Kreditkartennummern oder Krankenakten auf einen gemeinsam genutzten Host übertragen. Aber Shared Hosting ist billig und hat eine Attraktion. Ich selbst verwende Shared Hosting für mehrere meiner Websites. Ich wurde noch nicht gehackt, aber ich weiß, dass das Risiko besteht und ich bin auf den Tag vorbereitet, an dem es passiert. Wenn ich gehackt werde, lösche ich einfach alles auf dem freigegebenen Host und installiere die Site neu von einer Spiegelkopie, die ich auf einem sicheren Staging-Server verwahre.
Bei "config 2" sind die anderen das Hauptproblem . Wenn eine andere Website, für die Sie den Host freigeben, gefährdet wird, wird Ihre Website ebenfalls zum Mittagessen. Es ist keine gute Idee, die Sicherheit von einer anderen Partei abhängig zu machen, die Sie nicht kennen und über die Sie keine Kontrolle haben. Aus diesem Grund empfehle ich, Hosting-Arrangements vom Typ "config 2" zu vermeiden.
Mit "config 1" steuern Sie allein die Sicherheit Ihrer Website. Dies ist besser (insbesondere wenn Sie wissen, was Sie tun). Aber es ist nicht narrensicher. Niemand ist perfekt, und wenn Sie einen Fehler machen und Ihre Website kompromittiert ist, hat der Angreifer Zugriff auf alle Dateien, die auf dem Host gespeichert sind, der Ihnen gehört. Mit anderen Worten, um den Schaden zu minimieren, den Sie bei einem Hacking erleiden, sollten Sie auf diesem Host nichts aufbewahren , was Schaden anrichten würde, wenn jemand anderes auf ihn zugreifen würde. Insbesondere dürfen nicht halten Sie Ihre E - Mail auf diesem Hostern. In E-Mails sind normalerweise Unmengen vertraulicher Daten enthalten, sodass Sie nicht möchten, dass diese in der Nähe eines Webservers als "Sie" ausgeführt werden.
Und wenn Ihre Webanwendung sensible Daten verarbeitet, stellen Sie sicher, dass in Ihrem Budget ein dedizierter Host oder ein VPS vorgesehen ist.
Möglicherweise möchten Sie auch dieses Handbuch zum Sichern von Dateiberechtigungen und -eigentum auf Drupal.org lesen.