Zoneminder - new version, new logs #2643
Comments
Well I'm not sure... perhaps it simply depends on deployment (or selected authentication) backend.
It looks now, that the log-entry has also different format of timestamp (that fail2ban doesn't provide as standard datepattern at the moment), so it will never match without it. This would be correct $ fail2ban-regex -vv -d '^%m/%d/%y %H:%M:%S(?:\.%f)' \
'02/26/20 11:00:10.720338 web_php[1698].ERR [192.168.0.100] [Could not retrieve user testuser details] at includes/auth.php line 278' \
'^\s*web_php\[\d+\]\.ERR \[<HOST>\] \[Could not retrieve user \S+ details\]'
...
Failregex: 1 total
|- #) [# of hits] regular expression
| 1) [1] ^\s*web_php\[\d+\]\.ERR \[<HOST>\] \[Could not retrieve user \S+ details\]
| 192.168.0.100 Wed Feb 26 11:00:10 2020
`-
...
Date template hits:
|- [# of hits] date format
| [1] ^Month/Day/Year2 24hour:Minute:Second(?:\.Microseconds)
`-
Lines: 1 lines, 0 ignored, 1 matched, 0 missedFor your 0.9th version the filter may look like: [Definition]
failregex = ^\s*web_php\[\d+\]\.ERR \[<HOST>\] \[Could not retrieve user \S+ details\]
[Init]
datepattern = ^%%m/%%d/%%y %%H:%%M:%%S(?:\.%%f)Newer versions can specify both directly in jail.local: [zoneminder]
filter =
failregex = ^\s*web_php\[\d+\]\.ERR \[<HOST>\] \[Could not retrieve user \S+ details\]
datepattern = ^%%m/%%d/%%y %%H:%%M:%%S(?:\.%%f)Just the message |
|
Ah, great point. I would need to count as a failure the not found user and: |
|
No, I don't think so, it is enough to anchor it to begin only: failregex = ^\s*web_php\[\d+\]\.ERR \[<HOST>\] \[(?:Could not retrieve user|Login denied for user) \S+
datepattern = ^%%m/%%d/%%y %%H:%%M:%%S(?:\.%%f) |
ZM has gone from http auth to bcrypt. |
stand by; reading again.... missed the -or- :/
So your say'n I can remove the old zoneminder.conf and just put it in the jail.local for 0.10.2, right? |
You don't need to remove something. And yes you can put it directly in jail (since 0.10 the Lines 682 to 683 in ef1eaf9
Exactly, it will cause that jail doesn't have filter. |
|
Works great with: However after forcing failed attempts: In jail.local |
What is your point?
Unfortunately |
|
My bad, pasted wrong content :/ edited post. |
|
I don't know you timezone, but times you see in output of fail2ban-regex look obsolete to me. And may be the missed line said exactly what you miss: Better try to correct the zone (either in service or in your system) - so you've same time in log and fail2ban (system) at end. |
|
Yeah, caught that. fixed. Starting new tests. Quick side question, are the ports definitions read from the /etc/services file? |
It depends on which banaction is used (fail2ban supply it to the action as it is specified without internal modifications). Most of default actions (like iptables, nftables etc) will check that against |
|
I'm just using default actions. getting closer.... I've used /etc/services to define all the ports used by zoneminder for it's multi-port feature. And in jail.conf Is this even gonna work? |
This is just a first message, which shall be followed by command line (that could explain what is wrong there, as well as an output of command execution (failed message, that could point what exactly is wrong). For example if multiport does not supported by your kernel, no matter how you supply the ports via aliases or numeric - it will fail, so you have to use other action (like iptables-allports) in this case. |
|
Welp, that's the limit of my understanding. I'm using a stock UB18.04.4 LTS server. I'm not the guy who modifies his kernel. Now my Chevy is another story ;) That's the full screen out. I started out trying to have f2b read the new zoneminder logs, but now I'm not sure what's up. |
|
I'm going to try the obvious and just list each port individually... linear, I know, but trouble shooting. |
|
Well, this is embarrassing.... bantime = 1hr doesn't work multiport works fine. spec'ing ports in /.../services works fine. new zoneminder filter works fine. |
No, it is not. As I requested more information, I was still speaking about
Sure it does not. See man page JAIL.CONF(5) for TIME ABBREVIATION FORMAT.
Ok, so it's time to make a PR for new filter zoneminder-bcrypt.conf (or zoneminder-php.conf)... :) |
|
Thanks @sebres ! zoneminder-php.conf seems to make more sense since we're looking at the php log. |
|
I am having some trouble to get this working. I should say that I am runnung Fail2ban in Crazymax docker but there seems to be a regex problem for me? Just realized my problem only was occuring in docker container. It is working when Fail2ban is installed on the server itself. |
|
This PR may resolve this issue #2984 |
|
Starting with ZM 1.36.20 the time stamp within the logs reflects the time zone as set within ZM and so can have many different variations. To solve this with a Regex is beyond my knowledge, can someone here help resolve this? Example of the new log time stamp from 1.36.20 Example of the log time stamp from 1.36.19 |
|
if the TZ ( datepattern = ^%%m/%%d/%%y, %%I:%%M:%%S %%p \S+\.%%f
^%%m/%%d/%%y %%H:%%M:%%S\.%%f(it'd parse both formats) PoC (test with fail2ban-regex) |
|
Thank you, So for my understanding Fail2ban is using the Python strftime() function? I was getting a little confused with the missing leading zero in the month "7" instead of "07" and passing the string %%-m as this is the function to ignore the leading zero, so I assume this isnt a requirement. Also I noted you have passed the %p Locale’s AM or PM, |
fail2ban uses its own processing (a bit modified
It can recognize both But also python's You can try But possibly it would be better to use
It is impossible to say what was wrong without to known what exactly you were trying.
Yes, but both are not really mandatory (just if they are missing in pattern, it would match to |
|
Ah the ever changing zoneminder.... I'm not getting matches with the above formats. My fail2ban log is as follows: A failed login in web_php.log looks like this And a regx test looks like this After running the regex test the fail2ban log complains of a timezone error in jail (jail.local I presume) I'm running php 8.1; date.timezone = America/Los_Angeles What am I missing? |
# with failregex:
fail2ban-regex -d '^%m/%d/%y, %I:%M:%S %p %Z\.%f' "$log_or_msg" '^\s*web_php\[\d+\]\.ERR \[<ADDR>\] \[(?:Could not retrieve user|Login denied for user) \S+'
# with filter and modified prefregex:
fail2ban-regex -d '^%m/%d/%y, %I:%M:%S %p %Z\.%f' "$log_or_msg" 'zoneminder[prefregex="^\s*web_php\[\d+\]\.(?:ERR|WAR) \[<ADDR>\] <F-CONTENT>\[(?:Login denied|Could not retrieve).*</F-CONTENT>$"]'As for filter or jail, I'd use something like this: [zoneminder]
...
datepattern = ^%%m/%%d/%%y, %%I:%%M:%%S %%p %%Z\.%%f
# failregex = ^\s*web_php\[\d+\]\.ERR \[<ADDR>\] \[(?:Could not retrieve user|Login denied for user) \S+
prefregex = ^\s*web_php\[\d+\]\.(?:ERR|WAR) \[<ADDR>\] <F-CONTENT>\[(?:Login denied|Could not retrieve).*</F-CONTENT>$
This has nothing to do with the subject - as one can guess this is something about wrong timezone logged by
To "fix" that, either correct the time zone of logging service (e. g. restart |
|
@sebres I found the matching date pattern finally....
|
|
I guess the dot-token in
|
Environment:
Fill out and check (
[x]) the boxes which apply. If your Fail2Ban version is outdated,and you can't verify that the issue persists in the recent release, better seek support
from the distribution you obtained Fail2Ban from
The issue:
zoneminder.conf not appropriate for current version of zoneminder
Summary here
Zoneminder recently released a new version 1.34 and the method for authentication changed and is now logged differently.
Login failures now appear in /var/cache/zm/web_php.log in the form:
The current zoneminder.conf no longer works.
Steps to reproduce
f2bregex test date format
Expected behavior
Read date
Observed behavior
Does not read date
Any additional information
zoneminder logging must be set to at least error.
Configuration, dump and another helpful excerpts
Any customizations done to /etc/fail2ban/ configuration
Relevant parts of /var/log/fail2ban.log file:
preferably obtained while running fail2ban with
loglevel = 4Relevant lines from monitored log files in question:
The text was updated successfully, but these errors were encountered: