« Humor | Main | Other Software »

Monday, December 17, 2012

Update to Timelox for OpenSSH 6.1p1

I just patched openssh 6.1p1 with the timelox code, I've posted the installer tgz file up at:


This will likely be the last of these I do, since sshguard does a better job of the same thing. If you're curious about this, see Timelox and TheHand.

Posted by bil at 3:55 PM
Categories: My Software

Monday, May 16, 2011

Timelox and TheHand

The Problem

Since 2004 we've seen an increase in the number of brute force attempts to break into machines via ssh. These attempts appear to use the same password across different accounts, and thus do not trigger many of the normal methods of detecting brute force, such as pam_tally, nor do they result in the typical slowdowns associated with repeated attempts at a single ID.

Murray Anderegg turned me onto timelox, written by a fellow named Elad Efrat (aka Brian at ethernet.org). This code tracks failed logins by ip number, but doesn't care about which ids were hit, and when a threshold is reached, the offending ip number is put into a deny rule for a firewall.

The one thing I didn't like about it so much was that the code called the firewall explicitly from within ssh, so you'd have to change the patch code for different oses. And Murray wanted to make some changes in the source code to meet his needs with iptables under linux. So what we did was modify Elad's patch code and abstracted things a bit so that instead of calling a firewall directly, you can set a variable in the sshd_config file specifying a script that's called when the threshold is reached. I _think_ it's relatively safe, but I'm not that good at this kind of thing, so your mileage may vary. I can't be responsible if you use this code and something bad happens, whether that is someone hacking your machine, locusts attacking your rose bushes, or not-quite-flying cattle impacting your home in an adverse manner.

This particular doc is primarily oriented to OS X, but the timelox code works fine on Redhat and probably pretty much an flavor of linux, and there's an example script for iptables provided.

Why do it this way?

Well, partly to keep things portable, and partly since I think calling an external script is a more attractive option, since that keeps the patching of ssh to a minimum, since the same patch can be used for pretty much any operating system.

Also, although this example uses a timelox patch in ssh to call our scripts, one can use any manner of software as a trigger. For example, one could make a honeypot program to watch a socket and mimic ftp or other services, and call this script when anything odd is seen. Or one could call a completely different script to fire a report, trigger a firewall at the head of a network, etc.

What's here

Please note that the patches and scripts were updated around the time this page was last modified (see below for the date), the changes are pretty significant including changes in path names and script names in the default installation. 

All of the files are located here. If you're in a hurry, just go for the latest tgz of the installer , which includes openssh-5.8p1.

Installation Instructions

In a basic installation there are four steps:

  1. Patch (or download a patched copy of) openssh with the timelox code, and install it
  2. Modify the sshd_config file with the lines supporting timelox
  3. Copy TheHand.sh to the location where timelox can touch it
  4. Test
I've written an installation script for OS X, and this should simplify things greatly. The installer does not include a firewall, just the openssh code and the timelox additions. To use this, first open a terminal window, then run the following commands:

curl --raw -k -o openssh_timelox_installer-current.tgz \
tar -xvzf openssh_timelox_installer-current.tgz
Next cd into the result folder, as of today that would be openssh_5.8p1.installation Then you can run the installer, the usual way would be
sudo ./install.sh -a 
Other flags you can use:
  • install.sh -c will check for necessary files, unpack the source, patch it, and then configure the software.
  • install -m will run a make clean and a make of the software. You can use this make a master if you have to push out to a bunch of similar machines.
  • install -i will do an installation, but not the configure and make phases. Use this if you're installing to multiple systems that have the same OS/processor type.
The script will warn you if you do not have a firewall script in /Library/StartupItems/Firewall, but in my initial testing timelox works fine with the default firewall setting in OS X 10.5 so long as the firewall is on.

