« Pictures | Main

Wednesday, March 27, 2013

Tightening Java

Oracle's Java has been shown to be chock full of holes, but some people need to have it. This doc will outline some changes you should make to tighten it up a bit. To make these changes, open the Java control panel.

Set daily update checks

With the recent spat of security reports, you want to keep Java up to date. By default, it only checks for updates once a month. Change that to daily in the Update tab:

Move the slider

Next, go to the security tab and move the slider to High. If you don't have a slider here, your java needs to be updated via the Update tab:

Enabled online certificate checks

Finally, click on the Advanced link on the Security tab and enable both the enable online certificate validation and Check certificates for revocation using Certificate Revocation lists. The former tells Java to check online for the status of any certificate presented to it, and the latter tells java to chek online to see if a Certificate Granting Authority has issued a revocation for a given certificate. With these options checked, a bad certificate may be allowed.

Disable elevated priviledges for self-signed certificates

Anyone can make a self-signed certificate, so you want to disable granting elevated privileges for those.

Posted by bil at 9:41 AM
Edited on: Wednesday, March 27, 2013 11:34 AM
Categories: Other Software, Work

Monday, December 17, 2012

Installing Splunk forwarder on OS X

Splunk has a component called a forwarder, think of this as a thin client that forwards log data to a splunk server (the indexer, in particular). Here's a basic installation procedure for OSX. For this we will be using the darwin tarball, rather that the OS X dmg. The latter stores all of the data and configure inside of the OS X app bundle, and this strikes me as a Bad Idea (tm).

Also, since splunk isn't FOSS, so you'll need to go up to splunk.com to get a copy. I'll assume you already have a server step up somewhere--if you don't, there's no point to doing this.

Some general notes

The darwin forwarder installs in /opt. This is good in general, since it keeps the installation away from Apple's version of unixy goodness, but it might cause some issues if you use Darwin ports. I don't know if it does, since I don't use Darwin ports.

You have an option to use SSL to connect to the server. You should do this, but in my case, I found it better to try things out in a test setup without using SSL since setting up the certs can be a pain.

Initially, we'll try this running the splunk forwarder as root, but then we'll cut over to a different user. Running process as root if you don't have to is not a great idea.

You might also check out this:

http://docs.splunk.com/Documentation/Splunk/4.3.1/Deploy/Deployanixdfmanually

Installing Splunk forwarder

So your first step is to get the splunk universal forwarder. Go ahead, I'll wait here.

Sudo to a root shell:

sudo /bin/bash

We'll do this all as root, so be careful with your typing.

Make a directory for this:

mkdir /opt

cd /opt

Assuming you downloaded the splunk forwarder through the browser, it should be in Downloads, copy it to /opt (but keep in mind that you'll be installing a later version than this, so the names will change).

cp ~/Downloads/splunkforwarder-4.3.1-119532-Darwin-universal.tgz /opt

Unpack the forwarder and enter the directory:

tar -xvzf splunkforwarder-4.3.1-119532-Darwin-universal.tgz

cd splunkforwarder

Start splunk

/opt/splunkforwarder/bin/splunk start --accept-license;

Open a second terminal window,

sudo /bin/bash

cd /opt/splunkforwarder/var/log/splunk

tail -f splunkd.log

You can check this window to see how well your forwarder is working.

Add your server to the configuration, you'll be prompted for your splunk userid and password for this, so it will be admin and whatever you changed your password to from changeme. Also, the ip number of your server is likely to be different:

/opt/splunkforwarder/bin/splunk add forward-server 192.168.1.11:9997

Now, let's add a couple of logs to foward to the server:

/opt/splunkforwarder/bin/splunk add monitor /var/log/secure.log

/opt/splunkforwarder/bin/splunk add monitor /var/log/system.log

If everything goes well, at this point you should be able to look at the system.log and the secure.log from your splunk server's web interface.

Adding SSL Support

This is the best simple explanation I've found for using SSL with splunk. For this method, we're relying on splunk to make the CA, and then producing signed certs with passwords for some additional security.

http://splunk-base.splunk.com/answers/5518/what-is-the-recipe-for-creating-new-ssl-certs-for-forwarding-with-no-auth

Make a space to store the certs out of the way of the default installation:

mkdir /opt/splunkforwarder/etc/certs

chmod og-wrx certs

Posted by bil at 6:00 PM
Categories: Other Software, Work

Friday, November 30, 2012

Installing Splunk on Ubuntu

Recently, I've set up a splunk server to do remote logging. Splunk is easy to install, pretty easy to use with a very powerful searching system. They also allow 500 megs of logging per day in their free version (after that it gets expensive). But I can't really recommend the free level, since they removed the authentication, which makes making the service secure very difficult. I think it would be find to run at home behind your NAT, but not with a public IP address. So I'm looking into syslog-ng and some other options. But I figured I'd post this in case it might help someone.

Installing splunk

Get the splunk installer, in this case we'll use the .deb version since we're installing to Unbuntu. To do this, you'll need to sign up at splunk.com. I don't think any of this is FOSS, so I can't post it here.

Splunk likes to live in /opt, so make a /opt if there's not one,

sudo mkdir /opt;

Now, install the .deb file, in this example, the .deb file is in my home directory:

dpkg -i ~/splunk-4.3.1-119532-linux-2.6-amd64.deb

This shouldn't take long. At the end, you'll be prompted for how to start splunk.

Start splunk

/opt/splunk/bin/splunk start --accept-license

Let it run until you get back to a prompt. Further configuration is done via the web interface. Start your browser, login as admin and use changeme, then change to a better password. You can do this because right now your in a trial period--once that expires, you won't have to authenticate to reach the splunk server--and neither will anyone else.

The web interface will let you control most settings, if you click on Manager in the upper right menu, you'll be able to adjust most of the settings.

Since the main purpose of a splunk server is to accept logs from remote machines, we'll want to set up a couple of receivers, one for encrypted connections and one for non-encrypted. The latter we'll use primarily for testing, as we wouldn't want to pass logs for important servers in clear text. Under:

Manager, Data, Forwarding and receiving

create a listening on port 9997 and one on 9443

Configure Receiving, listen on 9997

You can also configure the listeners via command line by editing:

/opt/splunk/etc/system/local/inputs.conf

Securing connections

One of the trickier bits was setting up certificates. You can use the certs provided by splunk as is, and for many, that's fine. But I went ahead and generated new ones with different password from the default as a security precaution. The basic logic is you make self-signed certs for the forwarder (the software forwarding the logs to splunk) to use in order to connect over SSL. The passwords go into the inputs.conf (on the server) and outputs.conf (on the forwarders), and they get hashed the next time the server starts.

This is all based on http://splunk-base.splunk.com/answers/7164/how-do-i-set-up-ssl-forwarding-with-new-self-signed-certificates-and-authentication

http://splunk-base.splunk.com/answers/5518/what-is-the-recipe-for-creating-new-ssl-certs-for-forwarding-with-no-auth

First, make a place to store your certs out of the way of the default certs.

cd /opt/splunk/etc/

sudo mkdir -p ./certs;

Then run a splunk script to make the certs:

/opt/splunk/bin/genSignedServerCert.sh -d /opt/splunk/etc/certs -n server -c YOURSERVER.NAME.HERE -p

Use the Fully Qualified Domain Name (FQDN) for the server. The script will prompt for a password for the cert, and also for more information. Enter the server's FQDN for common name, all other entries are optional. This will make a server.pem file you can use in the inputs.conf file for the server.

Now, run that script again to make a cert for the forwarder.

/opt/splunk/bin/genSignedServerCert.sh -d ./ -n forwarder -p

Use the same or different password, and all other settings are optional. This will create a file named forwarder.pem. To use these, you'll make a certs folder in the forwarder's directory, and copy both the forwarder.pem and cacert.pem there.

Finally, to enable the server to run at boot:

sudo /opt/splunk/bin/splunk enable boot-start

That's it, best of luck!

Posted by bil at 7:02 PM
Categories: Other Software, Work

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 \
https://wwwx.cs.unc.edu/~hays/dev/timelox_and_TheHand/files/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.

Details

  • 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. 

Testing

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 0.0.0.0.
Server listening on 0.0.0.0 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 127.0.0.1

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 127.0.0.1
******************************************
* *
* Warning! Unathorized Logins Prohibited *
* *
******************************************
Password:

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.  

Troubleshooting

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 2.2.2.2 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:

username="susi";
homedir="/var/susi";
# 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;
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 \ 
http://voxel.dl.sourceforge.net/project/nagiosplug/nagiosplug/1.4.15/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
./configure
make
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 \
http://superb-sea2.dl.sourceforge.net/project/nagios/nrpe-2.x/nrpe-2.12/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:
   ssllibdir="$dir"
   #if test -f "$dir/libssl.so"; then
   if test -f "$dir/libssl.dylib"; then
found_ssl=yes
break
fi

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.

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 \
/usr/local/nagios/etc/nrpe.cfg.orig

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 127.0.0.1:

allowed_hosts=127.0.0.1,xxx.xxx.xxx.xxx

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:

include_dir=/usr/local/nagios/etc/nrpe.d

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_uptime]=/usr/bin/uptime
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.

