Atomicorp

Hello,

I just acquired a VPS server with Plesk 8.6. I was wondering if you guy's will be releasing the PHP 5.2.8 files for Plesk as I require this to pass the Merchant PCI Compliance for Visa, MasterCard, Amex as it stat's that PHP 5.2.6 is a risk and fails the scans.

I believe its CentOS 4 by the way. I'll have to check once they finish building it.

Thank you.

Thats probably a false positive, are you running the latest PHP from the vendor?

Sorry for the delayed response.

Server is actually running CentOS 5, Apache 2.2.3 with PHP 5.1.6 and MySQL 5.0.45.

All I've ever used in the past is cPanel but this one came with Plesk. According to the Plesk Update, everything is up-to-date.

the updater you want to use to maintain the system is the one from the vendor, its called yum. You can check with "yum update"

Tried that, said everything was up-to-date.

Then my host put me back to you guy's and a few link's on the web. Did the yum using some third party repository server and that put it up to PHP 5.2.6, MySQL 5.0.58.

Still fail the PCI scan's, stating it needs to be PHP 5.2.8 or newer. Displays this for port 80, 443, 8880, 8443

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.

Solution: Upgrade to PHP version 5.2.8 or later.

I'm about ready to give up.


Everytime I try to post the full message, it ban's me for 30 min...

PCI compliance is, IMO, a bit too anal in this regard. 5.1.6 is a perfectly good (and stable) branch. It's like saying you're at major risk by not running Windows Vista. I agree that you should aim for the latest bug releases but, as 5.2.5 and more recently 5.2.7 proved, sometimes going to the latest release breaks new things as well.

Also, send that full message to support AT atomicorp DOT com with the subject "False Positive" so they can fix it.

Yes indeed, for part 1 to that, php 5.2.8 is in atomic-testing now.

In reference to PCI auditing in general, unless someone is doing local checks, its virtually assured that the results from folks like hackersafe, scanalert, etc,etc will be *wrong*. They all have a fundamental flaw in the manner in which they perform their audits, moreso the tools they use to do it (like nessus) even tell them that their results will be inaccurate based on the manner in which they are doing it.

php-5.2.8 runs nicely on fc8 and fc9

Will there be a fc10 build of this? its missing...

Thank's Scott.

Does this php-5.2.8 update the version that is used on port 8443, 8880, 4643, 80, 443 or only port 80 and 443? (Failing on all those ports).


Also, do you know if the system's OpenSSL is tied into Plesk's port 8443, or if Plesk run's its own version in the background?

This is and update for the redhat/centos/fedora distributed PHP, we cant touch the Plesk version.

Plesk does link against the vendor distributed openssl though.

Okay, thank you Scott.

I might be able to fake the PCI results as it only scan's every 90 day's by blocking access on the firewall to port 8880. I would leave it blocked all the time, but when I tried blocking it and accessing port 8443 it stated that the SMTP service was offline and wouldn't let me do anything till I reopened port 8880. (Was able to telnet into the SMTP service and received header message so it was online)

Is it safe to yum update to 5.2.8 off the AtomiCorp repository?

I really appreciate your guy's help.

Anyway's as for the OpenSSL this is what I get.

Port: 8443
Fail Notice: The remote host is using a version of OpenSSL which is older than 0.9.6m or 0.9.7d
Solution: Upgrade to version 0.9.6m (0.9.7d) or newer

When I run rpm -qa | grep -i openssl I get two versions.

openssl097a-0.9.7a-9
openssl-0.9.8b-10.e15

Now I'm confused. But hey, I've hammered off most the stuff on the PCI compliant scan that failed. Now I only have 9 item's instead of the 122 I started with.

Yeah, thats a false positive. Redhat/CentOS backport the fixes without changing the version number. Like i said, unless the PCI checks are configured to do local testing, the results will be very very wrong.

Well I'm down to 5 items now.

1. Port 8880 TCP - PHP older then 5.2.8 - will fix by turning blocking that port for the scan.

2. Port 8443 TCP - Stats its using SSL 2.0 when it's actualy using SSL 3.0 - will fix this by turning off the control panel for the scan.

3. Port 8443 TCP - Stats I'm running the older version of OpenSSL when I'm not. - Will fix this by turning off the control panel for the scan.

4. Port 80 TCP - Login / Contact / Search form on vBulletin required over SSL. Will fix by .htaccess file to force it as a https.

5. Port 80 TCP - Stats that I'm running Apache Tomcat version prior to 3.3.1a and to upgrade to Tomcat 4.1.18 or newer (I'm not running Tomcat).

Since the scan has to be done every 90 day's, issue's 1 to 3 is a easy fix to pass. Issue 4 is an easy .htaccess fix.

Only problem is issue 5, I looked through the httpd.conf and all the files in the conf.d folder and couldn't find anything listing tomcat. Checked for any RPM's with tomcat or any other name I could find and no luck. This didn't get added until I did the atomicrocketturtle repository.

Any suggestions?

Thank you all for your help!

Commenting out the port 8880 and 8443 didn't work in the httpds.conf in the PSA conf folder, nor did blocking them in the plesk firewall. (I want to use IP Tables but every time I restart the server this Plesk firewall start's up and flushing everything). The only port that ended up being disabled was the 8880, but 8443 works no problem. I even did the service psa stopall and started the httpd, dns, mysql and other services needed and you could still access the plesk pannel on 8443. It just stated that the service was offline and recommended that I restart it.

Contacted my VPS provider seeing if they can disable the Plesk firewall from starting up.

I'm just down to three items then I pass, I don't know anymore.