Why am I using WordPress? A security engineer’s perspective

There’s a very negative perception of WordPress in the security world but I’m not going to touch that topic today. What I will address is why I am running WordPress on my personal blog about security. Some folks in the information security community might find that to be ironic however there are very specific and tactical reasons for it.

I’ll outline my thoughts below..

Policy tuning: I use this site for dialing in WordPress policy for WAF deployments. Since WordPress has 59% of the CMS market share as of Q4 2017, it makes sense to invest in building these policies since the platform isn’t going to disappear anytime soon. There’s a lot you can do to protect WordPress if you build your policies correctly.

Threat Analytics: I’m able to discover the most popular attack methods threat actors are using on WordPress installations. The majority of attacks I saw in 2017 were targeted towards the  xmlrpc.php and wp-login.php scripts. That’s no surprise to be honest since these attacks are low hanging fruit. These attacks are simple in nature such as xmlrpc DDoS attempts or brute force login attempts to wp-admin. I have seen a rise in theme specific attacks and attempts to hit existing malicious payloads on hosts that are already compromised.

Geo Map Analysis: Watching the trends of where WordPress attacks originate is quite interesting. I’ve seen a recent uptick in activity originating from the United States, European Union, and South America. My belief is that the usual suspects originating from IP space with known bad reputations are using VPNs, proxies, and compromised hosts from regions with a better IP reputation to slip past the perimeter of IP based reputation filters and IDS/IPS systems. The traditional methods of geoblocking are becoming less effective and dynamic IP reputation filtering is the way to go.

Security Hardening: The best way to help clients secure WordPress is to learn the platform inside and out. Whether it’s hardening PHP, the web server,  setting proper permissions on the PHP scripts, auditing activities, obfuscating fingerprints, or enabling FIM, there are several ways you can lessen the risk posed by WordPress. The ultimate goal is to use a defense in depth strategy that drives up the skill level of the threat actor involved.

Enable X-Forwarded-For on IIS 8.5 and up

It’s critical to enable X-Forwarded-For Logging when behind a proxy or load balancer in order grab the true IP address of visitors.

To enable this in your IIS site follow the steps below:

Step 1. Select your website in the IIS management console. In this example, I have a test site called www.larmeir.com. Ensure that the logging format is W3C then click –> Select Fields.

Step 2. From the Select Fields menu click –> Add Field.

Step 3. From the Add Custom Field form add the following entries for X-Forwarded-For as shown in the screenshot.

Step 4. Click –>OK

Step 5. On the actions menu in the upper right hand corner of the IIS manager click –>Apply

Conclusion: If everything went well you will now have a second IIS log in your logging directory with will have a postfix of _x (this indicates a custom log).
This log will now contain the true IPs of visitors that are connecting to your website.

Apache Reverse Proxy Vhost Examples

For certain projects I’ll use Nginx or Apache as a reverse proxy to back end web servers. While Nginx is far more light weight and faster, Apache is the swiss army knife of web servers and has just about every feature you could need.

Here’s a couple of examples of Apache Reverse proxy vhosts.

SSL Proxy with SSL back end origin:

1
2
3
4
5
6
7
8
9
10
11
12
13
	ServerName yourdomain.com
	ServerAlias www.yourdomain.com
        ProxyPreserveHost On
        ProxyPass / http://192.10.2.11:80/
        ProxyPassReverse / http://192.10.2.11:80/
 
        ErrorLog ${APACHE_LOG_DIR}/yourdomainerror.log
        CustomLog ${APACHE_LOG_DIR}/yourdomainaccess.log combined
 
	RewriteEngine on
	RewriteCond %{SERVER_NAME} =yourdomain.com [OR]
	RewriteCond %{SERVER_NAME} =www.yourdomain.com
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Standard HTTP proxy with HTTP back end origin (Forced SSL Rewrite):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<VirtualHost *:80>
	ServerName yourdomain.com
	ServerAlias www.yourdomain.com
        ProxyPreserveHost On
        ProxyPass / http://192.10.2.11:80/
        ProxyPassReverse / http://192.10.2.11:80/
 
        ErrorLog ${APACHE_LOG_DIR}/yourdomainerror.log
        CustomLog ${APACHE_LOG_DIR}/yourdomainaccess.log combined
 
	RewriteEngine on
	RewriteCond %{SERVER_NAME} =yourdomain.com [OR]
	RewriteCond %{SERVER_NAME} =www.yourdomain.com
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

I’ll do a write up in the future on the benefits of reverse proxy configurations.

Enabling X-Forwarded-For Logging In Apache 2.4

It’s critical to enable X-Forwarded-For Logging when behind a proxy or load balancer in order grab the true IP address of visitors.

To enable this in your Apache vhost configuration, simply add the following logging options:

1
2
3
4
5
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxy
SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" forwarded
CustomLog "/var/log/httpd/youraccess.log" combined env=!forwarded
CustomLog "/var/log/httpd/youraccess.log" proxy env=forwarded

This is a simple fix to get real data on the IPs hitting your website!

Simple .htaccess rules to protect wp-login.php and xmlrpc.php

The majority of trash WordPress traffic is targeting wp-login.php with bruteforces and xmlrpc.php for pingback/dos attacks.
A simple solution? Enforce IP based ACLs via your web server.

Apache 2.4 .htaccess Example:

1
2
3
4
5
<Files wp-login.php>
 Require all denied
 # your IP below
 Require ip xxx.xxx.xxx.xxx
</Files>
1
2
3
4
5
<Files xmlrpc.php>
 Require all denied
 # your IP below
 Require ip xxx.xxx.xxx.xxx
</Files>