Category: Apache
Wordfence – CPU issue with exhaustive scans – COMMANDDUMP
Wordfence has some default scans which run hourly. On many systems this works well. In at least one case we found a situation where Wordfence was running hourly scans on some VERY large libraries at the same time on multiple sites on the same server.
A fix was implemented for this, but in the time that it took us to recognize this issue, we came up with the following command which helped to kill the CPU hog so we could continue to use the WordPress websites.
kill `apachectl fullstatus|grep wordfence_doScan|awk '{print $2}'`
Some of the ways you can find out that the issue is occuring is by running some of these investigative commands
- apachectl fullstatus|grep wordfence – how many concurrent scans are running
- mysqladmin processlist|grep wf – the number of insert / update / select commands against Word Fence tables
- vmstat 1 – run a monitor on your system to see how active you are
- uptime – see your 1 , 5 and 10 minute loads
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 ProductOnlyServerSignature 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:
Invalid command ‘SSLEngine’, perhaps misspelled or defined by a module not included in the server configuration – enable apache ssl module
Invalid command ‘SSLEngine’, perhaps misspelled or defined by a module not included in the server configuration – enable apache ssl module
If you are moving an existing Apache configuration file from one server to another, or if you are enabling SSL configuration on an existing website, you could run into this error as you restart apache
server#/etc/init.d/apache2 restart Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration
This essentially means that Apache doesn’t understand what the SSLEngine command means. This is most likely because SSL has not been enabled on this server. For quite some time SSL has come with Apache2 by default, however you do still have to enable it.
To enable it you can simply run enable the ‘ssl’ apache module the command
#a2enmod ssl #/etc/init.d/apache2 reload #or #/etc/init.d/apache2 restart
The error should no longer show a the SSLEngine command is correctly recognized by the ssl mod.
Find out which PHP packages are installed on ubuntu / debian
Find out which PHP packages are installed on ubuntu / debian
As we have moved or upgraded sites from one server to another, sometimes we have needed to know which PHP5 dependencies were installed on one server servera, so that we could make sure those same dependencies were met on another server serverb
To do this we can run a simply command line tool on server a
servera# echo `dpkg -l|awk '$1 ~ /ii/ && $2 ~ /php5/{print $2}'`
libapache2-mod-php5 php5 php5-cli php5-common php5-curl php5-gd php5-mcrypt php5-mysql php5-pgsql
and then we copy the contents of the output and past it after the apt-get install command on serverb
serverb# apt-get install libapache2-mod-php5 php5 php5-cli php5-common php5-curl php5-gd php5-mcrypt php5-mysql php5-pgsql
Dont forget to reload apache as some packages do not reload it automatically
serverb# /etc/init.d/apache2 reload
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.
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