LinuxQuestions.org
Visit Jeremy's Blog.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices


Reply
  Search this Thread
Old 01-06-2011, 06:07 PM   #1
iplayoldmarshalls
LQ Newbie
 
Registered: Jan 2011
Location: New Hampshire, USA
Posts: 8

Rep: Reputation: 0
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?

Last edited by iplayoldmarshalls; 01-06-2011 at 06:18 PM.
 
Old 01-06-2011, 06:17 PM   #2
iplayoldmarshalls
LQ Newbie
 
Registered: Jan 2011
Location: New Hampshire, USA
Posts: 8

Original Poster
Rep: Reputation: 0
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.
 
Old 01-20-2011, 09:49 PM   #3
iplayoldmarshalls
LQ Newbie
 
Registered: Jan 2011
Location: New Hampshire, USA
Posts: 8

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by iplayoldmarshalls View Post
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.

Last edited by iplayoldmarshalls; 01-20-2011 at 09:52 PM. Reason: I had my domain open to see & don't want that.
 
Old 01-21-2011, 04:51 AM   #4
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Gentoo
Posts: 2,125

Rep: Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781
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.
 
1 members found this post helpful.
Old 01-21-2011, 11:29 PM   #5
iplayoldmarshalls
LQ Newbie
 
Registered: Jan 2011
Location: New Hampshire, USA
Posts: 8

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Noway2 View Post
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
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
my dns server is unable to resolve the domain annaabhi Linux - General 10 11-18-2010 12:34 AM
PLESK [Solution] Change port to 23 (telnet) instead of default port 8443 x5452 Linux - Software 6 05-10-2009 05:58 AM
Bind server is unable to resolve specific domain bizzaro Linux - Server 4 05-04-2009 08:47 AM
cannot acees to webserver port 8443 in LAN via squid cccc Linux - Server 2 01-31-2009 12:43 PM
tomcat don't listen on port 8443 (ssl) Kanaflloric Linux - Software 2 05-03-2007 05:41 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Server

All times are GMT -5. The time now is 08:34 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration