1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

Plesk 9.0.1 + PHP 5.2.8 = Still Failing PCI Compliance

Discussion in 'Plesk 9.x for Linux Issues, Fixes, How-To' started by Robert Coshland, Feb 26, 2009.

  1. Robert Coshland

    Robert Coshland Guest

    0
     
    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?
     
  2. atomicturtle

    atomicturtle Golden Pleskian

    29
     
    Joined:
    Nov 20, 2002
    Messages:
    2,110
    Likes Received:
    7
    Location:
    Washington, DC
    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
     
  3. Robert Coshland

    Robert Coshland Guest

    0
     
    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.
     
  4. atomicturtle

    atomicturtle Golden Pleskian

    29
     
    Joined:
    Nov 20, 2002
    Messages:
    2,110
    Likes Received:
    7
    Location:
    Washington, DC
    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?
     
  5. Robert Coshland

    Robert Coshland Guest

    0
     
    I am on:

    OpenSSL 0.9.7a Feb 19 2003
     
  6. atomicturtle

    atomicturtle Golden Pleskian

    29
     
    Joined:
    Nov 20, 2002
    Messages:
    2,110
    Likes Received:
    7
    Location:
    Washington, DC
    maybe :p Are you on redhat or centos?
     
  7. Robert Coshland

    Robert Coshland Guest

    0
     
    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!
     
  8. atomicturtle

    atomicturtle Golden Pleskian

    29
     
    Joined:
    Nov 20, 2002
    Messages:
    2,110
    Likes Received:
    7
    Location:
    Washington, DC
    Ok so the openssl one is a false positive, *IF* you are running the latest packages from centos (yum update).
     
  9. Robert Coshland

    Robert Coshland Guest

    0
     
    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...
     
  10. Robert Coshland

    Robert Coshland Guest

    0
     
    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?
     
  11. Robert Coshland

    Robert Coshland Guest

    0
     
    It appears that my issues may be due to "Offline Management" being active on my VPS.

    From my hosting co:
    ...fingers crossed...
     
  12. Robert Coshland

    Robert Coshland Guest

    0
     
    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
     
  13. Robert Coshland

    Robert Coshland Guest

    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
     
  14. R C

    R C Guest

    0
     
    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!
     
  15. Robert Coshland

    Robert Coshland Guest

    0
     
    Have you made all the changes suggesed earlier in this thread? Also, can you post the errors you are getting?
     
  16. R C

    R C Guest

    0
     
    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?
     

    Attached Files:

  17. Robert Coshland

    Robert Coshland Guest

    0
     
    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
     
  18. razah

    razah Guest

    0
     
    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
     
  19. TonyJ

    TonyJ Guest

    0
     
    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.
     
  20. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,564
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
    http://download1.parallels.com/Plesk/Panel9.5/plesk-9.5.0-for-rpm-based-os.html#20

     
Loading...