Typo3-Installation absichern und vor Hackerangriffen schützen

Typo3-Webseiten waren in der Vergangenheit immer wieder Opfer von Hackerangriffen. So machte im Jahr 2011 der so genannte Google Conditional Hack die Runde, bei dem heimlich tausende Typo3-Webseiten mit Spamlinks versehen wurden, die als Ziel die "unerwünschten Medikamenten und Glücksspielseiten" hatten. Der Grund für die Hackerattacken lag in den seltensten Fällen bei Typo3 selbst, da gefundene Sicherheitslücken sehr schnell von der Community behoben werden. Vielmehr liegt das Übel bei schlecht konfigurierten und gewarteten Typo3-Installation. Um solche Vorfälle zu vermeiden, ist es die Aufgabe eines jeden Typo3-Administrators, die Typo3-Installation bestmöglich abzusichern.

Die wichtigste Anlaufstelle, um die Typo3-Installation gegen Hackerangriffe zu schützen, ist der offizielle Typo3-Security-Guide. Es wird dringend empfohlen, sich diese Hinweise ausführlich durchzulesen. Leider sind die Informationen relativ allgemein gehalten und konkrete Handlungsempfehlungen fehlen. Daher werden in diesem Artikel zum einen die wichtigsten Sicherheitsvorkehrungen und zum anderen erweiterte Absicherungen am praktischen Beispiel vorgestellt. Die Praxisbeispiele sind...

  • das korrekte Setzen der Dateiberechtigungen
  • das Verschieben der localconf.php in ein externes Verzeichnis
  • das Typo3-Installationsverzeichnis absichern bzw. sperren

Empfohlene Standard-Sicherheitsmaßnahmen für Typo3

Die hier aufgezählten Maßnahmen gehören unserer Meinung nach zum Standard und sollten zwingend umgesetzt werden.

  • Aktuelle Typo3- und Extension-Versionen nutzen
    Wer nicht regelmäßig seine Typo3-Installation und deren Erweiterungen auf den aktuellen Stand bringt, begibt sich automatisch in Sicherheitsrisiken. Je älter eine Typo3-Installation ist, desto mehr Sicherheitslücken werden bekannt, die von Hackern ausgenutzt werden. Um über Typo3-Aktualisierungen regelmäßig informiert zu werden, kann man sich in die Typo3-Security Mailinglist eintragen.
  • Benutzer und Passwörter
    Verwende nur sichere und für jeden Bereich (Admin-Login, Benutzer-Login, Install-Passwort, Backend-Hash, Datenbank, FTP-Zugriff usw.) unterschiedliche Benutzer und Passwörter. Ändere diese auch von Zeit zu Zeit. Sollte ein Angreifer in Besitz eines Passwortes gekommen sein, so kann er (aufgrund unterschiedlicher Passwörter) nur auf einen Teilbereich zugreifen. Durch regelmäßiges Ändern ist der Zugriff zeitlich begrenzt.
  • SQL-Datenbank absichern
    SQL-Zugriffe sollten immer nur lokal (localhost) und niemals von außerhalb (%) möglich sein. Für jede Datenbank wird ein separater MySQL-Nutzer empfohlen, so dass Angreifer nicht auf andere Datenbanken übergehen können. Niemals, wirklich niemals, sollte die Verbindung mit dem root-Benutzer erfolgen. Für automatische Datensicherungen, bspw. durch Bash-Skripte sollte man einen weiteren Benutzer erstellen, der nur lesende Zugriffe hat.
  • Datensicherungen
    Erstelle regelmäßig Datensicherungen und bewahre diese über einen langen Zeitraum auf. Hat man das Gefühl, gehackt worden zu sein, kann man den aktuellen Stand mit den alten Sicherungen vergleichen und mittels Textvergleich-Programmen (bsp. WinDiff) die Änderungen schnell finden. Empfohlen werden neben der Tagessicherung auch Monats-, Quartals- und Jahressicherungen.
  • "Seriöse" Extensions nutzen
    Grundsätzlich gilt, dass man sich mit jeder zusätzlichen Extension ein potentielles Sicherheitsrisiko in das System holt. Man darf nicht vergessen, dass jeder Programmierer die Möglichkeit hat, eine Extension für Typo3 zu veröffentlichen und es keine offizielle Kontrollinstanz gibt. Daher wird empfohlen, alle nicht benötigten Extensions aus Typo3 zu entfernen und nur seriöse, etablierte und weitverbreitete Extensions zu nutzen.

Berechtigungen

