TYPO3 Security Checklist: 47 Massnahmen, um eine TYPO3-Installation sicherer zu machen

image

UPDATE: Version 0.9.2 verfügbar (Problem mit TYPO3-Font “Share” gefixt)

Der Angriff auf die Website von Bundesinnenminister Wolfgang Schäuble hat Diskussionen über die Sicherheit von TYPO3 entfacht. Wer nun allerdings TYPO3 als unsicher abqualifiziert und denkt, dass dies mit “seinem” CMS nicht passieren könnte, macht es sich zu einfach. Grundsätzlich ist jede Software angreifbar, um so mehr, wenn sie auf einem öffentlich zugänglichen Webserver läuft. TYPO3 ist weder sicherer noch unsicherer als vergleichbare Systeme – es ist vielmehr eine Frage der richtigen Handhabung.

Die TYPO3 Security Checklist ist eine Sammlung von rund 50 Tipps für die Praxis, wie man eine TYPO3-Installation sicherer macht. Sie richtet sich nicht an Entwickler, sondern an TYPO3-Administratoren, welche eine Website aufsetzen und betreiben. Die Empfehlungen lassen sich in den meisten Fällen auch in einer Shared-Hosting-Umgebung umsetzen, wo man nur beschränkten Zugriff auf Webserver und Datenbank hat.

Dies ist die erste öffentliche Version dieser Checkliste. Ergänzungen und Korrekturen nehme ich gerne entgegen – sei es als Kommentar in diesem Blog, sei es per Kontaktformular.

