fail2ban WordPress and Cloudflare

Fail2ban_logoLike most people that run a WordPress site, or any CMS, I’ve struggled with brute force attacks on my site. Having just installed fail2ban on a mail server, this seemed like an obvious. Thankfully, as well, someone had already written a plugin for WordPress to drop a message in the system log saying a login failed (by default, Apache doesn’t do this, it just shows someone hit the login page). At first, I had set up an iptables/pf rule to block the bad user, but for some reason, this wasn’t happening. My test browser kept hitting the page successfully.

After a break, I realized that I use Cloudflare, and of course blocking the offending IP wouldn’t work… it never actually connects to my host. Thankfully, Cloudflare has an API, and there was already a starting point for a fail2ban action, albeit, out of date (Cloudflare forces json now). Below is that action. You should be able to just call this like any other action, after you fill out the appropriate “token” and “email”.1

Good luck!

fail2ban action

# Fail2Ban cloudflare action
#
# Author: Ryan Stasel
#
# $Revision$
#

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart =

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop =

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck =

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionban = curl -s https://www.cloudflare.com/api_json.html -d 'a=ban' -d 'key=<ip>' -d 'email=<account>' -d 'tkn=<token>'

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    &lt;ip&gt;  IP address
#          &lt;failures&gt;  number of failures
#          &lt;time&gt;  unix timestamp of the ban time
# Values:  CMD
#
actionunban = curl -s https://www.cloudflare.com/api_json.html -d 'a=nul' -d 'key=<ip>' -d 'email=<account>' -d 'tkn=<token>'

[Init]

account = YOUR_CLOUDFLARE_EMAIL

token = YOUR_CLOUDFLARE_TOKEN

  1. Note: I had to disable “always online” with Cloudflare to have the block take effect within 5-10 seconds. With “always online” enabled, it took about 2-3 minutes to block the attack, all the while the “bot” was able to keep hitting my server. []

Quick repair of Fluke 87 (Faded Digits)

Fluke 87 Faded DigitsAt my suggestion, a coworker purchased a Fluke 87 (Series 1) off eBay, with the faded digit problem, for $70 a week ago. A very good deal. I assured him I could repair it.

The meter arrived, and really, there was very little fading, but it still needed “repair”. Rather than bring it home, I pulled it apart here and showed him what to do (should it happen again). Mr. Modemhead has a great article on this, but also there is a video from Fluke themselves on the issue, even though they’re incorrect on some facts with regards to the original 87 (they say there’s only one zebra strip, when there are two). Anyway, I’ve done the modemhead way, but I thought I’d try Fluke’s suggestion, and just clean the PCB side of the connection. I used some cotton swabs and 99% IPA, and after a couple minutes of scrubbing until clean, I put everything back together, and bingo! It works great. =)

Interestingly, this meter also had a slight issue with the buzzer/beeper. Turns out the speaker (Piezo) uses two rubber “nipples” to make contact with contact points on the back of the PCB. One of these nipples had been squashed/distorted over time and if you screwed the back of the meter on fully/snuggly, the nipple would distort enough to lose contact with the PCB. Simple solution was to leave the middle back screw loose, and place a piece of tape over the screw. Problem solved. =)

iOS (and possibly Android) Chrome .htaccess allow

google-chrome-for-iosI have a couple websites I limit access to with apache .htaccess files. I also use Google Chrome on my iPhone, and for some reason, it was being blocked even though I specifically allow my internal subnet. Looking at the logs, I saw the request was coming from IP 66.249.84.145, or google-proxy-66-249-84-145.google.com. Ah! There’s a Data Saver feature in Chrome on iOS (guessing it’s there for Chrome on Android too). The iOS Chrome uses a Google proxy to download the webpage, do some compression/minification/etc, and then send it to the phone. They call this “Data Compression Proxy“. According to the App, it saves me about 20% of my data (which, I don’t care about when on Wifi, but on cell, it’s not a bad idea).

[Read more…]