Troubleshooting

  • 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/
PropertyList-1.0.dtd">
   <plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <dict>
  <key>NetworkState</key>
  <true/>
  </dict>
  <key>UserName</key>
  <string>susi</string>
  <key>GroupName</key>
  <string>staff</string>
  <key>ProgramArguments</key>
  <array>
  <string>/usr/local/nagios/bin/nrpe</string>
  <string>-c</string>
  <string>/usr/local/nagios/etc/nrpe.cfg</string>
  <string>-i</string>
  </array>
  <key>Sockets</key>
  <dict>
  <key>Listeners</key>
  <dict>
  <key>SockServiceName</key>
  <string>5666</string>
  <key>SockType</key>
  <string>stream</string>
  <key>SockFamily</key>
  <string>IPv4</string>
  </dict>
  </dict>
  <key>inetdCompatibility</key>
  <dict>
  <key>Wait</key>
  <false/>
  </dict>
  <key>Label</key>
  <string>edu.unc.cs.nrpe</string>
  </dict>
</plist>

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.

matt.

iflowfor8hours.info
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.

Mark
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!

JohnO

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 $?
2

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.

Nagios

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:

nagios:x:114:121::/var/lib/nagios:/bin/false

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:

#allowed_hosts=127.0.0.1
allowed_hosts=your.nagios.server.address 
Then comment out the nrpe=nagios line and add a line making the nrpe user to nrpe:
#nrpe_user=nagios
nrpe_user=nrpe
And then set the group:
#nrpe_group=nagios
nrpe_group=nrpe

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!
#command_prefix=/usr/bin/sudo 

If you running nagios and this temperature monitor on the same machine you can uncomment the server_address=127.0.0.1 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
include=/etc/nagios/nrpe_local.cfg

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:
command[check_temper]=/usr/lib/nagios/plugins/check_temper

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 !

Bye
Riccardo
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.. ..

Tuesday, March 16, 2010

Installing Snort and Barnyard2 in Ubuntu 9.10: Part 1

This is based on Nick Moore's Snort_2.8.4.1_Ubuntu.pdf. There are some significant differences, but I'm following his lead. This is also useful:
http://ubuntuforums.org/showthread.php?t=145641

I'm assuming you have a working installation of Ubuntu 9.x, either in a virtual machine or on real hardware. Even if you have real hardware, you might consider using Sun's Virtualbox to do a test machine--you can do a base install, then take a snapshot here and there before throwing yourself into this. That way if things go south you can back out to the snapshot cleanly. Also, keep in mind, I don't even pretend to understand all of this myself, it's just a document I put together to document what I got to work for me.

Background

If you're interested in installing snort you probably already know something about it. But in case you don't:
  • Typically, you install snort to listen on a second network interface, so you can access your machine via the primary, and have snort listen on a second interface. Usually this second interface doesn't have an ip number.
  • You don't have to do that tho, and for a test install like this one, it's fine to just use the primary interface. In my case, my primary is eth1 and that's where everything is pointed. If you want to use a different interface, you can, just change eth1 to eth0 or eth2 or whatever. The ifconfig command will show you what you have available.
  • Snort does the analysis of packets. To take load off of snort, we'll use barnyard2 to handle logging of traffic. The way this works is snort logs what it finds in a snort.log file, and barnyard tails that file and puts the information into the mysql database.
  • We'll also install base and adodb, these packages let us put a pretty web interface on the snort data.

Installing some unixy bits

First thing we need to do is install some packages. Open a terminal window. If you don't know what a terminal window is, please go away until you do. From the command line run this (you can cut and paste this if you like, but review the command before executing it):
sudo apt-get install libpcap0.8-dev libmysqlclient15-dev mysql-client-5.0 \
mysql-server-5.0 bison flex apache2 php5 libapache2-mod-php5 php5-gd php5-mysql \
libtool libpcre3-dev php-pear vim ssh openssh-server
As part of the MySQL install, it will prompt you for a root password for that. I suggest you choose one password for this and all of the other admin passwords you set up throughout this process, it will reduce your confusion. This will take a while to run.

Set up Snort and MySQL

First, we install the mysql version of snort:
sudo apt-get install snort-mysql
This will prompt you for which interface you want to use, and also ask you about your home network. Don't worry about the home net setting, we'll twiddle that later. Do make sure to let it set up a database for you.

Next, we have to make a database for snort to use (before we run the commands the above install suggested!). Start mysql thusly:
mysql -u root -p
Then at the mysql prompt enter the following:
create database snort;
grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;
SET PASSWORD FOR snort@localhost=PASSWORD('YOURPASSWORDHERE!');
exit
Next, move to the directory where a template for the database is stored
cd /usr/share/doc/snort-mysql/
zcat create_mysql.gz | mysql -u root -p snort
This will import a schema for the snort db into mysql. Now we will check to see that the Snort database has been correctly installed. Start mysql again:
mysql -u root -p
Then at the mysql prompt:
SHOW DATABASES;
use snort;
SHOW TABLES;

You should see something like this:
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| snort |
+--------------------+
3 rows in set (0.00 sec)

mysql> use snort;
Database changed
mysql> SHOW TABLES; +------------------+ | Tables_in_snort | +------------------+ | data | | detail | | encoding | | event | | icmphdr | | iphdr | | opt | | reference | | reference_system | | schema | | sensor | | sig_class | | sig_reference | | signature | | tcphdr | | udphdr | +------------------+
16 rows in set (0.00 sec)
mysql>
Type exit, and we're done with that

Now, we need to edit the snort.conf file, in /etc/snort:
sudo vim /etc/snort/snort.conf
Find "var HOME_NET any", and comment it out and add a line specifying the interface you want to use:
#var HOME_NET any
var HOME_NET $eth1_ADDRESS
Find "output log_tcpdump: tcpdump.log" and comment that out:
#output log_tcpdump: tcpdump.log
Find "output log_unified". Insert the following below it:
output unified2: filename snort.log, limit 128
Now a quick test. Run the following and see if snort runs:
sudo snort -c /etc/snort/snort.conf -i eth1
If you get to this:
--== Initialization Complete ==--

,,_ -*> Snort! <*-
o" )~ Version 2.8.4.1 (Build 38)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
Copyright (C) 1998-2009 Sourcefire, Inc., et al.
Using PCRE version: 7.8 2008-09-05

Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.10 <Build 16>
Preprocessor Object: SF_SSH Version 1.1 <Build 1>
Preprocessor Object: SF_DCERPC Version 1.1 <Build 4>
Preprocessor Object: SF_DCERPC2 Version 1.0 <Build 1>
Preprocessor Object: SF_SMTP Version 1.1 <Build 7>
Preprocessor Object: SF_FTPTELNET Version 1.2 <Build 11>
Preprocessor Object: SF_Dynamic_Example_Preprocessor Version 1.0 <Build 1>
Preprocessor Object: SF_DNS Version 1.1 <Build 2>
Preprocessor Object: SF_SSLPP Version 1.1 <Build 2>
Not Using PCAP_FRAMES

you've successfully installed snort!

Setting up BASE and Adodb

In this step, we will set up the web environment for BASE and Adodb. First thing we need to do install some support for mail and smtp with pear.
sudo pear install --alldeps Mail
sudo pear install --alldeps Mail_Mime
Then in your home directory, make a space to keep the files we'll be working from as we build this:
cd
mkdir snortinstall
cd snortinstall

At this time the current version of BASE is 1.4.3.1 and you can get it from the Base site on Sourceforge:
wget -O base-1.4.4.tar.gz \
http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.4/base-1.4.4.tar.gz/download
Get adodb4991.tar.gz from Adodb's site on Sourceforge:
wget -O adodb4991.tgz \
http://sourceforge.net/projects/adodb/files/adodb-php-4-and-5/\
adodb-4991-for-php/adodb4991.tgz/download


Next, we'll unpack adodb and base, these are collections of php pages used to interface a web page to the mysql database into which we'll be feeding snort data.

cd ~/snortinstall
tar -xzvf adodb4991.tgz
tar -xzvf base-1.4.4.tar.gz
sudo mv adodb /var/www
sudo mv base-1.4.4 /var/www
Open the php.ini file:
sudo vim /etc/php5/apache2/php.ini

Find “Dynamic Extensions" and add the following lines at the bottom of that section:
extension=mysql.so
extension=gd.so

Now a minor edit of the httpd server config:
sudo vim /etc/apache2/apache2.conf
At the bottom of the file, insert the line
servername your.server.name.domain
Exit and then restart the web server:
sudo /etc/init.d/apache2 restart
Next, create a softlink to the base directory, this way you can install an update and just move the link. Also, we'll make the base dir writable so the webserver can update the config when we're done. I wouldn't do this on a multi-user machine tho:
cd /var/www
sudo ln -s base-1.4.4 ./base
chmod  a+w base

In a browser, go to http://localhost/base, you should be presented with the base configuration page. We'll walk through this and create additional links and mysql entries. Click “continue”
Step 1
Set the path to adodb to /var/www/adodb
Step 2
Database Name=snort
Database Host=localhost
Database User=snort,
Database Password=yourpassword
Step 3
check use authentication system
Admin User Name=snort
Password=yourpassword
Full Name=snort
Step 4
Click “Create BASE AG”
Step 5
Test your login and password.
Then, very important, reset the permissions on the base dir:
chmod og-w base

Setting up Barnyard

Barnyard was written to take over the various output processing tasks to take some load off of snort. We'll be using barnyard2.
cd ~/snortinstall
wget -O barnyard2-1.7.tar.gz \
http://www.securixlive.com/download/barnyard2/barnyard2-1.7.tar.gz
tar zxvf barnyard2-1.7.tar.gz cd barnyard2-1.7 ./configure --with-mysql make sudo make install sudo cp etc/barnyard2.conf /etc/snort sudo mkdir /var/log/barnyard2
Next, we'll edit the barnyard2.conf file.
sudo vim /etc/snort/barnyard2.conf
Look for "#config hostname:  thor" and replace that with:
config hostname: localhost
Look for  "#config interface: eth0" and replace that with whatever interface you want to listen on:
config interface: eth1
Look for output database, and below that section add a line, BUT don't let it wrap!:
output database: alert, mysql, user=snort password=yourpassword dbname=snort host=localhost

Starting Snort and Finishing Barnyard Config

Ok, let's test this puppy, at this point we can open snort on any active interface. If you have a machine with a single network interface, you'll use eth0 typically.

sudo snort -c /etc/snort/snort.conf -i eth1
It will take a bit to start, but if you get to:
--== Initialization Complete ==--

,,_ -*> Snort! <*-
o" )~ Version 2.8.5.2 (Build 121)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
Copyright (C) 1998-2009 Sourcefire, Inc., et al.
Using PCRE version: 7.8 2008-09-05

Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.11 <Build 17>
Rules Object: web-misc Version 1.0 <Build 1>
Rules Object: web-client Version 1.0 <Build 1>
Rules Object: sql Version 1.0 <Build 1>
Rules Object: smtp Version 1.0 <Build 1>
Rules Object: p2p Version 1.0 <Build 1>
Rules Object: nntp Version 1.0 <Build 1>
Rules Object: netbios Version 1.0 <Build 1>
Rules Object: multimedia Version 1.0 <Build 1>
Rules Object: misc Version 1.0 <Build 1>
Rules Object: imap Version 1.0 <Build 1>
Rules Object: exploit Version 1.0 <Build 1>
Rules Object: dos Version 1.0 <Build 1>
Rules Object: chat Version 1.0 <Build 1>
Rules Object: bad-traffic Version 1.0 <Build 1>
Preprocessor Object: SF_SSLPP Version 1.1 <Build 3>
Preprocessor Object: SF_SSH Version 1.1 <Build 2>
Preprocessor Object: SF_SMTP Version 1.1 <Build 8>
Preprocessor Object: SF_FTPTELNET Version 1.2 <Build 12>
Preprocessor Object: SF_DNS Version 1.1 <Build 3>
Preprocessor Object: SF_DCERPC2 Version 1.0 <Build 2>
Not Using PCAP_FRAMES
Then you're up and running. Open a second terminal window and run this:
ls -la /var/log/snort
Look for 10 digit suffix on snort.log. If there is more than one file, copy the latest one. Create a file called barnyard.waldo in the snort log dir:
sudo vim /var/log/snort/barnyard.waldo
Enter the following, then save and exit:
/var/log/snort
snort.log
<10 digit number from step 2 above>
0

