Crisis-Mode Scripting

As you probably remember all too well, on January 25, 2003, servers around the world running Microsoft SQL Server 2000 were the targets of an insidious virus known as SQL Slammer. The SQL Slammer virus is a self-propagating worm that exploits a buffer-overrun condition on SQL Server machines. A compromised server can potentially run arbitrary code on behalf of the attacker.

Unfortunately, the attack wasn't limited to servers running SQL Server 2000. Computers running the Microsoft SQL Server Desktop Engine (MSDE)—a scaled-down, redistributable version of the SQL Server 2000 database engine—were also vulnerable to the attack. What appeared to be a reasonably isolated and easy-to-identify attack became a widespread disaster because MSDE is an optional component that's included with a variety of Microsoft and third-party products, such as Microsoft Office XP Professional and Microsoft Visio 2002 Professional.

MSDE isn't installed by default on these desktop products, but how would you know if it was? One answer is scripting. When administrators think about scripting, they often think in proactive terms. For example, they think of scripting as a tool for automating common systems administration tasks, such as managing user accounts, asset tracking, and configuration management. However, scripting can play an equally important role when you need to react to an unforeseen crisis like SQL Slammer. To demonstrate, I'm going to use the SQL Slammer incident to show you how to use scripting to assess and mitigate damage.

Understanding a Crisis
Before you can write a script to deal with the SQL Slammer worm or any disaster, you have to know something about the problem. You can't write a script to shut down ports, kill processes, disable services, replace files, or perform some other task without some knowledge of the disaster with which you're dealing. Any information you can gather from the CERT Coordination Center (CERT/CC—http://www.cert.org), the vendor, network traces, and other sources can help you determine where to focus your efforts as you try to identify and contain the problem. For example, consider what administrators have learned about the SQL Slammer worm:

1. The worm can potentially infect all unpatched versions of SQL Server 2000 Service Pack 2 (SP2) and earlier, including all versions of MSDE SP2 and earlier.
2. The worm exploits a known buffer-overrun condition that was discovered and reported to CERT in July 2002. Although Microsoft released a patch that addressed the problem in July 2002, many systems (primarily computers running MSDE) went unpatched for two primary reasons. First, the steps required to apply the patch were far too difficult in some cases (e.g., the older patch required too many manual steps). Second, many administrators were unaware of the scope of the problem as it relates to the number of computers running MSDE in their environments.
3. The worm targets the SQL Server Resolution Service, which listens on UDP port 1434 (i.e., port ms-sql-m in netstat.exe's output).
4. After a computer becomes infected with the SQL Slammer virus, the memory-resident worm tries to propagate itself by sending 376-byte payloads to UDP port 1434 at random IP addresses.

Identifying the scope of the problem was one of the most challenging aspects of the SQL Slammer virus, which explains why Microsoft quickly provided tools to help identify computers running SQL Server 2000 and MSDE. Could you have used a script instead? You bet! You can use a script such as IdentifySQLComputers.vbs to identify the at-risk computers, then contain the crisis with a script such as DisableSQLService.vbs.

   Previous  [1]  2  3  4  Next