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
[Feature] firewall/blocklist grace period on (email) password changes #4314
Comments
Yes please this, I always find that I have un-ban IPs constantly because of this. |
Check this: #1588 It has been working for a long time now... |
@jlguerrerosanz thanks, but this is not what I am asking for. from what I understand your PR back there whitelists IPs after a successful dovecot login. however in my scenario I can not neccessarily count on a successful dovecot login to happen before the client changes his password via UI. so, we need something similar, but the actual hestia ui login should lead to the whitelisting. I have not reviewed your changes mentioned above, but probably it at least describes the proper way of adding the whitelisting, just needs to be changed for the trigger/picking up the IP from another log after the successful hestia login. |
I feel the pain of this issue... as far as I've seen, if the user changes the password via the webmail, at least snappymail then logs in via dovecot, so that would solve at least 50% from a users perspective imho. |
@jlguerrerosanz - I can't see how the code / fail2ban rules at #1588 reacts to the password change. Can you explain? |
This is good thinking and I have to admit, that I did not think about webmail because it is rarely used for changing the password by my users. So bringing webmail into play rather extend this feature request to temporarily whitelist IPs that either sucessfully logged into HestiaCP UI or the Webmailer (assuming that runs on the same server) |
the code does not react to a passwort change. it is a simple rule that temporarily whitelists IPs on a successful login. assuming you have multiple device in the same office/home/wifi they all will have the same public IP and if one of your devices issues a successful dovecot login the other ones will not be blacklisted for a while, even if they automatically try to login with a wrong/changed password. which in the end also gives some time to change the settings on multiple devices. I like the approach to handle this completely with a fail2ban whitelist rule, as this requires only picking the correct log and write a clear regexp rule to catch the successful login. should work for logins in hestiaCP or webmailers too, if those are or can be logged somewhere. however as mentioned above the dovecot login itself falls short for scenarios, where no device or setup with the correct password is available anymore... |
I have an extra script for that. Whenever someone is going to mess with outlook at an office, the IP will be banned for sure. I have this script that checks if an IP has been banned, gets the specific rule, unbans the IP, and whitelists that IP until the next fail2ban restart.
I also have a script to check the exim logs to see all failed login attempts. That way I can tell my client to look for an "android device trying to log in as user@domain.com from your office IP" |
Describe the feature or change in detail
When a user changes their password e.g. for the mail account it often happens, that they get their IP banned very quickly and before they can update all their devices which usually are even in the same network/connecting from the same IP address.
It's obivous that this happens because the mail clients automatically pull mails or sync with the server and therefore hit an auth error from the moment the password got changed.
I suggest to build in some kind of grace period for this use case. The user will usually log into the GUI from the same IP, so we can define an exception/whitelist for this IP for X amount of time after the successful login or even only after a password change.
We need to keep in mind that the unsuccessful login still will happen and be logged, so the timespan needs to be chosen carefully or there needs to be a different way of working around this, so that fail2ban will not block the IP immediately after the grace period.
Would you like to sponsor this feature to have it implemented?
No
The text was updated successfully, but these errors were encountered: