[gelöst] ISPC mit Fail2Ban absichern

[DarkTrinity]

Hallo Zusammen

ich würde gerne die LogIns zur ISPC-UI mit Fail2Ban absichern. Aus irgendeinem Grund scheint das aber nicht zu klappen....

Die Logs laufen unter /var/log/ispconfig/auth.log ein

Failed login for user 'deded' from aaa.bbb.ccc.dd at 2020-07-10 13:07:18

Dazu habe ich folgenden Filter /etc/fail2ban/filter.d/ispc.conf geschrieben:

[Definition]
failregex = ^Failed login for user .* from <HOST> .*$
ignoreregex =

Und diesen Eintrag in der /etc/fail2ban/jail.local :

[ispc]
enabled = true
port = https,http
filter = ispc
logpath = /var/log/ispconfig/auth.log
maxretry = 4

Ein fail2ban-regex /var/log/ispconfig/auth.log /etc/fail2ban/filter.d/ispc.conf ergab:

Running tests
=============

Use   failregex filter file : ispc, basedir: /etc/fail2ban
Use         log file : /var/log/ispconfig/auth.log
Use         encoding : UTF-8


Results
=======

Failregex: 47 total
|-  #) [# of hits] regular expression
|   1) [47] ^Failed login for user .* from <HOST> .*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [48] ExYear(?P<_sep>[-/.])Month(?P=_sep)Day(?:T|  ?)24hour:Minute:Second(?:[.,]Microseconds)?(?:\s*Zone offset)?
`-

Lines: 48 lines, 0 ignored, 47 matched, 1 missed
[processed in 0.06 sec]

|- Missed line(s):
|  Successful login for user 'udontknowme' from aaa.bbb.ccc.d at 2020-07-10 10:48:20 with session ID gbkrlavkhs6f28khkl8f3sfsio

Aber wenn ich versuche einen BAN zu produzieren, indem ich b ewusst falsche LogIns produziere, wird meine IP nicht gebannt. Die o.g. Logfile wurde aber entsprechend befüllt.

Dann habe ich versucht im Filter den Port auf den numerischen Wert 8080 zu setzen, was ebenfalls nicht zum Erfolg führte.

Was mache ich hier falsch ?

 

[Pixelpirat]

Probie mal diese Regexpr

[Definition]
failregex = ^Failed login for user '.*' from .*$
ignoreregex = ^Successful login for user .*$

 

[DarkTrinity]

Probie mal diese Regexpr

[Definition]
failregex = ^Failed login for user '.*' from .*$
ignoreregex = ^Successful login for user .*$

Damit wäre ja kein <HOST> Container für F2B da....
Aber ich habe ISPC nun mittels .htaccess geschützt - bei falschem LogIn wird der HTTP Code 401 protolliert, auf den F2B dann ggf anschlagen würde

 

[Pixelpirat]

Ich habe das Ganze jetzt mal etwas genauer unter die Lupe genommen. Irgend etwas stimmte nicht. Es hat eine Zeit gedauert bis ich heraus gefunden habe, woran es bei mir lag. Der DUAL-Stack hat hier zugeschlagen.

Aber zuerst meine funktionierende Konfiguration:

/etc/fail2ban/jail.conf

[ispconfig]

port    = 8081,8443
filter = ispconfig
logpath = /var/log/ispconfig/auth.log

/etc/fail2ban/filter.d/ispconfig.conf

# Fail2Ban filter for ISPConfig Login
#
#

[Definition]
failregex = ^Failed login for user .* from <HOST> .*$
ignoreregex =

/etc/fail2ban/jail.d/jail.local

[ispconfig]
enabled = true
filter = ispconfig
maxretry = 5
bantime = 15m

Ausgabe von ip6tables -L -n | grep ispconfig -A 5

f2b-ispconfig  tcp      ::/0                 ::/0                 multiport dports 8081,8443


Chain f2b-ispconfig (1 references)
target     prot opt source               destination
REJECT     all      XXXX:16b8:XXXX:e700:dcdb:6d49:XXXX:7f46  ::/0                 reject-with icmp6-port-unreachable
R

Die Einträge in der FW werden erst sichtbar, nachdem ein Ban erfolgt ist. Zuerst funktionierte die Loginseite von ISPConfig trotzdem weiter. Die Ports http und https reichten nicht aus. Dann habe ich die Ports erweitert um die Ports 8081 und 8443 wo bei mir derzeit noch ispconfig läuft.

Das Verhalten von dem Dual-stack habe ich erst bemerkt als ich vom Mobilnetz aus die Login-Seite mit Fehleingaben zu Sperrung brachte. Irgendwann erinnerte ich mich an nmap.
Damit getestet waren die Ports nach der Sperrung nicht mehr gelistet. (Nmap listet per default keine gefilterten Ports)

Den endgültigen Test habe ich dann noch von einem anderen Server aus gemacht. Ebenfalls mit Dualstack ausgestattet. Auf der Konsole mit lynx die Fehllogins simuliert bis der erste "ban"-Eintrag der Zielmaschine erfolgte. Trotzdem war die Seite weiterhin erreichbar. Allerdings kamnen die nächsten Loginversuche von der anderen IP des Dualstackes. Erst als die 2. IP durch die Fehlversuche gesperrt wurde, ging nichts mehr auf den Ports. Mit nmap erneucht kontrolliert. Die Ports waren dicht.

Vielleicht hast Du einen Provider (wie 1und1) der dem Modem einen Dualstack verpasst. Versuch es nochmals anzugehen und den Fehler zu finden. Viel Erfolg.