Banning IPs on DD-WRT Based on Failed SSH Authentication

In response to literally thousands of failed SSH attempts from china, I have written a Python script to automate blocking IPs that fail authentication.


It is a VERY dirty Python script. It reads syslog from my router, finds the IPs that have failed SSH authentication to my router, and adds a firewall rule to block them.

1. nvram get rc_firewall
2. Scan syslog for bad authentication
3. Build list of IPs in syslog but not in rc_firewall
4. scp file containing new rc_firewall
5. Apply new rc_firewall, commit, and reboot the router

It’s nasty right now, but it works!

This all assumes a very specific setup:

1. SSH is enabled

2. syslog is logging to an external server

3. The account you run this script on has public key authentication setup with the router

Linux apcupsd and Old APC Serial to USB

I recently acquired an old APC BackUPS 500 that has a ‘dumb’ serial connection. It is old enough that it doesn’t even support a ‘smart’ serial connection which gives much better output. Unfortunately it doesn’t communicate very much at all with the computer. However it is useful enough (I hope) to shut my computer down during an outage.

One of the first things I had to do was to recompile my kernel with the ‘usbserial’ and ‘pl2303’ modules. The usbserial module allows for serial interface over USB and the pl2303 module is for the model of serial to USB cable that I bought.

After inserting those modules, I found that I could not communicate with the UPS properly, or know which ‘/dev/ttyUSBx’ it would appear as on each boot. Thermionix of GitHub posted a great and simple fix for this issue by setting the specific model of serial cable to the same tty device each time it is inserted. Here are the instructions:

# use lsusb to find the details of the serial adapter to create a udev rule

~$ lsusb | grep Serial
Bus 003 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

# based on the output from lsusb add a rule to /etc/udev/rules.d/local.rules

~$ cat /etc/udev/rules.d/local.rules
#Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port"
ENV{ID_BUS}=="usb", ENV{ID_VENDOR_ID}=="067b", ENV{ID_MODEL_ID}=="2303", SYMLINK+="apc-usb"


# set /etc/apcupsd.conf to use the new device
~$ head /etc/apcupsd.conf
UPSTYPE apcsmart
DEVICE /dev/apc-usb


# After a reboot check the status of the UPS using
~$ sudo apcaccess status


Gentoo Upgrading to Netatalk 3.x (AFP & Time Machine)

I currently run a Time Machine server on my custom-built NAS that runs ZFS. This box hosts an AFP share for my TimeMachine backups over the network.

Recently I updated my Gentoo packages and I received Netatalk 3.x as an upgrade from Netatalk 2.x. This broke my shares as afp.conf is now being used to setup shares and it is located in /etc/afp.conf.

After upgrading, you must edit /etc/afp.conf to add your shares, which is self-explanatory. After setting up my Time Machine share again, my /etc/afp.conf looks like this:

cleteNAS netatalk # cat /etc/afp.conf
; Netatalk 3.x configuration file

; Global server settings

; [Homes]
; basedir regex = /xxxx

; [My AFP Volume]
; path = /path/to/volume
path = /rpool/cleteTimeMachine

This is correct in and of itself and you can access your shares using this configuration. However, you will receive the following error from TimeMachine (see the Console Mac application for more details):

11/10/12 7:58:04.294 AM[10232]: Destination /Volumes/TimeMachine does not support TM Lock Stealing

If you Google the issue, you will see that you should edit /etc/netatalk/AppleVolumes.default. However this is not where the setting resides anymore. An analysis of the Netatalk documentation on setting up shares reveals an extremely simple solution:

 Mac OS X 10.5 (Leopard) added support for Time Machine backups over AFP. Two new functions ensure that backups are written to spinning disk, not just in the server’s cache. Different host operating systems honour this cache flushing differently. To make a volume a Time Machine target use the volume option “time machine = yes“. 

Source: Netatalk Documentation

Modify your /etc/afp.conf to look like this:

cleteNAS netatalk # cat /etc/afp.conf
; Netatalk 3.x configuration file

; Global server settings

; [Homes]
; basedir regex = /xxxx

; [My AFP Volume]
; path = /path/to/volume
path = /rpool/cleteTimeMachine
time machine = yes

Restart /etc/init.d/avahi-daemon and you are good to go!

iPhone GPS Information and Accelerometer with Sharing

