Fail2Ban Problem - No Matches

🌐 Non-english support 🇩🇪 Deutsch (german)
1

Hallo liebe Nextcloud Community,

ich habe ein Problem mit der Absicherung meiner Nextxcloud 11-Installation. Leider funktioniert keiner der gängigen failregex-Strings die man so in diversen Tutorials findet und auch ein selbstgebauter regulärer Ausdruck führt beim fail2ban-regex Test nicht zu matches, obwohl ich mit gleichem String bei einem grep die gewünschten outputs bekomme.

Ein entsprechender Auszug aus dem nextcloud.log sieht so aus:

{“reqId”:“ngZGt1OAQCsVVGINeQ18”,“remoteAddr”:“192.168.1.100”,“app”:“core”,“message”:“Login failed: ‘dbb’ (Remote IP: ‘192.168.1.100’)”,“level”:2,“time”:“March 09, 2017 10:46:44”,“method”:“POST”,“url”:“/login”,“user”:“–”,“version”:“11.0.2.7”}

Meine nextcloud.config für Fail2Ban sieht folgendermaßen aus:

[INCLUDES]
before = common.conf

[Definition]
failregex = Login failed.*Remote IP: '<HOST>'
ignoreregex =

Die Fail2Ban jail.conf sieht so aus:

[nextcloud]

enabled = true
filter = nextcloud
port = http,https
logpath = /var/log/nextcloud*.log
findtime = 1800
bantime = 1800
maxretry = 3

Die Logconfig in der config.php meiner Nextcloud-Installation sieht so aus:

'log_type' => 'file',
'logfile' => '/var/log/nextcloud.log',
'loglevel' => 2,
'syslog_tag' => 'Nextcloud',
'logdateformat' => 'F d, Y H:i:s',
'log_rotate_size' => 104857600,

Wenn ich mit grep "Login failed.*Remote IP: '.*'" /var/log/nextcloud.log den Regex-String teste bekomme ich die gewünschten Einträge aus dem Log zurück, aber wenn ich den String mit fail2ban-regex /var/log/nextcloud.log /etc/fail2ban/filter.d/nextcloud.conf direkt über Fail2Ban teste, bekomme ich 0 Matches.

Kann sich wer erklären warum das so ist und wie ich Fail2Ban mit Nextcloud zum laufen bekomme?

Vielen Dank für eure Unterstützung!

Gruß

Nico

2

Hi Nico,

erste Idee: hast du vielleicht in der /etc/fail2ban/jail.local diese IP oder den IP-Bereich in dem Log als ignoreIP definiert?
ignoreip = 127.0.0.1/8 192.168.1.1/24

Bei meiner zweiten Idee bin ich nicht sicher, ob es was ausmacht, aber bist du sicher, dass
logpath = /var/log/nextcloud*.log
so richtig ist? Ich würde den * entfernen. Du willst ja ohnehin das aktuelle Log überwachen.

Hoffentlich ist da schon etwas hilfreiches dabei.

P.S. du solltest den Filter lieber in der jail.local definieren, anstatt in der jail.conf

3

Hallo Schmu,

danke für deine Antwort. Wenn ich den Test über fail2ban-regex durchführe, sehe ich folgendes:

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

Use   failregex file : /etc/fail2ban/filter.d/nextcloud.conf
Use         log file : /var/log/nextcloud.log


Results
=======

Failregex: 0 total

Ignoreregex: 0 total

Date template hits:

Lines: 1 lines, 0 ignored, 0 matched, 1 missed
|- Missed line(s):
|  {"reqId":"ngZGt1OAQCsVVGINeQ18","remoteAddr":"146.0.114.3","app":"core","message":"Login failed: 'dbb' (Remote IP: '146.0.114.3')","level":2,"time":"March 09, 2017 10:46:44","method":"POST","url":"\/login","user":"--","version":"11.0.2.7"}

Er liest also tatsächlich das komplette Log ein. Derzeit steht nur 1 Zeile da, da ich vorhin das Log mal geleert habe, da es über 23000 Zeilen hatte und der Test jedes mal ~20sec dauerte.

Edit: Achso, nein die ich habe keine IP ignoriert :slight_smile:

4

