PCI Compliance problem. Domain & SLL Certifacate Resolve to server Port 8443
I'm new to this so please go easy on me.
I cant pass a PCI compliance scan. Could someone tell me what's happening, if this is even a Plesk issue, or an Apache issue? I guess what's happening is my domain with an IP of it's own & SSL certificate of its own, resolve to my servers IP so I fail the scan. Evidently that has to do with port 8443 being open to some sort of attack because of this situation. My system info: Linux server; CentOS 5.5 with Parallels SB Panel 10 (64-bit) Apache 2.2.3 I copied the email the scan company sent me to make the issues more clear & put it in italics below to refer back to. Here is the email: The shiro.ini issue is flagging because the following URL is actually being resolved: https://www.domain.com:8443/./smb/login?returnUrl=%2F :~$ curl -vkl 'https://www.domain.com:8443/./smb/login?returnUrl=%2F' * About to connect() to www.domain.com port 8443 (#0) * Trying 00.000.000.72... connected * Connected to www.domain.com (00.000.000.72) port 8443 (#0) ... * Server certificate: * subject: /C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=info@parallels.com * start date: 2010-12-14 07:27:55 GMT * expire date: 2011-12-14 07:27:55 GMT * common name: Parallels Panel (does not match 'www.guitarcomplete.com') * issuer: /C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=info@parallels.com * SSL certificate verify result: self signed certificate (18), continuing anyway. > GET /./smb/login?returnUrl=%2F HTTP/1.1 > User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10 > Host: www.domain.com:8443 > Accept: */* > *< HTTP/1.1 200 OK* < Transfer-Encoding: chunked < Expires: Wed, 19 Jan 2011 17:08:48 GMT < Expires: Fri, 28 May 1999 00:00:00 GMT < Cache-Control: max-age=2592000 < Cache-Control: no-store, no-cache, must-revalidate < Cache-Control: post-check=0, pre-check=0 < Last-Modified: Mon, 20 Dec 2010 17:08:49 GMT < Pragma: no-cache < P3P: CP="NON COR CURa ADMa OUR NOR UNI COM NAV STA" Content-type: text/html Date: Mon, 20 Dec 2010 17:08:49 GMT Server: sw-cp-server First, I noticed that 'sw-cp-server' is part of the information above I unrerlined. It's also part of what the Plesk 10.2 PCI Compliance guide shows you how to make changes to that I implemented & I think I did them correctly. However, I don't know if those changes apply to this situation. Second, I don't think I have 'shiro' at all. When I looked for it in SSH, nothing is there! Can anyone help me to straighten this out so I can pass the scan? |
A little more info:
Below is what the scan company results say: TCP 8443 pcsync-https 5 Synopsis : The remote web server appears to use a security framework that is affected by an information disclosure vulnerability. Description : The remote web server appears to be using a version of the Shiro open source security framework that that does not properly normalize URI paths before comparing them to entries in the framework's 'shiro.ini' file. A remote attacker can leverage this issue to bypass authentication, authorization, or other types of security restrictions via specially crafted requests. See also : http://archives.neohapsis.com/archives/b ugtraq/2010-11/0046.html Solution: Upgrade to Shiro 1.1.0 or later. Risk Factor: Medium / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) CVE : CVE-2010-3863 BID : 44616 Other references : OSVDB:69067 [More] So the vulnerability is explained. But as I mentioned in my last post. I don't think I have it on my server. When I type both the '-v' & 'find' commands, no information shows. |
Quote:
To make the change to your firewall: • Login into Plesk • On the top right hand side of the panel, click the settings tab • Find the Firewall icon & click it • On this page under the tools heading, click “Edit Firewall Configuration” • On the next page click “Plesk administrative Interface” from the list of firewall rules • Under the properties heading, you can select an action. Click the radio button next to “Allow from selected sources, deny from others” • On the same page under the Sources heading, place any IP addresses you want to be able to access the interface into the box next the words, “Add IP address or network” click add & then click OK. • On the next page under the Tools heading, click the “Activate” icon to complete the modification to your firewall. |
I think you found a work around for the problem, but the underlying question remains of what application is listening on port 8443 that is willing to give up your certificate information? Try running this command (and post the output). It may be necessary to run it as root.
Code:
netstat -ntap | grep 8443 |
Quote:
A little more to know is, there is some way hackers could hack in using /./ in (I think) part of a domain to gain ways into a lot of other stuff. Thank you |
All times are GMT -5. The time now is 09:29 AM. |