PHP 5.2.8
PHP 5.2.8
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.
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.
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
Everytime I try to post the full message, it ban's me for 30 min...
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
I'm about ready to give up.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.
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.
Also, send that full message to support AT atomicorp DOT com with the subject "False Positive" so they can fix it.
-
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
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.
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.
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 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.
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.
Anyway's as for the OpenSSL this is what I get.
When I run rpm -qa | grep -i openssl I get two versions.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
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.
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!
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.
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.