SQLServerCentral Article

Who's to Blame for the SQL Slammer Virus?

,

Last week the SQL Sapphire (or “SQL Slammer”) virus hit corporate networks throughout the Internet. Although damage hasn’t been estimated yet, it’s sure to be in the tens of millions of dollars. One bank alone had their entire nationwide ATM network go down with their call centers and every branch. So who’s to blame when a virus like this manhandles a corporate environment?

Note: You can read more about how the SQL Sapphire virus propagated and how to clean it up at http://www.sqlservercentral.com/columnists/bknight/sapphirevirus.asp

So, were DBAs, Microsoft or someone else to blame? With this virus there’s plenty of blame to go around but it should be mainly laid at the laps of the firewall personnel and DBAs. This is because the virus could have been avoided by either stopping UDP port 1434 from entering your network or patching the system.

The tendency with one of these viruses to automatically blame Microsoft. While this is fun, Microsoft ultimately fixed this vulnerability back in July of 2002. How then did the Microsoft campus itself get infected? Most of the unexpected vulnerable servers came from servers, laptops and PCs running MSDE (Microsoft Desktop Engine). This freely redistributable version of SQL Server is automatically installed with many of today’s applications like Compaq Insight Manager, ARCServ, some JD Edwards products, Microsoft Office and Visual Studio. Most users that I approached to upgrade their MSDE didn’t even know that they had it installed on their desktop.

Where MSDE can be especially dangerous is when a user takes their laptop home with MSDE on it, becomes infected with any virus and then brings it back into your internal network and behind all of your firewalls. No firewall rule will protect you from that sort of event.

Where Microsoft does receive some blame is the difficulty in installing the patches. Installing a hot fix is remarkably difficult and it involves copying files manually into various directories. This may not be difficult for a few servers but multiply that by dozens or hundreds of laptops, desktops and servers running MSDE, and then you have a logistical nightmare. Also it is a hassle due to the sheer numbers of hotfixes that were released on a monthly basis. This will be fixed with a later update product from Microsoft that will automatically install hot fixes onto a SQL Server much like Windows Update.

The blame on Microsoft must stop there though. It ultimately rests on the shoulders of the DBAs. If it is an logistical nightmare to patch every PC every time a patch comes out, then management should be made aware of the risk and be asked for more manpower to patch systems. If anything, this gives you the proper “I told you so” card that you can pull out later if your network gets infected.

The worse thing about SQL Server for a DBA is how darn easy it is to install. Part of a DBAs responsibility is to constantly be aware of what systems have SQL Server on it. The fact that anyone can pop in a CD and a few moments later have SQL Server installed by clicking next a few times doesn’t make this task easy. The best way I found to combat this is to write down all the networks IP address ranges you have at your company and occasionally scan for systems with SQL Server. Save the output and then come back next month for a rescan.

Note : This is not an endorsement by any means, but I love a free product from http://www.eeye.com to scan for SQL Servers. It will also quickly tell you if the SQL Server is vulnerable. Their pay product is even better and will tell you much more about the server’s vulnerabilities. Once you know the server’s IP address, you may be able to use the DHCP server to find out where the server is if you didn’t know it existed previously.

Users in my network have gotten used to getting a call from me in the middle of the day asking why they have SQL Server installed on their PC. If they have a good answer I ask them to patch it immediately. If they don’t patch it within an adequate amount of time, I ask them to stop or remove SQL Server.

This virus provides a very appealing excuse to rush service pack 3 past some users that would normally drag their feet. Now I’m not saying “rush the service pack into production” but I’m saying instead it may let you skip some of the political mess you normally have to fight.

Since this virus is such a new type of virus, it’s a little unclear first on who to point the finger at. We’ve been quite lucky not to have a virus like this before. As a DBA, you’re a hero if you came out of the virus unscathed or you may be feeling like you’re under a microscope. Either way, you may find that you have a new task in your job description to look for and support workstations that you didn’t even know existed before.

So have we become lazy? Join the debate on our forum.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating