Question Massive Brute-Force Attacks on Plesk Panel – Looking for Additional Protection Measures

[Kulturmensch]

Server operating system version

Ubuntu 22.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.67 Update #3

Hello everyone,​

I’m running a Plesk panel that has been under a massive brute-force attack for some time. The login attempts are happening non-stop from globally distributed IPs, targeting users like admin, root, and even custom usernames.


I have already implemented the following security measures:
✔ 2FA enabled for the Plesk panel
✔ Fail2Ban set to block IPs for 1 year after 1 failed attempt
✔ GeoIP blocking for China, Russia, India, Indonesia, the Philippines & more
✔ Rate limiting set to 1 attempt per IP
✔ Over 1,000 malicious IPs manually blocked


Despite these protections, the attacks continue – it seems that a large botnet is targeting my panel.


I am now planning additional measures to either make the attacks ineffective or slow down the attackers:
Tarpit mechanism for login attempts (delaying connections significantly)
Honeypot for bot detection & automatic reporting to AbuseIPDB
Cloudflare Zero Trust Tunnel to mask the panel’s IP
Complete whitelisting of Plesk access (allow only known IPs)


Question to the community:
Are there any additional effective security measures for Plesk to handle high-frequency brute-force attacks?
Has anyone experience with Tarpit techniques, captchas, or advanced IP filtering for Plesk?


Thanks for your insights!

 

[Dave W]

fail2ban and the plesk-panel jail?

 

[learning_curve]

@Kulturmensch A paid option (it's always shown as a Plesk extension, but it's a separate package really, complete with a fully customizable, extensive config) which is what we use (and with which, we don't have / never have had any of the issues that you've posted FWIW) is Danami Juggernaut :
Plesk Firewall Extension | Danami
The product (link^) & knowledge pages are all self-explanatory, if you want to take a look first?
Plus @danami is also on this forum if you have any specific questions.

 

[DataPacket]

We are seeing this issue as well. Plesk servers are being actively targeted by brute-force attacks.

 

[Kaspar]

If those are only Brute force attempts for Plesk Panel and you access Plesk over port 8443, you could create a firewall rule to only allow access to port 8443 (and 8447) from your own IP address (or ISP subnets).

 

[Kulturmensch]

Thank you for all your valuable advice! Fail2Ban has now banned 1600 IPs and as I blocked countries with the most attackers now the attacks are slowing down to two to four each hour. I will test danami, as @learning_curve recommended. I am not sure, whether I could follow the recommendation by @Kaspar as I have not a fixed IP from where I manage my server. However, I have an VPN installed and I could use the fixed VPN-address for this purpose, but I have to further examine the approach.

 

[mdhodgson]

I change the default usernames to ensure that the obvious ones are non-existent. Looking the attempts that I’m seeing, the usernames are the domains without the ending of dot com etc.
When I setup a server, I always change the default port for SSH which typically reduces the majority of the attempts. I may do the same for the panel port as well.
Until today, I didn’t realise that there’s a full API spun up on my server - I may try to shut that down as well. I had some attempts to login that way.

Thanks for the tip about geo ip blocking - I’ll put that in place. Hopefully some of the above helps

 

[learning_curve]

Thank you for all your valuable advice! Fail2Ban has now banned 1600 IPs and as I blocked countries with the most attackers now the attacks are slowing down to two to four each hour. I will test danami, as @learning_curve recommended.

FWIW - IF - you decide to go with Danami Juggernaut, you will no longer use Fail2Ban / Plesk Firewall etc. You'll understand a lot more, but... only after reading all of the product data and knowledge pages in advance of any trial. This reading exercise will take some time if you do decide to do it.

I am not sure, whether I could follow the recommendation by @Kaspar as I have not a fixed IP from where I manage my server. However, I have an VPN installed and I could use the fixed VPN-address for this purpose, but I have to further examine the approach.

FWIW the very valid suggestion from @Kaspar is something we've always done. There's no reason not to, but more than one IP adddress is better (just in case!). Depending on your setup / config, you can apply this at Server level (above Plesk) at Plesk level and/or via Danami Juggernaut level (if you decide to use it). Not having a fixed IP / IPs is an inconvenience, but your VPN option would provide a workaround (better if you had at least 2 VPN fixed IP addresses though!)

@mdhodgson Apart from a small set of our own fixed IP's, we completely block all access to Port 22, at server level (and just in case: via Danami Juggernaut too). Plus our SSH access is 'key only' i.e. NOT using a password. This means that there's no benefit (for us) derived from changing SSH to a Port other than Port 22.

 

[Kulturmensch]

FWIW - IF - you decide to go with Danami Juggernaut, you will no longer use Fail2Ban / Plesk Firewall etc. You'll understand a lot more, but... only after reading all of the product data and knowledge pages in advance of any trial. This reading exercise will take some time if you do decide to do it.

FWIW the very valid suggestion from @Kaspar is something we've always done. There's no reason not to, but more than one IP adddress is better (just in case!). Depending on your setup / config, you can apply this at Server level (above Plesk) at Plesk level and/or via Danami Juggernaut level (if you decide to use it). Not having a fixed IP / IPs is an inconvenience, but your VPN option would provide a workaround (better if you had at least 2 VPN fixed IP addresses though!)

@mdhodgson Apart from a small set of our own fixed IP's, we completely block all access to Port 22, at server level (and just in case: via Danami Juggernaut too). Plus our SSH access is 'key only' i.e. NOT using a password. This means that there's no benefit (for us) derived from changing SSH to a Port other than Port 22.

Thanks for your good recommendation from Danami Juggernaut. But at the moment, it seems to be taking too much time for me to get it working. I'm about to go on a long trip and can only work on this solution more intensively after I return. In the meantime, I'm blocking all countries from which I'm receiving massive attacks.

 

[Kulturmensch]

I always change the default port for SSH which typically reduces the majority of the attempts.

I also changed port 22, which helps against targeted 22 attacks but not against port scans looking for SSH access. I also blocked SSH access using a user/password combination. You can only log in to my server with keys!

 

[Kulturmensch]

I have now blocked CN, RU, ID, PH, KR, TH, VN, MY, IN . This has helped. Recently, however, I've also noticed a sharp increase in attacks on my server from the US. I hope I can continue to manage this with fail2ban so I don't have to add US to the list.

 

[learning_curve]

I also changed port 22, which helps against targeted 22 attacks but not against port scans looking for SSH access. I also blocked SSH access using a user/password combination. You can only log in to my server with keys!

FWIW If Port 22 is blocked at server level (access permitted only to a defined set of specific IPs) then it's invisible as an open port anyway, so, any external port scans made, with a view to possibly obtaining SSH access are a bit pointless really.