Geteiltes Hosting und Sorgen um die Sicherheit? Folgendes müssen Sie wissen:

Werbung

Shared Hosting. Es ist die billige Option, nicht wahr? Und für einen großen Teil der Bevölkerung ist es alles, was sie jemals brauchen werden, um ihre Website oder Webanwendung zu hosten. Und wenn es gut gemacht ist, ist Shared Hosting skalierbar, schnell und sicher.

Aber was passiert, wenn es nicht gut gemacht wird?

Nun, dann schleichen sich gefährliche Sicherheitsprobleme ein. In diesem Fall besteht die Gefahr, dass Ihre Website unkenntlich gemacht wird oder die von Ihnen gespeicherten privaten Daten verloren gehen. Aber ärgere dich nicht. Die überwiegende Mehrheit der Webhosts verfügt über angemessene Sicherheitsmaßnahmen. Es sind nur die nächtlichen Schnäppchen-Gastgeber, vor denen Sie vorsichtig sein müssen.

Wir empfehlen Shared Hosting von InMotion Hosting mit SSD-Speicher.

Wir werden die Sicherheitsprobleme im Zusammenhang mit Shared Hosting untersuchen. Lassen Sie uns zunächst darüber sprechen, was eine Shared Hosting-Plattform sicher macht.

Was macht einen sicheren Webhost aus?

In Bezug auf Shared Hosting sollten einige herausragende Sicherheitsaspekte berücksichtigt werden.

• Jeder Benutzer auf dem Server sollte von anderen Benutzern isoliert sein und nicht auf die Dateien anderer Benutzer zugreifen oder diese ändern können.
• Eine Sicherheitslücke in der Logik einer auf dem Server gehosteten Website sollte keine Auswirkungen auf andere Benutzer haben können.
• Der Server wird regelmäßig gepatcht, aktualisiert und überwacht, um Sicherheitsprobleme in der Architektur zu beheben.
• Jeder Benutzer sollte über einen eigenen isolierten Datenbankzugriff verfügen und keine Änderungen an den gespeicherten Datensätzen oder Tabellenberechtigungen anderer Benutzer vornehmen dürfen.

Auch hier erfüllen die meisten Webhosts diese Anforderungen für ihre gemeinsamen Angebote. Wenn Sie jedoch mehrere Websites auf einem Server hosten möchten oder neugierig sind, wie sich Ihr Hosting-Unternehmen entwickelt, Oder denken Sie sogar daran, ein eigenes Hosting-Unternehmen zu gründen, und möchten Sie herausfinden, wie Sie Ihre Benutzer schützen können. Dann lesen Sie bitte auf.

Aber zuerst ein Haftungsausschluss

Bevor wir uns mit den üblichen Angriffen auf Shared Hosting befassen, möchte ich nur darauf eingehen Geben Sie an, dass dieser Beitrag keine vollständige Liste potenzieller Sicherheit darstellt (und nicht als solche gelesen werden sollte) Probleme.

Sicherheit ist mit einem Wort groß. Es gibt viele Möglichkeiten, wie Sie eine Website gefährden können. Dies gilt doppelt für Shared Hosting. Es war nie geplant, sie in einem einzigen Artikel zu behandeln.

Wenn Sie in Bezug auf Ihre Sicherheit paranoid sind, besorgen Sie sich einen VPS oder einen dedizierten Server. Dies sind Umgebungen, in denen Sie (größtenteils) die absolute Kontrolle darüber haben, was vor sich geht. Wenn Sie sich bei den verschiedenen Arten von Webhosting nicht sicher sind, Schauen Sie sich diesen Beitrag an Die verschiedenen Formen des Website-Hostings erklärt [Technologie erklärt] Weiterlesen von meinem Kollegen James Bruce.

Ich sollte auch betonen, dass dieser Beitrag nicht als Angriff auf Shared Hosting ausgelegt werden darf. Es handelt sich vielmehr um einen rein akademischen Blick auf die Sicherheitsaspekte dieser Kategorie von Webhosting.

Verzeichnisdurchquerung

Beginnen wir mit Directory Traversal-Angriffen (oft als "Path Traversal" bezeichnet). Mit dieser Art von Angriff können Sie auf Dateien und Verzeichnisse zugreifen, die außerhalb des Webstamms gespeichert sind.

In reinem Englisch? Stellen wir uns vor, Alice und Bob verwenden denselben Server zum Hosten ihrer Websites. Alices Dateien werden in / var / www / alice gespeichert, während Bobs Dokumente in / var / www / bob zu finden sind. Stellen wir uns außerdem vor, es befindet sich ein anderer Ordner auf dem Server (/ usr / crappyhosting / myfolder). Darin befindet sich eine unverschlüsselte Klartextdatei (wir nennen sie pwd.txt), die Systembenutzernamen und enthält Passwörter.

Bis jetzt bei mir? Gut. Stellen wir uns nun vor, die Website von Bob liefert lokal generierte PDF-Dateien, auf die in der URL verwiesen wird. Etwas wie:

http://example.com/file?=report.pdf

Was würde passieren, wenn ich die Datei "report.pdf" durch einige UNIX-Parameter ersetzen würde, die das Verzeichnis ändern?

http://example.com/file?=../alice/

Wenn der Server falsch konfiguriert ist, können Sie auf diese Weise das Dokumentenstammverzeichnis von Alice anzeigen. Interessant, aber wir sind viel mehr an dieser saftigen Passdatei interessiert. Accio-Passwörter!

http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt

So einfach ist das wirklich. Aber wie gehen wir damit um? Das ist einfach.

Hören Sie jemals von einem wenig bekannten Linux-Dienstprogramm namens chroot? Sie haben wahrscheinlich bereits erraten, was es tut. Dadurch wird das Linux / UNIX-Stammverzeichnis auf einen beliebigen Ordner festgelegt, sodass Benutzer ihn nicht beenden können. Effektiv werden Directory Traversal-Angriffe in ihren Tracks gestoppt.

Es ist schwer zu sagen, ob Ihr Gastgeber dies eingerichtet hat, ohne gegen das Gesetz zu verstoßen. Zum Testen würden Sie schließlich auf Systeme und Dateien zugreifen, auf die Sie nicht zugreifen dürfen. In diesem Sinne ist es möglicherweise sinnvoll, mit Ihrem Webhost zu sprechen und sich zu erkundigen, wie er seine Benutzer voneinander isoliert.

Betreiben Sie Ihren eigenen Shared Hosting Server und verwenden Sie chroot nicht, um Ihre Benutzer zu schützen? Zugegeben, das Chrooten Ihrer Umgebungen kann schwierig sein. Zum Glück gibt es eine Fülle von Plugins, die dies einfach machen. Schauen Sie sich insbesondere mod_chroot an.

Befehlsinjektion

Kommen wir zurück zu Alice und Bob. Wir wissen also, dass Bobs Webanwendung einige… Ähm… Sicherheitsprobleme enthält. Eine davon ist die Sicherheitsanfälligkeit bezüglich Befehlsinjektion, mit der Sie ausgeführt werden können beliebige Systembefehle Eine Kurzanleitung für den Einstieg in die Linux-BefehlszeileMit Befehlen unter Linux können Sie viele erstaunliche Dinge tun, und es ist wirklich nicht schwer zu lernen. Weiterlesen .

Auf der Bob-Website können Sie eine whois-Abfrage auf einer anderen Website ausführen, die dann im Browser angezeigt wird. Es gibt ein Standard-HTML-Eingabefeld, das einen Domänennamen akzeptiert und dann den Befehl whois system ausführt. Dieser Befehl wird ausgeführt, indem der PHP-Befehl system () aufgerufen wird.

Was würde passieren, wenn jemand den folgenden Wert eingeben würde?

example.com && cd ../alice/ && rm index.html

Lassen Sie es uns zusammenfassen. Einige davon sind Ihnen vielleicht bekannt, wenn Sie unsere gelesen haben ‘Erste Schritte für Linux’ Erste Schritte mit Linux und UbuntuSie möchten auf Linux umsteigen... aber wo fängst du an Ist Ihr PC kompatibel? Funktionieren Ihre Lieblings-Apps? Hier finden Sie alles, was Sie wissen müssen, um mit Linux zu beginnen. Weiterlesen E-Book, das wir bereits 2010 veröffentlicht haben oder das wir uns angesehen haben Linux Command Line Cheat Sheet.

Zunächst wird eine whois-Abfrage auf example.com ausgeführt. Dann würde es das aktuelle Arbeitsverzeichnis in Alices Dokumentenstamm ändern. Dann würde die Datei mit dem Namen "index.html" entfernt, die die Indexseite ihrer Website darstellt. Das ist nicht gut. Nein Sir.

Wie können wir als Systemadministratoren dem entgegenwirken? Wenn wir zum vorherigen Beispiel zurückkehren, können wir jeden Benutzer immer in seine eigene isolierte, bereinigte, chrootierte Umgebung versetzen.

Wir können dies auch von einer Sprachebene aus angehen. Es ist möglich (obwohl dies zu Problemen führen kann), Funktionsdeklarationen global aus Sprachen zu entfernen. Das heißt, es ist möglich, Funktionen aus den Sprachen zu entfernen, auf die Benutzer Zugriff haben.

Insbesondere bei PHP können Sie Funktionen mit Runkit entfernen - dem offiziellen PHP-Toolkit zum Ändern der Funktionalität der Sprache. Es gibt eine Fülle von Dokumentationen. Lies hinein.

Sie können auch die Konfigurationsdatei von PHP (php.ini) ändern, um Funktionen zu deaktivieren, die häufig von Hackern missbraucht werden. Öffnen Sie dazu ein Terminal auf Ihrem Server und öffnen Sie Ihre Datei php.ini in einem Texteditor. Ich benutze gerne VIM, aber NANO ist auch akzeptabel.

Suchen Sie die Zeile, die mit disable_functions beginnt, und fügen Sie die Funktionsdefinitionen hinzu, die Sie sperren möchten. In diesem Fall wäre es exec, shell_exec und system, obwohl es erwähnenswert ist, dass es andere integrierte Funktionen gibt, die von Hackern ausgenutzt werden können.

disable_functions = exec, shell_exec, system

Sprach- und Dolmetscherangriffe

Schauen wir uns also PHP an. Dies ist die Sprache, die eine erstaunliche Anzahl von Websites unterstützt. Es kommt auch mit einer Reihe von Eigenheiten und seltsamen Verhaltensweisen. So was.

PHP wird normalerweise in Verbindung mit dem Apache-Webserver verwendet. Mit dieser Konfiguration ist es größtenteils unmöglich, mehrere Versionen der Sprache zu laden.

Warum ist das ein Problem? Stellen wir uns vor, Bobs Webanwendung wurde ursprünglich im Jahr 2002 erstellt. Das ist lange her. Damals, als Michelle Branch noch die Charts anführte, spielte Michael Jordan noch für die Washington Wizards und PHP war eine ganz andere Sprache.

Aber Bobs Website funktioniert immer noch! Es verwendet eine ganze Reihe von eingestellten und veralteten PHP-Funktionen, aber es funktioniert! Die Verwendung einer modernen Version von PHP würde die Website von Bob effektiv beschädigen. Warum sollte Bob seine Website neu schreiben, um den Launen seines Webhosts gerecht zu werden?

Dies sollte Ihnen eine Vorstellung von dem Dilemma geben, mit dem einige Webhosts konfrontiert sind. Sie müssen das Gleichgewicht halten, um einen architektonisch soliden und sicheren Service zu gewährleisten und dies im Einklang mit der Zufriedenheit der zahlenden Kunden zu halten.

Daher ist es nicht ungewöhnlich, dass kleinere, unabhängige Hosts ältere Versionen des PHP-Interpreters (oder einer anderen Sprache) verwenden.

