fail2ban not banning and just does nothing
Environment:
- Fail2Ban version (including any possible distribution suffixes): v0.9.3
- OS, including release name/version: Ubuntu 16.04.3 LTS
- [x] Fail2Ban installed via OS/distribution mechanisms
- [x] You have not applied any additional foreign patches to the codebase
The issue:
fail2ban just not banning. Does nothing.
My jail.local file:
[sshd]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/fail2ssh.log
findtime = 600
maxretry = 6
bantime = 86400
fail2ban-client status
|- Number of jail: 1
`- Jail list: sshd
Meanwhile in my auth.log:
Dec 4 21:01:59 vps447398 sshd[21628]: Failed password for root from 42.7.26.61 port 3080 ssh2
Dec 4 21:02:13 vps447398 sshd[21628]: message repeated 5 times: [ Failed password for root from 42.7.26.61 port 3080 ssh2]
abriginets
All 37 comments
What do you see in fail2ban.log?
Do you see this IP there?
How many lines [sshd] Found <IP> for the same IP? Please note, that it will banned only after 6 (maxretry) attempt within 10 minutes (findtime) time window.
sebres
on 4 Dec 2017
What do you see in fail2ban.log?
2017-12-04 21:28:14,814 fail2ban.database [4031]: INFO Connected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3'
2017-12-04 21:28:14,820 fail2ban.jail [4031]: INFO Creating new jail 'sshd'
2017-12-04 21:28:14,833 fail2ban.jail [4031]: INFO Jail 'sshd' uses pyinotify
2017-12-04 21:28:14,842 fail2ban.filter [4031]: INFO Set jail log file encoding to UTF-8
2017-12-04 21:28:14,845 fail2ban.jail [4031]: INFO Initiated 'pyinotify' backend
2017-12-04 21:28:14,850 fail2ban.filter [4031]: INFO Set maxRetry = 6
2017-12-04 21:28:14,851 fail2ban.filter [4031]: INFO Set findtime = 600
2017-12-04 21:28:14,852 fail2ban.filter [4031]: INFO Set jail log file encoding to UTF-8
2017-12-04 21:28:14,852 fail2ban.actions [4031]: INFO Set banTime = 86400
2017-12-04 21:28:14,856 fail2ban.filter [4031]: INFO Added logfile = /var/log/auth.log
2017-12-04 21:28:14,860 fail2ban.filter [4031]: INFO Set maxlines = 10
2017-12-04 21:28:14,906 fail2ban.server [4031]: INFO Jail sshd is not a JournalFilter instance
2017-12-04 21:28:14,911 fail2ban.jail [4031]: INFO Jail 'sshd' started
There's no any Found <IP> or Ban <IP> messages. Also, /var/log/fail2ssh.log is empty.
abriginets
on 4 Dec 2017
May this issue been caused because of /etc/ssh(instead of /etc/sshd) on my machine?
abriginets
on 4 Dec 2017
May this issue been caused because of /etc/ssh(instead of /etc/sshd) on my machine?
Nope.
What do you see if you execute this:
ln="Dec 4 21:01:59 vps447398 sshd[21628]: Failed password for root from 42.7.26.61 port 3080 ssh2"
fail2ban-regexp "$ln" /etc/fail2ban/filter.d/sshd.conf
Tested with current 0.9.x version:
Lines: 1 lines, 0 ignored, 1 matched, 0 missed.
And this:
?sudo? fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
Lines: 1 lines, 0 ignored, 1 matched, 0 missed [processed in 0.00 sec]
And
Lines: 18312 lines, 0 ignored, 4938 matched, 13374 missed [processed in 12.70 sec]
Hmm... Strange... No further ideas, except pyinotify backend does not work on your machine (tried "polling"?).
Can you puts fail2ban into DEBUG mode?
sudo fail2ban-client set loglevel DEBUG
Or if does not work, just start within DEBUG level (set it fail2ban.conf and restart).
And provide an excerpt of /var/log/fail2ban.log after some failure in auth.log...
Don't forget to switch back if you are ready...
sudo fail2ban-client set loglevel INFO
Here's the logs of fail2ban.log after log level DEBUG was set:
2017-12-04 23:59:38,287 fail2ban.transmitter [5325]: DEBUG Command: ['stop']
2017-12-04 23:59:38,287 fail2ban.asyncserver [5325]: DEBUG Removed socket file /var/run/fail2ban/fail2ban.sock
2017-12-04 23:59:38,287 fail2ban.asyncserver [5325]: DEBUG Socket shutdown
2017-12-04 23:59:38,287 fail2ban.server [5325]: INFO Stopping all jails
2017-12-04 23:59:38,287 fail2ban.server [5325]: DEBUG Stopping jail sshd
2017-12-04 23:59:39,126 fail2ban.actions [5325]: DEBUG Flush ban list
2017-12-04 23:59:39,127 fail2ban.action [5325]: DEBUG iptables -w -D INPUT -p tcp --dport ssh -j f2b-SSH
iptables -w -F f2b-SSH
iptables -w -X f2b-SSH
2017-12-04 23:59:39,229 fail2ban.action [5325]: DEBUG iptables -w -D INPUT -p tcp --dport ssh -j f2b-SSH
iptables -w -F f2b-SSH
iptables -w -X f2b-SSH -- stdout: b''
2017-12-04 23:59:39,229 fail2ban.action [5325]: DEBUG iptables -w -D INPUT -p tcp --dport ssh -j f2b-SSH
iptables -w -F f2b-SSH
iptables -w -X f2b-SSH -- stderr: b''
2017-12-04 23:59:39,229 fail2ban.action [5325]: DEBUG iptables -w -D INPUT -p tcp --dport ssh -j f2b-SSH
iptables -w -F f2b-SSH
iptables -w -X f2b-SSH -- returned successfully
2017-12-04 23:59:39,230 fail2ban.actions [5325]: DEBUG sshd: action terminated
2017-12-04 23:59:39,230 fail2ban.jail [5325]: INFO Jail 'sshd' stopped
2017-12-04 23:59:39,239 fail2ban.server [5325]: DEBUG Remove PID file /var/run/fail2ban/fail2ban.pid
2017-12-04 23:59:39,239 fail2ban.server [5325]: INFO Exiting Fail2ban
2017-12-04 23:59:39,457 fail2ban.server [24399]: INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.3
2017-12-04 23:59:39,457 fail2ban.database [24399]: INFO Connected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3'
2017-12-04 23:59:39,462 fail2ban.jail [24399]: INFO Creating new jail 'sshd'
2017-12-04 23:59:39,473 fail2ban.jail [24399]: INFO Jail 'sshd' uses pyinotify
2017-12-04 23:59:39,482 fail2ban.filter [24399]: INFO Set jail log file encoding to UTF-8
2017-12-04 23:59:39,484 fail2ban.jail [24399]: INFO Initiated 'pyinotify' backend
2017-12-04 23:59:39,489 fail2ban.filter [24399]: INFO Set jail log file encoding to UTF-8
2017-12-04 23:59:39,489 fail2ban.filter [24399]: INFO Set findtime = 600
2017-12-04 23:59:39,489 fail2ban.actions [24399]: INFO Set banTime = 86400
2017-12-04 23:59:39,490 fail2ban.filter [24399]: INFO Set maxRetry = 6
2017-12-04 23:59:39,494 fail2ban.filter [24399]: INFO Added logfile = /var/log/fail2ban.log
2017-12-04 23:59:39,497 fail2ban.filter [24399]: INFO Set maxlines = 10
2017-12-04 23:59:39,542 fail2ban.server [24399]: INFO Jail sshd is not a JournalFilter instance
2017-12-04 23:59:39,546 fail2ban.jail [24399]: INFO Jail 'sshd' started
Also, nothing was written to fail2ban.log since I set it's log level to DEBUG. And I'm still getting spammed with bruteforce:
Dec 5 00:05:19 vps447398 sshd[25196]: Failed password for root from 42.7.26.61 port 64360 ssh2
Just tried to ban myself on my server previously connected to VPN and entering wrong password 6 times and here's what I've got in my auth.log:
Dec 5 01:08:13 vps447398 sshd[3236]: Failed password for root from 94.242.62.105 port 58699 ssh2
Dec 5 01:08:19 vps447398 sshd[3236]: Failed password for root from 94.242.62.105 port 58699 ssh2
Dec 5 01:08:24 vps447398 sshd[3236]: Failed password for root from 94.242.62.105 port 58699 ssh2
Dec 5 01:08:31 vps447398 sshd[3236]: Failed password for root from 94.242.62.105 port 58699 ssh2
Dec 5 01:08:37 vps447398 sshd[3236]: Failed password for root from 94.242.62.105 port 58699 ssh2
Dec 5 01:08:37 vps447398 sshd[3236]: error: maximum authentication attempts exceeded for root from 94.242.62.105 port 58699 ssh2 [preauth]
Dec 5 01:08:37 vps447398 sshd[3236]: Disconnecting: Too many authentication failures [preauth]
Dec 5 01:08:37 vps447398 sshd[3236]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=94.242.62.105 user=root
Dec 5 01:08:37 vps447398 sshd[3236]: PAM service(sshd) ignoring max retries; 6 > 3
After entering wrong password 6 times in a row host dropped the connection, but then I reconnected and still was able to enter password. Hope there's some helpfull data that could help you to find out what's the issue.
abriginets
on 5 Dec 2017
I'm staying with my guess - something wrong with pyinotify... Tried "polling"?
Otherwise try again with HEAVYDEBUG...
BTW your version is a bit obsolete... Can you try some newer version (>= 0.9.7, 0.10 or even 0.11)?
sebres
on 5 Dec 2017
@JamesJGoodwin hi !
I have the very same issue, but in my case, I have a jail/rule watching an Apache HTTP Server access_log, trying to identify users hitting hard the web servers.
It stopped working suddenly, no errors, no traces in the logs. I even enabled the DEBUG mode but nothing appears.
scampuza
on 5 Dec 2017
I was about to open a new issue, but as this is similar to the one I'm having, I will follow up this...
scampuza
on 5 Dec 2017
I've just installed v0.10.2 dev1 from fail2ban.org and seems like I did well and everything is working just fine, but there's no any bruteforce running currently on my server so I can't properly say if fail2ban working or not. I'll be in touch.
Tried "polling"
What is it? What am I supposed to do to enable it?
@scampuza hello! It seems like not fail2ban issue, but vendor's OS issue. Because earlier my server was hosted in Russia with OpenVZ virtualization and fail2ban worked just fine there, but then I moved to OVH server which has KVM virtualization and it's not working on this type of machine. Maybe there's just some kind of OS restrictions, idk.
abriginets
on 5 Dec 2017
What is "polling"?
"polling" is another file-related backend fail2ban can use.
What am I supposed to do to enable it?
For example set it in jail.local:
[sshd]
backend = polling
Just tried to ban myself by entering wrong password and still nothing happens.
Dec 5 16:21:12 vps447398 systemd-logind[1265]: New session 192 of user root.
Dec 5 16:22:12 vps447398 sshd[27225]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Dec 5 16:22:17 vps447398 sshd[27225]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=94.242.62.108 user=root
Dec 5 16:22:19 vps447398 sshd[27225]: Failed password for root from 94.242.62.108 port 58410 ssh2
Dec 5 16:23:00 vps447398 sshd[27225]: message repeated 5 times: [ Failed password for root from 94.242.62.108 port 58410 ssh2]
Dec 5 16:23:00 vps447398 sshd[27225]: error: maximum authentication attempts exceeded for root from 94.242.62.108 port 58410 ssh2 [preauth]
Dec 5 16:23:00 vps447398 sshd[27225]: Disconnecting: Too many authentication failures [preauth]
Dec 5 16:23:00 vps447398 sshd[27225]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=94.242.62.108 user=root
Dec 5 16:23:00 vps447398 sshd[27225]: PAM service(sshd) ignoring max retries; 6 > 3
fail2ban.log also is empty. None Found or Ban. I think I should contact my hoster's support in this case.
abriginets
on 5 Dec 2017
I think I should contact my hoster's support in this case.
Well, I don't think so. If fail2ban cannot ban (because of some reason like missing kernel features, etc.) you'll definitely get an error in fail2ban.log.
At least you'll see an [sshd] Ban <IP> before...
Your case - no failure will be recognized. This looks like the filter (backend):
- either does not seen the log-file is actualized;
- or just does not match (for some reasons, but you've tested it with fail2ban-regex).
Therefore I assumed that this is pyinotify-issue (possibly the modified-event just does not reach us).
So either try polling or use HEAVYDEBUG loglevel and see what fail2ban.log said if log-file get actualized.
sebres
on 5 Dec 2017
Well, enabling HEAVYDEBUG is caused very huge log file(now it's size is 332MB and it's still growing). Is it normal behavior?
abriginets
on 5 Dec 2017
Yes.
But do you see there something like Working on line ... <IP>? resp. something else that signals pyinotify works...
sebres
on 5 Dec 2017
After a few minutes under HEAVYDEBUG log file became unreadable because of it's size(1,2GB). So I had to stop fail2ban, clear logs and then start it for a few seconds. Now what I've got:
Total lines: 62018
Working on line matched 2611 lines
Take a closer look on fail2ban.log
abriginets
on 5 Dec 2017
Arghhh...
You path is wrong: you observe /var/log/fail2ban.log instead of /var/log/auth.log.
BTW. Therefore also a great "recursion" in heavydebug mode... :)
sebres
on 5 Dec 2017
Damn, shame on me. I'm so sorry I took so much time from you. Now it's working, much thanks!
2017-12-05 17:41:41,606 fail2ban.filter [5214]: INFO [sshd] Found 94.242.62.108 - 2017-12-05 17:41:41
2017-12-05 17:41:43,610 fail2ban.filter [5214]: INFO [sshd] Found 94.242.62.108 - 2017-12-05 17:41:43
2017-12-05 17:42:39,688 fail2ban.filter [5214]: INFO [sshd] Found 94.242.62.108 - 2017-12-05 17:42:39
2017-12-05 17:42:39,689 fail2ban.filter [5214]: INFO [sshd] Found 94.242.62.108 - 2017-12-05 17:42:39
2017-12-05 17:42:39,736 fail2ban.actions [5214]: NOTICE [sshd] Ban 94.242.62.108
Glad it works, thus I'm closing the issue.
sebres
on 5 Dec 2017
@sebres I'm having exactly the same issue as @JamesJGoodwin but with the difference that on Arch the file /var/log/auth.log doesn't exist everything is handled by systemd and journalctl shows efforts of brute force ssh attacks but fail2ban doesn't ban anything I"m trying to ban myself but nothing.
Issuing the following commands:
fail2ban-regex "$ln" /etc/fail2ban/filter.d/sshd.conf
Running tests
=============
Use failregex filter file : sshd, basedir: /etc/fail2ban
Use maxlines : 1
Use datepattern : Default Detectors
Use single line : May 28 21:39:04 ghost sshd[2824]: Failed password ...
Results
=======
Failregex: 1 total
|- #) [# of hits] regular expression
| 4) [1] ^Failed \b(?!publickey)\S+ for (?P<cond_inv>invalid user )?<F-USER>(?P<cond_user>\S+)|(?(cond_inv)(?:(?! from ).)*?|[^:]+)</F-USER> from <HOST>(?: (?:port \d+|on \S+)){0,2}(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [1] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-
Lines: 1 lines, 0 ignored, 1 matched, 0 missed
[processed in 0.00 sec]
sudo fail2ban-regex "$ln" /etc/fail2ban/filter.d/sshd.conf
Running tests
=============
Use failregex filter file : sshd, basedir: /etc/fail2ban
Use maxlines : 1
Use datepattern : Default Detectors
Use single line : May 28 21:39:04 ghost sshd[2824]: Failed password ...
Results
=======
Failregex: 1 total
|- #) [# of hits] regular expression
| 4) [1] ^Failed \b(?!publickey)\S+ for (?P<cond_inv>invalid user )?<F-USER>(?P<cond_user>\S+)|(?(cond_inv)(?:(?! from ).)*?|[^:]+)</F-USER> from <HOST>(?: (?:port \d+|on \S+)){0,2}(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [1] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-
Lines: 1 lines, 0 ignored, 1 matched, 0 missed
[processed in 0.00 sec]
Any ideas on what changes should I make?
kirk86
on 29 May 2018
I've seen the same issue on one of my machines.
Deleting the fail2ban.sqlite3 database and restarting fixed the problem.
distler
on 1 Jun 2018
everything is handled by systemd and journalctl shows efforts of brute force ssh attacks but fail2ban doesn't ban anything
@kirk86 I may be just wrong config. You should set your backend for sshd jail to systemd. File-backends (like pyinotify, polling as well as auto) do montoring of the log-files only (not systemd-journals).
[sshd]
backend = systemd
And for check it via fail2ban-regex you can use:
# for >= 0.10:
fail2ban-regex systemd-journal sshd
# or for 0.9:
fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf
@distler you're right deleting persistent database does help during debugging.
@sebres wrong config was also an issue as well.
I have a questions though, does fail2ban require iptables.service to be enabled and running in order to operate?
kirk86
on 1 Jun 2018
does fail2ban require iptables.service to be enabled and running in order to operate?
This is platform- resp. distribution-depended, e. g. debian's don't have iptables.service (but however have iptables subsystem). Some distribution have different firewall systems, and we've different actions to operate with, e.g. firewalld, pf, iptables, nftables, etc. Which firewall you'll use is your choice.
And there is also the question what exactly is supported by your kernel...
sebres
on 1 Jun 2018
@sebres thanks for the answer.
there is also the question what exactly is supported by your kernel...
I presume that no matter what distro, the kernel support is pretty much the same across distros since the kernel is one thing that is ubiquitous?
kirk86
on 1 Jun 2018
@distler you're right deleting persistent database does help during debugging.
I find that I have to delete it, periodically; otherwise fail2ban just stops banning (just as you describe). Haven't been able to pin down the source of the corruption, though.
distler
on 4 Jun 2018
@distler you're right deleting persistent database does help during debugging.
I find that I have to delete it, periodically; otherwise fail2ban just stops banning (just as you describe). Haven't been able to pin down the source of the corruption, though.
The same problem here. Fail2ban start failing soon after run when using sqlite3. I don't understand why this issue is marked as closed, the problem is still unsolved.
farynaio
on 16 Nov 2019
Fail2ban start failing soon after run when using sqlite3
Details?
Note this issue was caused by wrong path or backend (see https://github.com/fail2ban/fail2ban/issues/1986#issuecomment-349355409 and below).
Nothing else is known at the moment.
sebres
on 18 Nov 2019
Same issue here as Fail2ban fails to ban some IPs. I've tried by changing the backend to polling, deleting fail2ban.sqlite3, both unsuccessful at banning IPs. But this is only for one particular jail, with sshd jail, Fail2ban successfully ban IPs.
My Fail2ban version is :
$ apt list --installed | grep fail2ban
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
fail2ban/bionic,now 0.10.2-2 all [installed]
This is my jail:
[local-postgresql]
enabled = true
filter = local-postgresql
action = iptables[name=PostgreSQL, port=5432, protocol=tcp]
logpath = /var/log/postgresql/postgresql-datareport-*.log
findtime = 1d
maxretry = 1
bantime = 3d
I set the jail to search for multiple log files. And I've tried to change using single log file, and the result is the same.
$ sudo fail2ban-regex --print-all-matched /var/log/postgresql/postgresql-datareport-20191211.log /etc/fail2ban/filter.d/local-postgresql.conf
Running tests
=============
Use failregex filter file : local-postgresql, basedir: /etc/fail2ban
Use log file : /var/log/postgresql/postgresql-datareport-20191211.log
Use encoding : UTF-8
Results
=======
Failregex: 2 total
|- #) [# of hits] regular expression
| 5) [1] <HOST> .* LOG: could not accept SSL connection
| 7) [1] <HOST> .* LOG: invalid length of startup packet
-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [6318] {^LN-BEG}ExYear(?P<_sep>[-/.])Month(?P=_sep)Day(?:T| ?)24hour:Minute:Second(?:[.,]Microseconds)?(?:\s*Zone offset)?
| [4] ExYear(?P<_sep>[-/.])Month(?P=_sep)Day(?:T| ?)24hour:Minute:Second(?:[.,]Microseconds)?(?:\s*Zone offset)?
-
Lines: 14874 lines, 0 ignored, 2 matched, 14872 missed
[processed in 40.04 sec]
|- Matched line(s):
| 2019-12-11 01:45:45.538 +08 [28576] 104.206.128.70 db=[unknown], user=[unknown], app=[unknown] LOG: could not accept SSL connection: Success
| 2019-12-11 06:14:39.977 +08 [32571] 51.15.22.208 db=[unknown], user=[unknown], app=[unknown] LOG: invalid length of startup packet
-
However, on my other server with the same specs, fail2ban for PostgreSQL works fine (with multiple logfiles scanning)
any thoughts is appreciated. thanks
buzzing-bee
on 11 Dec 2019
For possible reasons, please see FAQ in our wiki.
If it basically works on other server, I can imagine a timezone issue (wrong time recognition).
sebres
on 11 Dec 2019
this just happen to me recently on Ubuntu 18.04, fail2ban not banning any failled attempt on ssh/auth.log, even if fail2ban know the file has been modified it's not create any iptables rules:
2020-01-30 20:26:02,058 fail2ban.filterpoll [11011]: DEBUG /var/log/auth.log has been modified
2020-01-30 20:26:24,087 fail2ban.filterpoll [11011]: DEBUG /var/log/auth.log has been modified
and i still see pyinotify and gamin requirements on the log, even if i already install it using apt-get
DEBUG Backend 'pyinotify' failed to initialize due to No module named 'pyinotify'
DEBUG Backend 'gamin' failed to initialize due to No module named 'gamin'
fail2ban start banning after i add backend=systemd options on the configuration like @sebres suggest
[sshd]
backend = systemd
kadekjayak
on 31 Jan 2020
No module named 'pyinotify' & 'gamin'
even if i already install it using apt-get
Well python (fail2ban running) does not find it, either you've installed it for invalid version (check which python version fail2ban uses, 2.x or 3.x, e. g. since 0.10 fail2ban-python --version) or some dependencies are broken.
Anyway in this case (I guess your backend was auto) it switches to polling and debug messages said that it notices the modifications.
So as I already said timezone issue (would see the different times) or wrong regex for filter for some reason.
Or even the messages, sshd jail waiting for, are really in journal only (not in auth.log) and this debug messages produces as some another messages were written in auth.log.
sebres
on 31 Jan 2020
Wow, sorry to pursue this thread but this is where google brought me while I was trying to understand what was happening, and all other suggestions failed until this message:
If it basically works on other server, I can imagine a timezone issue (wrong time recognition).
If you recently changed your timezone on the server, and restarted fail2ban, it can happen that the auth.log is still written with line prefixes in the old timezone the server was in, while fail2ban already uses the new timezone.
The FAQ linked above does mention it:
- note the time of values that fail2ban recognizes from the log-file will be converted using the system time zone (if not specified different) - be sure that the times, written from the corresponding service into the log, are not too old for the fail2ban;
Weirdly, restarting sshd via systemctl didn't change the timezone used in auth.log for me (Debian 10).
After rebooting the server, all went back to normal, and fail2ban started banning as expected.
TL;DR: if you change the server timezone, reboot afterwards
zertrin
on 28 Mar 2020
A reboot is not really needed here, mostly it is enough to restart syslog service (e. g. systemctl restart rsyslog) or journal service (e. g. systemctl restart systemd-journald) etc.
sebres
on 30 Mar 2020
Thank you so much @sebres !
backend = systemd
resolved also my issue.
webristle
on 4 Jul 2020
Related issues
4Syno
路
6Comments
gaia
路
3Comments
AleksCee
路
5Comments
mitchellkrogza
路
6Comments
mvastola
路
7Comments
Most helpful comment
this just happen to me recently on Ubuntu 18.04, fail2ban not banning any failled attempt on ssh/auth.log, even if fail2ban know the file has been modified it's not create any iptables rules:
and i still see pyinotify and gamin requirements on the log, even if i already install it using
apt-getfail2ban start banning after i add
backend=systemdoptions on the configuration like @sebres suggest