• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Plesk 9.0.1 + PHP 5.2.8 = Still Failing PCI Compliance

R

Robert Coshland

Guest
I have seen a handful of posts regarding PCI Compliance on Plesk with PHP 5.2.8. Here is my current PCI failure:

Code: 
TCP  	8443  	pcsync-https  	8  	Synopsis : The remote web server uses a version of PHP that is affected by multiple flaws. Description : According to its banner, the version of PHP installed on the remote host is older than 5.2.7. 

TCP 	8880 	cddbp-alt 	8 	Synopsis : The remote web server uses a version of PHP that is affected by multiple flaws. Description : According to its banner, the version of PHP installed on the remote host is older than 5.2.7. 

TCP 	465 	urd 	4 	Synopsis : The remote service encrypts traffic using a protocol with known weaknesses. Description : The remote service accepts connections encrypted using SSL 2.0, which reportedly suffers from several cryptographic flaws and has been deprecated for several years.

I have PHP 5.2.8 installed and I am running Plesk 9.0.1.

I changed "expose_php = Off" in /etc/php.ini but it doesn't seem to make a difference to the PCI scan.

This variable was not present in /usr/local/psa/admin/conf/php.ini

Should I add it there also?

Any ideas on how to fix this?
 
Yup, add it to /usr/local/psa/admin/conf/php.ini

Those are hitting the plesk ports, which uses a different (dedicated) instance of php than the system version, which you changed with /etc/php.ini
 
thanks that did the trick!

I still have a few weak cipher issues and (maybe) an older version of OpenSSL now to deal with but that PHP problem was quite vexing.
 
The OpenSSL one is probably a false positive, the network vulnerability scan methodology they're using isn't going to be accurate enough to really tell you if it is or isnt vulnerable.

What distribution are you on?
 
Centos 4.5

I seem to be having a real time of shutting down SSLv2 on 8443. My current failings

TCP 8443 pcsync-https The remote service supports the use of weak SSL ciphers.
TCP 465 urd The remote service encrypts traffic using a protocol with known weaknesses.
TCP 8443 pcsync-https The remote service encrypts traffic using a protocol with known weaknesses.
TCP 8443 pcsync-https The remote host is using a version of OpenSSL which is older than 0.9.6m or 0.9.7d

Oh! I see that I am running OpenSSL 0.9.7a and I am failing due to needing 0.9.7d.

I am pretty new to managing a Linux server (or any server for that matter). Can you advise or point me to a good reference for upgrading to the the latest OpenSSL? To that end, might that solve my other PCI fails?

Thank you for your help!
 
I managed to upgrade my OpenSSL to 0.9.8j and I am still failing on 8443 due to "The remote host is using a version of OpenSSL which is older than 0.9.6m or 0.9.7d" -- There is clearly something strange with this...
 
In my ongoing efforts to shut down SSLv2 I have added:

Code: 
SSLCipherSuite ALL:!ADH:!LOW:!SSLv2:!EXP:+HIGH:+MEDIUM
SSLProtocol all -SSLv2

to /etc/httpd/conf.d/ssl.conf

added:

Code: 
UserDir disabled
ServerTokens Prod
SSLCipherSuite ALL:!ADH:!LOW:!SSLv2:!EXP:+HIGH:+MEDIUM
SSLProtocol all -SSLv2

<VirtualHost 192.168.10.210:8880>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* - [F]
</VirtualHost>

<VirtualHost 192.168.10.210:8443>
SSLEngine on
SSLCertificateFile "/usr/local/psa/admin/conf/httpsd.pem"
SSLVerifyClient 0
SSLVerifyDepth 0
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* - [F]
</VirtualHost>

/usr/local/psa/admin/conf/httpsd.custom.include

but when I check openssl s_client -connect ip:8443 -ssl2

I get

CONNECTED(00000003)
write:errno=104

Any ideas on how to stop this blasted SSLv2?
 
It appears that my issues may be due to "Offline Management" being active on my VPS.

From my hosting co:
Port 8443 is a shared port for all VPS on a hardware node. Traffic to it is not actually processed on your VPS but on the hardware node system VPS. Therefore no changes you make on your VPS will affect the software processing the requests for port 8443. By disabling Offline Management, traffic would be processed by your own VPS rather than the hardware node system VPS. All changes relating to SSLv2/OpenSSL would then be effective.
Click to expand...

...fingers crossed...
 
That did the trick for the 8443 SSLv2 issues.

Now, the only thing left is:

TCP 465 URD The remote service encrypts traffic using a protocol with known weaknesses. Description : The remote service accepts connections encrypted using SSL 2.0
 
The fix for SSLv2 on 465 (if anyone is following this):

Add

ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!SSLv2:RC4+RSA:+H IGH:+MEDIUM

to

/var/qmail/control/tlsserverciphers and
/var/qmail/control/tlsclientciphers
 
