Upfront preparation helped my company ward off the SQL Slammer worm, which exploits a buffer overflow vulnerability in Microsoft SQL Server and creates a flood of packets, similar to a denial-of-service attack. But we still didn't totally avoid it.

Shortly after the worm appeared, we decided to run scans of our infrastructure to find and patch vulnerable systems. In the interim, we implemented Cisco Systems's Network-Based Application Recognition (NBAR) feature on our core edge routers, configuring it to drop any packets that matched the signature of the SQL Slammer attack. The problem with NBAR is that routers are designed to route traffic, not inspect packet payloads. NBAR consumes a considerable amount of router resources and can lead to performance problems, so we didn't want to keep it in place any longer than necessary.

Notifying Users

Once the NBAR rules were set, we sent out a mass e-mail internally with a link to a Web page we had assembled. The page contained information on SQL Slammer, instructions on determining whether a particular system is vulnerable and a link to the patch, which mitigates the vulnerability. Only after we had completed our scans and were satisfied that our SQL servers and other impacted desktops were patched did we remove NBAR.

Ultimately, we were lucky, but we weren't 100 percent successful. A few stray servers were somehow infected. Even a week later, we still found an occasional system that had slipped through the cracks.

A few days after the initial SQL Slammer incident, I received a call from our network operations center reporting that our servers were under a denial-of-service attack. We have a limited capability to monitor bandwidth utilization on some edge network devices. Those utilization rates were extremely high, and network performance was suffering. So we pulled up data from our intrusion-detection system sensors, examined the packets and discovered an excessive amount of file transfer protocol traffic.

It turns out that our company had just released a new software download that was in excess of 40MB, and the traffic was overloading our network. Until we could make significant changes in our systems, we decided to outsource the downloads by using Cambridge, Mass.-based Akamai Technologies Inc.'s EdgeSuite service.

The implementation went without a hitch. With a few modifications in our server configurations and some redirection, we were ready to go.

Eventually, we will either upgrade our network to handle the load, outsource to a managed service provider or possibly stick with Akamai.

EDirectory Assistance

With that incident out of the way, I've begun searching for an easily implemented, inexpensive method of providing centralized access control for our Sun Solaris servers.

In the past, most Unix administrators just used the Unix Network Information Service (NIS). Because of some vulnerabilities in NIS, however, we shied away from that and focused on tools that would integrate with our Novell eDirectory service. We use eDirectory for all of our enterprise accounts and as a user-information repository for controlling access to PeopleSoft, Siebel and other applications. The new system must allow central control of user-name, password and home-directory information through eDirectory and must let the administrator dictate the log-in shell for each user.

We use RSA Security Inc.'s SecurID tokens for two-factor authentication, so the log-in shell will be the program that activates the SecurID software. After some research and phone calls, we decided to implement a Unix pluggable authentication module (PAM). Several PAMs are available, depending on what you want to integrate. We wanted credentials stored in an LDAP-compliant database, so we used the PAM_LDAP program. For this to work, we needed both the PAM libraries and the LDAP client installed on our Solaris servers.

Unfortunately, we couldn't get the native Solaris LDAP client to work with PAM and properly authenticate to our Novell eDirectory. Instead, we had to use a third-party LDAP integration tool developed by Melbourne, Australia-based PADL Software Pty. The PADL libraries let us successfully direct the authentication requests to eDirectory. We have conducted some preliminary testing, and almost everything seems to work as advertised.

One issue that we're still trying to resolve, however, is establishing encryption between the Solaris resource and the eDirectory server. We initially thought that we could implement Secure Sockets Layer encryption for this, but it had problems. We're now experimenting with the IPsec protocol, but that will require additional configuration on each Unix resource we want to protect.

Adding Features

The other issue we face is support for additional features outside of the authentication portion of the deployment. For example, we might eventually want to enable netgroups (which group together machines and users with identical resource access rights for easier administration) and Role-Based Access Control.

When using PAM and the PADL libraries with Solaris 2.8 and eDirectory, we can't configure these additional features. However, we know through our testing of Solaris 9 and Netscape's iPlanet LDAP server that this functionality is available. So in theory, it should work with the LDAP-based Novell eDirectory. Perhaps I'll have the answer by next time. w What Do You Think?

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com