Zum Inhalt springen

Backend Login absichern

Erstellt am 27. August 2009 · 15 Antworten · letzte Antwort am 19. Februar 2012

Tags: Frage

einpraegsam.​net ·

Wenn ich SSL im BE aktiviere und das typo3 Verzeichnis umbenenne (da gab es doch mal eine Anleitung hierzu?), könnte ich mir Probleme bei diversen Extensions vorstellen.

Jemand Erfahrung?

just2b ·

security through obscurity hat noch nie funktioniert, IMO fängst du dir mehr ärger ein als es was bringt.

besser per htaccess/ip/getrennte server/whatever sperren als so

georg

einpraegsam.​net ·

In diesem Fall geht es nicht um meine Meinung sondern eine "Empfehlung" von einem externen Unternehmen.
Das BE über SSL zu verschlüsseln, halte ich übrigens auch für sinnvoll - aber der andere Punkt bereitet mir Kopfschmerzen.

Aber welche anderen Möglichkeiten (Links immer erwünscht) gäbe es gegen Brute Force Attacken aufs BE Login? IP Filter ist leider nicht möglich...

just2b ·

hallo,

naja empfehlungen sind nicht immer gescheit --- ich empfehle dir es nicht zu tun.

ansonsten: wie wärs mit einfach den login service erweitern, die IPs mitzuzählen und abe einer gewissen menge einfach das BE komplett zu sperren, da sollte sich doch ein hook finden lassen -- ansonsten den loginprozess frühzeitig abbrechen

einpraegsam.​net ·
just2b schrieb

ansonsten: wie wärs mit einfach den login service erweitern, die IPs mitzuzählen und abe einer gewissen menge einfach das BE komplett zu sperren, da sollte sich doch ein hook finden lassen -- ansonsten den loginprozess frühzeitig abbrechen

ja ok - aber ich wollte in diesen Mist eigentlich keine Zeit investieren - gibts nichts fertiges?

Ich habe es hier leider ohne Erfolg versucht nach drei Falscheingaben den BE_User zu deaktivieren:
#92477

LutzOMat ·
einpraegsam.net schrieb
just2b schrieb

ansonsten: wie wärs mit einfach den login service erweitern, die IPs mitzuzählen und abe einer gewissen menge einfach das BE komplett zu sperren, da sollte sich doch ein hook finden lassen -- ansonsten den loginprozess frühzeitig abbrechen

ja ok - aber ich wollte in diesen Mist eigentlich keine Zeit investieren - gibts nichts fertiges?

Ich habe es hier leider ohne Erfolg versucht nach drei Falscheingaben den BE_User zu deaktivieren:
#92477

Hallo zusammen, da ich vor kurzem auch ne Typo3 Seite begonnen habe, habe ich mich ebenfalls mit dem Problem der Attacken gegen die Login-Seite befasst. Als einfach funktionierende Lösung hat sich fail2ban herausgestellt ( http://www.fail2ban.org )
Das kann man allerdings nur dann installieren, wenn man Root-Rechte hat, also auf nem virtuellen Server oder nem echten Root-Server.

Hat man also fail2ban installiert, dann funktioniert es so:

=== Zur jail.conf folgende Zeilen hinzugefügen
[apache-typo3]
enabled = true
port = http,https
filter = apache-typo3
logpath = /var/log/apache*/*access.log
maxretry = 7
findtime = 3600
bantime = 7200

=== Den Filter apache-typo3 erstellen (das ist die Datei apache-typo3.conf im Ordner filter.d)
Die Datei muss mindestens folgenden Inhalt haben:
[Definition]
failregex = ^<HOST> -.*GET.*/login-alert-error\.gif
^<HOST> -.*POST.*/typo3/index\.php
ignoreregex =

=== Jetzt zur Erklärung: Warum und wie funktioniert das ?
Fail2ban prüft die angegebene Protokolldatei (hier access.log) in Sekundenabständen nach Veränderungen. Wenn eine Anmeldung stattfindet, dann wird immer kurzfristig die Seite /typo3/index.php aufgerufen und von dort aus die Login-Parameter gepostet. Wenn die Anmeldung fehlschlägt, wird erstens das Bild login-alert-error.gif angezeigt und 2tens erneut versucht die Parameter zu posten.

In der Konfiguration habe ich festgelegt, dass 7 mal innerhalb einer Stunde (3600sec) diese Ereignisse auftreten dürfen. Danach wird die entsprechende IP-Adresse für 2 Stunden (7200sec) verbannt.

Die Parameter maxretry, findtime, bantime sollte jeder nach Lust und Laune einstellen, allerdings:
Werte < 4 werden Ärger machen, denn da beim ersten Fehlversuch sowohl das Bild als auch das Script geladen werden, sind die ersten 2 Ereignisse von fail2ban schon mit einem Fehlversuch aufgebraucht !
Den dritten braucht man zu 2 ten Anmeldung.
Daher mein Tip: maxretry >= 5 einstellen !

Wer es braucht, kann sich die Datei aus dem Anhang laden.

Ich hoffe, dass hilft Euch weiter
Lutz

apache-typo3.conf
937B
mirco ·

Habe gerade fail2ban auf meinem Squeeze basierten Root-Server installiert, leider bekomm ich ne Fehlermeldung:

[root@www ~]
 7# /etc/init.d/fail2ban restart
Restarting authentication failure monitor: fail2banTraceback (most recent call last):
  File "/usr/bin/fail2ban-client", line 401, in <module>
    if client.start(sys.argv):
  File "/usr/bin/fail2ban-client", line 370, in start
    return self.__processCommand(args)
  File "/usr/bin/fail2ban-client", line 180, in __processCommand
    ret = self.__readConfig()
  File "/usr/bin/fail2ban-client", line 375, in __readConfig
    ret = self.__configurator.getOptions()
  File "/usr/share/fail2ban/client/configurator.py", line 65, in getOptions
    return self.__jails.getOptions(jail)
  File "/usr/share/fail2ban/client/jailsreader.py", line 64, in getOptions
    ret = jail.getOptions()
  File "/usr/share/fail2ban/client/jailreader.py", line 75, in getOptions
    ret = self.__filter.read()
  File "/usr/share/fail2ban/client/filterreader.py", line 53, in read
    return ConfigReader.read(self, "filter.d/" + self.__file)
  File "/usr/share/fail2ban/client/configreader.py", line 59, in read
    SafeConfigParserWithIncludes.read(self, [bConf, bLocal])
  File "/usr/share/fail2ban/client/configparserinc.py", line 105, in read
    fileNamesFull += SafeConfigParserWithIncludes.getIncludes(filename)
  File "/usr/share/fail2ban/client/configparserinc.py", line 76, in getIncludes
    parser.read(resource)
  File "/usr/lib/python2.5/ConfigParser.py", line 267, in read
    self._read(fp, filename)
  File "/usr/lib/python2.5/ConfigParser.py", line 490, in _read
    raise e
ConfigParser.ParsingError: File contains parsing errors: /etc/fail2ban/filter.d/apache-typo3.conf
        [line  3]: '^<HOST> -.*POST.*/typo3/index\\.php\n'
 failed!

Bin zu Regex unerfahren um da nen Fehler zu finden...

Ach und die angehängte apache-typo3.conf ist leer... Hab es halt genau so eingefügt wie oben beschrieben

/etc/fail2ban/filter.d/apache-typo3.conf erstellt

[Definition]
failregex = ^<HOST> -.*GET.*/login-alert-error\.gif
^<HOST> -.*POST.*/typo3/index\.php
ignoreregex =

und am Ende der /etc/fail2ban/jail.conf

[apache-typo3]
enabled = true
port = http,https
filter = apache-typo3
logpath = /var/log/apache2/*access.log
maxretry = 6
findtime = 1800
bantime = 7200
LutzOMat ·

Hallo Mirco,
in der Tat scheint mit der Datei was schief gelaufen zu sein. Der Fehler den Du hast liegt vermutlich am Zeilenanfang / ende oder so. Insofern ist das Runterladen der Datei natürlich sinnvoller. Hoffentlich klappts mit der neuen

apache-typo3.conf
937B
mirco ·
LutzOMat schrieb

Also ladet es an folgender Stelle runter:
http://www.ilLUTZmination.de/fileadmin/download/apache-typo3.conf.zip

Jetzt klappt der Download! Und der Dienst läßt sich starten:

[root@www ~]
2# mv apache-typo3.conf /etc/fail2ban/filter.d/
[root@www ~]
3# /etc/init.d/fail2ban restart
Restarting authentication failure monitor: fail2ban.

Nach ner Anpassung der jail.conf:

- logpath = /var/log/apache2/*access.log
+ logpath = /var/log/apache2/access1-*.log

besteht es nun auch den Test via UMTS:

2010-06-14 11:01:22,763 fail2ban.actions: WARNING [apache-typo3] Ban 80.187.101.155

Also sag ich herzlichen Dank und lass das Typo3 nun mit bestem Gewissen auf die Welt los!

Greetz
Mirco

Rookie ·

Hallo zusammen,

ich wollte fail2ban auch in diesem Zusammenhang ausprobieren.
Bei mir greift fail2ban aktuell leider nicht, weil bei mir die Datei login-alert-error.gif durch Cache-Einstellungen nicht erneut übertragen wird.
Man kann es aber zumindestens per Strg+F5 erzwingen.

Falls ich noch eine Lösung finde, werde ich posten.

Viele Grüße
Ulf

LutzOMat ·

Hallo Rookie,

selbst wenn login-alert-error.gif durch Cache-Einstellungen nicht erneut geladen wird, muss fail2ban trotzdem ansprechen, weil /typo3/index.php auch gezählt wird und zumindestens das wird definitiv neu aufgerufen. Nur dauert es dann eben ein paar Versuche mehr. Beobachte mal Dein Apache access.log bei diversen Anmelde-Versuchen.
Für JEDEN Versuch sollte POST /typo3/index.php in der access.log auftauchen

Grüsse,
Lutz

Rookie ·

Hallo Lutz,

danke für die Info. So ausdauernd war ich wieder nicht :-(.
Ich habe jetzt aber noch weiteres rausgefunden. Zuerst einmal: mod_pagespeed ist unschuldig. Die Cache-Header, die ich in Typo3 aktiviert hatte, sind schuld.

Deswegen habe ich in der Apache config jetzt noch folgende Zeilen eingefügt:

<Directory /srv/www/vhosts/vhostname/htdocs/typo3/>
    <IfModule mod_expires.c>
        # turn on the module for this directory
        ExpiresActive off
    </IfModule>
</Directory>

Ich werde es jetzt aber noch mal mit Deinen Hinweisen ausprobieren.
Danke schön.

Viele Grüße
Ulf

Rookie ·

Lutz, Du hast vollkommen Recht. Es dauert zwar ein paar Klicks länger funktioniert aber auch. Immer diesen ungeduldigen Admins ;-).
Suuuuper.

Vielen Dank.
Viele Grüße

Ulf