The script puts all of the ssh code in /usr/local. It also modifies the /usr/libexec/sshd-keygen-wrapper file to use the new version of openssh. It makes backup copies of the files, but the key file is /usr/libexec/sshd-keygen-wrapper--if you want to go back to the OS X version of sshd, just copy the backup version of this file back to the original location, eg:
sudo cp /usr/libexec/sshd-keygen-wrapper-091105-171749 /usr/libexec/sshd-keygen-wrapper
By default, the-hand.sh speaks a warning aloud, if you don't like this behavior, you can comment out the line. Run:
sudo vi /usr/local/libexec/the-hand.sh
and then go to the bottom of the file and find this section:
# And because it's a mac, and we can, speak the action
osascript -e "say \"Warning, the hand has blocked ${1} in i p f w with rule ${block_new_number} \"";
If you put a pound sign in front of osascript, that will suppress the audible warning, eg:
# And because it's a mac, and we can, speak the action
#osascript -e "say \"Warning, the hand has blocked ${1} in i p f w with rule ${block_new_number} \"";
For more detail on manual building of the code, you can use the information below.


  • Scripts as examples
    • the-hand.sh_ipfw: (if you're using 10.4 or earlier you must  use a custom ipfw firewall for this script to work, that's what the sample ipfw firewall listed above is for! The default firewall provided by OS X 10.5 does seem to work, since it doesn't use ipfw to set rules for inbound connections.
    • ipfw_example: An example of an ipfw firewall that intersects nicely with the ipfw version of TheHand. For more info on ipfw, see http://www.ibiblio.org/macsupport/ipfw/
    • TheHand.sh_iptables: A second older example script for linux/iptables
  • Also, do note that a particular version of openssh may not be ideal for your needs, so what you may wish to do is find out which version of openssh your distribution runs, and adapt the patch code to the source for that version. So test it throughly before deploying, and if you run into problems, you might consider adapting the patch to whatever version of openssh your system uses. Adapting the patch is pretty easy.

Editing the sshd_config file

The installer takes care of these setting for you, but here's a rundown on what's what in case you need it.

There are several variables that can be set in the sshd_config file. On OS X systems the first thing to do is enable PAM support, find the line that says "#UsePAM no" and change that to:

UsePAM yes

You also need to check out the timelox settings. Here's a list of timelox variables:

  • UseTimelox enables it,
  • TimeloxTimeFrame sets the window in seconds for failed logins
  • TimeloxMaxBadLogins sets the number of failed logins needed the timeframe to trigger timelox
  • TimeloxCall is the full path to whatever script or program you want to call
  • when the failed login threshold is reached
  • TimeloxPath is the full path to timelox's working files
  • TimeloxIPTable is just a string you can use to specify which chain in an iptables
  • firewall you want to insert blocks
  • TimeloxRuleno lets you set what rule number you want to use in a chain
  • TimeloxLogLevel lets you set a log level
  • TimeloxLabel is just an indentifier in case your script has multiple triggers.

All of these are just string or integers, so you can use them for other purposes if you like.

In this example, the number of bad logins and the time frame are both set relatively high, which is what I think makes sense for a workstation. These lines can go anywhere, so just scroll to the bottom of the file and add them there. Here are reasonable starting values

UseTimelox yes
TimeloxTimeFrame 7200
TimeloxMaxBadLogins 3
TimeloxCall /usr/local/libexec/TheHand.sh
TimeloxPath /usr/local/etc/timelox/
TimeloxIPTable INPUT
TimeloxRuleno 1
TimeloxLogLevel authpriv.info
TimeloxLabel sshd_timelox

While you're here you may want to make some other changes. Adding a banner is a good idea, if only to help you with your testing. Find the banner line and uncomment it: 

Banner /usr/local/etc/ssh/sshd_banner

TheHand script

In the example above, timelox is calling a script named TheHand.sh. This script is a bash shell script that takes variables, such the ip number and a text string used to indicate the source of the block. There are two sample scripts provided, one TheHand.sh_ipfw for Mac OS X, and TheHand.sh_iptables for redhat. Both use pretty much the same logic. The example for redhat is set up in a brutal fashion to insert rules at the beginning of the INPUT chain. This method works, but it's not elegant. The ipfw version assumes that you are using a custom firewall, and inserts rules starting at 5000. The way to use this is to set up ipfw so that local host rules are in the lower number ranges, and then put in services acceptance rules starting high (in my case, 25000). That way the deny rule inserted by timelox stays clear of your rules, and the denys occur before the service acceptance rules.

TheHand.sh does some basic sanity checks on the ip number to see that it's valid (currently only ipv4 addresses work) and then inserts a rule denying all traffic inbound from that ip address into the firewall. TheHand.sh also supports logging. There are comments throughout the script that explain pretty well what it does, and it's not very complicated. You should read through the file to make sure you understand (at least roughly) what it's doing. 


Ok, now that the bits should all be in place, time for some testing. To test our sshd installation, we'll start it with some flags in dbug mode on a non-standard port. 

sudo /usr/local/sbin/sshd -p 2222 -d

You'll see something like this:

[Avatar:/usr/local/bin] hays% sudo /usr/local/sbin/sshd -p 2222 -d
debug1: sshd version OpenSSH_4.0p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/local/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='2222'
debug1: rexec_argv[3]='-d'
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
debug1: Bind to port 2222 on
Server listening on port 2222.
Generating 768 bit RSA key.
RSA key generation complete. 

Now, in a different terminal window, try logging into localhost on port 2222, with:

ssh -p 2222

You should see some debugging code fly by in the window in which you started sshd, and something like this in the window you're logging in from:

[Avatar:~] hays% ssh -p 2222
* *
* Warning! Unathorized Logins Prohibited *
* *

Notice the banner--since we set this in the /usr/local/etc/ssh/sshd_config, we know we're using the right config file (and not the default mac /etc/ssh_config).  Give it your password and see if you can login. If you succeed, you've got a working sshd. Type exit, and you'll leave that ssh session and fall back into your terminal window. If you look at the other window, where you started sshd, you'll should have the prompt back. This method of running sshd in debug mode only sets up a single session, so to run another test, you have to restart it (but that's easy, just use the up arrow key to back up one in the cammand history and then hit return).

Now, restart the sshd login into a remote machine, and then try to ssh back to the machine with the new sshd installed, using the same port. This time, munge your password. What should happen is that you get three attempts, and the fourth will appear to lockup (if this worked, then when you try the fourth time, your machine with timelox will insert a firewall rule blocking all traffic from the remote machine). That block will stay in place until you reload your firewall or reboot.  


If it doesn't work the way you expect, use tail in a second terminal window to follow the systemlog:

tail -f /var/log/system.log

This should give you some clues as to what's failing.

The ipfw version of TheHand.sh should also speak aloud when triggered--if it doesn't then the path to it configured may be wrong, or there may be a permissions error. You can also run this script manually, eg:

sudo /usr/local/libexec/TheHand.sh blah blah blah 
Posted by bil at 2:34 PM
Categories: My Software, Work

Sunday, November 07, 2010

Installing nrpe on OS X

This is a guide to installing the nrpe plugin service on OS X. For getting this to work, I am endebted to the following:

If you don't know what nrpe is, you problably don't want it. What nrpe will do for you is allow your nagios server to contact a computer over the network and query it's state, using scripts to check on things such as cpu load, drive space, pretty much anything you can script together. Also, I'm walking through the steps of this process so as to provide a reasonable accounting of what I did, but I've also scripted pretty much all of it, and you can download the whole schmear. There's link to the script at the bottom of this article.

Create a user for the nrpe service to use

The nrpe service, as everything on the mac, will have to run under a user account, and it really shouldn't run under your account, since we wouldn't want it to be able to reach out and hurt your files. There are two ways you can create an account, either via the GUI using System Preferences, or via the command line. I use the latter, but we'll cover the former as well, since I'm not entirely sure of my kung fu creating accounts. I also deviant somewhat from standard unix practice--normally, you'd run nrpe under an account named nagios, but in this case, I'm going to create a general account used to do some housekeeping tasks in addition to just running the nrpe service. Think of this as a maid or butler, with limited power, to whom you can assign household tasks.

Creating the account in the GUI

In the GUI, create the account, and give it a password. Do not make it an administrator. For the purposes of this doc, it will be called susi.

Creating the account via command line

I found a good script online for creating accounts, and modified that, but the meat of it is:

# Create the user account
dscl . -create /Users/${username};
dscl . -create /Users/${username} UserShell /usr/bin/false;
dscl . -create /Users/${username} UniqueID ${new_uid};         
dscl . -create /Users/${username} RealName "${username}";
dscl . -create /Users/${username} PrimaryGroupID "${new_gid}";
dscl . -create /Users/${username} Password "*"        
dscl . -create /Users/${username} NFSHomeDirectory ${homedir};

# Create the group
dscl . -create /Groups/${username};
dscl . -create /Groups/${username} RecordName "_${username} ${username}";
dscl . -create /Groups/${username} PrimaryGroupID "${new_gid}";
dscl . -create /Groups/${username} RealName "${username}";
dscl . -create /Groups/${username} Password "*";

# Create the home dir
mkdir ${homedir};
chown ${username}:${username} ${homedir};

# Test results
echo "Testing results";

echo "User entry for ${username}:";
dscl . -read /Users/${username};

echo "Group entry for ${username}";
dscl . -read /Groups/${username};

Once we have the account in place, we can install the npre bits. The two main parts are the nagios plugins, and the nrpe service.

Install nagios plugins

First, make yourself a working space:
mkdir nrpe_install
cd nrpe_install

Now, get the plugins. The source forge site is http://sourceforge.net/projects/nagiosplug/files/ Or you can try this direct download from a mirror on the command line:

curl -o nagios-plugins-1.4.15.tar.gz \ 

Unpack the tarball, go into the directory and build the code then come back up:

tar -xvf nagios-plugins-1.4.15.tar.gz 
cd nagios-plugins-1.4.15
sudo make install
cd .. 
That was easy.

Install nrpe

You can fine nrpe here: http://sourceforge.net/projects/nagios/files/ Or try a direct mirror link:

curl -o nrpe-2.12.tar.gz \

Unpack and jump into the folder:

tar -xvzf nrpe-2.12.tar.gz
cd nrpe-2.12

Now, we have to make a minor change to the configure file, using vi or your favorite text editor, open the configure file and find the line that tests for the libssl.so file, and comment that out, and add a test for libssl.dylib instead:

vi ./configure 
It should look like this when you are done:
   #if test -f "$dir/libssl.so"; then
   if test -f "$dir/libssl.dylib"; then

Now, if you created the user account via System Preferences, configure nagios to use the susi account, and staff as the group:

./configure \
--with-nagios-user=susi --with-nagios-group=staff \
--with-nrpe-group=staff --with-nrpe-user=susi
If, on the other hand,you created the user account via command line, configure nagios to use the susi account, and susi as the group:
./configure \
--with-nagios-user=susi --with-nagios-group=susi \
--with-nrpe-group=susi --with-nrpe-user=susi
If the configure fails complaining about not being able to find the ssl libraries, double check the configure file--I got held up for a while missing that my browser and editor "helped" me by using smart quotes instead regular double quotes. Now run a make and install the parts we want.
make all
sudo make install-plugin
sudo make install-daemon
sudo make install-daemon-config

Ok, if everything went well, great. Next we edit nrpe.cfg.


The nrpe config file is at /usr/local/nagios/etc/nrpe.cfg, let's take a quick look:

less /usr/local/nagios/etc/nrpe.cfg
In the hardcoded commands section, note the structure:
command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10

In this case, if the nagios server contacts this machine asking for the nrpe service to run the command check_user, the nrpe service (running as susi) will run:

/usr/local/nagios/libexec/check_users -w 5 -c 10
and pass the results and error codes back to the nagios server. Try running the command now as yourself and see if it works ok. Next, let's try starting up an instance of the daemon to make sure it works:
sudo /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d

Now, what nagios uses on the server end to check the nrpe service running on the various machines to be monitored is itself a plugin, check_nrpe. That plugin is installed, so we can check to see if the nrpe service is working ok by calling it with check_nrpe thusly:

/usr/local/nagios/libexec/check_nrpe -H localhost -c check_users
Assuming this works, you should get something back like:
USERS OK - 3 users currently logged in |users=3;5;10;0

Now, what we've just done is verify that we have a working version of nrpe that can be started on this machine, and can be queried using the check_nrpe plugin from nagios. What we need to do now is get this working so that our nagios server can query this machine using that check_nrpe over the network. Next, kill the daemon, and we'll make some changes in the basic configuration. Run:

ps -A | grep nrpe
You should get back something like this:
28582 ??         0:00.03 /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d
28608 ttys000    0:00.00 grep nrpe

The process id for the nrpe command in this case is 28582, so we use that to kill it.

sudo kill -9 28582

Make a backup of the config file:

sudo cp /usr/local/nagios/etc/nrpe.cfg \

Open the config file:

sudo vi /usr/local/nagios/etc/nrpe.cfg

Find the line with allowed hosts, and add the ip number of your nagios server after


We also want to be able to add our own scripts for queries, and we want to do that in such a way as to allow for easy administration. So find the section for include config directory, and add a line:


This dir doesn't exist yet, but it is where we will put our plugin configuration. Any file ending in .cfg and place in this directory will be loaded when nrpe starts. Save the file and quit, then run:

sudo mkdir /usr/local/nagios/etc/nrpe.d

Next create a file, say:

sudo vi /usr/local/nagios/etc/nrpe.d/cs-nrpe-mac.cfg

And add your own commands:

# These are local CS check commands for macintosh systems
command[check_light_load]=/usr/local/nagios/libexec/check_load -w 6.00,6.00,6.00 -c 10.00,10.00,10.00
command[check_heavy_load]=/usr/local/nagios/libexec/check_load -w 12.00,12.00,12.00 -c 24.00,24.00,24.00
# Check for free space in /Users, exclude /afs
command[check_User_disk]=/usr/local/nagios/libexec/check_disk -w 10% -c 5% -x /afs -p /Users
command[check_kernel]=/usr/bin/uname -spr
command[check_zombies]=/usr/local/nagios/libexec/check_procs -s Z -w 3 -c 6
command[check_run]=/usr/lib/nagios/plugins/check_procs -s R -w 3 -c 6

If you write a script in bash or whatever, and you follow the guidelines on how the check_nrpe plug works, you can make custom queries. See for example the check_temper plugin. Restart the daemon:

sudo /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d

Now, login to your nagios server, and call the check_nrpe command against the workstation you've just set up with the check_users command, using the ip name or number of the machine you're running nrpe on:

/usr/lib/nagios/plugins/check_nrpe -H myhost.mydomain -c check_users

You should get a response similar to what you get when you run the check_nrpe plugin locally.


  • If you get an error "Connection refused by host" immediately, double check to make sure that you have the correct ip for the nagios server in the nrpe.cfg, and that the nrpe service is running normally.
  • If the connection appears to hang, check your firewall settings to make sure the firewall will accept connections from the nagios server.
  • If you get an error that check_users is not defined, make sure you are starting nrpe with the correct path to the nrpe.cfg file.

Starting nrpe via launchd

For more on this topic, see Starting-nrpe-via-launchd, but basically, you create a file in /Library/LaunchDaemons/ that contains the instructions for running the nrpe service. By convention, the name of this file begins with the reverse of the domain "owning" it, so in my case the file is named edu.unc.cs.nrpe.plist. Here's a copy of my version, which is a bit different from the one on the web site above.

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/
   <plist version="1.0">

Ok, to start the service, you go to the folder where the launchdaemons are storted and use launchctl to load the plist and to start the daemon:

cd /Library/LaunchDaemons/
sudo launchctl load edu.unc.cs.nrpe.plist 
sudo launchctl start edu.unc.cs.nrpe

And here's how you stop it:

sudo launchctl stop edu.unc.cs.nrpe 
sudo launchctl unload edu.unc.cs.nrpe.plist 

Try starting the daemon, and then run the check again:

/usr/lib/nagios/plugins/check_nrpe -H myhost.mydomain -c check_users

If you don't get a response, check the system log:

sudo tail -f /var/log/system.log
If you see a bunch of stuff similar to this run by:
Oct 27 11:28:32 myhost.mydomain com.apple.launchd[1] (com.apple.launchd.peruser.504): Throttling respawn: Will start in 10 seconds
Oct 27 11:28:42 myhost.mydomain com.apple.launchd[1] (com.apple.launchd.peruser.504[12283]): getpwuid("504") failed
Oct 27 11:28:42 myhost.mydomain com.apple.launchd[1] (com.apple.launchd.peruser.504[12283]): Exited with exit code: 1

you probably have a problem with the account. Double check to make sure that the nrpe.cfg file is specifying the correct user and group. Also, if you start over at some point and delete or create an account, one thing to be aware of is account data is cached in the system. The errors above I got after deleting an account via commnand line, that account had the UID of 504 but the cache had not cleared, so I rebooted and the errors stopped.

An installer script

I've put together some scripts to do all of this automagically, but use them at your own risk. There's a 00readme, but the short version is you download it, unpack it, and then run it, giving it the userid you would like nrpe to run under and the ip number of your nagios server. You can download it here.

myworkstation:~ hays$ tar -xzf nrpe_installer.tgz 
myworkstation:~ hays$ cd nrpe_installer
myworkstation:nrpe_installer hays$ sudo ./install.sh

Usage: install.sh [OPTIONS] 
   -c = Configure nrpe packages on this system
   -m = Make nrpe packages on this system
   -i = Install made verison
   -a = Configure, Make, Install all
This should work in all cases
for a fresh installation, and possibly all generic cases
   -u = Userid to use for installation, who the installed software
will run as (required)
   -s = Ip number of the nagios server (required)

   The most common usage would be:
   ./install.sh -a -u [userid] -s [nagios server ip number]

myworkstation:nrpe_installer hays$ sudo ./install.sh -u susi -s x.x.x.x -a
Posted by bil at 10:33 AM
Categories: My Software, Other Software, Work
Comment by Matt Urbanski - Thursday 02nd February 2012 07:19:40 PM

Thanks Bil! You saved me from what was likely going to be a night of figuring out how to get nrpe working on a Mac OSX box. We only have one and only need one, so it would have been knowledge I would have gained grudgingly!
I really appreciate it.


Comment by Mark Clayton - Monday 20th February 2012 05:47:59 PM

Maybe my post will help someone else out. I upgraded to Lion form SL the other day. After the upgrade my MBP's fan was running full speed and the battery drain was excessive. Turning off the network brought the symptoms back to normal. Eventually, I figured out that launchd was hogging the cpu by looking at 'top -o cpu'. Looking in system.log, I found getpwnam was failing on nrpe startup. Apparently the Lion upgrade removed the nrpe user and group. Once I recreated the user and group, cpu usage, the fan speed and the battery drain returned to normal. This error occurred on 2 different macs.

Comment by bil - Monday 20th February 2012 06:13:21 PM

Thanks, that's a good tip to know!
Comment by Mahesh - Tuesday 19th June 2012 04:09:33 PM

Thank you so much Bil. Was struggling with installing Nagios on Mac and you saved me now.. .. : )
Comment by John McAdams - Tuesday 03rd July 2012 12:04:36 PM

Thank you for this. I'm still new to Nagios and have a dozen OS X servers to monitor. The macosx-nrpe-agent in NagiosXI doesn't work on Mountain Lion (yet) and this was a great way to get my test machines into Nagios.
Comment by Raouf - Thursday 19th July 2012 07:10:56 PM

Thank you so much for this. It was a great help for me .. .
Comment by JohnO - Sunday 23rd December 2012 01:05:27 AM

Thanks for posting these excellent instructions! They worked very well in OS X 10.8.2 Mountain Lion with two changes:

1) After installing Xcode, you need to install the command line tools from within Xcode so that the makefiles can find the C compiler. This can be found via XCode --> Preferences --> Downloads: Install Command Line Tools.