Start barnyard:
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
Now, we need to test this out. The easiest way I think is to use nmap. This will do it (use the network tho that you are using, and keep in mind that if you're on someone else's network, they'll likely not like you scanning it). If you don't know how to use nmap at least a little bit, go learn something about it right after you're done here, linux.com has a good beginners tutorial):
sudo nmap -PN -v -O 192.168.1.0/24
If it starts correctly, you'll see alerts flow by in the terminal window. Check the base web page at http://127.0.0.1/base and see if you're getting alerts there. If you are, we're done.
On to part II?
Posted by bil at 8:01 PM
Edited on: Tuesday, June 15, 2010 11:13 AM
Categories: Other Software, Work
Comment by John Wan - Wednesday 03rd March 2010 06:33:18 PM

Hi Bil,

Thanks for all the good work,I am new to Snort, I followed the instructions on this url: https: / / wwwx.cs.unc.edu/ ~hays/ archives/ work/ index.php

All went well until I reached the following stage:

"Now a quick test. Run the following and see if snort runs: sudo snort -c / etc/ snort/ snort.conf -i eth1"

After running the command line above, I got the following outcomes:
Running in IDS mode

--== Initializing Snort ==--Initializing Output Plugins!Initializing Preprocessors!Initializing Plug-ins!Parsing Rules file / etc/ snort/ snort.confVar 'HOME_NET' redefinedPortVar 'HTTP_PORTS' defined : [ 80 ]PortVar 'SHELLCODE_PORTS' defined : [ 0: 79 81: 65535 ]PortVar 'ORACLE_PORTS' defined : [ 1521 ]Frag3 global config: .. .. .. .. .. +++++++++++++++++++++++++++++++++++++++++++++++++++

Initializing rule chains.. .ERROR: Undefined variable name: (/ etc/ snort/ rules/ bad-traffic.rules: 27): EXTERNAL_NETFatal Error, Quitting..

Is there anyone know what's this all about?

Would you please let me know "how to" fix this "Fatal Error"? what should I do next?

Any information and help would be much appreciated.

Thanks in advance.

Regards John
Comment by bil - Wednesday 03rd March 2010 07:03:36 PM

Sure, I'll take a look tomorrow. But I _think_ the issue might be that in the snort.conf file the EXTERNAL_NET variable isn't set. So you could try setting that variable. Try:
var EXTERNAL_NET any
And this might help:
Informit article on snort rules
BTW, I tried to email you directly but got a bounce back. bil
Comment by latgarf - Friday 05th March 2010 08:40:04 AM

Bil, Thanks a lot for the awesome tutorial! : )
Comment by Andy - Wednesday 10th March 2010 12:04:07 PM

Don't know if this is allowed here, but this link is a great help to people with troubleshooting their installs. It's helped me tons.

It's a how-to guide on setting up Snort and BASE on Ubuntu

http: / / ubuntuforums.org/ showthread.php?t=919472

Comment by Rob - Friday 12th March 2010 05:38:26 AM

Thanks for the great tutorial, everything is working fine : )

Just curious about the 10 number digit, do I have to edit the barnyard.waldo everytime I restart snort?
Comment by bil - Friday 12th March 2010 05:45:56 AM

No, in fact if you look at the waldo file after you've started snort, it should now be a binary file--for barnyard2, the text file is used as a "seed" to get things started.
Comment by Rob - Wednesday 17th March 2010 05:52:28 AM

Thanks for the quick response.

I'm running snort now for a few days, but maybe I'm a bit impatient, I'm really looking forward to part 2.

I'm a bit stuck now on how I can work with the rules, how to enable rules, how to manage the system so I really could do something with the alerts it gives etc.

It is really hard to find good tutorials on the net on what to do after the snort installation.

Again thanks for the great article and hopefully we can see part2 very soon.

Comment by Todd - Wednesday 17th March 2010 08:11:53 AM

Bil,

By far the best install I have ever found on the web. My only wish is that everyone should take note to the details and not leave anything to question or figure out for yourself. GREAT JOB!!!

Now, if I can find someone who can help me with SMTP on Ubuntu 9.10 which sends mail to another domain by logging in to it. Been working on this one at home for week and no joy. Tried PostFix, Sendmail with mutt and having a lot of issues.

Thanks for this Bil.. .. Oh, BTW, If we stop and restart snort, then I take it we need to add the new snort ID to the barnyard file, right? If, so I think I'll work on a script to automate starting snort, creating the barnyard file and then starting barnyard, that is unless there already is one. Any thoughts?

Todd
Comment by bil - Wednesday 17th March 2010 08:48:03 AM

Todd,
Thanks for the compliment.

In answer to your question, no, you shouldn't have to reseed the waldo file--if you stop and start snort, everything should just continue to work, since barnyard just watching the snort log. So far with barnyard2, I haven't noticed any issues, but in prior testing with barnyard last year, I did notice that if I stopped snort, I need to stop barnyard and restart snort first, then barnyard.

In terms of starting and stopping snort, there already is an init.d script in place if you used a pkg installation. Try:
sudo /etc/init.d/snort start

Also, I have a simple upstart script for barnyard, but I haven't done enough testing yet to post it. That'll probably be up by monday tho.
Comment by SnortUser - Friday 19th March 2010 02:38:44 PM

Thanks for all of your help in this. This guide was great, followed it step by step and I am up and off to the races, a HUGE thanks.
Comment by Jimbo - Tuesday 23rd March 2010 07:12:21 PM

Hi, Great tutorial.. I am running into one issue though.. I don't have an / etc/ snort.conf file just / etc/ snort/ snort.debian.conf that looks no where close to normal snort.conf file.. Do you know where i went wrong?

thanks again!
Comment by super newbie - Thursday 25th March 2010 12:00:25 PM

after I do apt-get install snort-mysql, an error screen comes up:

root@ubuntu: ~# apt-get install snort-mysql
Reading package lists.. . Done
Building dependency tree
Reading state information.. . Done
The following extra packages will be installed:
libprelude2 oinkmaster snort-common snort-common-libraries
snort-rules-default
Suggested packages:
snort-doc
The following NEW packages will be installed:
libprelude2 oinkmaster snort-common snort-common-libraries snort-mysql
snort-rules-default
0 upgraded, 6 newly installed, 0 to remove and 119 not upgraded.
Need to get 0B/ 2,523kB of archives.
After this operation, 16.2MB of additional disk space will be used.
Do you want to continue [Y/ n]? y
Preconfiguring packages .. .
eth0: error fetching interface information: Device not found


when I was using wireshark previously, I noticed that eth1 was my default and eth0 wasn't available as an option. I was able to do the commands following the install to create the database (and received the correct "Bye" response), however, when I try to move into the directory / usr/ share/ doc/ snort-mysql, I get this message:
root@ubuntu: ~# cd / usr/ share/ doc/ snort-mysql
bash: cd: / usr/ share/ doc/ snort-mysql: No such file or directory


Also note: I'm using VMware, so I know this disables eth0 - is there a way to get snort to either use eth1 or change eth1 to eth0? I'm a super newbie fyi.

Thanks so much!
Comment by Lolailo - Wednesday 14th April 2010 12:51:43 PM


THanks that is a great help!



I get these errors

Warning: include_once(Mail.php) [function.include-once]: failed to open stream: No such file or directory in / var/ www/ base-1.4.4/ includes/ base_action.inc.php on line 29

Warning: include_once() [function.include]: Failed opening 'Mail.php' for inclusion (include_path='.: / usr/ share/ php: / usr/ share/ pear') in / var/ www/ base-1.4.4/ includes/ base_action.inc.php on line 29 - I

$apt-cache search pear

I installed php-mail-mime php-pear

Then realized I miss php-mail

Comment by Jemiro - Tuesday 20th April 2010 02:58:20 AM

Thanks so much, i need this tutorial, ill use MySQL
: )
Comment by maravicasa - Tuesday 20th April 2010 12:01:17 AM

thanks
Comment by shiva - Wednesday 21st April 2010 03:27:46 PM

Hi bil,

I am using Ubuntu in sun virtual box and I followed your tutorial but at the end of the tutorial I found the following error, can you please find the solution for that error.

Thanks regards
shiva
--== Initializing Barnyard2 ==--
Initializing Input Plugins!
Initializing Output Plugins!
Parsing config file "/ etc/ snort/ barnyard2.conf"
Log directory = / var/ log/ barnyard2

--== Initialization Complete ==--

______ -*> Barnyard2 <*-
/ ,,_ Version 2.1.7 (Build 225)
|o" )~| By the SecurixLive.com Team: http: / / www.securixlive.com/ about.php
+ '''' + (C) Copyright 2008-2009 SecurixLive.

Snort by Martin Roesch & The Snort Team: http: / / www.snort.org/ team.html
(C) Copyright 1998-2007 Sourcefire Inc., et al.

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..
Comment by Petter - Monday 17th May 2010 12:54:18 AM

Thanks for the info.

Quick question, any idea why I would get a "ERROR: / etc/ snort/ snort.conf(193) => Invalid keyword 'compress_depth' for 'global' configuration. when I run snort -c / etc/ snort/ snort.conf -i eth1??

I'm running Ubuntu 9.10 and Snort 2.8.6, and snort was compiled with --enable-zlib, and I did install the latest zlib from source.

I have spent time googling this to no avail.. .

Thanks for any help I can get.

-Petter
Comment by ndepoh - Wednesday 02nd June 2010 09:46:05 AM

Thank you sir
installation et setting up snort was my homework
with your document it was so easy
I am new in snort. it was my first time
it work correctly and so glad

excuse my bad English but I speak French
Comment by bil - Wednesday 02nd June 2010 09:52:44 AM

Merci. Sans aucun doute ton anglais est vachement meilleur que mon fran├žais.
Comment by Grant - Tuesday 03rd August 2010 12:24:00 PM

Hi Bil,

Great tutorial, thank you very much for taking the time to create this tutorial!

Thanks again,

Grant!
Comment by adhry - Saturday 29th January 2011 01:13:08 AM

Hi Bil,

Great tutorial,
I wanted to ask,
why alerts do not appear on its base,
snort when it goes well?
Comment by bil - Saturday 29th January 2011 05:12:10 PM

Well, I think the first thing to do would be to check the various logs to see if you can see any errors. You might also log in directly to the SQL db and see if it's being populated.
Comment by adi - Wednesday 02nd March 2011 03:51:37 AM

hi bil, i wanted to ask
i get a problem
unified2 fatal error, quiting
how can I solve the problem?
Comment by bil - Wednesday 02nd March 2011 07:55:02 AM

Can't say without more details, can you give me an outline of what you're doing when you get the error? Also, OS version, version of barnyard, etc?
Comment by Josh - Thursday 23rd September 2010 12:23:01 PM

Awesome job, I have a 100% working snort server!
Comment by Fafa - Saturday 04th August 2012 08:54:16 AM

Thanks a lot !!!
Comment by shad - Wednesday 21st November 2012 09:48:41 AM

I'm getting an error like this, any ideas on what i can do ?

FATAL ERROR: Failed to initialize dynamic engine: SF_SNORT_DETECTION_ENGINE version 1.16.18

Thank you in advance.
Comment by bil - Wednesday 21st November 2012 12:45:09 PM

Dunno. Found:
http: / / marc.info/ ?l=snort-users&m=120109371628312

Path idea sounds good. The other thing to try is to disable that module.

Do your prototyping in a virtual machine, like VirtualBox, take snapshots as you go.
Comment by Balaji - Monday 26th November 2012 11:58:36 PM

Hi Bil,

Great tutorial for a newbie. Thanks.
Everything works great until i reach the last step.
My barnyard.waldo file is like below:

/ var/ log/ snort
snort.log
1353991140
0

but when i run barnyard2 i get the following error:

--== Initialization Complete ==--

______ -*> Barnyard2 <*-
/ ,,_ Version 2.1.7 (Build 225)
|o" )~| By the SecurixLive.com Team: http: / / www.securixlive.com/ about.php
+ '''' + (C) Copyright 2008-2009 SecurixLive.

Snort by Martin Roesch & The Snort Team: http: / / www.snort.org/ team.html
(C) Copyright 1998-2007 Sourcefire Inc., et al.

WARNING: Ignoring corrupt/ truncated waldofile '/ var/ log/ snort/ barnyard.waldo'
Opened spool file '/ var/ log/ snort/ / snort.log.1353967120'
Closing spool file '/ var/ log/ snort/ / snort.log.1353967120'. Read 0 records
Opened spool file '/ var/ log/ snort/ / snort.log.1353967297'
Closing spool file '/ var/ log/ snort/ / snort.log.1353967297'. Read 0 records
Opened spool file '/ var/ log/ snort/ / snort.log.1353968421'
Closing spool file '/ var/ log/ snort/ / snort.log.1353968421'. Read 0 records
Opened spool file '/ var/ log/ snort/ / snort.log.1353968548'
Closing spool file '/ var/ log/ snort/ / snort.log.1353968548'. Read 0 records
Opened spool file '/ var/ log/ snort/ / snort.log.1353980386'
Closing spool file '/ var/ log/ snort/ / snort.log.1353980386'. Read 0 records
Opened spool file '/ var/ log/ snort/ / snort.log.1353981965'
Closing spool file '/ var/ log/ snort/ / snort.log.1353981965'. Read 0 records
Opened spool file '/ var/ log/ snort/ / snort.log.1353991140'
Waiting for new data

Is there a solution for this?
Thanks a lot!!
Comment by bil - Thursday 29th November 2012 11:06:03 AM

The waldo file seems to be a tricky thing. It's been a while, but I recall having to try setting it up multiple times before it took. Sorry I can't be of more help.

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:

cd
wget -O device-usb0.31.tgz \
https://wwwx.cs.unc.edu/~hays/dev/bash/temper/device-usb0.31.tgz
tar -xvzf device-usb0.31.tgz 
cd Device-USB-0.31/
perl Makefile.PL
make
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).

Jack
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.

Thanks.
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:
http://relavak.wordpress.com/2009/10/17/temper-temperature-sensor-linux-driver/
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.
bil
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? : )

Cheers!

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

Hello

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

Hi,

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,
bil

Monday, November 09, 2009

INLS Classes

From time to time I teach a night course in the School of Library and Information Science. The last course I taught was INLS672, Advanced Internet Applications, which is really an introduction to PHP, Ruby on Rails, and Javascript. I've also taught courses in Lan Management, Network Protocols, and Server Administration.

Posted by bil at 2:46 PM
Edited on: Saturday, December 05, 2009 1:32 PM
Categories: Work

What I do for a living

I work for the Department of Computer Science at Chapel Hill as the Infrastructure Manager. My duties include managing the department's network, high level support for Macintosh systems, database development, and taking care of the department's facilities, Sitterson Hall and the Frederick P. Brooks, Jr Building.
Posted by bil at 2:39 PM
Edited on: Sunday, December 06, 2009 12:45 PM
Categories: Work