Recently, I’ve been wanting to learn more about mobile development. I picked up an Objective-C book targeted for the Mac (iOS development is very similar) but the transition from Java and C++ to Objective-C’s methodologies was difficult for me. For a while, I put the book down because it wasn’t getting me anywhere. It did not do a good job of explaining MVC to someone who had never used it before and it didn’t do a good job at explaining the delegate pattern that is extremely common in the Cocoa and Cocoa Touch frameworks. I did not understand at all how it worked.

My interest piqued again when I saw Stanford University’s iTunes U series on iPhone Application Development. I decided to give the first two classes a whirl as I figured they might be good at introducing the way that Objective-C and the Cocoa frameworks function. It turns out that I was right and they were a great introduction. I didn’t even continue to watch the series and I just jumped straight into creating some simple applications.

The first application that I have created is a GPS sensor information app, with a minimal feature list. All the app will do is allow you to view a map and it has two other tabs, one showing GPS information along with your current address and another showing accelerometer data. Each of the last two tabs has buttons so that you can easily e-mail or message the information to someone.

This application turned out to be a good starting point for me with Cocoa Touch and I am now working on two more applications that follow along the GPS path. I will be creating a trip tracking application soon as well as a “live” online trip tracking application. Look out for these in the next six months, as they might actually be useful. 😉

Check out my GPS & Sensor Info app on the App Store.

Munin Monitoring – Temperature

I’ve written yet another Munin monitoring plugin recently. I am a little bit obsessed with checking the weather, so this latest plugin allows me to see exactly what the temperature is both outside and inside at any given point in time, as well as view graphs for the past week, month, and year. I haven’t figured out how to make Munin store more than 1 year of data (if you know, please post a comment).

Daily temperature:


Monthly temperature:


Yearly temperature:


I wrote this plugin in conjunction with an Arduino script, an Arduino, an Ethernet shield, and two DS18B20 Dallas OneWire sensors. The plugin will send a request over to my Arduino’s URL to get the sensor data once each polling period (5 minutes default). The Arduino will send data as such:

Indoor.value 70.47
Outdoor.value 37.06

When running the script for testing, you should see:

cleteNAS ~ # munin-run arduinotemp
multigraph temperature
Indoor.value 69.69
Outdoor.value 36.84

multigraph temperature.Indoor
Indoor.value 69.69
multigraph temperature.Outdoor
Outdoor.value 36.84


The plugin will parse the information (remove the line break) and create a unified graph as well as individual graphs for each sensor. The whole setup is easy to get going once you have the parts and it is easily adaptable. I didn’t write the code for reusability, so each file attached will have to be modified in order to fit your build.

If you want to use this plugin but are having issues, leave a comment below.

Code on GitHub (you must have the Dallas OneWire library first)


Munin Plugins – CrashPlan Monitoring and Hard Drive Spinning State

Ever since I have installed Munin, I have been noticing system statistics that I would like to monitor that the built-in plugins do not. I have written two Munin plugins and I’d like to share them, as simple as they are. Munin doesn’t require a lot when it runs its plugins. The only necessary steps to writing a plugin can be learned in just a few minutes. A guide to writing plugins can be found on Munin’s website.

The first plugin I have written is one that will graph the spinning state of a specified hard drive. At the time I wanted to keep track of whether or not my drives were spinning. After realizing that it is best to keep my drives spinning, I have since turned off drive sleep. Never the less, the plugin graph is shown below.

Source code for hddsleep_.


The second and more interesting plugin I have written is one that will monitor the status of the incoming backups to my NAS from my family’s CrashPlan clients. This plugin will produce multiple graphs; one set for each computer that is backing up to the computer that Munin is monitoring. Two graphs will be created for each incoming backup: a remaining backup size and a backup state. Two graphs are linked below, but they can be hard to read. Clicking on these graphs will show a page detailing each individual computer.

Source code for crashplan.

Munin – Simple Monitoring at its Finest

On Thursday, I discovered Munin, a nifty daemon for monitoring just about anything on any type of system. I had previously tried Nagios, but found it to be cumbersome and simply too much for my personal needs. I want a monitoring solution that doesn’t have any bells or whistles, doesn’t alert me, but is there when I want to check up on my new system. Munin is perfect for just that. Munin’s installation is simple and its configuration script will setup a majority of the plugins automatically based on its discovery of your installed packages. Munin is also easily customizable and its scripting interface is very easy to utilize.

Check out some graphs for my system below:

See my Munin installation here.