An excellent meta-analysis on the Slammer / Sapphire infection (and cautionary tale for open source enthusiasts) by Karsten Self (posted with permission):
Looking over the BUGTRAQ and NANOG lists, a few trends start to emerge.
Apologies if this is fundamental knowledge — if I’m duplicating well-known summaries, please post links as followup as I’m unaware of them.
- Attacks worldwide appear to start at 05:29:30 UCT, give or take a few seconds. The launch of this attack *does* appear to be highly coordinated. I’ve seen reports of up to several minutes later, but nothing earlier.
- University of Dartmouth registers 10k independent sources within the first 30 minutes of the attack, and a peak of 16k independent sources, speaking for extremely rapid propagation. Early propagation appears to be from many widely dispersed sites, though large colo facilities (e.g.: Hurricane Electric) appear in several reports. Other references speak of ~19k distinct sources. Whether or not this represents the maximum scope of the attack isn’t clear, but let’s presume that the total number of infected hosts were < 100k. Current estimates of total Internet nodes tend to range in the 200m – 400m range, though I don’t have good numbers on this. I’d be interested in same if anyone has a reference.
- Another number I’ve been pulling out of /dev/ass (mostly because nobody’s provided anything more useful) is that there are 10m Win2K systems in existence.
- This means that the infected hosts were on the order of 1% of all potential hosts. That is, Microsoft users were attaining a 99% patch and/or secure rate of systems publicly visible to the worm. This is a pretty good compliance rate. It was also wholly inadequate in preventing this attack.
- Several NANOG sources report prior scans of the 1434 port across systems earlier in January, particularly on the 16th and 19th. This may have been preparatory work for the sort of rapid-propagation exploit attack that was hypothesized last summer.
- The MS SQL engine is incorporated into a large number of MSFT products. While not absolving guilt, it does help to explain why so many exposed systems existed. The overhead of knowing what services exist on a given system, and of keeping these systems patched, increases consequently.
- In balance, the level of infection for this attack was *small*, not large. The effects were disproportionate to the number of directly infected systems. Calling this the result of a widespread software monoculture may not be appropriate (IMO it is, for complex reasons, but that’s a longer discussion). A similar vulnerability in a widely deployed free software utility could produce similar results, and the GNU/Linux & free software communities shouldn’t enjoy excessive schadenfreude over this incident.
- I recall (but can’t locate) a reference, possibly following the Mindcraft Apache / IIS rigged shootout, in which it was observed that raw webserving capacity was a poor performance metric, as a score or so Sun workstations would be more than sufficient to flood major Internet backbone links.
While it’s fun (however unsporting) to blast away at Microsoft for its security deficiencies, IMO the free software world should view the Sapphire / Slammer worm as more a cautionary tale. This is the sort of attack which _could_ potentially hit GNU/Linux or another ‘Nix. I feel that the likelihood is lower than that for legacy MS Windows, though there are a large number of likely poorly maintained GNU/Linux and other ‘Nix systems live on the Net.
Smugness kills.
Peace.