2) With the current nrpe (nrpe-2.14) you no longer need to modify the ./ configure script to deal with the libssl dynamic libraries. That check has been added to the configure script already.

One suggestion: You might wish to highlight the lines in the plist file that are likely to need to be edited. For example, I saved my plist with a name that made sense for me. I also created a different username than susi. Straightforward, I know, but it might save future person a little head scratching since the errors you receive do not clearly point you to what you did wrong when you try to load or start via launchctl.

Thanks again!


Tuesday, June 15, 2010

Installing Snort and Barnyard2 in Ubuntu 9.10: Part 2

This is a follow up to Installing Snort and Barnyard2 in Ubuntu 9.10: Part 1, in this part we'll look at how snort is started by init.d and we'll set up a simple upstart config to start barnyard2 when the system starts

Starting Snort

By default, snort is set to start as a daemon via init.d, so we'll leave that be. But Ubuntu is moving to Upstart as a replacement for init.d, so we'll try to get that working for barnyard, rather than use init.d. Fortunately, upstart was designed with compatibility in mind. The first thing we'll do is check out the init.d file for snort (that got installed when we installed the snort package). To see if snort is already running, use the ps command, if it's running you'll see something like this:

$ ps -A | grep snort
1569 ?        00:00:01 snort 

If it's not running, try starting it manually:

