PCI Certification Fail

Submitted by sjgomez on Fri, 01/06/2012 - 12:34

I can't get my webserver to pass the PCI Certification. It is being tested by Trustwave. Can I pay someone from Virtualmin to fix the long list of problems

I tried:

http://www.virtualmin.com/documentation/security/pci

and this:

http://www.borgnet.net/clients/knowledgebase/7/How-to-be-PCI-Compliant.html

Help!

-Steve

Status: 
Active

Comments

Submitted by andreychek on Fri, 01/06/2012 - 12:45

Yeah, getting everything configured so that you can pass the PCI tests can be difficult... and even if you have all the things in those documents configured, specific testing companies may have additional requirements that they ask of you.

If you want someone to log into your server and fix all the PCI issues, you could file a request in the "Jobs" forum.

However, I'm curious what outstanding issues you're seeing... could you post those in here?

Submitted by sjgomez on Fri, 01/06/2012 - 13:02

FAILED ON THESE:

Apache APR and APR-util Multiple Integer Overflow Vulnerabilities, CVE- 2009-2412

Apache 2.2 prior to 2.2.15 Multiple Vulnerabilities, CVE-2009-3555 CVE- 2010-0408 CVE-2010-0425 CVE-2010- 0434

OpenSSH < 4.4 Multiple Vulnerabilities, CVE-2006-5051 CVE- 2006-5052

Apache HTTP Server 2.x Prior To 2.2.12 Multiple Vulnerabilities, CVE- 2009-0023 CVE-2009-1191 CVE-2009- 1195 CVE-2009-1890 CVE-2009-1891 CVE-2009-1955 CVE-2009-1956

Apache Server 2.x Prior To 2.2.14 Multiple Vulnerabilities, CVE-2009- 2699 CVE-2009-3095 CVE-2009-3094

OpenSSH X11 Cookie Local Authentication Bypass Vulnerability, CVE-2007-4752

OpenSSH Privilege Separation Monitor Weakness, CVE-2006-5794

OpenSSH X11 Session Hijacking Vulnerability, CVE-2008-1483

Apache HTTPD suEXEC Local Multiple Privilege Escalation Vulnerabilities, CVE-2007-1741

Multiple Vulnerabilities for versions of Apache HTTP Server prior to 2.2.6, CVE-2007-3304 CVE-2007-3303 CVE- 2007-1863 CVE-2007-1862 CVE-2006- 5752 CVE-2007-3847 CVE-2007-4465

Apache Prior to Version 2.2.9 Multiple Vulnerabilities, CVE-2007-6420 CVE- 2008-2364

Apache HTTPD suEXEC Various Vulnerabilities, CVE-2007-1743

Apache HTTP Prior to Version 2.2.8 Multiple Vulnerabilities, CVE-2007- 6422 CVE-2007-6388 CVE-2008-0005 CVE-2007-6421 CVE-2007-6203 CVE- 2007-5000

Apache mod_proxy_ftp Wildcard Characters Cross-Site Scripting Vulnerability, CVE-2008-2939

Apache HTTP Server mod_status Unspecified Cross-site Scripting Vulnerability, CVE-2007-6388

Apache HTTP Server Undefined Charset Cross-site Scripting Vulnerability, CVE-2008-0005

Apache HTTP Server mod_imagemap and mod_imap Cross-Site Scripting Vulnerability, CVE-2007-5000

Apache HTTP Server mod_proxy Malformed URL Vulnerability, CVE- 2011-3639

Submitted by sgrayban on Fri, 01/06/2012 - 14:27

What OS are you using ?

Submitted by sgrayban on Fri, 01/06/2012 - 14:47

Ignore that last post.

Joe/Jamie one of them might be able to fix the apache issue if they compile the newest apache version.

As for the the openssl/ssh that is up to the CentOS people to fix that. A update came out for debian the minute the security flaw was posted.

The proftpd problem is your fault as mod_proxy_ftp has always been a security risk. In all of my docs about proftpd I never said to use that mod and its not needed for VM at all and it should not be allowing non-ssl connections and it certainly shouldn't be open to the public and restricted to local IP's, the same goes for ssh.

My PCI doc is very specific about what you should have running and to set it up.

Lastly your billing server should NOT be hosting anything except for the billing program itself. PCI WILL FAIL if you try to use the same server to host websites.

Submitted by sgrayban on Fri, 01/06/2012 - 14:54

If you want me to help fix your PCI compliance personally its $65/hr USD and I will need all logins for everything, the server the software is on and the login for your PCI supplier.

Submitted by sgrayban on Fri, 01/06/2012 - 14:55

Oh and one more thing I really hope you have bought a SSL cert for the domain, a self-signed cert will never pass PCI.

Submitted by sjgomez on Fri, 01/06/2012 - 15:08

"Lastly your billing server should NOT be hosting anything except for the billing program itself. PCI WILL FAIL if you try to use the same server to host websites."

The same sever hosts several websites, most share a common IP. The credit card processing ones have their own IP. So this won't ever pass PCI?

Submitted by sgrayban on Fri, 01/06/2012 - 15:11

You can't do that... because of the security involved you cannot share your billing software on the same server as public websites.

There are settings that must be enforced that will break any shared hosting.

Submitted by sjgomez on Fri, 01/06/2012 - 15:15

"billing software"

A shopping cart that sends the info to Authorize.net, Is that considered billing software?

Submitted by sgrayban on Fri, 01/06/2012 - 15:21

Correct -- the software that you use to let people order webhosting and so on. That software can not be on shared servers. It must have its own server.

Submitted by sgrayban on Fri, 01/06/2012 - 15:35

I have edited my PCI docs to reflect that requirement.

Shared hosting servers can not be used for any ordering/billing use.

Submitted by sjgomez on Fri, 01/06/2012 - 16:43

I will need to find another solution than running my own server......:o(

Submitted by sgrayban on Fri, 01/06/2012 - 16:54

Using PayPal is the only choice if you want to use a shared public server.

Submitted by sjgomez on Fri, 01/06/2012 - 17:00

No AVS check with paypal standard. They only confirm the address of paypal users, if they use a credit card and are not a paypal user it will be unconfirmed.

Submitted by sgrayban on Sat, 01/07/2012 - 02:07

So upgrade to a PayPal business account and you can get AVS checking.

PayPal no matter what type is the only way with everything being a shared server.

Submitted by sjgomez on Sun, 01/08/2012 - 12:43

I was looking into host-99.com PCI shared hosting as a solution.

My home server is near it's end.....