24 April 2009

The Benefits of a Late Start

Today is the day the company I work for moves the DOD Emall from its home at a commercial data center to a Defense Enterprise Computing Center (DECC) facility. I doubt that the information is classified but I'm not going to reveal which DECC facility we're moving to. Anyway, because the move is going to be a huge undertaking and will require most of the work be done after the sun goes down, I didn't have to be to work until 12:00 MDT.

I wish I could say I slept in, but I didn't and that's okay. I did something even better than catching a few extra winks: I barbecued a steak and fried some eggs outside and had steak and eggs for breakfast! (Sorry, no photos.)

I learned a few things this morning.
  1. I can't eat a large breakfast. I couldn't bring myself to finish the 10-12 oz. steak and four AA large eggs.
  2. The skillet grill attached to the BBQ works for cooking but the self-igniter does not work.
  3. I don't enjoy eating a great meal by myself. Unfortunately, my wife had already left for work; I missed having her with me.
  4. On the other hand, I only blog about things I do on my own so it may be beneficial—for the blog's sake—for me to do a few things solo once in a while.
I think I may have to make steak and eggs (or a morning barbecue) a fairly regular thing, though probably on Saturdays when neither the wife or I have to be anywhere too early.

14 February 2009

Changing The Default Keyring Password In Ubuntu 8.10

Several days ago I changed my user password on my laptop and noticed that, after a boot up or after logging in, the keyring manager would ask me for the keyring password in order to access the WPA password stored there for the various wireless networks I connect to.

My initial reaction was one of annoyance, but after several days I decided to do something about it so I went searching on Google. Not surprisingly, I found several solutions but most were either for versions of Ubuntu too old to be of use or too off base to be correct. Until I stumbled upon a solution that pointed me in the right direction (I can't find the link now, otherwise I'd post it and give proper credit).

Here's the solution for Ubuntu 8.10 (a.k.a. Intrepid Ibex)

Click Applications > Accessories > Passwords and Encryption Keys


Click Edit > Preferences.


You will be presented with a Password Keyrings tab with a "login Automatically unlock when user logs in." option. Highlight that line and click on the "Change Unlock Password" button.


Enter your current keyring password then enter your current user password and click Change. If you do not enter your user login password, you'll still be asked to unlock the keyring after logging in.


Done. Click "Close" on the remaining windows. The next time you log in you will not be prompted for your keyring password.

06 February 2009

My Political Compass

During my morning jaunt through other people's blogs courtesy of Google Reader I read one of my peer's 25 Things meme. One of his items was his political standing. Apparently, there's a political compass test on line (take the test). The test asks some pretty basic questions about your political standing then plots the results on a Cartesian coordinate system. I believe the results to be pretty accurate.

See my political compass

25 August 2007

Set up OSSEC HIDS web UI in OpenBSD Apache jail

Yesterday, I spent a bit of time searching the OSSEC mailing lists, manual, and wiki to find something--anything--OpenBSD-specific. I didn't find a whole lot. So, after some trial and error, I came up with a solution for hosting the OSSEC HIDS Web UI (v0.2) inside the default OpenBSD Apache jail (chroot'ed environment).

My OpenBSD server is running the 4.2 kernel (snapshot taken 2007-08-21) with the base install taken from snapshots (2007-08-23).

These instructions assume you have the $PKG_PATH environmental variable already set to your favorite/nearest OpenBSD package mirror.

# pkg_add php5-core

Follow the install instructions to enable PHP.

# pkg_add wget
# cd /tmp
# wget http://www.ossec.net/files/ossec-hids-1.3.tar.gz
# wget http://www.ossec.net/files/ui/ossec-wui-0.2.tar.gz

For those of you who enjoy checking the MD5/SHA1/GNUPG signatures of packages (HIGHLY recommended), take a look at the OSSEC HIDS Install Instructions.

# tar zxvf /tmp/ossec-hids-1.3.tar.gz
# cd /tmp/ossec-hids-1.3
# sh install.sh

Go through the install (see the link above for instructions) and configure OSSEC to install to /var/www/ossec

Start OSSEC HIDS

# /var/www/ossec/bin/ossec-control start

And install the web UI

# cd /var/www/ossec
# tar zxvf /tmp/ossec-wui-0.2.tar.gz
# cd ossec-wui-0.2
# sh setup.sh

The setup.sh script is pretty basic, it asks you for a user name and password to use with the web UI. Now, I'm not a big fan of having files in chroot environments (well, anywhere) with the x bit set unnecessarily, so ...

# chmod -x CONTRIB
# chmod -x index.php
# chmod -x setup.sh

And, for extra protection:

# mv setup.sh sh.setup

... or whatever you want to call it (don't presume that that is the name I chose :) ).

# vi ossec_conf.php

Change $ossec_dir to point to /ossec

/* Ossec directory */
$ossec_dir="/ossec";

The reason OSSEC HIDS and the web UI are installed in /var/www is because we're working in a chroot'ed environment; nothing on the inside can access the outside. The "inside" for Apache's jail is /var/www.

Finally, create a symbolic link in /var/www/htdocs to point to the ossec-wui-0.2/ directory.

# cd /var/www/htdocs
# ln -s ../ossec/ossec-wui-0.2 ossec-wui

Be sure to use the relative path. Remember, Apache, once started, won't be able to access anything outside /var/www (which becomes / as far as Apache is concerned). Test the install by browsing to http://yourdomain.com/ossec-wui. You should get the OSSEC Web UI with the OSSEC-generated alerts, et cetera. If you get an error telling you it can't access the OSSEC files (I forget exactly what it says), check the value of $ossec_dir in the /var/www/ossec/ossec-wui-0.2/ossec_conf.php file.

Cleanup.

If you don't want to hold onto the archives in /tmp, delete them or let the system clean them out on the next boot.