Um Manipulationen von Dateien zu verhindern, sollten die Datei- und Verzeichnisberechtigungen möglichst streng, im Optimalfall nur lesend gesetzt werden. Ziel ist es, dem Angreifer von Seiten des Betriebssystems die Möglichkeit zu nehmen, Dateien zu verändern und beispielsweise Schadcode einzuschleusen. Aber nicht immer ist es möglich, nur lesende Berechtigungen zu setzen. Für die redaktionelle Tätigkeit ist es sogar zwingend Voraussetzung, dass Bilder und andere Elemente (in den fileadmin) hochgeladen werden dürfen. Anders sieht es beim Typo3-System selbst aus: wer keine Änderungen an den Extensions vornimmt, der verändert auch keine Dateien in den Verzeichnissen typo3_src und typo3conf. Für ein Produktivsystem können diese mit strengeren Zugriffsrechten versehen werden.

Schauen wir uns folgendes Beispiel an, wie Datei- und Verzeichnisberechtigungen unter Linux gesetzt werden. Typischerweise sind die Dateien und Verzeichnisse im Besitz des Benutzers apache und der gleichnamigen Gruppe apache. Der Benutzer apache, der den Webserver repräsentiert, darf sowohl lesen, ausführen und ändern, er besitzt also voll Rechte. Über die Gruppe apache kann man beispielsweise einem FTP-Benutzer Zugriff gewähren. In diesem Beispiel hat die Gruppe keine ausführenden Rechte, was aber problematisch sein kann, da man beispielsweise die Verzeichnisse durchklicken kann. Auch hier sollten vollständige Rechter gewährt werden. Alle anderen Nutzer bekommen standardmäßig nur lesende Rechte.

Die Typo3-Systemverzeichnisse kann man sogar nur mit lesenden Berechtigungen versehen, da in der Regel am Live-System keine Änderungen darin vorgenommen werden.

Datei- und Ordnerberechtigungen unter Typo3 sollten möglichst strikt gesetzt werden
Datei- und Ordnerberechtigungen unter Typo3 sollten möglichst strikt gesetzt werden

Für den Produktiveinsatz von Typo3 haben sich folgende Berechtigungen bewährt. In den meisten Bereichen werden Lese-/Schreibrechte gewährt, Ausnahmen bilden die Typo3-Sources und der Typo3conf-Ordner:

// Benutzer und Gruppe dem Apache zuweisen
chown -R apache:apache

// Standard-Berechtigung setzen
// Apache-Benutzer = Lesen, Schreiben, Ausführen
// Gruppenmitglieder = Lesen, Schreiben, Ausführen
// Alle anderen = KEINE Berechtigung
chmod -R 770 *

// Typo3-Sources und Extension-Ordner
// für Live-Betrieb nur lesend setzen,
// um Änderungen und Manipulationen zu verhindern
chmod -R 500 typo3_src-4.3.13/
chmod -R 500 typo3conf/ext/

// Zentrale Konfigurationsdatei localconf.php
// nur lesend setzen
chmod 500 typo3conf/localconf.php

Sehr wichtig ist, dass die zentrale Konfigurationsdateien localconf.php auf lesend gesetzt wird. Kein Benutzer ist in der Lage, Änderungen an dieser Datei vorzunehmen, was in einem Produktivsystem auch nicht von Nöten ist. Wer administrative Änderungen vornehmen möchte, der erweitert die Berechtigungen temporär. Durch diese strenge Einschränkung der localconf.php können Angreifer keinen Schadcode in das Herz einer jeden Typ3-Konfiguration einfügen.

// Berechtigungen
# ls -l
drwxrw---- 17 apache apache   504 Jun 24 14:52 fileadmin
lrwxrwxrwx  1 apache apache    19 Jan 24 07:17 index.php -> typo3_src/index.php
lrwxrwxrwx  1 apache apache    15 Jan 24 07:17 t3lib -> typo3_src/t3lib
lrwxrwxrwx  1 apache apache    15 Jan 24 07:17 typo3 -> typo3_src/typo3
lrwxrwxrwx  1 apache apache    17 Feb 12 08:36 typo3_src -> typo3_src-4.3.13/
dr-x------  5 apache apache   368 Aug 16  2011 typo3_src-4.3.13
drwxrw----  4 apache apache   648 Jul 11 09:31 typo3conf
drwxrw---- 11 apache apache 12104 Jan 30  2013 typo3temp
drwxrw---- 15 apache apache   472 Nov 17  2012 uploads

