Protect WordPress Login Using Fail2Ban and Cloudflare

I’ve discovered a way to protect my WordPress site from brute force attacks thanks to these two guides I found:

WordPress Login Security with Fail2Ban

The best part is these guides do not require installing yet another plugin to WordPress. If your WordPress site does not sit behind Cloudflare, you can just follow the second guide; if you are using Cloudflare however, that guide won’t do anything for you because iptables will only ever see IP addresses from Cloudflare, not your attacker. To make it work with Cloudflare, we need the action filter created in the first guide.

The following steps are a combination of the two guides above and are what I used to configure fail2ban to ban IPs at Cloudflare after failed logins on WordPress; if you haven’t done so already you need to install mod_cloudflare for Apache so it can see the IPs of visitors instead of Cloudflare’s. It’s also a good idea to configure iptables to only allow HTTP/HTTPS traffic from Cloudflare so they can’t bypass it and browse your site directly; the list of Cloudflare IPs is available here as a text file.

First we need to make WordPress log failed authentication attempts; edit the functions.php of your site’s theme and add the following:

Next we need edit /etc/rsyslog.conf and add the following lines under the “Rules” section:

Since we’ve added a new log, we should configure logrotate; add the following to the bottom of /etc/logrotate.conf:

Restart rsyslog with:

Next we create the filter for fail2ban to use; create a new file /etc/fail2ban/filter.d/wordpress.conf with the following contents:

Now we define the action for fail2ban to use; create a new file /etc/fail2ban/action.d/cloudflare.conf with the contents below. Remember to insert your Cloudflare email address and API Key at the bottom.

Now that we have the filter and action created for fail2ban we can add the jail to /etc/fail2ban/jail.local:

Restart fail2ban and it will watch /var/log/wp_f2b.log for failed WordPress authentication and use the Cloudflare API to ban/unban IPs.

Nginx Reverse Proxy with Deluge Web UI

Last year I experimented with using a seedbox for torrenting; I built one using CentOS and Deluge and took a snapshot before I decided to stop using it. Recently I tried deploying it again from the snapshot and found the Deluge Web UI unreachable as Chrome displayed the error message ERR_SSL_VERSION_OR_CIPHER_MISMATCH. It appears in the time since I built it, browsers have stopped supporting SSLv3 due to the POODLE vulnerability. According to this thread, it can be fixed by updating to a newer version of Deluge; however I needed to keep using version 1.3.6 because reasons. Fortunately I was able to configure Nginx as a reverse proxy with SSL enabled for the Deluge Web UI; instead of connecting to the Deluge Web UI directly, I can connect to it through Nginx over HTTPS while the Web UI continues to listen on localhost:8112. Nginx is easy to install and there are many guides on the internet; here’s one for Ubuntu 14.04 and one for CentOS 6.

Below is my configuration for proxying Deluge Web UI through Nginx with SSL enabled; I found the SSL cipher settings on a blog post about hardening SSL ciphers here and the proxy settings on the Deluge Bug Tracker here.


Windows Deployment Services – Event ID 772 and Capture Boot Image failure

I recently tried to set up Windows Deployment Services (WDS) on Server 2012 R2 in my home lab environment; WDS has been around since Windows 2003 and sadly I’ve never tried using it until now. It allows you to deploy Windows operating systems quickly by allowing workstations to PXE boot from a WDS server; you no longer need a DVD or USB stick with Windows on it in order to image a desktop or laptop. You can simply boot a machine via PXE and select the appropriate image to install; you can also include driver packages to be installed automatically or build your own custom images by capturing a sysprepped machine.

Installing Windows Deployment Services is straight forward; if you’ve added a Server Role before like DNS or DHCP then you’ll be familiar with the process. You can read more about it here. I already had a 2012 R2 VM running as a Domain Controller; I added the WDS role first and then the DHCP role as I needed to provide DHCP Options 60, 66 and 67. I initially only added options 66 and 67 for the server IP and boot path; I didn’t immediately notice a way to specify Option 60 and tried PXE booting my notebook anyway. The PXE boot process failed (connection timeout) and I noticed the Event Log on the WDS Server had one error concerning Event ID 772:


After looking up Event ID 772, I found the issue was due to having WDS and DHCP running on the same machine; it seems they both listen on some of the same ports which why the error log mentions “some other application is already using the port.” I fixed this by enabling the following options in the WDS Server properties:


These options can also be enabled by command line:

After enabling those options I was able to successfully boot from an install image I had added. Next I tried creating a custom install image based the Windows install that was already on my notebook. I created a capture image by following the TechNet instructions but it gave an error when I tried to boot from it; the error was a “Windows failed to start” message similar to this one:


I don’t know how but someone in this thread figured out that mounting and unmounting the capture image resolves the issue. I issued the following commands to fix my capture image:

Now I could boot my capture image and after fixing my issue with sysprep, I was able to capture and upload the Windows install on the notebook (complete with applications and drivers) to the WDS Server. I installed the image I captured but ran into an error message as Windows was booting: “Windows could not finish configuring the system”.

Sysprep – Windows Could Not Finish Configuring the System Error

After installing a custom image on a notebook via Windows Deployment Services, I received the following error message as soon as the machine started:


I found this thread and decided the first solution was a bit more complicated than what I wanted to do at the time; I was about give up and chalk up the error message to a compatibility issue with some software I had installed but I decided it would be best to figure it out and know for sure. Then I found this blog post which coincidentally references the same TechNet thread I was looking at earlier. The author of the blog writes that the correct solution was booting into Safe Mode first, waiting for the error and then rebooting again solved the issue; I tried this on my notebook and it worked. It wasn’t until I started writing this post that I noticed the person who posted the first solution in the TechNet thread was using ESET Antivirus; I also have ESET on my notebook which is probably what caused the issue in the first place.

Sysprep – LaunchDll: Failure Occurred While Executing ‘drmv2clt.dll,Sysprep’

I was trying run Sysprep on a spare notebook in order to test image capture via Windows Deployment Services when I received a rather unhelpful error message: “A fatal error has occurred while trying to sysprep the machine.” After looking into the error log I found something more useful and ran a search for drmv2clt.dll sysprep and found the following thread:

The OP of the thread figured out that the issue was due to the “Windows Media Player Network Sharing Service” – as soon as I disabled the service I was able to run sysprep successfully. It is interesting how this thread dates back to 2009 and how another poster writes that this issue was fixed in Windows 7 RTM; I was running sysprep on a notebook running Windows 7 SP1 with all current updates.