Vor ein paar Jahren auf der DefCon 18, einer auf Sicherheit fokussierten Konferenz in den USA, erzählte ein Referent namens Zoz die Geschichte, wie sein Computer aus seiner Wohnung gestohlen wurde – und wie er sein Fachwissen nutzte, um den Dieb zu bestrafen.
Ironischerweise wurde der Computer des Hackers aufgrund eines klassischen physikalischen Sicherheitsfehlers gestohlen: Er hatte zwar überall Schlösser, aber ein schwaches Glied erlaubte es dem Dieb, die meisten davon einfach zu umgehen. Der Verlust seines Computers war eine Katastrophe, sagte Zoz, und es kam noch schlimmer: Alle seine gewissenhaft erstellten Backups wurden ebenfalls gestohlen, da sie auf tragbaren Festplatten gespeichert waren, die im selben Raum aufbewahrt wurden.
Ich wurde an diese Präsentation erinnert, als ich von einem Wochenendausflug nach Hause kam und feststellen musste, dass in meine eigene Wohnung eingebrochen worden war, ein sehr ähnlicher Tatort wie der oben erwähnte. Ich hatte schön aussehende, aber offensichtlich sinnlose Schlösser an den Fenstern und sogar eine Kette an der Eingangstür, die ich von meinem Vormieter geerbt hatte. Anstatt mich jedoch zu schützen, wurde genau diese Kette benutzt, um mich, den rechtmäßigen Eigentümer, daran zu hindern, meine eigene Wohnung zu betreten. Laut der Polizei ist das eine übliche Vorgehensweise: Wenn der Eigentümer zufällig nach Hause kommt, während die Wohnung noch durchsucht wird, hat er genug Zeit, durch das Fenster zu entkommen – noch bevor Sie die Chance haben, herauszufinden, was passiert ist!
Beide Geschichten unterstreichen einen wichtigen Ratschlag, den Sie immer beachten sollten: Es ist immer das schwächste Glied, das Sie erwischt. Das heißt, wenn Sie als Webentwickler gute Arbeit geleistet haben, wird das schwächste Glied nicht die Website selbst sein, sondern die Infrastruktur, auf der sie läuft. Das kann der Datenbankserver sein, der trotz besseren Wissens nicht in einem privaten Netzwerk versteckt ist, sondern für „administrative Zwecke“ öffentlich erreichbar ist. Oder das Backup, das Sie auf einem physischen Rechner gespeichert haben, der dem ISP oder jemand anderem gehört und von ihm betrieben wird.
Lassen Sie uns am Anfang beginnen: Standardmäßig liefern die meisten Linux-Distributionen den Apache-Webserver aus, auf dem PHP als Modul installiert ist und der durch MySQL ergänzt wird, was den klassischen LAMP-Stack bildet. Die Absicherung – oder wie die Sicherheitsindustrie es nennt: Härtung – eines Mehrzweck-Servers ist nicht einfach und erfordert möglicherweise verschiedene Kompromisse, um ihn überhaupt zum Laufen zu bringen. Wer auch immer gesagt hat, dass „alles auf der gleichen Maschine laufen muss“, sagt allerdings nicht die Wahrheit: Das muss es auch nicht. Gerade in virtuellen Umgebungen und sogar in der Cloud, wo dedizierte Maschinen aufgestellt werden, ist der Aufwand nicht viel größer. Ein komplexes System in einzelne Server aufzuteilen, macht die Absicherung der einzelnen Maschinen viel einfacher, vor allem wenn man jeden Server (außer dem Webserver) nur auf privaten IP-Adressen laufen lässt. Anstatt also einen All-in-One-Server zu betreiben, würde Ihre sichere Umgebung aus drei Maschinen bestehen: dem Webserver, einem PHP-Server und einem dedizierten Datenbankserver.
Moment mal. Habe ich gerade gesagt, den Webserver und PHP aufzuteilen? Wie soll das denn funktionieren? Seit geraumer Zeit kann PHP als Dienst ausgeführt werden, der das FastCGI-Protokoll implementiert. PHP-FPM, der FastCGI Process Manager, wird unabhängig von jedem Webserver ausgeführt, entweder lokal oder remote. Durch die Installation von PHP-FPM auf einem einzelnen Server – oder auf mehreren Servern, falls ein einzelner Rechner die volle Last nicht bewältigen kann – entfällt die Notwendigkeit, den PHP-Interpreter sowie die PHP-Quelldateien auf dem Webserver zu haben. Damit bleiben nur noch statische Dateien wie Bilder, CSS oder JavaScript-Code übrig.
Die Reduzierung der öffentlich zugänglichen Dienste auf HTTP und die Tatsache, dass kein Quellcode in Reichweite ist, bedeutet, dass Angreifer es schwer haben werden, Zugriff auf PHP-Code zu erlangen. Es gibt natürlich noch viele weitere Dinge, die man tun kann, um die Infrastruktur zu sichern, aber die Überlegung, was das schwächste Glied sein könnte und wie man es festigt, ist der Schlüsselfaktor für ein wirklich sicheres System. Wenn man eine sichere Umgebung aus technischer Sicht hat, wird das physische Hosting zum schwächsten Glied. Dies ist keine Überraschung; der physische Zugang war schon immer das Hauptproblem für jede IT-Infrastruktur.
Wenn Sie also die Infrastruktur planen, sollten Sie nicht nur die Menge an CPU, RAM oder Formfaktor berücksichtigen, sondern auch den Hosting-Standort, dessen Backup-Mechanismen sowie die Sicherheitsprotokolle. Es muss nicht einmal ein Angriff sein, der Sie Ihre Server kosten kann. Wenn Sie ein gemeinsam genutztes Rack haben und jemand anderes darauf zugreifen muss, kann es passieren, dass Sie aus Versehen die Verbindung oder Ihre Festplatten verlieren. In diesem Fall wäre menschliches Versagen das schwächste Glied – etwas, das sehr schwer zu planen und zu bekämpfen ist.
Wenn Sie sich dafür entscheiden, keinem ISP zu vertrauen und stattdessen alles selbst zu hosten, sollten Sie sich darüber im Klaren sein, dass es keine leichte Aufgabe ist, selbst eine physische Zugangskontrolle zu implementieren und durchzusetzen. Und das bloße Verschließen von Türen, 19"-Racks und Servern an einem Ort hilft nicht, wenn ein Eindringling alle Zeit der Welt hat – zum Beispiel am Wochenende.
Als letzte Vorsichtsmaßnahme sollten Sie ein verschlüsseltes Backup an einem anderen Ort aufbewahren. Sie wissen schon, nur für den Fall!