# ls -l typo3conf/
-rwxrw----  1 apache apache      1 Jul 11 09:31 deprecation_c18a88a1ff.log
dr-x------ 16 apache apache    456 Nov 18  2012 ext
-rwxrw----  1 apache apache   1465 Oct 22  2007 extTables.php
drwxrw----  3 apache apache    112 Nov 17  2012 l10n
-r-x------  1 apache apache     99 Jul 11 09:30 localconf.php
-rwxrw----  1 apache apache  59770 Jul 14  2013 temp_CACHED_FE_ps502c_ext_localconf.php

Hinweis: der typo3conf-Ordner selbst kann sollte für den Apache beschreibbar sein, da hier u.a. temporäre Cache-Dateien abgelegt werden.

localconf.php aus Web- in ein Systemverzeichnis verschieben

Man stelle sich vor, der PHP-Parser bzw. -Installation funktioniert nicht richtig und der Webserver zeigt die PHP-Skripte im Klartext an. Oder jemand hat die FTP-Zugangsdaten abgegriffen und hat nun Zugang zum Webverzeichnis. In beiden Fällen ist die localconf.php Datei frei einsehbar und somit auch die Datenbank-Zugangsdaten der Typo3-Installation. Aus diesem Grund empfiehlt es sich, die localconf.php in ein Verzeichnis außerhalb des Webverzeichnisses auszulagern, in welches nur der Apache-Webserver lesende Zugriffsberechtigungen hat. Diese wird dann in der in der "eigentlichen" localconf.php inkludiert. 

Der Vorteil ist, dass ein Angreifer eines Typo3-Systems im schlimmsten Fall die localconf.php-Datei einsehen kann, dort aber nur eine Zeile mit dem Include-Befehl vorfindet. Auf die angegebene Datei kann er optimalerweise nicht zugreifen.

// Die localconf.php liegt zwar weiterhin im richtigen
// Verzeichnis, so dass Typo3 darauf zugreifen kann...
vi /var/www/domain/typo3conf/localconf.php

// ... aber der "richtige" Inhalt liegt an einem anderen Ort und
// wird lediglich inkludiert. Hier der gesamte Inhalt der localconf.php
// im typo3conf-Verzeichnis
<?php
require('/home/secure/configFiles/localconf.php');
?>

Diese Vorgehensweise ist etwas umständlich, da beispielsweise während der Entwicklung Typo3 die modifizierte localconf.php bearbeitet und man die neuen Einträge stets in die versteckte localconf.php übertragen muss. 

Wie im vorherigen Abschnitt beschrieben sind strenge Dateiberechtigungen für die ausgelagerte localconf.php wichtig. Auch an dieser Stelle wird für ein Produktivsystem empfohlen, die Berechtigungen auf nur lesend zu setzen:

// chmod 500 => nur für Apache lesend
ls -l /home/secure
dr-x------  2 apache apache       208 Jul 14 22:03 configFiles

ls -l /home/secure/configFiles/
-r-x------ 1 apache apache 15575 Jul 14 22:01 localconf.php

Typo3 Install absichern bzw. sperren

Hat ein Angreifer das Typo3-Admin-Passwort ergattert, so wird er wahrscheinlich über die Typo3-Funktionen im Backend versuchen, das System zu übernehmen. Sind die Berechtigungen wie zuvor beschrieben gesetzt, verbietet ihm das Betriebssystem, Erweiterungen zu installieren oder Änderungen an der localconf.php vorzunehmen. Was aber tun, wenn man auf die Dateiberechtigungen keinen Einfluss nehmen darf? Was tun, wenn der Angreifer sowohl das Admin- als auch Install-Passwort kennt?

Hierfür bietet es sich an, den Install-Bereich komplett zu sperren. Auch hier gilt wieder das Motto: "ist die Webseite produktiv online, sind Konfigurationsarbeiten nicht notwendig. Dies erledigt man in einer lokalen Testumgebung". Im Produktivsystem ist es ratsam, den Install-Bereich wie folgt zu sperren:

Das Install-Tool für Typo3 sperren
Sperrt man das Install-Tool, können Unbefugte keine Änderungen
an der Typo3-Konfiguration vornehmen, wenn Sie im Besitz des
Admin-Zugangs sind.

Die Umsetzung ist relativ einfach. Man öffnet die index.php im Install-Ordner und fügt folgende Zeile Code ein, die die Abarbeitung des PHP-Skriptes deaktiviert.

// in den Typo3-Sources die index.php des install-Ordners bearbeiten
vi typo3/install/index.php

// Folgendes zu Beginn der Datei hinzufügen
die('von mir gesperrt ;-)');

Dies ist wahrscheinlich die sicherste Methode, den Install-Bereich zu schützen.