[Feature] firewall/blocklist grace period on (email) password changes about hestiacp HOT 8 OPEN

Yes please this, I always find that I have un-ban IPs constantly because of this.

from hestiacp.

Check this: #1588

It has been working for a long time now...

from hestiacp.

@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.

from hestiacp.

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.

from hestiacp.

Check this: #1588

It has been working for a long time now...

@jlguerrerosanz - I can't see how the code / fail2ban rules at #1588 reacts to the password change. Can you explain?

from hestiacp.

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.
BUT ;-)
I would assume the culprit with webmail would be that the dovecot login is not coming from the users real IP but from the server itself as that is the place where the webmailer is actually hosted and the login is done via the backend aka PHP ...

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)

from hestiacp.

Check this: #1588
It has been working for a long time now...

@jlguerrerosanz - I can't see how the code / fail2ban rules at #1588 reacts to the password change. Can you explain?

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...

from hestiacp.

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.

#!/bin/bash
#import functions
source /opt/nm-bin/functions.sh
#abort if you are not root user
comoroot
#abort if number of arguments is not exactly 1
exactargs 1 $#
#attain IP
ip=$1
#check if the provided IP fits into an IP regex
validateip $ip
#check the fail2ban.log creation time
logdesde=$(head -n 1 /var/log/fail2ban.log | cut -d' ' -f1)
#Check if the IP has been banned in the recent past.
cat /var/log/fail2ban.log | grep "Ban" | grep $ip > /dev/null
#abort if the IP has not been banned in the last days.
testabort "$ip no ha sido baneada desde $logdesde. No está en /var/log/fail2ban.log"
#send a message to confirm the user that the IP has been banned at least once. since $logdesde
msg "$ip ha sido baneada al menos una vez desde $logdesde"
for regla in $(cat /var/log/fail2ban.log | grep "Ban" | grep $ip | grep -v "(" | cut -d'[' -f3 | cut -d']' -f1 | sort | uniq )
do
#Check if the IP is actually banned
fail2ban-client status $regla | grep "Banned IP list:" | grep "$ip" > /dev/null
if [ $? -eq 0 ]; then
#unban IP
fail2ban-client set $regla unbanip $ip > /dev/null
if [ $? -eq 0 ]; then
msg "[$regla]: $ip desbaneada con éxito"
else
error "[$regla]: $ip error en el desbaneo"
fi
msg "[$regla]: Añado $ip a lista blanca temporal"
#add ip to fail2ban whitelist (until reboot)
fail2ban-client set $regla addignoreip $ip > /dev/null
else
msg "[$regla]: $ip ya estaba desbaneada. Nada que hacer"
msg "[$regla]: Añado $ip a lista blanca temporal"
#add ip to fail2ban whitelist (until reboot)
fail2ban-client set $regla addignoreip $ip > /dev/null
fi
done

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 [email protected] from your office IP"

from hestiacp.