LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   PCI Compliance problem. Domain & SLL Certifacate Resolve to server Port 8443 (https://www.linuxquestions.org/questions/linux-server-73/pci-compliance-problem-domain-and-sll-certifacate-resolve-to-server-port-8443-a-854723/)

iplayoldmarshalls 01-06-2011 06:07 PM

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?

iplayoldmarshalls 01-06-2011 06:17 PM

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.

iplayoldmarshalls 01-20-2011 09:49 PM

Quote:

Originally Posted by iplayoldmarshalls (Post 4215858)
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.domain.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?

I found an easy way to deal with this. Just edit your firewall to block port 8443 from any IP address you dont to have see port 8443.

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.

Noway2 01-21-2011 04:51 AM

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
You mention trying for PCI compliance, which suggests that you are looking to run an e commerce site with the intent of accepting credit card payments. If this is the case, you have a couple of more fundamental problems. Most noticeably that you are using a self signed certificate and that you have an incorrect domain versus common name.

iplayoldmarshalls 01-21-2011 11:29 PM

Quote:

Originally Posted by Noway2 (Post 4232773)
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
You mention trying for PCI compliance, which suggests that you are looking to run an e commerce site with the intent of accepting credit card payments. If this is the case, you have a couple of more fundamental problems. Most noticeably that you are using a self signed certificate and that you have an incorrect domain versus common name.

You're spot on correct. I actually did get my compliance & this was the final hurtle. Port 8443 is the port Plesk's control panel/interface listens on. By blocking all IP's other than the ones I want to let in, it ended the problem & my site passed the scan. I'll definitely look at what you had to say more closely. I just saw you reply come in & wanted to answer you ASAP.

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.