Sicherheit: Webserver und öffentliche Backups

Heutzutage betreiben sehr viele Personen Webseiten und teilen über ihre Webserver, so manches mal, auch sicherheitskritische Dateien. Die Rede ist von Backups und anderen Archiven. In der Regel sollen Backups die Webseiten schützen bzw. sollen bei einem Fehler, eine Möglichkeit bieten den früheren Stand der Webseite zu laden. Manchmal will man auch, nur mal eben schnell, dass soeben erstellte Backup herunterladen und dann wieder löschen. Viele vergessen dabei, dass dieses Verhalten einem Super-GAU gleichkommen kann. Man stellt ja auch nicht sein Fahrzeug mit laufendem Motor auf dem Ku’Damm ab und geht mal kurz Zigaretten kaufen.

Wozu der Hinweis?

Ich bin, wie man sehen kann, selbst ein Betreiber von Webseiten. Folglich kümmere ich mich um diese Webseiten, deren Logs, und deren Sicherheit. Seit einiger Zeit vernehme ich einen erhöhten Zugriff auf vermutete Dateien in meinen Speichern. Darunter sind beispielsweise Name wie [domain].de.zip, [domain].zip, backup.zip oder archiv.zip. Neben den üblichen Zugriffen auf php-Skripte wie config.php, config.inc.php, installer.php, installer-backup.php, wp-config.php oder wp-config.php.save eine “neue” Art, an mögliche Zugangsdaten heran zu kommen. Natürlich werden auch diverse Plugins auf meinen Webseiten gesucht, die Schwachstellen aufweisen und weniger häufig geupdatet werden.

Mal schnell Sichern…

Viele Betreiber haben in ihren Konfigurationen ähnliche Einträge und untergraben mit zusätzlichen Dateiendungen ihre eigene Sicherheit. Ein einfacher Kopierjob, zum Schutze der Konfigurationsdaten, kann die ganze Seite kompromittieren.

<files wp-config.php>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
</files>

Der Webserver achtet, wie immer in der Informationstechnik, nur auf die Dateien welche explizit angegeben wurden. In dem oberen Skript, werden folglich nur Zugriffe auf die wp-config.php blockiert. Ein Zugriff auf eine Datei mit dem Namen wp-config.php.save wird damit nicht unterbunden!

Eigentlich wollte der Betreiber der Webseite die Konfigurationsdaten vor dem überschreiben sichern. Hat aber somit und unweigerlich, einen Zugang zu seiner Konfiguration offen gelegt. Diese “gesicherte” Konfiguration wird jetzt im Klartext vom Webserver ausgeliefert. Folglich hat jeder, der mal rein zufällig nach dieser Datei gesucht hat, vollen Zugriff auf die Datenbank hinter der Webseite. Natürlich muss hier auch der Datenbankserver entsprechend, für den externen Zugriff, konfiguriert sein. Meistens hat man jedoch Tools installiert, wie beispielsweise phpMyAdmin, die lokal auf die Datenbank zugreifen können.

Immer mit Bedacht handeln

Ein Webserver ist, in der Regel, ein öffentlich zugängliches Konstrukt. Folglich sollte man auch bei einfachen Dingen, wie einen kleinen Abruf von Daten oder Veröffentlichung von Bildmaterial. Immer darauf achten, dass man nicht versehentlich Daten veröffentlicht die nicht für die Öffentlichkeit gedacht sind. Konfigurationsdaten und Backups sind Daten, die niemals ohne entsprechende Sicherheit abgelegt werden sollten.

Betreibt man beispielsweise einen WordPress-Blog oder eine andere Webseite mit aktiven Inhalten. Ist es immer ratsam, die Konfigurationsdatei außerhalb des Webverzeichnisses abzulegen. Durch einen einfachen include(), require() oder require_once() Befehl (PHP), kann man diese Datei dann in die ursprüngliche und abgespeckte Konfigurationsdatei einfügen. Natürlich muss hier die PHP-Konfiguration so angepasst werden, dass der PHP-Interpreter auf die neue Datei zugreifen kann bzw. darf.

Stichwort: PHP open_basedir

Andere Dateien…

Auch das kleine Bild, was man mal eben mit einem Screenshot-Tool gemacht hat, kann einem das Genick brechen. Beispielsweise eine Sitzungsnummer des Remotewartungstools. Gepaart mit einem schwachen Passwort, könnte schon zu einem Problem werden. In diesem Blogbeitrag, habe ich beispielsweise nicht die Dateinamen angepasst. D.h. man sieht bei einigen Bildern die AnyDesk-ID meines Testcomputers in der URL. Die Installation ist nicht mehr existent, von daher ist die Nummer nicht von Bedeutung. Es sollte euch nur aufzeigen, wie einfach man ein Datenleck produzieren kann.