Thoughts About Slammer

The Slammer worm (also called W32/SQLSlam-A, W32/SQLSlammer, W32.SQLExp.Worm, DDOS_SQLP1434.A, and Sapphire) hit the Internet about 13:30 Hong Kong time on 25th January 2003. Within three minutes it had infected most vulnerable hosts on the Internet. It attacks Microsoft SQL servers, infecting them by sending a specially-crafted packet to UDP port 1434. The graph shows the Slammer packets stopped at Yui Kee's firewall.

The rapid rise seen in the graph is interesting. Last year, a theoretical paper "How to 0wn the Internet in Your Spare Time" described the Warhol Worm - a worm capable of attacking most vulnerable hosts on the Internet in under 15 minutes by utilising a "hit list" of vulnerable hosts with good connections. Slammer achieved the same in less than three minutes by being small and efficient. The choice of a single UDP packet was particularly interesting - this eliminated the latency involved with creating a TCP connection.

Slammer basically did nothing but spread, so the damage was the consumption of bandwidth and CPU time. The SQL servers that were infected essentially stopped being database servers until they were rebooted and patched. Many Internet users saw a slowdown, and some sites lost contact with the Internet for several hours. This mainly affected sites with an infected SQL server, but some sites with no Microsoft SQL servers were also affected. This appears to be because their ISP's router also served one or more infected sites, and was unable to cope.

Another interesting feature is the fall in the graph. Code Red and Nimda stayed with us for months, but Slammer was 90% gone by the end of the day. Partly, this was because it utilised all available bandwidth on the infected machines - if you are using a database for something important, and it stops working, you take action immediately. In contrast, Code Red did not take all the bandwidth, and it infected Microsoft's webserver, which many people used because it was there, and which is installed by default in some circumstances. However, it seems the ISPs should take the main credit: some companies did not fix their servers until after the weekend, but many ISPs took action and disconnected the infected sites, allowing the rest of the Internet to resume working. This is not unreserved praise; the confused reaction of some ISPs revealed their staff were poorly-equipped to react to an incident.

Slammer was also easy to deal with because it used an unusual protocol - almost no normal traffic uses UDP port 1434, so a simple filter blocks it with no side-effects. It also makes it easy to identify infected hosts from the traffic.

What lessons should we learn from Slammer?

• Defence in depth. Do not expose systems on the Internet unnecessarily. There are very few (no?) reasons why you need a SQL server accessible to the world.
• Apply security patches. The patch for the vulnerability that Slammer utilised was available last year from Microsoft.
• Warhol Worms are no longer "just theoretical". There will be more; they may be even faster (although that does not matter much - 3 minutes is already too fast for a human to analyse and decide on a response).
• You need good neighbours. The availability of your connection depends on the security of networks "close" to you.
• Good incident response at ISPs can make a big difference.