$ sudo /etc/init.d/snort start
* Starting Network Intrusion Detection System snort                    [ OK ]

If this is the first time you've fired up snort via init.d, you'll likely get this back:

$ sudo /etc/init.d/snort start
[sudo] password for hays: 
* Starting Network Intrusion Detection System  snort
* /etc/snort/db-pending-config file found
* Snort will not start as its database is not yet configured.
* Please configure the database as described in
* /usr/share/doc/snort-{pgsql,mysql}/README-database.Debian
* and remove /etc/snort/db-pending-config

Ok, that error is caused by a bit just a left over from our install. Move the file (it's best to not delete a file if you can just mv it, that way you can undo the damage if you mess up), and try again to start snort:

sudo mv /etc/snort/db-pending-config /etc/snort/db-pending-config.orig
sudo /etc/init.d/snort start

If you're not familiar with init.d, you can also use "stop" and "restart" instead of "start"

Next, just to make sure everything's working as expected, fire up barnyard and check the base web page:

sudo /usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf \
-G /etc/snort/gen-msg.map -S /etc/snort/sid-msg.map \
-d /var/log/snort -f snort.log -w /var/log/snort/barnyard.waldo

If the base page is showing alerts, we're good to go.

Now, one issue is that the way snort starts in Ubuntu 9.10 via init.d is that the configuration files are spread out a bit. For example, some settings are stored in /etc/snort/snort.debian.conf.

# This file is used for options that are changed by Debian to leave
# the original lib files untouched.
# You have to use "dpkg-reconfigure snort" to change them.


/etc/default/snort is used to set the user, group, and log file location:

# Parameters for the daemon
# Add any additional parameteres here.
PARAMS="-m 027 -D -d "
# Snort user
# This user will be used to launch snort. Notice that the 
# preinst script of the package might do changes to the user 
# (home directory, User Name) when the package is upgraded or
# reinstalled.  So, do *not* change this to 'root' or to any other user 
# unless you are sure there is no problem with those changes being introduced.
# Logging directory
# Snort logs will be dropped here and this will be the home
# directory for the SNORTUSER. If you change this value you should
# change the /etc/logrotate.d/snort definition too, otherwise logs
# will not be rotated properly.
# Snort group
# This is the group that the snort user will be added to.
# Allow Snort's init.d script to work if the configured interfaces
# are not available. Set this to yes if you configure Snort with
# multiple interfaces but some might not be available on boot
# (e.g. wireless interfaces)
# Note: In order for this to work the 'iproute' package needs to 
# be installed.

But, aside from the parameters in these files, the rest of the stuff in the /etc/snort/snort.conf file is honored.

Automating the Barnyard startup

Upstart is a replacement for init.d, similar in most respect to Apple's launchd. Since Ubuntu is moving to upstart, we'll use a simple upstart config file to start barnyard2. There is a good article on upstart at linux.com.

Upstart files live in /etc/init, basically the upstart system reads the files in this directory and starts them accord to the settings. Let's take a look at a couple of examples.


# ufw - Uncomplicated Firewall
# The Uncomplicated Firewall is a front-end for iptables, to make managing a
# Netfilter firewall easier.

description     "Uncomplicated firewall"

start on net-device-added INTERFACE=lo
stop on runlevel [!023456]

console output

pre-start exec /lib/ufw/ufw-init start quiet
post-stop exec /lib/ufw/ufw-init stop

This config controls the ufw interface for iptables. Some things to note:

  • The exec statements execute the command, in this case when the localhost interface is added, /lib/ufw/ufw-init start quiet starts the firewall.
  • The stop command tells upstart to stop the firewall (via post-stop exec /lib/ufw/ufw-init stop) when the run level is not set to 0, 2, 3, 4, 5, or 6.


# tty1 - getty
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

exec /sbin/getty -8 38400 tty1

This one uses slightly different settings, note especially the respawn flag, which will restart the getty if it crashes

For barnyard2, we'll use the same command we use to start the program manually, but put it in a barnyard2.conf file in /etc/init. Here's a version that works for me:

# rc - System V runlevel compatibility
# This task runs the old System V-style rc script when changing between
# runlevels.

description     "Barnyard2 for Snort support"
author          "bil b@unc.edu"

start on started networking
#start on startup
#start on (startup
#          and filesystem
#          and started udev)
#stop on runlevel [!023456]


exec /usr/local/bin/barnyard2 \
   -c /etc/snort/barnyard2.conf \
   -G /etc/snort/gen-msg.map \
   -S /etc/snort/sid-msg.map \
   -d /var/log/snort -f snort.log \
   -w /var/log/snort/barnyard.waldo

With that file in place, barnyard2 should start on boot and keep running until shutdown. This is admittedly a very crude upstart configuration, but it seem to work.

After restarting, check your base page to make sure you're getting alerts. You can also use the ps and kill commands to check the reliability of barnyard2--if you kill the process, upstart should respawn it for you:

$ ps -A | grep barnyard2
 1198 ?        00:00:00 barnyard2
$ sudo kill -9 1198
[sudo] password for hays: 
$ ps -A | grep barnyard2
 2078 ?        00:00:00 barnyard2 

Finally, you can stop and start barnyard2 manually using the start and stop commands, eg:

sudo stop barnyard2

Ok, we're done, time for a refreshing beverage.

Posted by bil at 11:10 AM
Categories: My Software, Other Software
Comment by Nathan Beam - Tuesday 18th October 2011 04:41:21 PM

I had a hard time finding this second tutorial but boy am I glad that I did. The more of your stuff that I go through the more accustomed I am getting to Linux, snort, and all of the surrounding programs.

Anyhow, learning about init and init.d was extremely useful. Upstart seems VERY easy to use compared to the scripts I looked at in the init folder.

I was wondering if you were going to do a third part talking about how to download new definitions for snort and how to install them?

These two tutorials have been an absolute lifesaver and I really can't thank you enough!


Comment by bil - Wednesday 19th October 2011 09:49:00 AM

Thanks for the compliment! I don't know when I'll have time to get back to this, but what you're looking for is oinkmaster:
http: / / oinkmaster.sourceforge.net/

You might also check out easyids, it's a pretty nice prepackaged snort box running under centOS.

Saturday, May 08, 2010

Updates to TEMPer Articles


I've updated the check_temper script to include support for multiple TEMPer units, and updated the documentation with some bugs fixes and corrections. The two relevant articles are:

Software to support the TEMPer USB thermistor 

Service Monitoring with the TEMPer USB thermistor 

Posted by bil at 11:15 AM
Categories: My Software

Sunday, March 21, 2010

Service Monitoring with the TEMPer USB thermistor

In the first part of this tutorial, we looked at the perl modules for the TEMPer device. I also wanted a way to use this for monitoring and logging, and as I don't happen to be proficient in perl, I decided to write a bash script that will call the perl script. In this part, we'll look at the bash script, a php program that can act as a central logger or notification tool, and also how to use the bash script as a plugin for nagios. Please keep in mind that this document is written for Unbuntu 9.10, this may also work with other operating systems and versions, but this isn't tested elsewhere. Also, please note that this is a revised version, I've made some significant improvements, I think.

Bash: check_temper

The bash script is named check_temper (to mesh with nagios's naming convention, and is listed here. First off, download the bash script and check the script:

wget -O check_temper http://www.cs.unc.edu/~hays/dev/bash/temper/check_temper
chmod a+x check_temper
sudo ./check_temper 

You'll likely get an error like this:

/usr/local/bin/temper_mon.pl not found

check_temper looks for the perl script, temper_mon.pl in /usr/local/bin/, which is the standard local for user installed software on most linux systems. In the first part of this, we left the temper_mon.pl file in the home dir. It would be better to have check_temper in /usr/local/bin/ also, so let's move that:

sudo cp temper_mon.pl /usr/local/bin

Now try the check_temper file again:

sudo ./check_temper 

You should get back something like:

Critical: Temperature is 78.8 F

If you take a look at the script, you'll see that there are some variables at the top that define what a warning temperature is, and what a critical temperature is. You can also control whether output is in fahrenheit or celcius.

If you run the program again, and then check the error code, you should see that a critical temp reports an error code of 2, a warning an error code of 1 (2 is also used if something is not found or didn't work), and 0 if the temp is low enough. For example:

bil@test:~$ sudo ./check_temper 
Critical: Temperature is 78.8 F
bil@test:~$ echo $?

Now copy check_temper to /usr/local/bin so it's available on the path:

sudo mv check_temper /usr/local/bin

The way the script works, it looks at the output from the temper_mon.pl script, and compares the temperature to the warning and critical values. If the temperature is below the warning level, the program exits with a 0 error code. Anything between the two generates a 1 error code, and if the temperature is above the critical level, the program exits with a 2 error code. This behavior is consistent with nagios as we will see, but it also allows you to use this script with other programs.

PHP Monitor

If you look in the variable section of check_temper, you'll see that you can specify a url. The idea here is that the script can pass data to a program on a web server, which will then do some logging or send an alert. The bash script uses wget to GET a web page from the server and passes variables to the server, specifically the temperature, error code, and the message. If you don't want to use this feature, you can just leave that line commented out.

I've written a pretty simple php program that can process the data passed in the GET. What it does is take in the data, and then writes out a log file with the ip address of the machine that send the get, with a time and data stamp, the ip address, the temperature, the error code, and the message. I'm not going to tell you how to set up a php server, but it's not that hard to do. But when you do, do please make sure to restrict access to it if you use this program, it doesn't do much sanitizing of user data, and since it does send email, I'm not going to claim that it's secure. All we want here is for a machine to be able to report to a server, so restricting access by password and ip numbers should be sufficient. You can download a zip of the php directory I use. The package includes an emailer function I use, and a file directory where the logs get written--you need to make sure the web server can write to that directory.

If the temperature is too high, it will also write out two additionals files, a WARNING file that acts as a log of all the warnings seen for that IP address, and an ALERT file that acts as a marker for when a warning was sent. If the ALERT file isn't stale, no email is sent (this allows one to limit the number of warnings sent via email.) The interval that defines staleness is in the variable section of the php program. There's also a default high temperature setting, and a case statement that allows one to tailor temperatures for other devices.

Now, this php program is a bit unusual--it does not put out any html. There are some echos and whatnot that are commented out, you can uncomment these and call the page with a get statement to test things out to get it working. But the program is really just designed to act as a logger/warning. Of course, at some point I'll write a php program to read the data being logged, but that's a job for laterman. What the program does do is to write out a file in the files directory with the ip number of the host reporting as the file name, and the data (timestamp, ip, temp, error code and message) in tab delimited format.

So, if you want to use just this php program as your monitor, that should work fine--what you'd do is set up a cron or an upstart to call this however often you want it to run. If you're new at this stuff, the cron's the easier way to go.


The way the bash program is written, it can also serve as a nagios plugin via nrpe. This will not do you any good unless you already have a nagios server setup and running. If you don't know what I'm talking about, you can either run off and learn nagios, or just skip this part. Nagios isn't trivial, but I'll wait here until you come back.

To use this, first install the nrpe server for nagios:

sudo apt-get install nagios-nrpe-server
On a system that's bound to an external NIS database for users and groups I got the following error:
Unpacking nagios-nrpe-server (from .../nagios-nrpe-server_2.12-3ubuntu1_i386.deb) ...
addgroup: The group `nagios' already exists as a system group. Exiting.
usermod: user 'nagios' does not exist in /etc/passwd

I imagine that Any system bound to an external user system such as LDAP might get a similar message, this is a known bug. So I added:


as the last line in /etc/passwd, since that's the line that this installation puts into that file on a standalone machine. That let me run the installation, and afterwards, I just removed that line. I don't think this will hurt anything, but if you know better, please let me know. You won't need to do this on a stand along machine, the nrpe server install will create the nagios account for you.

To make things easier to troubleshoot, we'll run our nagios plugin as a user named nrpe. The reason for this is that the nagios nrpe debugging information is a bit sparse, and for troubleshooting, it's handy to be able to login to the same account as nagios will use to run the plugin.

sudo adduser nrpe

Next link the check_temper file to the nagios plugins directory:

sudo ln -s /usr/local/bin/check_temper /usr/lib/nagios/plugins/ 

Make sure to double check the permissions to make sure it's only writable by root. Now, edit the /etc/nagios/nrpe_local.cfg file:

sudo vi /etc/nagios/nrpe_local.cfg

and add this line (and please note this is a change from the previous verson of this article, I found that using the sudo command prefix in the nrpe.cfg file interferes with other plugins):

command[check_temper]=sudo /usr/lib/nagios/plugins/check_temper

This tells the nrpe service to run /usr/lib/nagios/plugins/check_temper when nagios contacts it and asks for check_temper. Please note, you can also make or use a directory, /etc/nagios/nrpe.d and put your config file there--if there are any files that are in that directory, nrpe will try to use them. This is useful if you're adminning multiple machines with similar configurations.

Next, edit the config file /etc/nagios/nrpe.cfg

sudo vi /etc/nagios/nrpe.cfg

Replace with the IP address of localhost that is running the Nagios monitoring server:

Then comment out the nrpe=nagios line and add a line making the nrpe user to nrpe:
And then set the group:

Also, uncomment the line command_prefix=/usr/bin/sudo Don't do this after all, it's easier to use the sudo command in the .cfg file.

# This lets the nagios user run all commands in that directory (and only them)
# without asking for a password.  If you do this, make sure you don't give
# random users write access to that directory or its contents!

If you running nagios and this temperature monitor on the same machine you can uncomment the server_address= line:

Finally, check the bottom of the file to make sure that the include for the nrpe_local.cfg is enabled:

# local configuration:
#       if you'd prefer, you can instead place directives here

Next, open the /etc/nagios/nrpe_local.cfg file:

sudo vi /etc/nagios/nrpe_local.cfg
And add the line telling nrpe where check_temper is located:

Then save the file and restart the nrpe service:

sudo /etc/init.d/nagios-nrpe-server restart

If you're new to nagios, you might look into other commands that work through npre. For example, you can use npre to check load:

command[check_light_load]=/usr/lib/nagios/plugins/check_load -w 6.00,6.00,6.00 -c 10.00,10.00,10.00

or look for zombies:

command[check_zombies]=/usr/lib/nagios/plugins/check_procs -s Z -w 3 -c 6

Next, softlink the check_temper file to the /usr/lib/nagios/plugins dir:

sudo ln -s /usr/local/bin/check_temper /usr/lib/nagios/plugins

So far so good. Open a ssh connection to your nagios server. If you don't have nrpe support, you need to install it:

sudo apt-get install nagios-nrpe-plugin

Now try running the check_nrpe plugin from the nagios server, pointing it at your temperature monitor:

/usr/lib/nagios/plugins/check_nrpe -H test -c check_temper

You should get something like this:

-sh-3.2$ /usr/lib/nagios/plugins/check_nrpe -H test -c check_temper
check_temper failed to log temp F

That's ok, we know from this that the check_temper program got called, and somehow failed.

The reason it didn't report back a temperature is probably because the check_temper isn't allowed to run in privileged mode, and thus cannot query the device.

If, on the other hand, you get:

CHECK_NRPE: Error - Could not complete SSL handshake.

that probably means you didn't restart the nrpe service on your remote system, or didn't add your nagios server as an allowed host.

Or, if you get:

NRPE: Command 'check_temper' not defined

it's probably a problem with the line in the nrpe_local.cfg file.

What we need to do now is added nrpe to the sudoers file so that it can run commands without a password. To do this we run the visudo command:

sudo visudo -f /etc/sudoers

Add this line to the file at the bottom and try it out:

nrpe  ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/

Now, log in as nrpe, and try to run the plugin with out a password:

sudo /usr/lib/nagios/plugins/check_temper

It should run without you having to provide a password. Should's a big word though. If it asks for a password, double check your /etc/sudoers file.

Now, go back to your nagios server and try calling the plugin again:

/usr/lib/nagios/plugins/check_nrpe -H test -c check_temper

Hopefully, this time you got good output.

Now, what you should probably do is go back to the /etc/nagios/nrpe.cfg file and change the user and group from nrpe to nagios, so that your installation is in line with a standard installation. If you do this, you'll also need to use visudo to edit the /etc/sudoers file removing nrpe's privileges and grant the same priviledges to nagios. But if you don't want to bother, at least disable nrpe's ability to login and use a shell, so as to safeguard your system.

At this point all you need to do is add this service into the service.cfg and host.cfg files in /etc/nagios.

Example of host.cfg entry:

define host{
use                     generic-server
host_name               test.unc.edu
alias                   TEST
address                 test.unc.edu

Example of services.cfg entry:

define service{
use                             generic-service
host_name                       test.unc.edu
service_description             CHECK-TEMPERATURE
contact_groups                  server-admins
check_command                   check_nrpe!check_temper

So there you have it, a simple set of ways to leverage the USB TEMPer module to set up an alert system. Please let me know if you run into any problem with this, and best of luck.

Posted by bil at 4:38 PM
Edited on: Saturday, May 08, 2010 11:15 AM
Categories: My Software, Other Software, Work
Comment by Joseph Dyland - Thursday 29th April 2010 11:40:15 PM

Great post, Very helpful and informative, I had purchased two of these units and was at a standstill for quite a while.

Would you happen to have any tips on getting the temperature to populate the performance data field in Nagios?, I would love to be able to graph temperature overtime and am so close now!
Comment by bil - Friday 30th April 2010 08:36:53 AM

I'll look into it, thanks,
Comment by Anonymous Coward - Friday 30th April 2010 08:51:36 AM

I ended up figuring it out, I found that performance data is taken from any thing after |

So I simply added a pipe to the area where the message is being printed out, adding temperature= then the variable of the temperature it self, followed by minimum and maximum values, It is now working exactly as I have wanted!

message="${message} Sensor ${iteration} Temp is ${x} ${temp_ind}|temperature=${x};55;60"

In nagios it looks like this,

Status Information: Normal: Sensor 0 Temp is 25.5 C
Performance Data: temperature=25.5;55;60

Now I do have one more question, Do you know how I could add a second TEMPer sensor using the methods you have provided?

Comment by bil - Friday 30th April 2010 09:41:45 AM

I haven't written up the docs yet, but I updated the check_temper bash script to support multiple sensors. So if you download it again, it should just work with 2-3 sensors.
Comment by Riccardo - Wednesday 08th September 2010 09:48:22 AM

Great Post !
Only a note, the PHP directory structure zip file is not more available !

Comment by bil - Thursday 16th September 2010 01:35:27 PM

Thanks for letting me know, it's up now. Expect a new version in a few weeks.. ..

Themes for Thingamacomment

I've started putting together some themes for Thingamablog that support the Thingamacomment software. Only the template files are modified, the stylesheets have been left alone since I'm not very good with CSS yet. To make it easy to keep these separate from exisiting themes, I've adopted a naming convention of adding "TC" to the end of these--you can safely install them using the Tools, Install Theme Pack, and then apply that theme to your blog. The ones I've done so far are up at https://wwwx.cs.unc.edu/~hays/dev/php/thingamacomment_themes/ 

Posted by bil at 2:24 PM
Edited on: Sunday, March 21, 2010 3:49 PM
Categories: My Software

Monday, March 15, 2010

Software to support the TEMPer USB thermistor

The TEMPer USB thermistor is a small unit you can buy online. The short version is that this is a cheap solution to having a computer record temperatures, but there are some issues. First of all, the company that makes these has used a variety of internals--early versions were straight serial devices converted to usb. Sometime in the last year or two, they switched to unit that use the HID interface, so you may need to search around to find code that will work with your unit. Also the software that comes with it is really bad, and support is almost non-existant, and the language barrier for english speakers is pretty severe. But the good news is the net being what it is, there are a lot of folks working on these things, and now there are some pretty good options.

Some links for background:

The last link is the one that was most useful to me, especially the part down in the comments--Magnus Sulland wrote a perl module that leverages libusb to read the device (many thanks to him!).

This document outlines installing his code on Unbuntu 9.10 (Karmic). I also tried this on Redhat and OSX, but no joy--the perl used on those systems is different (5.8.x) and this requires 5.10. Also, I think that using libusb might be tricky on OSX, since Apple handles some things very differently. If anyone out there has good installation for a TEMPer unit for OSX or Redhat, drop me a line.

First thing to do is install libusb's headers:

sudo apt-get install libusb-dev

Then we'll install some perl modules:

sudo cpan -fi Bundle::CPAN

If this is the first time you've run cpan, it will walk you through a series of configuration questions. I just took all the defaults and choose some local repositories when prompted. I'm sure that there's some way to tell cpan to not ask questions and just use defaults, but I don't know how (love to learn how tho).

Next, install the MakeMaker util:

sudo cpan -fi ExtUtils::MakeMaker

You may see some warnings that there are dependencies that have to be satisfied, just say yes. They'll look something like this:

---- Unsatisfied dependencies detected during [S/SI/SISYPHUS/Inline-0.46.tar.gz] -----

Parse::RecDescent Shall I follow them and prepend them to the queue

of modules we are processing right now? [yes]

I just hit return to accept the yes.

Once that's all done run these commands:

sudo cpan -fi Inline::MakeMaker 
sudo cpan -fi Device::USB

Now, install Magnus's module for the TEMPer device:

sudo cpan -fi Device::USB::PCSensor::HidTEMPer

The source for this is up at: http://search.cpan.org/dist/Device-USB-PCSensor-HidTEMPer/

Now, you need a file that will call the perl module, mine is named temper_mon.pl
cd ..
wget -O temper_mon.pl http://www.cs.unc.edu/~hays/dev/bash/temper/temper_mon.pl
chmod a+x temper_mon.pl
The file contains this code from Magnus Sulland into the file:
#! /usr/bin/perl

use 5.010;
use strict;
use warnings;
use Carp;
use Device::USB;
use Device::USB::PCSensor::HidTEMPer::Device;
use Device::USB::PCSensor::HidTEMPer::NTC;
use Device::USB::PCSensor::HidTEMPer::TEMPer; 
use lib;
use Device::USB::PCSensor::HidTEMPer;

my $pcsensor  = Device::USB::PCSensor::HidTEMPer->new();
my @devices   = $pcsensor->list_devices();
foreach my $device ( @devices )
   say $device->internal()->celsius();

Now, try to run it:

sudo ./temper_mon.pl

At first mine didn't respond. On one machine it started working on the third try. Another required a reboot. But in general, so far so good.

Note: After doing some installs, I started running into problems getting a segmentation fault when running the temper_mon.pl script. I got some advice from Magnus, and it turns out that the upgrade from Device::USB version 0.31 to 0.32 or 0.32 breaks this. To get around this issue in the short term, I downloaded version 0.31, built and installed that from source. I've put a copy of device-usb0.31.tgz up in case you need it. To use this, run the following commands:

wget -O device-usb0.31.tgz \
tar -xvzf device-usb0.31.tgz 
cd Device-USB-0.31/
perl Makefile.PL
make test
sudo make install

There's also a README file in the package with some information.

I've also written a short shell script to use with this as a nagios plugin and also a php program to use as a web logging tool, see Service Monitoring with the TEMPer USB thermistor for details.

Posted by bil at 8:07 PM
Edited on: Sunday, April 04, 2010 12:24 PM
Categories: My Software, Other Software, Work
Comment by internet - Sunday 09th May 2010 06:49:34 PM

I ran into this problem as well..
WARNING: Ignoring corrupt/ truncated waldofile '/ var/ log/ snort/ barnyard.waldo'
Opened spool file '/ var/ log/ snort/ snort.log.1271249772'
ERROR: Unknown record type read: 2148576734
Fatal Error, Quitting..
The fix was to configure bardyard as indicated on this site:
http: / / www.securixlive.com/ barnyard2/ faq.php

I also had a problem where Base-1.4.4 only displayed the main screen, none of the sub pages showed up. After turning on debugging in the php.ini i found the error Fatal error: Call to undefined method ProtocolFieldCriteria: : ProtocolFieldCriteria() in / var/ www/ base-1.4.4/ includes/ base_state_citems.inc.php on line 1113 I traced the problem back to something that was resolved in the Base-1.4.5 release Using 1.4.5 resolved the problem. http: / / sourceforge.net/ projects/ secureideas/ files/
Comment by Aaron - Thursday 26th August 2010 11:33:10 PM

I was able to get the TEMPer to work on ubuntu 10.04, the first try, using your instructions. Thank you very much for the work you've put into this howto.
Comment by jnihil - Thursday 02nd September 2010 08:24:44 PM

Likewise, no issues. Thanks a lot for the great article.
Comment by Jack Myers - Monday 13th September 2010 10:22:29 PM

When I reach the step:
sudo cpan -fi Device: : USB
and it hits the tests, it maxes out 7 gb ram and 7gb swap, thrashes my drive badly, kills Firefox & any other programs running and fails just about all the tests. It eventually finishes but leave the OS in such a sad state that I have to reboot.
Not sure what is going on here.
I'm on Ubuntu 10.04 64 bit, AMD quad w/ 7gb ram. I see that others have been successful on 10.04 so I'm confused.

Any suggestions on how I can track down the problem? (I'm pretty new to PERL but have been programming in a couple of dozen languages for a living for the last 30 years. Generally, adding a new language comes easy to me though I'm just starting reading the O'Reilly Perl nutshell book).

Thanks for any suggestions you may have (and for the work you've done on this).

Comment by eclyptox - Wednesday 15th September 2010 06:36:32 PM

Hi! Yesterday I worked out to make it run as you say. But since today in the internal in celcius I only read 0.99609375.

I read the temperature several times, but the internal one only shows that number.

Comment by bil - Thursday 16th September 2010 01:46:17 PM

Sorry, these last two I can't be of much help with. You might want to check out this like:
There's an extended discussion there, and Magnus Sulland has updated the perl code, but I haven't tried that or gone to ubuntu 10. I'll post a note when I do about my results, should be doing that in a couple of weeks. Also, 0.99609375 I think represents a limit of some kind being exceeded.
Comment by Baskin Tapkan - Saturday 05th February 2011 06:48:12 PM

Thanks for the great post. Worked out great. I am in the process of brushing up with Perl and write the results to a file using perhaps Cron. Any other automated ideas? : )


Comment by Torsten - Monday 02nd May 2011 07:27:20 AM


i tried the TEMPer stick for a few days with good results.
But today i can only read out 0.99609375 as 2 comments above.
Some one known this problem ?

BR/ Torsten
Comment by bil - Monday 02nd May 2011 09:02:38 AM

Yes, I see similar behavior from time to time, usually just reseating the Temper USB device clears it.
Comment by zelotoh - Wednesday 01st June 2011 05:33:26 PM


Do you know how can I execute temper_mon.pl without sudo rights?

Thanks in advance
Comment by bil - Wednesday 01st June 2011 07:34:08 PM

No, I don't, since it needs privs to access the temper device. But if you add your user id, or if you want to allow anyone on your server to use it without admin rights, you can edit the sudoers file with visudo to grant users the ability to run this or any other command without typing a password. If you check out the followup to this article, there's some discussion of how to allow a user npre to run plugins without a password, and an example. Feel free to email me if you have questions,

Saturday, January 09, 2010

Count Down Timer

I've written a simple countdown timer. The idea is you can use this program when speaking before an audience to keep track of time. The program counts down from time specified in hour or minutes, indicates yellow at the warning interval, and starts flashing red and counting up once the time has expired. It's written in javascript, so it displays in a browser window (if you use firefox you can use zoom in and out to change the size). You can try it out, and it's available for download.

Posted by bil at 4:17 PM
Categories: My Software

Saturday, November 28, 2009

New Version of Timelox for Openssh 5.3p1

I've put up a new version of Timelox for use with Openssh 5.3p1. Timelox is a patch for sshd that shuts down brute force attempts to break into machines via ssh. Timelox is different than most other methods in that it detects failed logins from a given ip number, rather than attempts against a userid. So if, as we've seen, attackers use a script that attempts to login with multiple userids, timelox will detect that and call a script to lock out that ip in the firewall.

The latest version includes an installer script for OSX. For more information see the main timelox page at  https://wwwx.cs.unc.edu/~hays/dev/timelox_and_TheHand

Posted by bil at 1:24 PM
Edited on: Monday, March 15, 2010 8:44 PM
Categories: My Software


I've been playing around with Thingamablog, a nice little standalone application you can use to manage a site without having to use a database on your server--the approach appeals to me since the resulting web site is portable and more secure. But I wanted to be able to support comments. I poked around a bit, didn't find anything that really suited me or worked easily. I did find a nice page, part of Notes from James, that had a simple set of php scripts that would enable comments. That worked nicely, but it wasn't very secure, so I started playing with it and before long I had something workable, at least for my needs. It's still in need of testing and poking and prodding, so if you give it a try send me some feedback. I'm calling it Thingamacomment, and the current version is 0.9d.

The short version of how it works is you edit the template pages in your Thingamablog with some php code to pull in comments or parts of Thingamacomment. The commenting code and data are stored in a folder named "comments" at the root of the Thingamablog software. Comments are stored in a files folder and are named after the Thingamablog article to which they belong. When a user added a new comment, the comment is put into a small file named with an article number and a timestamp, and then are appended to the appropriate comments file, either immediately or after confirmation by the blog owner. When a comment is address, an email is sent to the blog owner (either with a confirmation URL or just to let the owner know).

For the long version, see the enclosed readme file.

The scripts also try to prevent malicious use by stripping out html tags, and looking for malformed data in email messages. It can also use ReCaptcha to help filter out bot traffic.

Posted by bil at 11:13 AM
Edited on: Sunday, March 21, 2010 4:34 PM
Categories: My Software
Comment by guest - Sunday 07th February 2010 09:31:14 AM

testing your comments feature
Comment by Matthew Carrick - Thursday 11th February 2010 02:05:31 PM

Thanks for this Bill. With Haloscan morphing into echo I was looking for something nice and low-res.
Comment by bil - Thursday 11th February 2010 02:53:05 PM

Thanks! Pop me some email to let me know how it works out for you.
Comment by bil - Sunday 21st March 2010 08:01:58 AM

Comment by jesus2099 - Saturday 17th April 2010 11:12:40 AM

How about gravatar support ?
Comment by bil - Saturday 17th April 2010 02:02:33 PM

Not likely, as I don't know what that is. (;
Comment by my name - Wednesday 05th May 2010 04:31:50 AM

testing the comment feature. Looks good.
Comment by Jason - Wednesday 19th May 2010 07:23:09 AM

Just testing the system. If this works - Woohoooo
Comment by akash - Thursday 03rd June 2010 01:43:16 AM

test is complete
Comment by Jan - Friday 16th July 2010 01:07:52 PM

Looks nice and clean, may try it out
Comment by Am M - Thursday 05th August 2010 12:26:53 AM

Looks great. Will it work as a standalone comment feature or just with Thingamablog?

Comment by baz - Monday 30th August 2010 07:50:52 AM

Thingamacomment looks cool - nice job.
Comment by Zack - Tuesday 17th May 2011 09:41:06 PM

I'd love to use this for my blog!

Monday, November 09, 2009

Software Development

I do a fair bit of programming in bash, php, and ruby.

Posted by bil at 2:52 PM
Edited on: Monday, November 09, 2009 2:53 PM
Categories: My Software

First Entry

Not very interesting.....

Posted by bil at 1:24 PM
Categories: My Software