-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BR]: Problem with multiple PAM-modules and sshd & pam-generic filters #3449
Comments
Little Update: the "forget" feature doesnt seem to work correctly too. One connection in auth.log:
fail2ban.log:
|
To cut a long story short, it is hardly possible now (unless #1243 gets fully implemented), no matter how you'd try to rewrite the filter. The only way I see at the moment would be to adjust |
The user1 log is a single scp copy of a small file. Thats why its happening 20 times in 1 minute. How about this not so dirty workaround (well still extremely dirty but slightly better):
Adding this to the sshd filter will ignore ANY pam_* lines BUT STILL capture the "authentication failed" lines. |
It is clear to me, just they are different strings (therefore I spoke about normalization above).
It can surely work, but instead you could also try to add it to the failregex as no-failure: [sshd]
failregex = ^<F-NOFAIL>pam_\w+\(sshd:auth\)</F-NOFAIL>:\s+authentication failure;\s*logname=\S*\s*uid=\d*\s*euid=\d*\s*tty=\S*\s*ruser=\S*\s*rhost=<ADDR>\s
%(known/failregex)s (try to avoid catch-alls like Just in both cases it may be affected by the afore-mentioned issue with a bruteforce on foreign name (legitimate user trying to launch an attack against different login in-between). It is definitely depending on your logging, so one can't predict how fail2ban would process that after all, but I'd recommend to check how it'd look on some test attempt with interim user switch.
Sure. Ideally a good filter must always find only 1 failure by 1 login attempt... just it is not always possible. |
Environment:
The issue:
We have joined our machines to a Samba active directory controller and are using pam_winbind and pam_unix to authenticate users.
We've enabled the sshd and pam-generic filters. Both filters in conjunction with multiple pam_modules are leading to false positives - banning "good" people that successfully authenticated itself.
I think we've found 4 problems (or oddities if you want).
Steps to reproduce
Expected behavior
Not get banned.
Observed behavior
Got banned.
Any additional information
If a users connects successfully via SSH to a machine these log entries are generated:
And the fail2ban.log shows:
After googling for a while we found that there is a "forget" feature in the sshd filter. A successfull connection clears the bad reputation of a user + ip combination. Sadly this is not reported in the fail2ban.log and the eventual ban is shown as in both filters ("sshd" and "pam-generic"). (IMHO Problem 1 & 2)
Disabled the pam-generic filter changes this behavior slightly: the "bad attempts" are still printed in the fail2ban.log but it seems like the forget features works correctly. I can connectly successfully 100 times without a ban.
Enabling it back again: ban galore! So this forgetting is filter-specific and not for all of fail2ban?
We tried to exclude the ssh daemon from the filter regex, but this only works in the
filter.d/pam-generic.conf
and not in thejail.local
:(Problem 3? idk)
Debugging this further we've discovered that pam-generic only reports
pam_unix
errors and ignores all the other pam-modules. (Problem 4) So we've created acommon.local
to override this:The problem is: the pam-generic filter only sees auth failures, because there is no "pam auth succeeded" log entry. SSHd logs successfully entries - thats why the forget feature works great for this filter.
Configuration, dump and another helpful excerpts
Any customizations done to /etc/fail2ban/ configuration
Please see above.
Relevant parts of /var/log/fail2ban.log file:
Please see above.
Relevant lines from monitored log files:
Please see above.
The text was updated successfully, but these errors were encountered: