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.
I had a brief chat with one of the Network Security guys regarding a project that they are working one. It's an issue that every IT shop has to deal with- password management. The biggest problem that most organizations face is propagating the administrative passwords to key people in a safe and efficient manner. In my experience, the big questions that need to be answered are:
- How are password changes to administrative accounts propagated to key staff?
- Are there at least two people that have each password?
- Are there procedures in place for emergency account additions/removals/changes?
- Are appropriate measure in place to monitor how the administrative passwords are used?
- Has everyone tested to make sure that their access to appropriate resources works?
It's an issue that has hit home now that one of the Unix/Linux admins on my team is moving over to the storage. A different role means different access. Hence, we'll need to go through all of his systems and make sure that his access is appropriate for his new position. We'll be having what our team calls the "password party" in the near future.
The new Nagios server is sending email notifications! The email flood has been released.
Nagios Replacement: The AppHosting team is still entering hosts and services into the new Nagios server. The quantity and quality of the checks will be a great benefit to the team. The server is still very snappy considering that it is an extremely trim server compared to the current server.
IDM Rollout: My interaction on the IDM project have been relatively minimal until this point; however, team transitions have forced me to become more involved. I am now attending project meetings with Kenon so that the transition from Kenon to me will be relatively smooth.
Chancellor Announcement: I participated in the launch of the chancellor announcement. My key duties involved removed the redirect to the interim site and ensuring that the new content was web accessible.
Sitemason Disk Space Addition: Additional disk space was added to the virtual machine providing the web service for the Sitemason frontend. This was a relatively easy task involving the creation of another virtual disk and addition to the web content volume.
SSL Certificate Replacement: The certificates for www4.vanderbilt.edu, pave.vanderbilt.edu, and swdist.vanderbilt.edu were renewed for another year.
Hera Decommissioning: The Projector and Port Block applications have been migrated over to the main ITS website after the power supply failure. The Xserve is now merely providing a redirect page to the current locations. All existing links to these two applications have been found and corrected. The change to remove the Xserve hardware has been scheduled for Apr 7.
MC Intranet: I added another aliased virtual interface to VICC virtual machine to handle the new MC intranet website. I also created another Apache virtual host as a placeholder for the content.
Website Migration Cleanup: Some of the DNS names used during the transition from the Solaris platform were removed from service.
CGI Functionality Fix: The Apache rewrite rules were modified to fix a problem with the CGI functionality in the test and production web environment. The previous rules were performing a "greedy" match and attempting to send some CGI requests to the Sitemason server. The rules have been corrected.
Server Decommissioning: The following servers were powered off and removed from the Hill Data Center to be prepped for disposal:
- meru2
- samsara
- sitemsn-fe
- sitemsn-be
- nde-syslog
- apps3
Team Member Evaluations: I finalized my evaluation input for the Unix/Linux team members. I'm very proud of my team performance. I think we have done very well as a team.
I'm updating my Linux workstation in the background today. It's going from Ubuntu 7.10 to 8.0.4 beta. It's going slowly right now because of the downloads. I've only got to retrieve 1302 packages. My desktop is defintely not as trim as our RHEL servers.
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.
