Der Drupal Basis Sicherheit Guide
Das Content Management System (CMS) Drupal ist zwar nicht so weit verbreitet wie WordPress oder Shopify, kommt aber immerhin auf rund einer Million Webseiten zum Einsatz. Eine solche Verbreitung zieht natürlich auch das Interesse potenzieller Angreifer auf sich, sodass es wichtig ist, seine Drupal Installation bestmöglich abzusichern. In diesem Basis Sicherheit Guide zeigen wir Ihnen, wie Sie mit ein paar wenigen einfachen Schritten die Sicherheit Ihrer Drupal Webseite verbessern können.
Eine Kurzversion dieses Guides finden Sie übrigens hier als praktische Checkliste. Diese können Sie ausdrucken und die einzelnen Punkte bequem nacheinander abhaken.
Default Credentials ändern
Wenn man nach „Drupal Default Credentials“ googelt erscheint als erstes Suchergebnis die folgende Frage:
Ok, es geht hier um eine Demo Seite, eine reale Version hat glücklicherweise kein Default Passwort. Aber wer sich auf diese Weise mit der Bedienung der Seite vertraut macht, bei dem besteht ein gewisses Risiko, dass er die Username/Passwort Kombination auch für die eigene Seite übernimmt. Und damit macht man es einem Angreifer dann wirklich leicht.
Um dem Angreifer dagegen die Arbeit zu erschweren, sollten sowohl Passwort als auch Username auf nicht zu erratende Werte geändert werden. Während es bei einem Passwort logisch ist, dass es geheim sein sollte, ist dies bei einem Usernamen vielleicht nicht auf den ersten Blick offensichtlich.
Was also ist das Problem mit Namen wie „admin“, „Administrator“ oder „root“? Das Problem ist, dass solche „Funktionsusernamen“ (also Username die sich auf eine konkrete Funktion auf der Seite beziehen) leicht zu erraten sind. Wenn ein Angreifer also weiß, oder zumindest vermutet, dass Sie einen Usernamen wie „Admin“ verwenden, kann er sich bei einer Brute Force Attacke auf die Login Seite auf das Passwort Feld konzentrieren.
Hat er dagegen keine Ahnung was für ein Username verwendet wird, müsste er sowohl für das Feld Username als auch für Passwort verschiedene Kombinationen durchprobieren, wodurch sich der Aufwand deutlich erhöht und die Wahrscheinlichkeit steigt, dass Sie etwas von der Attacke mitbekommen und gegebenenfalls darauf reagieren können.
File Zugriff einschränken
Über das .htaccess File kann der Zugriff auf andere Files beschränkt werden. Das sollte etwa für die Files authorize.php, upgrade.php, cron.php, und install.php durchgeführt werden. Denn falls ein Angreifer Zugriff auf diese Files erhält, erfährt er schon sehr viel mehr über den Aufbau der Seite. Kann er darüber hinaus auch noch Veränderungen an diesen Files vornehmen, steht einer Übernahme der Seite im Prinzip nichts mehr im Weg.
Ein möglicher Eintrag im .htaccess File kann etwa so aussehen:
<FilesMatch „(authorize|cron|install|upgrade)\.php“>
Order deny, allow
deny from all
Allow from 127.0.0.1
</FilesMatch>
Auf diese Weise kann niemand außer 127.0.0.1 (Localhost) auf die definierten Files zugreifen. Falls der Zugriff auch für andere IP-Adressen erlaubt werden soll (beispielsweise Softwareentwickler, die Veränderungen an der Seite durchführen müssen) können diese ebenfalls angegeben werden.
Datenbank absichern
Bei einer SQL Injection gibt ein Angreifer SQL Code an einer Stelle ein, an der dieser normalerweise nicht vorkommen soll. Beispielsweise in die Eingabefelder der Login Seite. Wird dieser SQL Code von der Anwendung nicht korrekt gefiltert, werden die eingegebenen Befehle möglicherweise von der Datenbank ausgeführt, was ziemlich unangenehme Folgen haben kann.
So kann ein Angreifer auf diesem Weg etwa versuchen die Datenbank zu löschen (Drop Table) oder sich die Daten zu allen registrierten Usern ausgeben lassen (Select * from Users).
Um solche Angriffe zu erschweren, sollte ein selbstgewähltes Prefix für Tabellennamen verwendet werden. Dieses kann während der Installation der Drupal Seite vergeben werden: während der Installation gibt es in den Advanced Options die Möglichkeit ein eigenes Prefix für Tabellennamen einzugeben.
Wird ein Prefix wie gr59l2x_ vergeben, besteht nur noch eine geringe Wahrscheinlichkeit, dass ein Angreifer dieses Prefix erraten kann, wodurch mögliche SQL Injections erschwert werden. Zwar werden nicht alle möglichen SQL basierten Angriffe auf diese Art verhindert, allerdings zumindest diejenigen, bei denen der Angreifer den Namen einer Tabelle kennen muss. Zum Löschen einer Tabelle muss etwa der Name der jeweiligen Tabelle bekannt sein. Diese Maßnahme ist also sicher kein Allheilmittel, kann die Sicherheit Ihrer Drupal Seite allerdings zumindest ein wenig erhöhen und da sie nicht schwierig umzusetzen ist, sollte sie auch durchgeführt werden.
Wenn Sie die Seite bereits installiert haben, können Sie das Prefix nachträglich noch über phpMyAdmin ändern.
Fehlermeldungen deaktivieren
Fehlermeldungen sind für die User einer Webseite nicht schön anzusehen. Das allein wäre allerdings noch kein Grund, warum man sie deaktivieren müsste. Sie haben darüber hinaus aber auch das Potenzial, einem Angreifer mehr über den Aufbau der Seite zu verraten.
Vor allem komplizierte Fehlermeldungen, die direkt vom System generiert werden, können eine Fülle an Informationen enthalten: So können etwa verwendete Module in einer Fehlermeldung enthalten sein, Versionsnummern von Modulen und der Drupal Software, Systempfade etc.
Alternativ kann ein Angreifer das Auftreten einer Fehlermeldung auch für DoS Angriffe nutzen: Wenn eine Fehlermeldung etwa beim Aufruf einer bestimmten URL auftritt, kann diese automatisiert einfach immer wieder aufgerufen werden, bis die Webseite die Anfragen nicht mehr sinnvoll verarbeiten kann.
Um einem Angreifer also nicht zu viel über ein System zu verraten, sollten Fehlermeldungen deaktiviert werden. Dies kann bei Drupal über die Adminoberfläche erledigt werden: Unter Configuration/ Development/ Logging and Errors, sollten Error Reports auf None gesetzt werden.
Ok, aber was macht man, wenn man Fehlermeldungen zwar vor den Usern verbergen möchte, als Admin aber wissen will, welche Probleme auf der Seite existieren? In diesem Fall kann man das Modul Disable Messages verwenden. Damit ist es einerseits möglich, nur bestimmte Meldungen zu filtern (basierend etwa auf einem regulären Ausdruck), Meldungen vor bestimmten Usergruppen zu verbergen und bestimmte Fehlertypen zu filtern.
Dadurch kann man sehr feingranular einstellen, wer was zu sehen bekommt. So kann es etwa in Ordnung sein, Usern Fehlermeldungen vom Typ 400 anzuzeigen. Fehler dieses Typs zeigen etwa an, dass eine Ressource nicht gefunden wurde (404, z.B. wenn eine Seite entfernt wurde) oder eine Autorisierung nötig ist um zuzugreifen (401, z.B. wenn ein nicht eingeloggter User die Seite /userprofil aufrufen möchte).
Verbergen sollte man dagegen Fehler des Typs 500, da sich diese auf Probleme der Anwendung beziehen (z.B. 500 = Internal Server Error, eine Fehlermeldung die zu diesem Ergebnis führt, könnte eventuell genutzt werden um Denial of Service Angriffe durchzuführen).
Security Module nutzen
Wie bei den meisten CMS gibt es auch bei Drupal eine Reihe von Drittanbieter Anwendungen, die installiert werden können, um der Kernanwendung neue Funktionen hinzuzufügen. Bei Drupal werden diese Anwendungen „Module“ genannt und natürlich gibt es auch hier wieder einige Module, die die Sicherheit der Webseite verbessern können.
Ohne Anspruch auf Vollständigkeit sollen an dieser Stelle einige hilfreiche Security Module für Drupal Anwendungen vorgestellt werden, weitere Security Module finden sich hier:
- Login Security
- Session Limit
- CAPTCHA
- Security Kit
- Password Policy
- Two-factor Authentication (TFA)
- SpamSpan filter
- ACL
- Content Access
Wenn man sich die Seite mit den verschiedenen Modulen anschaut, wird man übrigens feststellen, dass diese sehr viel schlichter und weniger „shopmäßig“ daherkommt als beispielsweise bei WordPress oder Shopify:
Dafür kann Drupal allerdings mit einem anderen netten Feature aufwarten: Auf der Detailseite eines Moduls werden verschiedene Metriken wie die Anzahl offener Bugs oder die Reaktionsquote der Entwickler auf Meldungen angezeigt.
Diese Daten kann man durchaus in den Entscheidungsprozess mit einbeziehen, wenn es darum geht, ein bestimmtes Modul auf der eigenen Seite zu installieren. Meiden sollte man etwa Module, die seit längerer Zeit keine Updates mehr erhalten haben, insbesondere dann, wenn seit dem letzten Update die Zahl der Bugs deutlich angestiegen ist.
Nicht genutzte Module deaktivieren
Module zu installieren ist nicht schwer. Wenn man erst einmal damit angefangen hat, ist es oft schwer wieder damit aufzuhören. Schließlich gibt es so viele interessante Erweiterungen mit denen man seine Webseite noch besser machen kann. Das Problem daran ist allerdings: Jede Zeile Code die man der Kernanwendung hinzufügt, vergrößert die Angriffsfläche. Software wird nie völlig fehlerfrei sein, je mehr Software (in diesem Fall in der Form von Modulen) man also verwendet, umso wahrscheinlicher ist es, dass man dabei auch zusätzliche Sicherheitslücken in die Seite integriert.
Aus diesem Grund sollte man sich ganz genau überlegen, welche Module man wirklich braucht. Zwei verschiedene Module zu installieren die das Gleiche machen ist ok, solange man herausfinden will, welches besser funktioniert. Im Anschluss sollte man dann aber auch daran denken, das schlechter funktionierende Modul wieder zu entfernen.
Ebenso verhält es sich mit Modulen die schlicht nicht genutzt werden. Ein Modul das sich um die Verwaltung von Kommentaren kümmert, verliert seinen Sinn, wenn seit über einem Jahr niemand mehr etwas auf der Seite kommentiert hat. In diesem Fall sollte man sich fragen: Benötige ich die Funktion wirklich? Und wenn man diese Frage mit Nein beantwortet, sollte das Modul auch konsequenterweise wieder deinstalliert werden.
Das Entfernen nicht benötigter bzw. nicht genutzter Module verringert also die Angriffsfläche der Webseite und stellt dadurch eine einfache Möglichkeit dar, die Sicherheit der Seite zu verbessern.
Doch auch Module, die aktiv genutzt werden, sollten von Zeit zu Zeit auf den Prüfstand kommen. Denn es besteht immer ein gewisses Risiko, dass ein Modul nicht mehr aktiv weiterentwickelt wird d.h. keine Updates mehr erhält. In diesem Fall reagiert der Entwickler also nicht mehr auf mögliche Sicherheitsprobleme, wodurch das Modul zur tickenden Zeitbombe werden kann. Vor allem beliebte Module, die auf vielen Seiten verwendet werden, stellen ein großes Risiko dar, wenn ihre Entwicklung aufgegeben wird. Erhält ein Modul keine Updates mehr, sollte es folglich deinstalliert werden.
Seite regelmäßig prüfen
Sicherheit ist ein kontinuierlicher Prozess. Was heute sicher ist, kann morgen schon wieder unsicher sein. Es ist also nicht damit getan, einmalig ein paar Maßnahmen umzusetzen, sondern man muss regelmäßig daran arbeiten, das Sicherheitslevel hochzuhalten.
Eine Möglichkeit dazu ist das Security Review Modul. Die Bedienung ist simpel: Nach dem Download und der Aktivierung erscheint ein „Run Checklist“ Button. Wird dieser geklickt, prüft das Modul die Seite auf typische Schwachstellen und Fehlkonfigurationen wie etwa:
- Unsichere Fehlermeldungen
- Username und Passwort Prüfung
- Zugriffsberechtigungen
- Unsichere Uploads
- Skript Tags als Input
Das Modul führt keine Veränderungen an der Seite durch, sondern gibt die Ergebnisse in Form einer Liste aus, in der die einzelnen Punkte entweder grün oder rot markiert sind. Als User kann man dann also selbst entscheiden, welche Probleme man beheben möchte und an welchen Stellen man sich vielleicht eher dafür entscheidet, das Risiko zu akzeptieren.
Daneben gibt es noch verschiedene webbasierte Scanner wie Raz0r oder den Drupal Scanner von Pentest-Tools. Dort muss lediglich die URL einer drupalbasierten Webseite eingegeben werden, um diese auf typische Probleme zu scannen.
Solche webbasierten Scanner und auch das Review Modul bieten sich an, um die Webseite von Zeit zu Zeit auf typische Probleme zu untersuchen und diese dann zu beheben. Der Nachteil solcher Scanner ist allerdings, dass sie a) eine gewisse Anzahl an false positives liefern und b) komplexere Probleme in der Regel nicht finden.
False positives sind dabei zwar ein wenig nervig aber nicht weiter schlimm. Schließlich schaut man sich ein mögliches Problem lieber einmal zu oft an als einmal zu wenig und wenn sich eine Meldung als ungefährlich herausstellt, ist das ja sogar noch ein erleichterndes Gefühl.
Problematischer wird es bei komplexeren Problemen. Solche sind für Scanner schwer zu erkennen, weil sie sich beispielsweise erst unter bestimmten Umständen ergeben oder nur dann zum Problem werden, wenn verschiedene Schwachstellen kombiniert werden. Wer auch solche Probleme eliminieren möchte, sollte seine Seite einem Penetrationtest unterziehen. Ein solcher ist zwar nicht günstig, liefert dafür aber ein akkurates Bild der Seite aus der Sicht eines möglichen Angreifers und ermöglicht es weitere Sicherheitsmaßnahmen umzusetzen.
Ein Penetrationtest bietet sich dann an, wenn bereits erste Maßnahmen zur Verbesserung der Sicherheit umgesetzt wurden und nun einerseits deren Wirksamkeit getestet werden soll und andererseits zusätzliche, bisher noch unbekannte Schwachstellen, aufgespürt werden sollen.
Informiert bleiben
Auch wenn man seine Seite bestmöglich absichert, stellt das natürlich immer nur eine Momentaufnahme dar. Wenn morgen eine kritische Sicherheitslücke in der Drupal Software entdeckt wird, dann ist die Webseite die heute sicher ist morgen vielleicht schon komplett unsicher.
Um solche Risiken zu minimieren, sollte man auf dem Laufenden bleiben was die Sicherheit von Drupal angeht. Auf der Seite https://www.drupal.org/security informiert das Entwicklerteam hierzu über Sicherheitslücken und entdeckt Schwachstellen. Ein Beispiel für eine solche Schwachstelle ist im Screenshot zu sehen:
Klickt man auf Read more, werden einem zusätzlich noch mögliche Lösungen angezeigt:
Obwohl die Schwachstelle also als kritisch angezeigt wird, kann sie bereits mit einem Update auf eine aktuelle Version behoben werden (bzw. betrifft User die eine aktuelle Version verwenden gar nicht erst).
Grundsätzlich sollte man immer versuchen, seine Software so aktuell wie möglich zu halten. Allerdings kann es auch vorkommen, dass das nicht möglich ist. Beispielsweise wenn eine neue Version zu Problemen an anderer Stelle führt. Um auch diese Fälle abzudecken, ist in diesem Fall die Deaktivierung verschiedener File Typen als Mitigation aufgeführt. Dadurch kann die Schwachstelle also auch entschärft werden.
Um nicht unvorbereitet zu sein, wenn eine neue Angriffswelle anrollt, sollte man sich etwa einmal die Woche Zeit nehmen und prüfen, ob neue Schwachstellen gefunden wurden. Ein Blick in die Vergangenheit zeigt dabei, dass es zwar durchaus vorkommen kann, dass an einem Tag mehrere Schwachstellen veröffentlich werden, allerdings gibt es auch immer wieder Perioden von mehreren Monaten, in denen keine einzige gemeldet wird. Der entsprechende Zeitaufwand sollte sich also auch für vielbeschäftigte Webseitenbetreiber in Grenzen halten, zudem man vielen potenziellen Schwachstellen schon dadurch entgehen kann, dass man seine Drupal Version auf dem neuesten Stand hält.
Fazit
Wir hoffen, dass dieser Basis Sicherheit Guide Sie dabei unterstützt, erste Sicherheitsmaßnahmen bei Ihrer Drupal Webseite umzusetzen. Eine Kurversion dieses Guides können Sie übrigens auch als Checkliste herunterladen um erledigte Punkte bequem abhaken zu können.