MFC überwacht automatisiert Loginversuche per Graylog2

Bereits im letzten Jahr haben wir einen Artikel zur Absicherung des TYPO3 Backends durch die von uns erstellte Extension mfc_belogin_captcha veröffentlicht. Jedem, der diesen Artikel nicht gelesen hat, empfehle ich nochmal ausdrücklicherweise die Lektüre. Freilich gibt es noch TYPO3 Installationen, die diese Extension nicht installiert haben. Oft gibt es auf Websites auch noch andere passwortgeschützte Bereiche, die sensible Kundendaten oder ähnliches enthalten. Ein geglückter Zugriff eines Hackers kann hier schwerwiegende Folgen haben – vom Imageverlust des Website-Betreibers mal ganz abgesehen.

Eine sichere Kennwortspeicherung in Form eines „salted Hash“ und weitere Vorkehrungen sind natürlich obligatorisch – werden die Kennwörter von den Benutzern allerdings selbst gewählt, so sind auch die besten Sicherheitsvorkehrungen nur Makulatur. Ein unbedarft gesetztes Kennwort reicht dann in der Regel aus, sodass der Zugang per Bruteforcing unfassbar einfach ist.

Die von der MFC erstellte Extension mfc_belogin_captcha verhindert solche Bruteforce Angriffe, jedoch lässt sich das nicht überall anwenden – wie zum Beispiel bei einer Authentifizierung per Apache Access Control.

Eine zuverlässige Erkennung von Bruteforce Attacken ist also unabdingbar, um die Sicherheit eines geschützten Bereichs zu bewahren. Wichtig ist vor allem die Geschwindigkeit, mit der man eine Bruteforce Attacke erkennt und die entsprechende Eskalationskette durchläuft, um noch vor dem nicht authorisierten Zugriff agieren zu können. Wird der Zugriff erst erkannt, nachdem er passiert ist, ist es in der Regel schon zu spät, und man kann sich nur noch um Schadensbegrenzung bemühen.

An dieser Stelle kommt das Tool Graylog2 ins Spiel. Graylog2 ist ein Open Source Daten Analyse Tool, mit dem sich Logs durchsuchen, grafisch darstellen, Reports erstellen und vor allem Alarme absenden lassen. MFC überwacht mit einem Graylog2 Setup die Webserverlogs aller Systeme in Echtzeit. Unter anderem werden alle Zugriffe mit einem HTTP Response Code von „401 Unauthorized“ kategorisiert. Wird eine kritische Zahl an Einträgen in einem bestimmten Zeitraum überschritten, so wird sofort der zuständige Techniker unmittelbar per SMS alarmiert. Dieser kann die Zugriffe sofort per Weboberfläche auswerten und die entsprechenden Gegenmaßnahmen einleiten.

Das Großartige ist, dass automatisch alle geschützten Bereiche überwacht werden – solange die Anwendung auch den korrekten HTTP Response Code zurück gibt. Seit Neuestem tut dies im Übrigen auch TYPO3 – fehlerhafte Backend Loginversuche werden nun mit einem „401 Unauthorized“ belohnt (vgl. http://forge.typo3.org/issues/51803).

Wie richtet man das ganze nun im Graylog2 ein?

Ich werde jetzt nicht auf die komplette Grundinstallation eingehen – nur soviel dazu: Wir nutzen ein Setup aus Logstash, Redis, Graylog2 und Elasticsearch. Zur Grundeinrichtung der einzelnen Programme findet man im Netz jede Menge Tutorials, das Zusammenspiel der einzelnen Komponenten hängt letztendlich von der schon bestehenden Infrastruktur ab und bedarf einer ordentlichen Planung.

Im Folgenden zeige ich bespielhaft die Einrichtung einer Überwachung der TYPO3 Backend Logins per Stream. Zuerst wählt man in der Graylog2 Weboberfläche den Reiter „streams“ und erzeugt einen neuen Stream (zum Beispiel mit dem Namen „typo3_be-401“). Anschließend erzeugt man im Reiter „Rules“ zwei neue Regeln, nach welcher Logeinträge erfasst werden. Dazu wählt man im Drop Down „Add rule“ jeweils den Eintrag „Additional Field“ und befüllt das Feld mit „response=401“ und „request=/typo3/index.php“.

Graylog2_stream_1

Die Feldnamen „response“ und „request“ können je nach Setup natürlich variieren. Um den Stream zu aktivieren deaktiviert man den Eintrag „Stream disabled“ im Reiter „Settings“. Die Alarmierung wird im Reiter „Alarms“ durch das Häkchen „Active“ aktiviert – dort wählt man auch die gewünschten Parameter, die zur Alarmierung führen sollen. Beachten sollte man, dass die „Grace period“ mindestens genauso lange wie „Minutes“ eingestellt ist, damit man pro Event jeweils nur eine Alarmierung erhält.

Graylog2_stream_2

Nach der Durchführung der oben genannten Schritte erhält man nun Alarm E-Mails unter der Adresse, die man bei seinem User angegeben hat. So sieht dann die Hauptseite des Streams aus:

Graylog2_stream_3

Hier nochmal ein Screenshot, wie dann ein Graph für fehlerhafte Loginversuche in der freien Wildbahn aussieht:

Graylog2_stream_4

Share on Facebook1Tweet about this on TwitterShare on Google+0Pin on Pinterest0