[TYPO3-german] Wie stelle ich "zuverlässig" fest, ob meine TYPO3-Installation gehacked wurde?

[David Bruchmann]

----- Ursprüngliche Nachricht -----
Von:        Daniela Waranie <typo3-community at gmx.de>
Gesendet:   Montag, 9. März 2009 15:19:31
An:         typo3-german at lists.netfielders.de
CC:
Betreff:    Re: [TYPO3-german] Wie stelle ich "zuverlässig" fest, ob 
meine TYPO3-Installation gehacked wurde?
Hallo Daniela,
> 
> Danke für Deine Tipps.

Nun, am Ende profitieren wir vielleicht alle davon.

> 
> Zugriffszeiten:
> Die Zugriffszeiten sind in der Tat sehr interessant. Beim Manipulieren 
> der Zeiten fällt mir nur die Änderung der Systemuhr ein, um dann die 
> Dateiänderung exakt zum Originalzeitpunkt durchzuführen. Hier wäre es 
> toll wenn das System bei jeder Uhrzeitänderung auf sich aufmerksam 
> macht. Dann kann man die Zugriffszeiten als Prüfstein verwenden. Für 
> beides wüsste ich nicht genau, wie es am besten machen sollte (weil auch 
> das ein Hacker umgehen könnte).

Nun, die Systemzeit umzustellen geht natürlich auch. Ich dachte daran, 
daß man per Hex-Editor einfach die Dateieigenschaften ändert - dort 
werden die Zugriffszeiten auch gespeichert. Wenn jemand viele Änderungen 
durchführt währe Dein "Rezept" natürlich einfacher, würde aber ein 
"Zeitloch" bei den normalen Seitenzugriffen in den Logfiles hinterlassen.
Bei den Datenbankzugriffen werden auch die Zeitstempel gespeichert, 
sofern sie aus TYPO3 heraus erfolgen - bei anderem Zugriff (z.B. per 
PhpMyAdmin) wird nur der Zeitpunkt der letzten Tabellenänderung 
gespeichert. Hier könnte man einen Vergleich durchführen, ob die letzte 
Tabellenänderung auch mit einer TYPO3-Änderung einhergeht.

> 
> Log-Dateien / Apache-Log-Dateien:
> Was genau wäre aus Deiner Sicht verdächtig?
> 

Verdächtig ist alles was nicht der reinen Frontendausgabe dient 
(allerdings läßt sich per SQL-Injection auch das Frontend missbrauchen 
um an Backend-Daten zu kommen).
Welche Dateien bzw. Ordner im Einzelnen auf Backendzugriffe hinweisen 
müßte man mal testen bzw. aus den Logdateien auslesen, wenn man mal 
aktiv war.
Bei dem letzten Sicherheitsloch waren Zugriffe mit "jumpurl" verdächtig.
Innerhalb von TYPO3 gibt es zwar klar abgegrenzte Aufgabenbereiche, die 
sich auch in der Ordnerstruktur wiederspiegeln, aber einzelne 
Erweiterungen können auch Dateien einbinden, die darüber hinausgehen.
Entscheidend sind hier die Dateien, die eine Ausgabe bewirken, andere 
werden in den Apache-Logs nicht erscheinen.

> Login-E-Mail:
> Interessante Idee. Auf den Server habe ich nicht so viel einfluss, da es 
> eine Shared-Host-Umgebung ist. Aber TYPO3 könnte ich schon "abdichten" - 
>   wie genau geht das in TYPO3?
> 

In TYPO3 kannst Du einmal Mails erhalten, wenn jemand sich generell 
einloggt, das wird für jeden Benutzer einzeln bei 
"Benutzerwerkzeuge->Einstellungen" eingestellt, aber informiert nur den 
Inhaber der dort hinterlegten E-Mail.

Ausserdem kann man sich informieren lassen, wenn jemand das Installtool 
startet. Die Einstellungen dazu finden sich im Installtool selbst:
[BE][warning_email_addr]
[BE][warning_mode]
Hier kannst Du auch einstellen, daß Du informiert wirst, wenn sich ein 
beliebiger Backendbenutzer einloggt.

> ------------------------------------------------------
> Die restlichen Punkte fallen in meinen Augen alle unter Vorsichtsmaßnahmen:
> 
> Zugriffsbeschrängungen:
> Jedes Script bekommt nur die Zugriffsrechte, die es benötigt. Das heißt, 
> nicht jedes Script braucht alle Datenbank-Tabellen und auch nicht immer 
> schreibend Zugriff.

Währe sinnvoll hier auch verschieden MySQL-Konten verwalten zu können, 
aber das ist wie gesagt nicht vorgesehen. Eventuell kann man so etwas 
per dbal (Database Abstraction Layer, was sowohl eine Technik, ein 
integriertes Modul bezeichnet) lösen, habe ich mir aber nicht angesehen.

> 
> SQL-Injection:
> Hier ist TYPO3 schon sehr gut aufgestellt. Problematischer sind vorallem 
> die Extensions, ohne intensive Einarbeitung in den Code dürfte man 
> eigentlich keine Extension übernehmen. Aus betriebswirtschaftlicher 
> Sicht ist also ein gewisses Grundvertrauen in die Community notwendig 
> und angebracht. Sicher sein, kann man sich jedoch nie. Auch der Core hat 
> immer wieder Lücken - und dieser ist wohl am häufigsten geprüft. Sobald 
> einmal Zugriff auf das Dateisystem besteht, kann beliebiges 
> SQL-Statement abgesetzt werden.

Klar, ist die Festung einmal eingenommen, hilft nur noch Schadensbegrenzung.

> 
> Frame-Script:
> Wie verhinderst Du das? Außer mit JavaScipt fällt mir da nichts ein - 
> und das ist alles andere als "zuverlässig"?
> 

Naja, JavaScript oder VB. Teilweise habe ich auch gesehen, daß *.pl 
(Perl) oder Java-Dateien an den Client ausgeliefert werden - aber gerade 
bei *.pl weiss ich nicht wie das funktioniert, oder ob dort überhaupt 
tatsächlich Perl drin notiert war (schätzungsweise waren das JS- oder 
CSS-Dateien mit anderer Dateisuffix).
Die meisten Hacker-Skripts werden aber wohl JS verwenden, daher liegst 
Du schon richtig.

> Aufruft via Script verhindern:
> Wie machst Du das?
> 

Hab lange kein JS mehr verwendet, aber ich glaube man kann per JS den 
Caller sowohl von Fenstern als auch von Funktionen feststellen und 
entsprechend darauf reagieren.

Viele Grüße
David