Archive for October, 2009

Oct
28
2009

Fuzz Testing for Reliability

In a course on writing secure software here at University we looked into the practice of fuzz testing. That is, generating arbitrary information to be used as inputs for software. Apparently this is a very high cost:benifit practice in secure software development and testing.

Around 1990 the National Science Foundation provided grants for research regarding operating systems reliability testing, one culmination of efforts was presented in a paper written by Barton P. Miller, Lars Fredriksen and Brian So; (Paper). In this work the claim was made that many of the assumed reliable operating system utilities could be broken using the basic technique of fuzzing:

Operating system facilities, such as the kernel and utility programs, are typically assumed to be reliable. In our recent experiments, we have been able to crash 25-33% of the utility programs on any version of UNIX that was tested. This report describes these tests and an analysis of the program bugs that caused the crashes.

For our purposes we created a quick program in C, and used a simple bash scripting test bench to perform many iterations of each test:

fuzz — Source for the fuzzer, used by the following script. Very limited functionality, by no means is this a product for use in any setting other than academic investigation.

(more…)

Posted in Security | No Comments »

Oct
21
2009

Fitting and AOC-USAS-L8i in a PCIe slot (UIO to PCIe)

One of the recent server upgrades called for the purchase of raid controller cards. I use software raid in Linux for its versatility and the L8i controllers can perform in hba (Host Bus Adapter) mode. These cards ship with Supermicro’s IT mode firmware which essentially lets all of the drives show up independently in linux.

Before I could see all that, I needed to get these cards into my case. Don’t be too upset when you first try to slide this card into your case and mobo (I have a Norco 4220 and Gigabyte EP45-UD3P) they will not fit at all. It appears as if the bracket is off on the Y axis by about a quarter inch, this is because these cards are UIO form factor.

Establishing my frame of reference

Establishing my frame of reference

This can easily be resolved with some longer screws and nylon spacers. Be sure to use the original brackets as buying new brackets was really hard to figure out (If anyone knows the exact bracket for this then please let me know).

Using quarter inch nylon spacers for number ten machine screws (need to verify)

Using quarter inch nylon spacers for number ten machine screws (need to verify)

We used two spacers on each of the ‘posts’, it appeared that this resolved the issue as we got a good solid fit for both of the cards.

Posted in RAID | 6 Comments »

Oct
19
2009

Power Monitoring with APCUPSD, Email using SSMTP and Google Apps

Recently I performed a large upgrade to my raid file-server, the information being stored is much more critical at this point in time and I have chosen to step up the game in four ways:

  1. Move from on-board Intel controller to dual LSI L8i 8channel hba controllers
  2. Move from raid5 to raid6
  3. Install an APC UPS and monitor it with apcupsd
  4. System monitoring with email alerts via mdadm and Google SMTP

(Sorry for re-iteration if you are following the feed, trying to establish context)

The apcupsd tool lets you connect to your UPS and control when the machine shuts itself down during a scenario where you loose power. Another really nice thing this will do is allow you to send yourself an email through whatever MTA you set up.

The difficult part of getting email setup is configuring a MTA (Mail Transfer Agent). I searched for quite a while on how to get this setup. My initial impression was that I would have to host my own via postfix or some other alternative. I was happy to find that I could use a much more lightweight solution with ssmtp and an email I created from my google apps account.

Install ssmtp

sudo apt-get install ssmtp

Configure ssmtp via its config file /etc/ssmtp/ssmtp.conf

# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=serveremailaddress@yourgoogleappsdomain.tld

# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
mailhub=smtp.gmail.com:587

# Where will the mail seem to come from?
#rewriteDomain=

# The full hostname
hostname=servername.yourgoogleappsdomain.tld

# Are users allowed to set their own From: address?
# YES – Allow the user to specify their own From: address
# NO – Use the system generated From: address
#FromLineOverride=YES

UseSTARTTLS=YES
UseTLS=YES
AuthUser=serveremailaddress@yourgoogleappsdomain.tld
AuthPass=password

Now for a test of ssmtp, create a test file with some text in it. My test file was called ‘test’:

ssmtp youremail@yourgoogleappsdomain.tld < test

For apcupsd we need to modify two files to set our email address up for alerts. They are both located in the /etc/apcupsd directory and are called ‘onbattery’ and ‘offbattery’. I would suggest to leave these as they are because if you set up ssmtp like I have, when an email comes in for root it will be sent on to the ssmtp root address.

Now unplug your UPS and wait for the emails to come!

Posted in Server Administration | No Comments »

Oct
19
2009

RAID Monitoring with MDADM, Email using SSMTP and Google Apps

Recently I performed a large upgrade to my raid file-server, the information being stored is much more critical at this point in time and I have chosen to step up the game in four ways:

  1. Move from on-board Intel controller to dual LSI L8i 8channel hba controllers
  2. Move from raid5 to raid6
  3. Install an APC UPS and monitor it with apcupsd
  4. System monitoring with email alerts via mdadm and Google SMTP

Software raid tool mdadm has monitoring functionality that is easily configured through the /etc/mdadm/mdadm.conf file. You simply need to specify an email address under the MAILADDR property. I would suggest to leave this as root, because with ssmtp you are going to set the email address for everything routed to root.

The difficult part of getting email setup is configuring a MTA (Mail Transfer Agent). I searched for quite a while on how to get this setup. My initial impression was that I would have to host my own via postfix or some other alternative. I was happy to find that I could use a much more lightweight solution with ssmtp and an email I created from my google apps account.

Install ssmtp

sudo apt-get install ssmtp

Configure ssmtp via its config file /etc/ssmtp/ssmtp.conf

# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=serveremailaddress@yourgoogleappsdomain.tld

# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
mailhub=smtp.gmail.com:587

# Where will the mail seem to come from?
#rewriteDomain=

# The full hostname
hostname=servername.yourgoogleappsdomain.tld

# Are users allowed to set their own From: address?
# YES – Allow the user to specify their own From: address
# NO – Use the system generated From: address
#FromLineOverride=YES

UseSTARTTLS=YES
UseTLS=YES
AuthUser=serveremailaddress@yourgoogleappsdomain.tld
AuthPass=password

Now for a test of ssmtp, create a test file with some text in it. My test file was called ‘test’:

ssmtp youremail@yourgoogleappsdomain.tld < test

Test mdadm

sudo mdadm –monitor –scan –test

Everything should be set to go now, hopefully you wont ever need to be notified of a failure.

Known Issue

Using ssmtp with Google’s smtp is great, however if you use special characters in your email password ssmtp will not be able to authenticate. I ran into this and saw the following error:

ssmtp: Authorization failed (454 4.7.0 Cannot authenticate due to temporary system problem. Try again later. 14sm88672bwz.5)

This was promptly resolved by my choosing a password without special characters.

Posted in RAID, Server Administration | 4 Comments »