Ein beliebtes und verbreitetes CMS wie Joomla! ist natürlich auch ein lukratives Ziel für Schadcode und ungewollte Besucher.
Auch wenn die Seite noch so klein und unwichtig scheint, so steckt dennoch mit dem Webserver i.d.R. eine mächtige Maschine dahinter, welche zudem 24h jeden Tag läuft und allerhand Dinge erledigen kann.
Eines der wichtigsten und zugleich einfachsten Dinge, sein CMS sicher zu halten ist die Aktualisierungen von Joomla! zu verfolgen und gerade wenn Sicherheitsthemen dabei waren, sie zeitnah zu installieren.
Joomla! Login Angriffsversuche - Bruteforce Attack
Bruteforce Angriffe sind sehr verbreitet, sind sie doch einfach auch per Skripte zu automatisieren. Dabei werden an Serverdienste oder eben CMS Login Versuche geschickt.
Früher gab es einen "admin" Account oder seine UserID, welcher sehr oft Ziel wurde. Immerhin haben die Angreifer dann schonmal einen Benutzernamen und die halbe Miete.
Mit reinem Versuchen werden dann Passwörter durchprobiert, bis dann doch mal eines funktioniert. Ab dann hat der Angreifer Zugriff auf die Seite und mehr oder weniger Rechte diese zu verändern oder Schadcode zu installieren.
Joomla! hat in seinem Log-Verzeichnis eine error.php, welche bei gescheiterten Anmeldeversuchen ähnliche Zeilen protokolliert:
2018-12-01T16:34:19+00:00 INFO 111.222.333.444 joomlafailure Benutzername und Passwort falsch oder das Benutzerkonto existiert noch nicht!
2018-12-01T16:34:19+00:00 INFO 111.222.333.444 joomlafailure Username and password do not match or you do not have an account yet.
Auf diese Einträge können wir den Dienst Fail2Ban setzen, um die IP-Adresse zu sperren, welche zu oft einen solchen Eintrag erzeugt.
Fail2Ban Regeln zur Auswertung der Joomla! error.php
Als erstes erstellen wir eine Definition, welche die Datei auf das Vorkommen gewisser Inhalte für jede Zeile überprüft:
mcedit /etc/fail2ban/filter.d/apache-joomla.conf
[Definition]
failregex = ^.*INFO <HOST>.*joomlafailure.*(Benutzername|Username).*Hier haben wir den Regex, welcher unsere englischen wie deutschen Zeilen ermittelt.
Danach können wir den eigentlichen Jail definieren:
mcedit /etc/fail2ban/jail.local
# etwas nach unten scrollen bis all die Jails beginnen
[joomla-auth]
enabled = true
port = http,https
filter = apache-joomla
logpath = /var/www/*/web/administrator/logs/error.php
findtime = 43200
bantime = 86400
maxretry = 5
An diesem Beispiel setze ich auf die normalen sowie verschlüsselten Ports.
Die Web-Verzeichnisse sind hier von einem ISPConfig Server und müssen evtl. angepasst werden, auch wenn ältere Joomla! Installationen vorhanden sind, welche ihren Log-Order noch nicht im Administratorverzeichnis haben.
Hier suche ich nach 5 gescheiterten Versuchen der gleichen IP Adresse innerhalb von 12h.
Diese bekommt dann eine Sperre für 24h.
Nun den Dienst noch neu starten und in der Logdatei von Fail2Ban sollten sämtliche error.log Dateien der Joomla! Webseiten erscheinen.
service fail2ban restart
# um die Logdatei von Fail2Ban zu prüfen
mcedit /var/log/fail2ban.log
Bei neueren Debain Systemen gibt der obige Service Befehl keine Rückmeldung.
Fail2Ban startet nicht, sobald ein Fehler vorliegt, was gerade bei Regex-Ausdrücken schnell der Fall sein kann.
Dann heißt es nochmal alles gut ansehen bzw. die Logausgabe von Fail2Ban genauer einsehen, was dem Dienst genau nicht gefällt:
fail2ban-client -d -vvv | grep [Ee]rror
Hier geht dann i.d.R. eigentlich die fehlerhafte Stelle hervor.
In meinem Fall waren es lange Zeit fehlende Logdateien, was bei mir u.a. der Fall war, da ich ältere und neuere Joomla! Installationen hatte.
Joomla! Logpfad anpassen
Um die Jails einheitlich auf den aktuellen Stand zu bringen, habe ich einfach die Log Pfade aus dem Root jeder Joomla! Installation in den Administratorbereich kopiert.
Hier ist er in neueren Joomla! Installationen eh zu finden.
Es ist aber unbedingt daran zu denken, dass in der Joomla! Konfiguration unter System das Protokollverzeichnis entsprechend aktualisiert wird!
Was soll der Aufwand? Dann währen doch Millionen Joomla! Seiten gefährdet?
Stimmt... Aber wenns dann dochmal die eigene Seite erwischt hat man selbst die Probleme und den Aufwand es wieder zu korrigieren.
Folglich ist es in meinen Augen immer besser, lieber zuvor in überschaubarer Zeit Maßnahmen zu ergreifen, die vielleicht für den ein oder anderen Angriff ausreichen.
Außerdem erzeugen einmal gesperrte IP-Adressen auch keine weitere Serverlast mehr, da sie mit ihrer Anfrage gar nicht mehr bis zum Login kommt.
Sind IP-Adressen immer und immer wieder in der Sperrliste, können sie auch ganz ausgeschlossen werden.
