• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Ban IP after X login attempts

schlimpf

Basic Pleskian
As the title says, I would like to have a setting to automatically ban a IP after X login attemts.
Am I the only one who wants a feature like this? I think this is a substantial feature.

Regards,
schlimpf
 
Last edited:
You can define allowed network here - Home>Tools & Settings>IP access restriction management
 
Right, but I do not want to allow single IPs, but automatically ban IPs with a preset number of failed login attempts
 
At least a captcha

This should really be on the development list. If not banning the IP address then at least add a captcha after X failed attempts. If I view all our plesk server access logs then you can see distributed attacks with people trying to bruteforce the plesk admin panel.
 
As the title says, I would like to have a setting to automatically ban a IP after X login attemts.
Am I the only one who wants a feature like this? I think this is a substantial feature.

Regards,
schlimpf

That's for sure a very important feature especially for Mail, FTP & Control Panel. I like the cPanel default "cPHulk Brute Force Protection"

Surely to the least we should have something like that in default Plesk installation.
 
Anybody good at fail2ban, or/and at regex?

Then we could add it in the fail2ban rules. I already have it installed to avoid bruteforcing SSH, FTP and Email.
Excellent program, but i thought plesk had a block after x number of attempts :-/
 
With fail2ban I'm checking /usr/local/psa/admin/logs/httpsd_access_log against the following regex:
failregex = ::ffff:<HOST> .*POST /login_up.php3 HTTP
Then, in /etc/fail2ban/jail.local I've got the following thresholds:
maxretry=10 w. findtime=60 -> 10min ban
maxretry=20 w. findtime=60 -> 2hr ban
Works for me(TM)
 
It's unbelievable Plesk still doesn't have a mechanism to protect itself from brute-force login attacks!

While we are waiting for authors to make it available as an option in the Admin panel, here's how I do it:

Have a look at database "psa", table "log_actions".
Plesk logs failed logins here, unfortunately without the username entered. Nevertheless, we can see the IP address in this table.
The field "action_id" has the value of 125 for failed logins. The field "ip_address" holds the IP address.. :)

So, we can create the script, run from cron every 5 minutes:

Code:
mysql -NBe "SELECT CONCAT('host=',ip_address),date FROM log_actions WHERE action_id=125 AND UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(date) < 300" psa | while read line
do
        logger -p auth.warn -t PLESK-LOGIN-FAILED $line
done

OK, fine, now we can configure fail2ban to detect this. First, create the new filter rule, for example: /etc/fail2ban/filter.d/plesk-login.conf :

Code:
[Definition]
failregex =  PLESK-LOGIN-FAILED: host=<HOST>

Finally, create the appropriate fail2ban jail in /etc/fail2ban/jail.local :

Code:
[plesk-login]
enabled  = true
port     = 8443
action   = iptables-multiport[name=plesk-login, port=8443, protocol=tcp] # ... etc (chnage it to suit your needs)
filter   = plesk-login
logpath  = /var/log/auth.log
findtime = 300
maxretry = 5
bantime  = 86400

Restart fail2ban service.

Et voila... :)
 
Hello, IgorG, and thanks for replying.

Unfortunately, restricting the panel access statically by IP is not an option in many cases. Customers could be .. well.. anywhere. :)
I've already heard about future fail2ban integration, I just hope it won't mess up already working f2b installations.

Have a nice day! :)
 
Agree with SinišaB. Restricting the panel access statically by IP is not an option in many cases. I believe that feature will not be hard to implement, when fail2ban will be available in plesk. I hope ;) Typical solution for that - after 3 invalid logins ban for 30 min.
 
We need to be able to lock out an IP after certain number of failed login attempts for any user, not just for those with admin privileges.
Current mechanism restricts admin access only, but leaves customers' accounts open to password guessing attacks.
 
Back
Top