Reset of failure counter on successful login

[snajak]

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

• Fail2Ban version (including any possible distribution suffixes):
• OS, including release name/version: Debian on raspberrypi
• Fail2Ban installed via OS/distribution mechanisms: apt-get
• You have not applied any additional foreign patches to the codebase
• Some customizations were done to the configuration (provide details below is so)

The issue:

I would like to ask, if it would be possible to add a function to reset the counter by a successful login. Assume ban on 5 false logins. Now 4 false logins, 5th is successful. Logout and one more false login kicks the user out, although he has been shown valid to the system before. With this feature one could allow longer ban times, as it reduces the risk of getting blocked significantly. Assume a user has to login frequently, e.g. copying files, etc., he could esily be band when in 20 authenications 5 are false.

The old denyhost had another nice reature, that I am missing: Check of valid and infalid usernames. A useful setting was that a correct username had e.g. 10 attempts, an invalid one 5.

Steps to reproduce

5

Expected behavior

Counter gets reset after successful login.

Observed behavior

ban counter=5, user after 4 false logins has success at 5th login. After login again, e.g. a sectiond shell with a false login, he looses all access.

Any additional information

Configuration, dump and another helpful excerpts

standard debian installation without no modification

Any customizations done to /etc/fail2ban/ configuration

Relevant parts of /var/log/fail2ban.log file:

preferably obtained while running fail2ban with loglevel = 4

Relevant lines from monitored log files in question:

[sebres]

So you wanna really allow someone (who has an account) try other user accounts and then do one success login to forget invalid attempts?
Just imagine someone has an account restricted-user, and then tries to logon as root (with interim successful logins to reset failed attempts).
This will be never accepted so in this form by fail2ban. Just because it is intrinsically vulnerable.

In the newer versions (>= 0.10) for multiple tries inside the same connect (with an connection-id, specified using tag <F-MLFID>...</F-MLFID> enclosed) you could use non-empty match for tag <F-MLFFORGET>...</F-MLFFORGET> to forget previous failed attempts.
Be sure you've also specified a user-name patterns in the filter like <F-USER>\S+</F-USER>, otherwise fail2ban will not be able to differentiate between the attempts of good and bad user (that trying different users).
See our sshd-filter for example.

[snajak]

Dear Sergey, yes, I would appreciate this as an option to alternatively turn on. In most attack scenarios, they come from outsiders. This covers 99.99% or more of the cases. In medium large workgroup setups with 20-50 user, it is a trusted environment and people would know each other, even risk to be discovered by a good admin. Without counter reset, I am more involved to free blocked users. In the past, I have used denyhost with the seeting: 10 attemps for valid username before banned 5 attemts for invalid user name before banned A successful login rests the counter. I am I am just starting to learn more about fail2ban and yet do not know, if it has a server option to collect bad IPs. This was what denyhost at that time did. IP addresses that were identified to perfrom brute force attacks, got sent do a central server and got distributed between the denyhost users. Attackers IP addresses quickly become useless. It would be nice if such a collection server would exists that can be either installed in an institution or run on a fail2ban server globally. I have studied quite common attacks on ssh logins: Once I had denyhost running, I discovered that the attackers were limiting their login attempts to 4 at a time and waiting the apropiate time interval in order to avoid getting banned by the central denyhost distribution of bad IPs. However, the attackers did the attacks on all my servers, finally using large botnets. I solved this with an addition: Between my 10 servers I merged the auth.log files together using syslog, so that an attacker who uses only one login attempt with long intervals but scanning through a network with many different IP addresses, also gets caught and banned by the central denyhost IP distribution server. This is a very powerful technique to fight against botnets that become quickly useless for the attackers. As a result I could discover that these attacks had ended and my servers were avoided, probably even more of our larger organization. However, you may understand that avoiding false positives is sometimes more important that a very restrictive configuration, just because someone, who is clumsy, might cause more distributed blockings and affects other users of a multi users system. With this suggestions above, one could reach quite extended bannings for several days, ranther than short bands and drive attackers with distributed methods crasy. :-) But back to your problem, that you have a valid user on your system who tries to crack other user logins and especially root. (by the way I never permit ssh root logins.) I would suggest the following solution: If a user tries to break into another account, you could use short bans 10 seconds and after 15 attempts exit him from the system and lock the account. Otherwise, you could expect that the one tries other methods on the system too. What do you think about my suggestions? best wishes from Germany Jens

…

________________________________ From: Sergey G. Brester [notifications@github.com] Sent: 03 April 2018 10:32 To: fail2ban/fail2ban Cc: Jens Roder; Author Subject: Re: [fail2ban/fail2ban] Reset of failure counter on successful login (#2102) So you wanna really allow someone (who has an account) try other user accounts and then do one success login to forget invalid attempts? Just imagine someone has an account restricted-user, and then tries to logon as root (with interim successful logins to reset failed attempts). This will be never accepted so in this form by fail2ban. Just because it is intrinsically vulnerable. In the newer versions (>= 0.10) for multiple tries inside the same connect (with an connection-id, specified using tag <F-MLFID>...</F-MLFID> enclosed) you could use non-empty match for tag <F-MLFFORGET>...</F-MLFFORGET> to forget previous failed attempts. Be sure you've also specified a user-name patterns in the filter like <F-USER>\S+</F-USER>, otherwise fail2ban will not be able to differentiate between the attempts of good and bad user (that trying different users). See our sshd-filter<https://github.com/fail2ban/fail2ban/blob/0.10/config/filter.d/sshd.conf> for example. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2102 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AhvE9lljRy5SGs7Kr2vHApvebTOMg7z5ks5tkzORgaJpZM4TEOpL>.

[ghost]

Had this been implemented? If yes, what commit contains the implementation?

[sebres]

Had this been implemented? If yes, what commit contains the implementation?

Well, indeed (but at the moment partially). #2279 provides new "flag" tags <F-MLFGAINED> that can allow to forget failures from current session only (if user name is not switched).

There is also another PR #1243 addressing that... but it should be extended to close multiple legitimate users issue (follow the same rules as #2279 does - reset only if single user name was used, so a user login does not change), see #1243 (comment)