SecurityMetrics and whm service ports questions
In dealing with security metrics I get this feeling like cpanel is just some small obscure thing that only a few dozen people use on the whole planet for hosting and nobody else. Yet the usage numbers indicate that they should be dealing with customers cpanel pci issues on a minute by minute basis. And that leaves me confused because why am I the one bringing up this issue and not a few hundred thousand other people all at the same time. And if they are all bringing it up, where is the massive sticky thread somewhere documenting this issue, with lots of tired angry people sick of explaining the same thing over and over again..
Fundamental process for whm/cpanel: Ports 2087, 2083, 2078, 2096
These ports provide account holders the ability to manage their accounts, access webmail, webdisk, and allows admins to use whm itself.
When these ports are invoked, they will use the servers domain certificate. Browsers will be redirected to the primary server certificate, which is signed and secured. Users do not authenticate to these ports using their own domains because many of them may not even have an ssl available and shouldnt have to. Using the primary server certificate for the server is how these services are kept secure regardless of what account is logging in.
But scan after scan Security Metrics keeps flagging these ports as using the wrong SSL certificate. They expect the certificate for the account domain instead of the certificate for the root server domain. Their expectation makes security worse for the entire rest of the server.
Am I the only one here dealing with this issue week after week after week?
-
Well thats fine I can just keep doing this battle myself. The reason why they are wrong is that /cpanel and /whm actually redirects to . Once there, the user is presented with the hostdomain certificate. The ONLY reason why they think this is a mixed certificate situation is that their scanner software does not properly follow the same redirect that a human using a browser would follow, it just connects to the port. Unless PCI is making the redirect itself somehow a bad thing, this is all false positive because the scanner is breaking the rules. 0 -
Their expectation makes security worse for the entire rest of the server.
Could you expand on this a bit more? Having trouble understanding your main issue here.0 -
Okay on our PCI scans, they always have a complaint on 2087, 2083, 2078, 2096 that when they connect to these ports they are served the host domain cert instead of a cert associated with the account domain. So normally clientaccount.com/cpanel will forward you to https:hostdomain.com:2083, and you will be served the cert for hostdomain in this situation. The problem is their scanner doesnt forward to hostdomain.com, it just connects to the port 2083, and they see the cert for hostdomain instead of the cert for clientaccount domain. They think this is a cert name mismatch, but its a false positive. All browsers are going to follow the redirect first to the hostdomain before they get served the hostdomain cert. For a real life user THERE IS NEVER A CERT MISMATCH. Their scan is generating a false positive because it does not behave the way a browser behaves. 0 -
Correct. They'll need to find a better way to imitate a browser. It never ceases to amaze me how these PCI companies fail to grasp common sense here. You'd think after having to flag something over and over and over again that they'd learn. 0 -
Hi, For this reason, and others, we are working on SNI support for our daemons. See SNI support for cPanel, Webmail, WHM 0 -
Okay so they are telling me that it is fine when people go to clientdomain.com/cpanel and get redirected to serverdomain.com:2083 What they are complaining about is that someone somewhere might type in clientdomain.com:2083 and then get a mismatched certificate. And then they want to call that risking a MIM attack. Ill continue after the laughter subsides.... So if I could just block those ports from working under the clientdomain and only work under the serverdomain, then this would not be a problem. Yeah I dont know anything about mapping ports to specific IPs, is that a thing thats easy to do. This is a centos machine, maybe theres a file I can mess with? Otherwise am I stuck waiting for this SNI feature to be finished? There must be tons of other people stuck in this situation, any of you have gotten past this with security metrics before? 0 -
Wow it looks like people here are just really in the dark about this issue. For anyone that finds them self in this same situation, which I thought there would be a few thousand given the nature of the issue, you should probably look into using an Organizational SSL for your server certificate, and add SAN domains onto this that will allow that cert to represent for other domains that need to be PCI compliant. This is the solution our server host finally came upon for us and we are currently in the process of getting this setup and working. Has anyone else ever done this before to address these specific PCI violations? 0
Please sign in to leave a comment.
Comments
7 comments