Peter Woods

I decided to give myself a little upgrade on blog. It's a wee bit different than the previous version that I was running.We'll see how this goes. Troy gets to start with the new version.

If you happen to be installing Joomla and the site will be using SSL, you should also configure the MySQL connection to force the use of SSL.  It's the old rule: If there's SSL in the front, there's SSL in the back. Unfortunately, the Joomla installation script does not provide any immediate configuration utility to specifiy that the site needs to use SSL. This is easy to fix. Modify the myql_connect function in the mysql.php file under the library folder. This is similar to the fix that I have done for WordPress and Drupal.

Lately Drupal has been pretty popular on campus. Several departments (including mine) are looking at Drupal to ease the management issues of running a large multi-user informational site. So far most of the sites have been relatively vanilla installations. One of our customers is implementing Drupal for a secure intranet site using VUnetID authentication.  The VUnetID requirement introduces a few additional puzzles which need to be solved before the site is usable. Given that we don't want VUnetID and Epasswords going over the wire in clear text, the site must use SSL. Getting Apache to use SSL is a relatively simple process, and it has been documented many times over.  The tricky part is getting the MySQL connect to the database to also use SSL.  To make this work, the Drupal code needs to be slightly modified to force the connection to use SSL. This change is very similar to WordPress change that I had to implement for our secure blogs. The Drupal code already passes one parameter for CLIENT_FOUND_ROWS in the connection.  To add SSL to the connection, the mysql_connect functions in install.mysql.inc and database.mysql.inc.  Both of these files are located in the includes directory of the standard installation. Find the lines with the mysql_connect functions, and add the SSL parameter in. If the requires SSL on the frontend, then it should also have SSL on the backend. Making this small change will ensure that the data will remain encrypted from the point it is extracted from the database until it reaches the reader's screen.

Although the shared web servers don't see as many session hijacking attempts as XSS or RFI attacks, I figured that I'd throw this out there for everyone.  Validate your application sessions before allowing the client to trespass all over the place! This is a relatively simple thing to do in PHP. A simple check like the following is a good simple test:

session_start();
if ( !isset($_SESSION['ClientID']) || $_SESSION['ClientID'] != md5($_SERVER['REMOTE_ADDR']) )
{
        session_regenerate_id();
        $_SESSION['ClientID'] = md5($_SERVER['REMOTE_ADDR']);
}

It's highly unlike that the client IP is going to change in the middle of the session so it's a good starter check. An even better check would be to validate against the combination of REMOTE_ADDR and HTTP_USER_AGENT since neither of these should change in the middle of a session. If the validation fails, restart or destroy the session, depending on which is appropriate for your application.

All of the primary web servers (the A group) have been patched up to current levels.  I've only got a few Linux systems left to complete.

This morning I updated one half of the shared web hosting environment.  All of the B servers were patched with the latest available patches.  They are now sporting shiny new kernels and vmware-tools. It took a few minutes on each server to apply the RPM updates, reboot, and check services. As far as our web visitors are concerned, it really was a non-event. The A servers picked up a brief spike in traffic, but it was not high enough to cause a problem.

The FIPP website is back online thanks to the folks over at Hammock Publishing.

The Sitemason migration has been completed.  The frontend and backend servers were migrated to new hardware- one virtual and one physical.  Once again the life-cycle-replacement clock has been restarted for another service.

I've got an up2date running on my development web server while I'm working on my weekly incident report.  Hopefully I finish my report before the up2date completes.

Last night was the first import performed with the new SAN storage.  The performance is great.  The import appears to have taken about 4.5 hours, which is less than half of the usual times that we have seen lately.