PCI Updates that ‘might’ help your system pass TrustWave scans

PCI Updates that ‘might’ help your system pass TrustWave scans

I have written another article of apache commands that might make website more PCI compliant.

This is another task based on that article,  but this goes a little further to address some additional securiity scans that TrustWave does.

In addition to these configuration in apache,  you should also put some items into your .htaccess file.

If your site allows both port 80 and 443,  make sure your forward all port 80 requests to 443 so scanners dont bark about you allowing non secure access to the site.

RewriteEngine On
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]

 

If you have an FTP server that is open to all FTP addresses,  consider locking it down to IP Addresses for specific developers (If you dont have a static IP Address,   get one!)

<Limit LOGIN>
 Order allow, deny
 Allow from w.x.y.z/32
 Allow from w.x.y.0/24
 DenyAll
</Limit>

You will want to make sure you have already installed firewall rules which limit services to only your IP addresses like in this post

Make sure you install / upgrade to the latest apache2  executable (as of 10/15 the minimum needed to pass tests is 2.2.31)

apt-get update
apt-get install apache2

Update the /etc/apache2/apache2.conf file to not expose the apache version

ServerTokens ProductOnly
ServerSignature Off

Update your SSL Cipher settings in Apache2.conf to exclude some additional ciphers that are considered insecure

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !ECDHE-RSA-AES256-SHA !ECDHE-RSA-AES256-SHA !ECDHE-RSA-AES256-SHA !ECDHE-RSA-AES256-SHA !DHE-RSA-AES128-SHA !DHE-RSA-SEED-SHA !DHE-RSA-CAMELLIA128-SHA !ECDHE-RSA-RC4-SHA !DHE-RSA-AES256-SHA !DHE-RSA-CAMELLIA256-SHA !ECDHE-RSA-AES128-SHA !RC4-SHA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

Note,  the SSL Cipher list above was generated from a list that was created for a previous article for updates to apache.  At the that article helped pass a different PCI scan.  Since this PCI scan is newer and obviously more in depth,  the list of excluded ciphers has increased.

I came up with the list above by reading the ‘Evidence’ column of the TrustWave report and then specifically excluding the listed Ciphers by putting  an ! in front of it.   As new reports come out and additional ciphers are marked insecure,  we will add additional ciphers to the apache files in the same way:

trustwavereoport

SSL Cipher Suites – Apache config for IE 11

SSL Cipher Suites – Apache config for IE 11

In past posts I showed how I had followed some suggestions from qualsys on configuring Apache to only use specific ciphers in order to pass all of the required security scans.

However it turns out that blindly using their list of Ciphers led to another problem,   (displaying the page in IE 11) which I describe the fix to below.

In addition though,   the process I go through below,  can / will help you trouble shoot and possibly find and enable / disable the Ciphers for any situation and browser.

On this page:
https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

They suggest setting this SSLCipherSuite:

 EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4

However I found IE 11 was showing “This web page can not be displayed” on Windows 7 and Windows 2008 Server (probably others as well),

I figured out that the problem was the CipherSuite, by commenting out the SSLCipherSuite line in apache, restarting, and the page loaded.

So the next step was to , with the line commented out, to run the ssllabs test with the SSLCipherSuite commented out,
https://www.ssllabs.com/ssltest/

the result of which I found to show some details about the CipherSuites used by different browsers. I would use this tool to make sure you have the correct CipherSuite for any, all browsers and exclude any older insecure browsers.

If you look down the report to the “Handshake Simulation portion of the report you will find a listing of browsers with the Cipher they used. IE 11/ Win 7 was working EVEN BEFORE noticed the ‘can not be displayed’ error, so I went on a hunch and decided to try and enable the IE 8-10 / Win 7 option which showed

 TLS_RSA_WITH_AES_256_CBC_SHA

I googled “openssl TLS_RSA_WITH_AES_256_CBC_SHA” which brought me to the openssl page where they show all of the ciphers and on this page I found “AES256-SHA” which I needed to include in the Apache SSLCipherSuite directive

https://www.openssl.org/docs/apps/ciphers.html

Next, to confirm that this cipher is even available on my server, i ran this command

openssl cipher AES256-SHA

which returned a result showing that the cipher was indeed an option on the server

So, I added it towards the end, and the resulting SSLCipherSuite directive I have is:

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA AES256-SHA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

And now I can load the webpage in the IE 11 browser.

Note that when I ran the ssllabs.com test again, it downgraded the site to an A- probably because the cipher did not offer Forward Secrecy (notated with a small orange ‘No FS’) on the report,

I decided that this is an okay grade in order to allow IE 11 to access the site, but hopefully Microsoft figures it out.

SSL Vulnerability and Problem Test – Online and Command Line

SSL Vulnerability and Problem Test – Online and Command Line

There are many vulnerabilities out there,  and there seems to be no single test for all of them.

When working to correct SSL issues, some of the more comprensive tests, test EVERYTHING,  while this is good,  it can also make it difficult to test the smaller incremental changes that we make as system administrators make

This blog post is a way to collect and keep a resource in one place of links or methods we can use to quickly test individual failures

The big test,  which only takes a minute or so,  but is somewhat bloated for individual tests,  is ssllabs.com.   You will find out most failures here and even get a grade

http://ssllabs.com

But you wont find them all,  and it is difficult to quickly test small changes.  So here are some instant tests.

if you have an SSL Chain issue

openssl s_client -connect example.com:443

to test for CVE-2014-0224, otherwise know n as a CCS Injection vulnerability enter your domain here

http://ccsbug.exposed/

to test for CVE-2014-0160 or Heartbleed test or

http://possible.lv/tools/hb/

Verify ssl certificate chain using openssl

Verify ssl certificate chain using openssl

SSL Certificates ‘usually’ work and show ‘green’ in  browsers,    even if the full certificate chain is not correctly configured in apache.

You can use tools such as SSL Labs (link) or run a PCI ASV check on your site to find out if you are compliant,  but a quicker way to do it is using openssl from the command link.

Using this command you can quickly verify your SSL Certificate and Certificate chain from you linux command line using openssl

openssl s_client -showcerts -connect mydomain.com:443

If you receive a line,  ‘Verify return code: 0 ‘ at the end of the long out put,  your chain is working,  however you might receive an error 27 if it is not configured correctly.

In order to configure it correctly you will like need an line in your apache conf file

 SSLCACertificateFile <yourCAfilename>

In addition to the files which list your Key and Cert file

SSLCertificateFile <yourcertfilename>
SSLCertificateKeyFile <yourkeyfilename>

apache commands that ‘might’ make your server more PCI compliant

apache commands that ‘might’ make your server more PCI compliant

Add the following commands to you Apache configuration file to help make it more PCI compliant.

 
RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F] 
RewriteCond %{REQUEST_METHOD} ^TRACK
RewriteRule .* - [F]
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

Update: I have made some new notes in another blog post for requirements that helped a client pass an additional test with TrustWave

ip tables commands which ‘might’ make your firewall PCI compliant

ip tables commands which ‘might’ make your firewall PCI compliant

This is a list of the iptables commands that will setup a minimal firewall which ‘might’ be PCI compliant

This is primarily here to remind me, so I have a reference in the future.

I also have ports for FTP and SSH for a single developer IP as well as monitoring for a single monitoring server.   The format is simple and can easily be changed for other services.

Be sure to replace ‘my.ip’ with your development ip,  and ‘monitoring.ip’ with

This is on a Linux Ubuntu machine (of course)

apt-get install iptables iptables-persistent
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s my.ip/32 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -s my.ip/32 -j ACCEPT
iptables -A INPUT -p tcp --dport 5666 -s monitoring.ip/32-j ACCEPT 
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p udp --dport 443 -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable


iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP
iptables -A OUTPUT -p icmp --icmp-type timestamp-reply -j DROP

iptables -t raw -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
iptables -t raw -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -t raw -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
iptables -t raw -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j DROP
iptables -t raw -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
iptables -t raw -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
iptables-save > /etc/iptables/rules.v4


PCI SAQ Security Links

PCI SAQ Security Links

It seems there are a couple Google searchs that can be done to help find the forms you need to fill out the SAQ as a Self Reporting Web Hosting Company of links out there. But it took me a little bit to put them all together.

I am not a PCI Security Consultant so dont take this as any kind of gospel, but here are the forms I found that I needed.

To fill out the Attestation of Compliance SAQ D 3.0 for Service Providers, get the form here:
https://www.pcisecuritystandards.org/documents/SAQ_D_v3_ServiceProvider.pdf

If you are not a service provider, perhaps you need a different form

For a quick reference, see their file here
https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf

The PCI DSS Glossary has details of many of the items mentioned in the form

https://www.pcisecuritystandards.org/security_standards/glossary.php

 

Call Now Button(208) 344-1115

SIGN UP TO
GET OUR 
FREE
 APP BLUEPRINT

Join our email list

and get your free whitepaper