• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Disable non-secure Plesk login port 8880

qpidity

New Pleskian
Hi,

One failure cited by a recent PCI compliance report was that of the Plesk non-https login at port 8880. I believe we can resolve this by adding a firewall rule to block access to this port but wanted to check first if this will have any negative consequences elsewhere. Or is there a better way to achieve PCI compliance on this point? Any help gratefully received.

Thanks in advance
 
I would never follow this advice and rather would question, WHY this should be worth a complaint. I'm sure that they don't complain over an open http - port 80 and in the case of a Plesk - environment, this is nothing more, than an additional non-https-port for Plesk in order to ensure that in case of issues with certificates or any other SSL - related issue, there is always the possibility to login over a non-https-port into the Plesk Control Panel to solve that. If you secure this port with a fail2ban - jail, set the security roules in Plesk at least to "medium" and control your auth - and Panel - logs periodically, such a complaint about that open port is absolut nonsens.

Apart from all, it's pretty easy to block the whole port with "iptables -I INPUT -p tcp --dport 8880 -j DROP" if you insist, that there should be no reason to allow a non-https-login in case of issues/problems. Be aware that your customers/clients then won't be able at all to login to your Plesk Control Panel on a non-https-Port 8880 and only got the https - Port - option on 8443.
 
Thanks for the advice. What you say makes perfect sense, but since I am the only person who accesses the plesk control panel, I think closing off that non-https login option really is a non-issue for us.
 
I would never follow this advice and rather would question, WHY this should be worth a complaint. I'm sure that they don't complain over an open http - port 80 and in the case of a Plesk - environment, this is nothing more, than an additional non-https-port for Plesk in order to ensure that in case of issues with certificates or any other SSL - related issue, there is always the possibility to login over a non-https-port into the Plesk Control Panel to solve that. If you secure this port with a fail2ban - jail, set the security roules in Plesk at least to "medium" and control your auth - and Panel - logs periodically, such a complaint about that open port is absolut nonsens.

Apart from all, it's pretty easy to block the whole port with "iptables -I INPUT -p tcp --dport 8880 -j DROP" if you insist, that there should be no reason to allow a non-https-login in case of issues/problems. Be aware that your customers/clients then won't be able at all to login to your Plesk Control Panel on a non-https-Port 8880 and only got the https - Port - option on 8443.


Sorry to reply to such an old post.
But really, there is a very good reason to close off port 8880 -> MITM / Sniffing attacks!

You don't EVER want to send these credentials over a plain text communications protocol like HTTP :S


The values are not encrypted in the browser via JS or anything like it:

Code:
login_name=foo&passwd=bar


If anything is wrong with HTTPS on Plesk, I would not log in to Plesk via HTTP to debug this, I would SSH into the server and read the logs / analyze the system and debug from there.
 
Back
Top