I'm running a PCI scan (Comodo) on the same setup, Plesk 9.0.1 + PHP 5.2.8 on Centos 5

I'm stuck at 3 security holes and 7 warnings all to do with Plesk port 8443 (Security hole found on port/service pcsync-https (8443/tcp) ). The majority of them are to do with Apache version being 2.0.46. I presume this is Plesk's own version of Apache as my VPS has 2.2.3 installed.

Is there a way of stopping these Apache version errors? I've tried using:

ServerSignature Off
ServerTokens Prod

in: /usr/local/psa/admin/conf/httpsd.conf.saved_by_psa and httpsd.custom.include, but this doesn't seem to stop the version reporting to the scan. Are these files the correct place to put these statements? I've managed to disable the SSLv2 problems through these files.

I can't seem to limit access to the 8443 port via the Virtuozzo firewall either.

I'm just trying to get my web-shop PCI compliant, and my Linux knowledge is limited.

Any help with this would be much appreciated!
 
Have you made all the changes suggesed earlier in this thread? Also, can you post the errors you are getting?
 
Hi there,

thanks for the reply.

I've attached the scan report as a pdf (3 holes and 7 warnings).

I think most of the issues addressed in this thread have been fixed i.e. SSLv2, PHP version no.

OpenSSL version is one of the warnings, but I'd like to address the Apache version issue first as most of the problems seem to stem from this. As I mentioned before, my server has Apache 2.2.3 installed, whereas Plesk reports 2.0.46.

I've thrashed the firewall trying to block port 8443 as I'm convinced this would fix all the issues, but that port just stays open. I read somewhere that this port is forced open at the kernel level by Plesk.

Just out of interest, have you had a scan done on your system recently, as I presume the scan specifcations change as new vulnerabilities are discovered?
 

Attachments

  • pci-scan-report.pdf
    48.7 KB · Views: 11
Once I got my system compliant, I haven't rescanned.... that day will come soon enough :). A few of the things that were really bugging me around 8443 were only fixable by my hosting company as I also have a VPS. One key issue was having "Offline Management" enabled for Plesk. If your hosting company has this set to 'on' it can cause grief on 8443.

Regarding the false positive on Apache, try adding this line: "expose_php = Off"
to /usr/local/psa/admin/conf/php.ini
 
Plesk Apache problem

im getting this error when asking for pci compliance scanner to be run

Synopsis : The remote web server is vulnerable to a cross-site scripting attack. Description : The remote web server fails to sanitize the contents of an 'Expect' request header before using it to generate dynamic web content. An unauthenticated remote attacker may be able to leverage this issue to launch cross-site scripting attacks against the affected service, perhaps through specially-crafted ShockWave (SWF) files. See also : http://archives.neohapsis.com/archives/b ugtraq/2006-05/0151.html http://archives.neohapsis.com/archives/b ugtraq/2006-05/0441.html http://archives.neohapsis.com/archives/b ugtraq/2006-07/0425.html http://www.apache.org/dist/httpd/CHANGES _2.2 http://www.apache.org/dist/httpd/CHANGES _2.0 http://www.apache.org/dist/httpd/CHANGES _1.3 http://www-1.ibm.com/support/docview.wss ?uid=swg1PK24631 http://www-1.ibm.com/support/docview.wss ?uid=swg24017314 Solution: Check with the vendor for an update to the web server. For Apache, the issue is reportedly fixed by versions 1.3.35 / 2.0.57 / 2.2.2 for IBM HTTP Server, upgrade to 6.0.2.13 / 6.1.0.1 for IBM WebSphere Application Server, upgrade to 5.1.1.17. Risk Factor: Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C:N/I:p/A:N) CVE : CVE-2006-3918, CVE-2007-5944 BID : 19661, 26457 Other references : OSVDB:27487, OSVDB:27488, OSVDB:38700
 
UserDir Causing me to fail, Please Help!

Hi All,

Sorry for hijacking this post but seems its talking about a similar issue to what I'm experiencing..

I have a single PCI failure, I've been working my nuts of for the past week and the only thing I'm unable to get UserDir disabled over 8443 (plesk).

I know this probably isn't possible from my VPS, does my host have to disable it on the server that my VPS resides?

Not sure if they will, and if they don't it all doom and gloom for my PCI clearance!

Any advice GREATLY appreciated.

Tony.
 
You must log in or register to reply here.

Similar threads

Edi Duluman
Resolved How to fix the TLS Poodle PCI Compliance issue
Replies
2
Views
2K
Edi Duluman
Edi Duluman
D
SSL/TLS Protocol Vulnerability PCI Scan
Replies
8
Views
19K
RalphP
R
D
Plesk 10.2 - FAILS PCI - qmail EXPN/VRFY
Replies
3
Views
3K
MacroP
M
K
Panel 10x still failed PCI scan
Replies
4
Views
3K
littlefrog
L
O
PCI compliance problem
Replies
0
Views
2K
Otakucouk
O
Back
Top