Hm, wirklich sicher bin ich nicht, warum das nicht funktioniert, aber vielleicht magst du mal die RegEx probieren, die ich erfolgreich im Einsatz habe:
failregex = ^.*Login failed: '.*' \(Remote IP: '<HOST>'.*$

Ich weiß nur noch, dass ich daran auch eine Weile rumprobiert hatte es damit dann funktionierte.
Meine ganze nextcloud.conf sieht so aus:

[Definition]
failregex = ^.*Login failed: '.*' \(Remote IP: '<HOST>'.*$

Meine jail.local:

[nextcloud]
enabled = true
filter = nextcloud
banaction = iptables-allports
protocol = all
port = anyport
logpath = /var/ncdata/nextcloud.log

Viel Erfolg! :slight_smile:

5

Ich habe deine Config jetzt 1:1 übernommen (incl jail.conf/jail.local) und bekomme nach wie vor 0 Hits -.-
Da dahinter ein Active Directory hängt muss das funktionieren, sonst kann ich die Nextcloud gleich wieder deinstallieren :confused:

6

Ja, das verstehe ich.
Also ich habe jetzt eine ganze Weile damit rumexperimentiert und mit meiner RegEx klappt es gegen deinen Logeintrag auch nicht. Bei mir funktioniert es aber durchaus und daher habe ich mal meine Logeinträge mit deinen verglichen.
Der einzige Unterschied bei unseren Logeinträgen ist das Zeitformat. Während du hast:
MON Day, Year 12hour:Minute:Second
habe ich:
Year-Month-DayT24hour:Minute:Second+TimeOffset

Im Test habe ich deinen Logeintrag und meinen in eine Datei test.txt kopiert und die RegEx drauf laufen lassen:

root@nextcloud:~/NC# fail2ban-regex -e us-ascii /root/test.txt /etc/fail2ban/filter.d/nextcloud.conf

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

Use   failregex filter file : nextcloud, basedir: /etc/fail2ban
Use         log file : /root/test.txt
Use         encoding : us-ascii


Results
=======

Failregex: 1 total
|-  #) [# of hits] regular expression
|   1) [1] ^.*Login failed: '.*' \(Remote IP: '<HOST>'.*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [1] Year-Month-Day[T ]24hour:Minute:Second(?:\.Microseconds)?(?:Zone offset)?
`-

Lines: 2 lines, 0 ignored, 1 matched, 1 missed [processed in 0.00 sec]

Meine Zeile findet er also und zeigt auch mein Datetimeformat als hit an.
So wie ich das sehe, nutze ich NC- Default für das Zeitformat. Es dürfte dir vermutlich helfen entweder dein Zeitformat umzustellen oder fail2ban auf dein Zeitformat zu konfigurieren. Leider weiß ich für letzteres nicht, wie das richtig gemacht wird.
Default hat fail2ban wohl folgende Templates:

Date template hits:
|- [# of hits] date format
|  [0] (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?: Year)?
|  [0] Year(?P<_sep>[-/.])Month(?P=_sep)Day 24hour:Minute:Second(?:,Microseconds)?
|  [0] Day(?P<_sep>[-/])Month(?P=_sep)(?:Year|Year2) 24hour:Minute:Second
|  [0] Day(?P<_sep>[-/])MON(?P=_sep)Year[ :]?24hour:Minute:Second(?:\.Microseconds)?(?: Zone offset)?
|  [0] Month/Day/Year:24hour:Minute:Second
|  [0] Month-Day-Year 24hour:Minute:Second\.Microseconds
|  [0] TAI64N
|  [0] Epoch
|  [0] Year-Month-Day[T ]24hour:Minute:Second(?:\.Microseconds)?(?:Zone offset)?
|  [0] ^24hour:Minute:Second
|  [0] ^<Month/Day/Year2@24hour:Minute:Second>
|  [0] ^Year2MonthDay  ?24hour:Minute:Second
|  [0] MON Day, Year 12hour:Minute:Second AMPM
|  [0] ^MON-Day-Year2 24hour:Minute:Second
`-

Ich dachte erst dein Log würde auf “MON Day, Year 12hour:Minute:Second AMPM” zutreffen, aber dem ist wohl offensichtlich nicht so.
Ich hoffe das hilft nun :slight_smile:

7

Vielleicht geht folgendes aus dem fail2ban Wiki in die Richtung:

Ich bekomme die Fehlermeldung “Please check the format and your locale settings”

Die Meldung sieht in etwa so aus:

ERROR: time data did not match format: data=Mar 21 10:00:50 fmt=%b %d %H:%M:%S
ERROR: Please check the format and your locale settings.

Das ist ein bekannter Bug. Seit der Version 0.6.1, benutzt Fail2ban deine lokalen Einstellungen des Datums- und Zeitformats. Wie auch immer, einige Unholde achten nicht auf die lokalen Einstellungen und schreiben ihre Lognachrichten, indem sie den POSIX-Standard benutzen. Sieh dir folgendes an bug, um mehr Informationen zu erhalten.

Du könntest versuchen die LANG-Variable zu überschreiben:
# LANG=en_US /etc/init.d/fail2ban restart

Du kannst die verfügbaren lokalisieren mit:
# locale -a

Quelle: http://www.fail2ban.org/wiki/index.php/FAQ_german#Ich_bekomme_die_Fehlermeldung_.22Please_check_the_format_and_your_locale_settings.22

8

Tatsächlich kommt fail2ban nicht mit der Zeitformatierung 'logdateformat' => 'F d, Y H:i:s', in der config.php von Nextcloud zurecht.

Jetzt funktioniert es! Vielen Dank!

1 Like
9

Hallo zusammen
Ich wollte jetzt kein neues Thema hierfür aufmachen darum schreib ich mein Problem hier mal dazu, denn im Prinzip hab ich genau das gleiche wie hier schon behandelt wurde.
Ich benutze Fail2ban und Nextcloud 11 auf einem RaspberryPi und hab die besagten Config und Filter Daten hier weitestgehend übernommen.

[nextcloud]
enabled  = true
filter   = nextcloud
action   = %(action_mwl)s
logpath  = /var/www/nextcloud/nextcloud.log
port     = 80,443,tcp
findtime = 36000 
bantime = 36000
maxretry = 3


[Definition]

_daemon = nextcloud
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login faile$
            ^.*Login failed: '.*' \(Remote IP: '<HOST>'.*$
ignoreregex =


'log_type' => 'file',
  'syslog_tag' => 'Nextcloud',
  'logdateformat' => 'F d, Y H:i:s',
  'logfile' => '/var/www/nextcloud/nextcloud.log',
  'loglevel' => 2,

Allerdings kann ich auch machen was ich will, wenn ich das Kommando zum überprüfen ausführe werden zwar Lines erkannt aber alle samt werden bei missed angezeigt. Die Locale Einstellungen sind soweit alle auf DE und UTF8 gesetzt und auch das Zeitformat steht auf Europe/Berlin. Leider bin ich aus dem teil mit der Zeitformatierung nicht so ganz schlau geworden.
Hier noch ein Auszug aus meiner Log Datei

{"reqId":"ytVfMYBbbVvBrReEWxVl","remoteAddr":"73.213.52.227","app":"core","message":"Trusted domain error. \"73.213.52.227\" tried to access using \"MeineIP\" as host.","level":2,"time":"2017-03-09T22:41:37+00:00","method":"POST","url":"\/","user":"--","ver$

Ich hoffe hier kann mir jemand von euch helfen.

10

Guten Morgen,

lösch mal diese Zeile aus deiner Nextcloud-Config:

'logdateformat' => 'F d, Y H:i:s',

Dann versuch dich mit ausgedachten Daten anzumelden um ein neuen Log-Eintrag zu generieren und überprüf die fail2ban-Config erneut.

Gruß

Nico

11

Hi @Select25 ,

wie Nico schon vorschlägt, solltest du es mal mit falschen Logindaten probieren und dann die Config gegen dein Nextcloud-Log testen. Die von dir genannte Zeile aus dem Logfile hat eine ganz andere Bedeutung und wird von der RegEx gar nicht erfasst.

12

Okay hab die Zeile aus der config gelöscht und mal mit falschen Login Daten getestet. Fail2ban hat hier dann einwandfrei funktioniert :slight_smile: Danke für die schnelle Hilfe :smiley:

Aber was ist das dann was in meinem Logfile aufgeführt wurde? Wie soll ich das verstehen? Leider bin ich noch nicht so ganz mit der Materie vertraut. Bin mich zwar grad am reinfinden aber das dauert :smiley:

13

Bei deiner Fehlermeldung hat es sich nicht um einen falschen Loginversuch gehandelt, sondern um einen Zugriff auf den Server über eine Adresse, die nicht in der config/config.php als trusted_domain eingetragen ist.

Beispiel:
In der config.ph steht als trusted_domain
localhost
sub.domain.de

Du hast aber per 192.168.1.100 auf den Server zugegriffen. Dann erscheint im Webbrowser auch eine Meldung, dass der Admin diese Adresse nicht als Trusted Domain eingetragen hat.

14

Ah okay also ist das schon eine vorherige Absicherung das niemand einfach so auf das Login Fenster zugreifen kann.

15

Ähm, ja, würde ich mal so sagen :slight_smile:
Du kannst es ja einfach noch mal testen, dass du über eine Adresse vom Server in deinem Browser eingibst, die nicht in den Trusted Domains aufgeführt ist und dann mal sehen, wie die Meldung aussieht.
So kannst du im Grunde absichern, dass nur Nutzer auf deinen Server zugreifen, die dies per FQDN (Full Qualified Domain Name) tun und Nutzer, die nur IPs abgrasen eben kein Login-Screen zu sehen bekommen.

16

Ahhh okay :smiley: sehr verständlich.
Wenn ich jetzt über die Adresse meiner Myfritz DynDNS zugreife funktioniert das einwandfrei, wenn ich das allerdings über meine IP tue kommt die besagte Meldung.
Danke für die schnelle Hilfe :slight_smile: