Ubuntu – Base Secure Apache

Ubuntu – Base Secure Apache

In order to install a server that is able to pass the many SSL problems out there you can not install the default servers.

apt-get install make gcc

Install the latest open ssl from the openssl site first.

– download it to a directory

extract , config and install

then install apache2

 

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

Coldfusion / PCI double null vulnerability – Addressed with apache rewriterule

Coldfusion / PCI double null vulnerability – Addressed with apache rewriterule

Coldfusion 8 and before have a ‘double null’ vulnerability that comes up as a fail on Nessus PCI reports. (output below)

Basically, some one can embed some custom characters into the URL and drive an error which breaks Coldfusion

https://yourdomain.com/coldfusion_apache_double_null_info_disclosure.nasl-14285118 17%2500.cfm

You can either upgrade Coldfusion (recommended)  or you can put in place an Apache RewriteRule which prevents anyone from accessing your Coldfusion pages with the exploited URL.

 RewriteRule %00 / [B,R]

Nessus Output before the error is corrected.

Application: https Port: 443 Protocol: tcp VATID: 40667 Synopsis : The remote web server has an information disclosure vulnerability. Description : The remote host is running a vulnerable version of ColdFusion on Apache. When requesting a non-ColdFusion file, appending a double-encoded null byte and an extension handled by ColdFusion (such as '.cfm') will display the contents of that file. A remote attacker could exploit this to view the source code of other files on the web server (e.g. PHP scripts), which may contain credentials or other sensitive information. This vulnerability is similar to CVE-2006-5858, which affected systems running ColdFusion on IIS. This vulnerability reportedly only affects systems running ColdFusion on Apache. See also : http://www.adobe.com/support/security/bulletins/apsb09-12.html Solution : Apply the relevant hotfix referenced in the vendor's advisory. CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) CVSS Temporal Score : 3.7 (CVSS2#E:U/RL:OF/RC:C) Public Exploit Available : false

 

AWK script to show number of apache hits per minute

AWK script to show number of apache hits per minute

Documenting this script,  to save me the time of rewriting it time and again on different servers

 tail -n100000 www.access.log|awk '/09/Apr/{print $4}'|awk -F'[' '{print $2}'|awk -F':' '{print $1":"$2":"$3}' |sort -n|uniq -c

This shows output like this

 21 09/Apr/2015:12:48
 21 09/Apr/2015:12:49
 21 09/Apr/2015:12:50
 21 09/Apr/2015:12:51
 21 09/Apr/2015:12:52
 711 09/Apr/2015:12:53
 1371 09/Apr/2015:12:54
 1903 09/Apr/2015:12:55
 2082 09/Apr/2015:12:56
 2256 09/Apr/2015:12:57
 2123 09/Apr/2015:12:58
 1951 09/Apr/2015:12:59
 1589 09/Apr/2015:13:00
 1427 09/Apr/2015:13:01
 811 09/Apr/2015:13:02

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.

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

Call Now Button(208) 344-1115

SIGN UP TO
GET OUR 
FREE
 APP BLUEPRINT

Join our email list

and get your free whitepaper