17 Gedanken zu „TYPO3 Security Checklist: 47 Massnahmen, um eine TYPO3-Installation sicherer zu machen“

  1. Erstmal herzlichen Dank für das PDF! Eine Kleinigkeit ist mir jedoch aufgefallen: Unter Mac OS X wird das PDF mit Vorschau nicht vollständig korrekt angezeigt. So ist das Deckblatt zum Beispiel unkenntlich. Nur mit Acrobat (Reader) lässt sich das Dokument sauber lesen.

  2. Hallo Martin,

    danke für das Werk!

    Hab ein paar Kommentare, die teils sehr von meinem persönlichen Geschmack abhängen:

    * tboley’s Kommentar kann ich bestätigen. Die Überschriften sind in der Vorschau auf dem Mac nicht lesbar
    * Massnahmen schreibt man Maßnahmen, oder? 😉
    * “admnin-Account eliminieren” würde ich lieber “absichern/umbenennen” nennen; häufig wird hierbei auch das Ändern der ID direkt in der DB als zusätzliche Sicherheit genannt.
    * Anstatt die Leute direkt in die localconf.php schreiben zu lassen würde ich auf das Installtool verweisen. Denke für Anfänger ist das geeigneter.
    * Von dem Vorschlag, dem DB-User die CREATE- (oder ALTER-)Rechte zu nehmen, halte ich persönlich nichts. Bei welchem Angriff werden schon Tabellen erstellt. DROP könnte ich halbwegs nachvollziehen.
    * Ich würde nicht raten, das typo3tem/* zu löschen. Am Ende sind die Verzeichnisse mit gelöscht und es gibt Probleme. AFAIK müsste nach Ändern des Enc-Keys ein Löschen des FE-Caches ausreichen. Eine Aufräumaktion von typo3temp/ würde dann aber natürlich nicht schaden. Aber das geht sicherer über das Install-Tool 😉
    * Installtool-Passwort-Änderung (5.) gaaaanz hoch vor/nach Admin-PW-Änderung.
    * Punkt 11 auch ganz wichtig. Punkt 15 ist ja in etwa das Gleiche. Ich würde das zusammenfassen und als einen der allerersten Punkte erwähnen.
    * 16 ist unnötig, da es ja bereits standard ist, oder? (außer das .htaccess glaub ich).
    * 19 könnte eine Erklärung der Zahlen gebrauchen. Ich würde sagen, es werden die 4 (3,2) letzten Bytes der IP-Adresse geprüft.
    * 20 ist (glaube ich) nicht gut. Es werden im FE auch ab und zu mal Grafiken aus typo3/gfx/ verwendet.
    * 22 sehr schön, aber passt ja nicht mehr zu 4.3. Wäre toll, wenn du das darauf aktualisieren könntest (saltedpasswd ist da sysext)
    * 23, Teil 2, selbiger Grund wie 20, falls das Zertifikat nicht signiert ist
    * 27: Wenn wir schon ein Sicherheitshandbuch schreiben, dann bitte auch zwischen Verschlüsselung und Hashing unterscheiden 😉
    * 29: RTE halte ich nicht für tragisch, da der RTE ja alles Böse entfernen sollte (und noch mehr..)
    * 30: weiß nicht so recht, ob es das braucht. sicher sinnvoller Gedanke
    * 33: weiter Vor.
    * 40: kein Sicherheitsaspekt -> raus
    * 42: sehr wichtiger Aspekt. Genereller: Den Server stets absichern und (da Wichtig) an den Anfang. Da könnte auch gut der mysql-Zugriff ausschließlich von localhost reinpassen.
    * 44: safe_mode: jetzt wirds aber ganz schön sicher.. mir sogar zu sicher! Wenn ich ehrlich bin möchte ich keinem raten, TYPO3 im safe_mode zu betreiben
    * 45: open_basedir ist auf alle Fälle gut! Es müssen halt nur alle benötigten Pfade enthalten sein. saltedpw braucht zB auch Entropie von /dev/urandom. Dann gibts daran nichts zu meckern und eindeutig Sicherheit!
    * Zur Anmerkung über config.baseURL = 1: Da sollte die base-url fest drin stehen und nicht nur 1, dass TYPO3 das automatisch macht (also config.baseUrl = http://www.workshop.ch/). Ich bilde mir ein, der Hintergrund ist, dass die Seiten dann mit der beim ersten Aufruf genutzten URL gecacht werden.

    Eine Idee wäre in der .htaccess z.B. auch noch pauschal den Zugriff auf *.sql zu verbieten, falls aus versehen mal ein Backup nach database.sql rutscht…

    Generell würde ich mir eine bessere Sortierung nach Wichtigkeit und untergliedert nach FE/BE weniger durchmischt wünschen.

    Ansonsten aber sehr nett und hilfreiches Werk!

    Gruß
    Steffen

  3. Die Angeführten optionen, speziell SSL und die IP Locks halte ich für sehr sinnvolle Ergänzungen.

    register_globals sollte eh schon per default auf allen webhosts auf off stehen.

    das thema .htaccess als sicherung des backends ist zwar schön, aber ein .htaccess ist nicht gleich .htaccess, bruteforce anyone?

    die auslagerung der localconf.php halte ich für sehr vernünftig, aber was sagt eigentlich das extension update tool und installations tool dazu?

    sprich wenn ich nach verschiebung der localconf.php ne extension installation mache, kann ich mir vorstellen, dass es zu Problemen kommen könnte, ausser wenn ich nur die Pfade, die nicht davon abhängig sind auf ein file ausserhalb des webroots auslagere.

  4. Geile Sache! Beim überfliegen ist mir auch aufgefallen das evtl. der ein oder andere Punkt höher müsste (nach Ranking sortiert?!?!). Wenn es kein richtiges Ranking gibt/geben soll, dann sollten vielleicht Kategorien her (wie Steffen schon angemerkt)

    Ansonsten Top Sache!

  5. @tboley: Danke für den Hinweis. Es ist natürlich nicht Trebuchet, sondern Share, der offizielle TYPO3-Font. Ich habe nun einen anderen PDF-Generator benutzt, das Problem sollte in der neusten Version 0.9.2 behoben sein.

    @Steffen: Danke für das ausführliche Feedback. Ich werde das für die nächste Version berücksichtigen und vielleicht mit Detailfragen noch auf Dich zukommen. Nur eins: Massnahmen schreibt man in der Schweiz ganz genau so. Du wirst im ganzen Dokument kein “ß” finden.

    @Oliver: Die Verschiebung der localconf.php müsste ich sicher noch etwas detaillierter beschreiben. Habe ich mir notiert.

    @Tim: Genau diese Gedanken habe ich mir auch gemacht, aber wenn ich eine Reihenfolge nach Wichtigkeit mache, dann werden wir endlos diskutieren, was denn nun wichtiger ist. Aber eine Art “Tagging” wäre wahrscheinlich ein gute Idee. Ich überlege mir was.

  6. Moins, ich arbeite nun seit ‘kurzem’ (knapp 2 Jahre) mit Typo3. Da kommt die Checkliste gerade recht. Die meisten Pinkte waren mir bekannt. Allerdings gibt es noch Einiges, worüber ich nachdenken sollte.

    Vielen Dank für Deine Mühen!

  7. Hi Martin,

    vielen Dank für Deine Mühen.

    config.baseURL = 1 öffnet eine Sicherheitslücke!
    D.h. es ist zwingend
    config.baseURL = http://www.example.com/
    (mit abschließendem Slash!) zu setzen.

    config.linkVars = L ist laut Security Team ungefährlich, sieht aber im Zweifel doof aus.

    Du könntest noch einen Hinweis auf TypoScript mit reinnehmen:

    10 = TEXT
    10.field = userinput
    oder
    10.data = GPvar:variable

    muss mit
    10.htmlSpecialChars = 1
    oder
    10.intval = 1
    oder
    10.removeBadHTML =1
    oder
    10.stripHtml = 1
    abgesichert werden.

    Ein Hinweis auf die Gefahr, dass im SELECT ggf. übergebener Input abgesichert werden muss, sollte auch noch folgen:)
    10 = CONTENT
    10 {
    table = tt_content
    select {
    andWhere.data = GPvar:sqlInjection
    }
    }
    Auch dort muss also der Inhalt überprüft und gesichert werden – entweder mit intval oder per userFunc falls ein string verwendet werden soll.

    Und mit Punkt 14. “Nur geprüfte Extensions benutzen” bin ich überhaupt nicht einverstanden. Das ist eine theoretische Absicherung, hilft dem User aber überhaupt nicht.

    Wesentlicher fände ich einen Hinweis darauf, dass eingesetzte Extensions auf Sicherheitsaspekte untersucht werden sollten.

    Alles andere hat glaube ich Steffen schon geschrieben.

    Aber alles in allem eine sehr gute Liste – nicht nur für Anfänger sehr zu empfehlen!

    Vielen Dank & gruß,
    ein anderer martin

  8. Nachtrag:

    Wir sichern den Zugriff auf klassische “Problem”-Dateien mit einer .htaccess Regel ab:

    deny from all

    Es arbeiten da ja überall immer Menschen – und wenn dann jemand einen t3d-Export macht oder ein SQL import/Export oder warum auch immer logfiles rumliegen, dann sind die trotzdem nicht zugreifbar.

    Denn rumliegende T3D- oder SQL-Dateien sind ein großes Sicherheitsrisiko.

    gruß,
    martin

  9. Hallo Martin. Vielen lieben Dank für den Aufwand, den Du in dieses Dokument hineingesteckt hast. Danke auch dafür, dass Du es der Allgemeinheit zur Verfügung stellt.
    Über die Inhalte gab es ja mittlerweile bereits ausgiebige hilfreiche Kommentare. Wenn das Dokument für jeden zufriedenstellend angepasst ist, hoffe ich, es an zentraler Stelle auf typo3.org wiederfinden zu können. 😉

  10. @Markus: Wenn die TYPO3 Association das Dokument auf http://www.typo3.org publizieren möchte, dann würde mich das freuen. Für nicht-kommerzielle Zwecke darf die Checkliste generell kopiert und publiziert werden (Creative Commons Licence – Details im PDF). Im Moment gibt es das Dokument allerdings nur auf Deutsch.

  11. ganz ganz große klasse! auch die anschließende diskussion darüber. das ist das beste zum thema typo3 dass mir seit einiger zeit übern weg gelaufen ist. gleich als broschüre ausgedruckt und den kunden auf den tisch geknallt, die sich für ihre e-mail accouts passwörter wie ‘123456’ oder ‘passwort’ einrichten. 😉 traurigerweise trifft das auf eine mehrzahl meiner zu.

  12. Also zum Runterladen von *.t3d’s oder sqldumps kann man ja den jeweiligen WebServer schon “richtig” einstellen, z.B.
    in Apache:

    Order allow,deny
    Deny from all

    Ist natuerlich die Schwierigkeit, ob Servereinstellungen nun zu einer TYPO3-Absicherung gehoeren!?

  13. Hallo Martin,
    danke für die Zusammenstellung der Sicherheitsmassnahmen.

    Ich habe auch noch einen Tip für Administratoren, die root-Zugriff auf den Server haben
    Verhinderung von Brute-Force gegen Typo3 mit fail2ban.

    Wie das funktioniert habe ich bereits in
    http://www.typo3.net/forum/list/list_post//92450/?tx_mmforum_pi1%5Bpage%5D=&tx_mmforum_pi1%5Bsword%5D=fail2ban#pid359654
    beschrieben.

    Der Donwload von dort funktioniert leider nicht. Daher unter
    http://www.illutzmination.de/fileadmin/download/apache-typo3.conf.zip
    die Datei füer fail2ban downloaden.

Hinterlassen Sie einen Kommentar