Es ist nicht ungewöhnlich, dass kleinere, unabhängige Hosts ältere Versionen von PHP verwenden, wodurch Benutzer möglicherweise Sicherheitsrisiken ausgesetzt sind.

Warum ist das eine schlechte Sache? Erstens würde es Benutzer einer Reihe von Sicherheitsrisiken aussetzen. Wie die meisten großen Softwarepakete wird PHP ständig aktualisiert, um die Vielzahl von Sicherheitslücken zu beheben, die ständig entdeckt (und offengelegt) werden.

Darüber hinaus bedeutet dies, dass Benutzer nicht die neuesten (und besten) Sprachfunktionen verwenden können. Dies bedeutet auch, dass Funktionen, die aus einem bestimmten Grund veraltet sind, erhalten bleiben. Im Falle der PHP-Programmiersprache Lernen Sie mit PHP zu bauen: Ein CrashkursPHP ist die Sprache, in der Facebook und Wikipedia täglich Milliarden von Anfragen bearbeiten. Die De-facto-Sprache, in der Menschen Web-Programmierung lernen. Es ist wunderschön einfach, aber brillant kraftvoll. Weiterlesen Dies schließt die lächerlich schrecklichen (und kürzlich veralteten) mysql_-Funktionen ein, die zur Interaktion verwendet werden mit dem MySQL Relational Database System und dl (), mit dem Benutzer ihre eigene Sprache importieren können Erweiterungen.

Als Benutzer sollten Sie sehen können, welche Version eines Interpreters auf Ihrem Dienst ausgeführt wird. Wenn es veraltet ist oder eine Reihe von Sicherheitslücken enthält, wenden Sie sich an Ihren Host.

Was ist mit Sysadmins? Hier haben Sie einige Optionen. Das erste (und vielversprechendste) ist die Verwendung von Docker für jeden Ihrer Benutzer. Mit Docker können Sie mehrere isolierte Umgebungen gleichzeitig ausführen, ähnlich wie bei einer virtuellen Maschine, ohne jedoch ein anderes Betriebssystem ausführen zu müssen. Dies ist schnell. Wirklich sehr, sehr schnell.

In reinem Englisch? Sie können den neuesten und besten Dolmetscher für die Mehrheit Ihrer Benutzer ausführen, während die Kunden die alte Anwendungen verwenden, die alte, veraltete Dolmetscher verwenden, ohne andere zu gefährden Benutzer.

Dies hat auch den Vorteil, sprachunabhängig zu sein. PHP, Python, Ruby. Wie auch immer. Es ist alles das Gleiche.

Ich habe keine Albträume.

Dieser Beitrag sollte ein paar Dinge tun. Zunächst sollten Sie auf die Anzahl der Sicherheitsprobleme aufmerksam gemacht werden, mit denen Webhosting-Unternehmen konfrontiert sind, um die Sicherheit ihrer Kunden und ihrer Daten zu gewährleisten.

Es sollte Ihnen auch zeigen, wie sich auf demselben Server gehostete Websites gegenseitig beeinflussen können. Möchten Sie dies eindellen? Befolgen Sie gute, sichere Codierungsstandards. Beginnen Sie insbesondere damit, Ihre Eingaben sowohl im Front-End als auch im Back-End zu bereinigen.

Ein guter Anfang ist die neue HTML5-Formularvalidierungsfunktion. Wir haben bereits in unserem HTML5-Handbuch darüber gesprochen. Gemeinsam können wir Websites sicherer machen, indem wir bessere und gewissenhaftere Programmierer sind.

Wie immer bin ich bereit, Ihre Gedanken zu hören. Schreiben Sie mir unten einen Kommentar.

Fotokredit: Jeder braucht einen Hacker (Alexandre Dulaunoy), Aufkleber auf Taxi-Fenster (Cory Doctorow), Serverraum (Torkild Retvedt), Linux Bücher und Zeitschriften (library_mistress), PHP Elefant (Markus Tacker)