Strengthen Your IDS/IPS With Known WordPress Plugins

I maintain a dashboard in my Splunk environment to monitor for potential hacking attempts against my web servers. One way that I do this is to monitor for sources that are generating repeated 404 errors looking for exploitable web pages on the sites. During this recent review, I became aware of a number of new WordPress plugins that hackers are attempting to exploit. The URLs are easy to spot. They all begin with /wp-content/plugins/ followed by the name of plugin. The plugins that I saw are not even installed on my server, so these are obviously hackers looking for a way in.

This got me thinking about how I can use this information to strengthen my security with my intrusion detection and prevention systems.

Controlled WordPress Environment

For my particular installation, I am the only administrator for all of the hosted WordPress sites. This means that I have complete control over which plugins are installed. Because of this, I can use the solution that follows.

Identify Installed Plugins

The first step in my solution is to identify the list of currently installed plugins across all of my sites. From the directory where all of my sites are stored, I was able to use the following Linux command to get a list of plugins:

find . -type d -name plugins -exec ls {} \; | sort -u | grep -v "\.php$"

This command does the following:

  • find – Looks for all directories with the name of “plugins” and lists the contents of each directory.
  • sort – The sort command takes all of the plugin directory names, sorts them and removes duplicates.
  • grep – The plugins directory in WordPress may contain some PHP files in the directory. We can ignore these. This grep statement removes anything found to end with a .php extension.

Configure a Fail2Ban Filter

In order to secure my environment from these malicious invaders, I decided to again use Fail2Ban. If someone attempts to access a plugin that isn’t in a list of known plugins, then I want to immediately block any further access from that IP address. Fail2Ban makes this process very each.

Assuming that my list of installed plugins was pluginA, pluginB and pluginC, my filter file would look like the following:

failregex = ^<HOST> -.* \[.*\] "(GET|POST) \/wp-content\/plugins\/
ignoreregex = ^<HOST> .* "(GET|POST) \/wp-content\/plugins\/pluginA\/
  ^<HOST> .* "(GET|POST) \/wp-content\/plugins\/pluginB\/
  ^<HOST> .* "(GET|POST) \/wp-content\/plugins\/pluginC\/

This filter starts by triggering on any attempt made against the wp-content/plugins URL, but then provides exclusions for each plugin that is allowed.

I store this in a filter file that I named wp-plugin.conf in /etc/fail2ban/filter.d. I then add the following to my jail.local in /etc/fail2ban:

enabled  = true
port     = http,https
filter   = wp-plugin
logpath  = /var/log/web/*access.log
maxretry = 1
bantime  = 2592000

This creates a jail with the wp-plugin filter. It monitors all of my web access logs and blocks a sender after 1 malicious attempt. Once triggered, the user is blocked for 2592000 seconds (30 days).

With this in place, restart the Fail2Ban service and a new layer of protection will be added to your security defenses.

Leave a Reply