Microsoft Worms and Global Routing Instability

James Cowie writes: "Fresh analysis here indicates that worm propagation periods correlate very strongly with global BGP routing instability, as measured by sustained exponential increases in the number of prefix announcements and withdrawals seen in BGP message traces."

Comments

Story misleading?

[baptiste]

The story seems to imply that the works spread faster because of BGP instability when the paper seems to be saying the BGP instability is being CAUSED by the worms.

In this online note, we summarize our preliminary analysis of the surprisingly strong impact of the Internet propagation of Microsoft worms (such as Code Red and Nimda) on the stability of the global routing system.

Re:Story misleading?

[DCheesi]

Err, no, you're just reading too much into it. The story only mentions a correlation between the two phenomena; there's no implication of causality there. In fact, my impression upon reading it was that the worms cause the instability --probably because that's the only scenario that really makes sense to me.

Re:Story misleading?

[sammy baby]

What do you mean, "seems to imply?" It states it flat out:

Instead, we have documented a compelling connection between global routing instability and the propagation phase of Microsoft worms such as Code Red and Nimda... what were thought to be purely traffic-based denials of service in fact are seen to generate widespread end-to-end routing instability...

If you're trying to suggest that the story submission is unfair in alleging that Microsoft worms are causing this instability... well, that's exactly what the paper is saying, eh?

Also... and *not* off topic.

[minus23]

Net instability can also be predicted if Slashdot links to a .... well anything.

Good report, but what's the point?

[disc-chord]

Very fascinating read, with lots of graphs that really strike the message home. But what is the point? Anyone with an internet connection will have no doubt experienced the instability.

I've personally had a particularly poor router lossing my packets for the last week, and have been trace routing it from all over the country to triangulate the problem. Doing a tracert from Maine, California and Texas seems to provide a reasonable picture of what's going on with a specific router by triangulating in on the offending router... so I'm a bit unclear on why this study was called for, unless it's just to point fingers at microsoft...

Re:Good report, but what's the point?

[iso]

But what is the point? Anyone with an internet connection will have no doubt experienced the instability. ... so I'm a bit unclear on why this study was called for

It's an analytical tool called a scientific proof. Believe it or not, anecdotal evidence (like you suggested) is not enough to prove your intuition that IIS worms influence global routing stability. You need scientific evidence to prove a hyptothesis such as this.

- j

Re:Good report, but what's the point?

[tjgoodwin]

But what is the point? Anyone with an internet connection will have no doubt experienced the instability.

The point, is clearly stated in the article: Contrary to conventional wisdom, what were thought to be purely traffic-based denials of service in fact are seen to generate widespread end-to-end routing instability originating at the Internet's edge.

Maybe the "highway" analogy works here. Everybody knows that the Internet goes all flaky during worm propagation, but it's been assumed that this is simply due to too much traffic. This report is saying that it's more fundamental than that: during worm propagation, for as yet unknown reasons, many of the direction signs disappear at the intersections! Not only are the roads full, but many of the cars can't find where they're meant to be going...

Msft is definitely guilty

[ch-chuck]

of contributing to global worming. They need to cut back their toxic emissions immediately before it's too late to save the planet.

Re:Msft is definitely guilty

[sien]

Ha. Someone mod this up as funny please !
But seriously, if a company makes a product that costs large numbers of other companies money they get fined. If a company's negligence causes a public resource to be degraded they get sued. Has anyone heard anything about some of the major service providers or any of the major uses launching a class action against MSFT ? It seems that they would have at least a start for a case here.

Caching and port-scanning

[osolemirnix]

I would assume that this effect is in part due to the nature of port-scanning a wide range of IP adresses with a small data packet. This kind of traffic is different from "regular" traffic where a lot more data gets sent along the same route.

Consequently, since routes time out after a while (and get cached), the IP adress sweeping increases the necessity to figure out more seperate routes than usually (or FIFO caches are too small so routes get purged from the cache faster?).

This would logically increase the load on route discovery protocols such as BGP. A whole new class of DoS attacks...

Re:Caching and port-scanning

[mdouglas]

first off, i'd just like to say, i love it when a hardcore networking article gets posted to slashdot, the number of responses is so much lower due to the userbase having no experience with the subject; and mindless pontificating and chest beating (as in anti microsoft/pro linux articles) doesn't cut it with this subject matter.

as an aside, i don't mean the above preamble as a negative statement about the specific poster i'm responding to.

"Consequently, since routes time out after a while
...This would logically increase the load on route discovery protocols such as BGP."

well...not exactly. when 2 routers are set up in BGP partnership they exchange an initial set of rotes which are statically set by the AS administrator, there's no dynamic discovery process. those routes are only changed under a few specific conditions : explicit changes announced by the BGP partner, or the loss of connectivity to the partner (too many missed hello packets). BGP route exchange is not based on some kind of dynamic route timeout/refresh algorithm as that would be horrifyingly inefficient.

a few words on how routing and route caching work (this is assumed to be on an defaultless internet backbone router) :

a packet enters the router destined for some ip address, a lookup against the routing table is done, the appropriate outbound interface is selected (this set is known as path determination), the packet is then sent to the appropriate outbound interface, re-framed, and sent out to the next hop (this step is known as switching); route caching associates a destination ip address with an next hop interface, thus bypassing the redundant route table lookup. a definate gain in efficiancy, cisco makes a number of advanced caching/switching engines that are used in thier high end core routers.

to summarize/explain the BGP/worm paper : worms generate excessive traffic; the traffic overwhelms some routers and wan links; thus, BGP hello packets get lost or never sent depending upon traffic or router load; consequently the BGP routes are being announced/withdrawn at a high rate (this is known as route flapping). this is bad, having a route fail is not a problem, as long as it stays failed. rapidly changing states creates extra load on the router. route dampaning policies help, but with a worm creating these conditions everywhere at once the cumulative effect is instability.

check these sites out to learn networking :
http://www.cisco.com/univercd/cc/td/doc/cisintwk /i to_doc/index.htm
http://www.merit.edu/mail.archives/nanog/

anyone who writes a wise ass follow up to this had better include a CCIE number.

Re:Caching and port-scanning

[figment]

> These same high-end routers often have traffic
> shaping/prioritization features. You'd think >that they could be configured so that the
>routing-protocol packets have a very high
>priority so that they're among the last to be
>dropped even at high load.


Not necessarily. In a lot of cases, mostly with multiple exit routers, it's more desireable for a hosed router to withdraw it's own route, presumably because you have another un-hosed router which can pick up the slack. In most cases, withdrawing a route is a lot better than advertising a route that doesn't work.

Re:Caching and port-scanning

[Salamander]

I think you missed the point of what I was saying. The problem that the original article talked about was BGP traffic getting dropped due to load. If that's happening, you can't add routes, you can't modify routes, you can't withdraw routes. What I was talking about was using existing facilities that allow you to prioritize traffic by type to ensure that the BGP packets get through even if nothing else does. Once you've done that, you can manipulate routes however you want to adapt to conditions.

What's happening now is like allowing emergency vehicles to get stranded in traffic because they don't have lights and sirens. I say give them lights and sirens, let them zip past the regular traffic so they can do something about the conditions that led to the traffic jam.

Re:Caching and port-scanning

[figment]

Very good explanation, but there's one pseudo-misunderstanding that a lot of people didn't pick up on. Routers can normally handle a lot of traffic (well good ones can), but are still susceptible to cpu overload due to the massive ip scanning that these worms do, which overloads the arp subsystem of the router. arp is mainly to blame, not necessarily increased ip traffic.

Assuming that the router has an interface with a larger than /30 subnet, the router has to do an arp request for every ip on that subnet during a scan, and if enough of these ips just don't exist, then it has to wait for a massive amount of timeouts, then rerequests again, etc. Endlessly.

While you suggest that saturated WAN links could be the problem (and it very well could be given enough infected machines and a small enough link), the data i have indicates that most, if not all, of the problems within our organization are because of excessive the excessive arp requests. A router at one of our pops doesn't run bgp and our traffic data shows it had plenty of bandwidth, but it's cpu usage was at 100% for 3 hours during the first nimda attack. We see similar cpu increases on other CPE equipment with no dynamic routing or any significant increase in traffic.

(ccie in progress ;)

Here's a great idea! (word association)

[Uttles]

OK, everyone knows that word association is a powerful marketing tool. Example: Microsoft Office. When you say "office suite of programs" to the average person, they automatically think Microsoft Office. Well this article sure gives us a great one:

In this online note, we summarize our preliminary analysis of the surprisingly strong impact of the Internet propagation of Microsoft worms (such as Code Red and Nimda) on the stability of the global routing system.

Look on AP, Yahoo, MSNBC, CNN, and you always see "the Nimda virus" or "the Code Red virus," but I prefer the way the article said it. So from now on in your conversations with others, refer to each virus in this category as a "Microsoft Virus" and hopefully by word of mouth word association we can sway public opinion away from this crappy MS software.

Re:Here's a great idea! (word association)

[DCheesi]

That's fine for casual conversation, but professionals and those writing formal papers need to steer clear of this sort of propaganda. I was going to criticize Slashdot for stating it that way, until I realized that the original authors used that same phrase. Calling it a Microsoft worm is really a distortion, and it's the kind of thing that can damage the credibility of the author. If you're preaching to the choir, that's one thing; but if you're trying to produce a study that will actually persuade a 'non-believer,' you need appear as unbiased as possible.

Re:Here's a great idea! (word association)

[pubjames]

That's fine for casual conversation, but professionals and those writing formal papers need to steer clear of this sort of propaganda.

I completely disagree.

'Cancer', 'Intellectual property destroyer', 'viral like' these (amongst others) are all terms that Microsoft has associated with the GLP and hence linux when communicating with their customers. And look how effective they've been - they have got loads of press coverage about it. And the terms are misleading, and in the case of 'cancer' just downright offensive.

To describe the Nimda virus or the Code Red virus as Microsoft worms is not misleading at all - it is difficult to argue that they are not Microsoft worms, after all.

I think this is a great idea. May I also suggest 'Outlook viruses' as a term we should use to cover Outlook specific email attachment viruses.

Re:Here's a great idea! (word association)

[peter hoffman]

Some people refer to them as MSTDs which I think is pretty funny and accurate.

Viruses, terrorism and Microsoft

[riflemann]

So...on a related note.

If it is true that viruses create BGP instability, one can extrapolate that this is a form of
terrorism, by disrupting international communications.

Now - as Microsoft has done almost nothing to effectively eliminate the threat of viruses, and
hence a form of terrorism, MS can then be seen as "harbouring terrorism".

Didn't George W himself say that those who harbour terrorists will receive the same fate?

It's therefore in the international communities best interests to destroy Microsoft!

Re:Viruses, terrorism and Microsoft

[thrig]

Windows has anti-virus software, for windows.

Linux has anti-virus software, for windows.

FreeBSD has anti-virus software, for windows.

Solaris has anti-virus software, for windows.

Open, exploitable ports are nothing compared to the design flaws inherent in the Office document format and the Outlook family, that cause wave after wave of new virus to saunter past anti-virus software, laughing.

Oh, wow.

[jd]

You mean, if the Internet gets saturated by bizare routing requests, it puts its feet in the air and dies?

I'd never have guessed.

Seriously, though, this does strongly suggest that merely using NAT and crude approximations of heirarchical routing are not enough. The networks aren't capable of tolerating the kinds of loads even a humble skript can put on them.

In short, we need a better routing system, better IP stacks, a more stream-lined structure, and better load-balancing. In short, we need IPv6, if we're to survive anything but these relatively feeble virus attacks.

(And they are feeble! In comparison to what could be done. The world is very, very lucky.)

Oh, and we also need a stronger backbone. T3's don't cut it, in a world where T4's are "standard items" and high-speed optics of up to 4 Tbs are potentially usable tomorrow.

When you start upping the bandwidth across the board by 2-3 orders of magnitude, the impact of a few flea-bag packets will not be noticable. For that matter, the impact of a major world event (such as the Starr Report, or the WTT disaster) would not bring the information infrastructure to its knees.

*Orator Mode On* Now, more than ever in the history of humanity, our society, our economy and our security depend on good lines of communication. No expense is too great, because the price of failure is greater still. This truth has tragically shown itself these past few weeks, and no amount of money can undo a single death, reverse a single bereavement, or heal a single injury.

Forty billion dollars has been allocated to the cause of chasing shadows, yet we know that shadows can never be caught. A mere four billion, on shining the light of information around the world, would have gone a long way to prevent the shadows from being there to start with.

Terror, fear - these are weapons that rely on ignorance and superstition. Without ignorance, terror has nothing to hold onto. Yet ours is a society that lives in ignorance. We have computers on our desks that are many hundreds of times more powerful than the ones used to put man on the moon. Yet those computers can be crippled by a simple forwarder virus, and the users of those computers do not wish to know. The dark is much more comforting than the light, even though it is the dark, not the light, that these viruses can grow in. Perhaps, because in the light, you do not need comforting. There is no fear to be comforted over.

Someday, maybe, people will become less frightened of living in understanding. When that day comes, the terrors of the night will no longer threaten.

*Orator mode off*

Re:Microsoft x Worms

[ethereal]

If IIS gets r00ted in a forest where no one's around, can you still hear the nimda flood it unleashes?

Viruses and evolution

[Anonymous Coward]

What we are seeing here is evolution happening on the internet. When we (humans) became the dominating species on earth, viruses started spreading amongst us. The same thing is happening among computers now!

We have two choices to fight this problem:
1: We can try to fight it using antivirus-programs, which is equivalent to using medicine to cure our viral diseaces. We already know that this means fighting an uphill-battle, because protection against the unknown is hard, if not impossible.
2: We can try to bring more diversity to the operatingsystems and programs we use. This would automatically decrease the viruspopulation, because a virus designed to infect more than one program/os/specie, would have to be far more advanced, and would thus lower the probability for it's existance. And in the case of computers, the bugs on one platform/program is rarely the same as the bugs on another.

No: Microsoft worms are NOT "web/email viruses"!

[Jens]

... but professionals and those writing formal papers need to steer clear of this sort of propaganda ...

Whats propaganda here? They are telling the truth. Those viruses only propagate and damage Microsoft systems. They are there because Microsoft systems are so vulnerable. If it weren't for IIS, Windows 2000 etc. those worms wouldn't exist. (And don't "but others would" me - I don't see any reason why Unices, Apache, etc. would be unsafer without Windows.)

Tell the truth. Don't hide behind words. That's a journalist's job, isn't it? And anyway, now with Microsoft distributing reports that claim Apache is also vulnerable, citing relatively harmless directory listing bugs from 1999, why should we not try to educate the public?

Yeah Well, Except...

[Greyfox]

The patches to prevent these worms were out for ages. It's just that system administrators and others never installed them. So Microsoft has quite an out there, and for some reason the businesses that whine about the costs of these worms never seem to be looking to their own admin staff and asking them why the hell those patches were never installed.

Re:Yeah Well, Except...

[anomaly]

It's easy to say this, but speaking as one who works for an enterprise, it's not easy to do.

We've got tens of thousands of PCs running hundreds of applications - some internally developed, some externally developed.

For MS security patches (or anything else) that we release into "production" we need to engineer the build to make sure it works with our OS build, then test against Tier 1 applications.

Once that is complete, the development groups need to sign off saying that their application runs with that code.

Specifically in terms of IE 5.5 SP2, Quicktime is no longer compatible. Sure, there's an update to Quicktime, but my point is this - how many other things stop working? Which of our internal apps are dependent on IE or subcomponents that no longer work with IE5.5 SP2?

We don't know. Frankly, even if we thought that we knew, we couldn't be sure outside of testing.

IE has seen 7 security patches in the last 8 months. Particularly in this economy, we can't afford the testing staff to nail each of these as they are released.

Of course we're at risk. Now is the time to question our continued use of MS products. I'm doing that.

Regards,
Anomaly

Embrace and Extend

[Greyfox]

Whenever a popular product shows up on Windows, Microsoft usually ends up either buying the company or writing their own version which sucks for the first few versions. So when will we be seeing MS Worm Version 1.0?

A Simple Solution

[Anonymous Coward]

One of the inherent problems with all routing protocols is that rely on inband announcements and updates, and communciate state purely by reachability. This is clearly a flawed approached on heavily loaded links and routers. This problem has already been addressed worldwide on the telephone network with the introduction of SS7. One of the key aspects of SS7 is that it is transported over an Out of Band network (the actual transport may be on a dedicated timeslot on a SONET link, but the basis is that the link is dedictated to management).

By implementing a low throughput (say 64K -256K - this requires more analysis) management network, the ISPs could be certain that the state of the BGP peering sessions and the integrity of the UPDATE messages are always intact.

One of the key aspects/benefits of BGP is that unlike other routing protocols it does not advertise routes in the simple - "here's my routing table" messages that protocols such as RIP and while less so, but similarly, OSPF and ISIS use. BGP relies on TCP sessions between peers. On connection the entire known (or filtered via policies) short test path routing table is exchanged. After this the link stays idle, with the exception of TCP keepalives, until an UPDATE message is sent to communicate that a new route is added or an existing route is removed from that peer's routing table. Also BGP does not assign any significance to the port that receives the information - merely the peer. This all makes BGP inherent scaleable, stable and reliable - unless resources are not available (CPU, memory, buffers or links). TCP is the reliability mechanism here. The presence of the TCP session validates all the routes learned via that session. The absence of the TCP session invalidates all the routes and causes them to be withdrawn for that TCP session.

Maintenance of the TCP session stability is key to the stability of the routing table. With over 80,000 routes on any BGP full update, the processing needed to cope with multiple TCP sessions failing or starting is immense (and probably better servered by a UNIX platform than by a router to be honest).

SS7 uses a mechanism whereby UNIX servers process the routing information and create the core routing table - note: table is the key - it is not the path the data or calls follow. Building a similar architecture within the Internet would allow routers to have one or two TCP sessions to BGP servers (a concept already grasped with route reflector servers) and dedicate their CPU to forwarding packets etc. The dedicated servers never need to see a packet to be forwarded - it's just not that important to BGP, so they have no need to be on the same physical cables/links as user packets. This architecture would take some rethinking but not would not be outside the plans of most ISPs, and definitively not outside the skillsets.

Clearly the next problem then becomes low speed customer connections. Again the Telco industry has addressed this problem with ISDN - with the B channels. For these lower speed connections, there is no need to change the existing model. Losing one customer here or there is nothing (UPDATEs on BGP are typically well over 100 a second at NAPs) and would be catered for simply.

The NAPs could merely serve as routing table peering points, and not data transfer points - again another area of congestion.

The Internet is proving to be reliable and a trustworthy international communications medium, the next step is to make it even more robust, and truly scalable. Using OOB management is the obvious next step to this goal.

GMPLS is being touted as the next step for ISPs in terms of exchanging routing information in an OOB network. This is only one aspect of the work that is being done there.

Re:A Simple Solution

[darkonc]

The in-band nature of the Hello packets, loss of which causes the 'flapping' is not an accident or an error. It is a feature. If you lose the hello packets, then chances are that you're losing other packets as well. This means that this branch of the network is overloaded and you should try another path.

Lost packets cause retries -- which cause even more traffic. If your problem is overload, you are far better to try another path than to lose packets and generate (overall) more packets through retries on the shorter path.. If all inbound paths to a network are overloaded, then the whole network is overloaded, anyways. You might as well just drop the packet, and give the overloaded routers that 30 second flap time to catch up to the backlog.

If you took those packets out of band, then you'd be needing another method to measure packet loss... This would require more CPU and/or more packets (bandwith) -- thus making the whole problem even worse.

Distortion ?

[AftanGustur]

Calling it a Microsoft worm is really a distortion, and it's the kind of thing that can damage the credibility of the author.

And what is being distorted ? Truth ?

Until worms start to propagate efficiently on other platforms, this problem is strictly limited to Microsoft products and calling it "Microsoft worm" is a reflection of reality.

root cause nothing to do with credibility

[twitter]

Calling it a Microsoft worm is really a distortion, and it's the kind of thing that can damage the credibility of the author.

Nope, sorry a tabbaco virus is a tobbaco virus because it destroys tobbaco crops. These worms are MS worms because they destroy MS boxes which then attempt to destroy everything. It's time the world knew about it.

You won't hear the popular press refering to "another MS worm", however. They would not risk losing their piece of the $1,000,000 advert budget MS has for XP. As you see, "professionals", and those writing formal papers are free to call the thing what it is and should. The popular press will get it sooner or later.

You and I should not censor our own speech for MS and their sloppy wares.

Re:Funny stuff!

[PolaRis75]

The reason for this is more than obvious. There are a lot of small ISPs and companies that do BGP over links as slow as T1s and fractional T1s. This recent M$ worm caused a lot of connectivity issues for a lot of people with links even faster than that. A company with just a few unpatched IIS boxes could easily produce more than 1.54 MB or traffic per second, which would cause massive latency and packet loss across their T1. This, in turn, would cause timeouts of TCP sessions like FTP downloads, web browsing, and yes, BGP sessions.

This would then cause the session to start flapping, the upstream provider to dampen the session and routes being advertised, and their address space being removed from the global routing table.

This doesn't mean that there was routing instability due to the worm, it just means that a lot of networks running unpatched IIS boxes became unreachable.

Fascinating... (Kill Whitey!)

[erroneus]

Okay, I just put the subject to troll for readership... Hehehe.

Actually, though there may be a direct connection between routing problems and Code Red/Nimda activities, it's still a routing problem and to my regret, I can't lay any direct blame on Microsoft for this one.

Okay, it only runs on Microsoft platforms... That's not enough. If the probes/propogation (as opposed to sheer traffic) are responsible for this then it's an issue that should be addressed with the router people. Clearly their firmware isn't written well enough and should be patched to handle this problem.

Additionally, ISPs should start cutting off infected users without hesitation now. The attacks are now more than simply annoying in the way it fills up my logs. They are now affecting the whole damned internet. This affects just every commercial interest and should be motivation enough I think... (complaints of the people are never enough, but start playing with or threatening money and you will get someone's attention eh?)

What are the positives surrounding Code Red/Nimda? Well, though they have managed to keep their sunglasses on it's still a black eye for Microsoft. And while the argument has been made that patches have been available long before this mess has started, blame can be placed on Microsoft for a different reason.

It's not the presence of patching that is at issue. Rather, it's about default configuration(s) at install time and Microsoft's neglect over issues of reasonable expectation that its users are smart enough to to know how to turn things off or even know they are running.

Microsoft's users, as Microsoft is aware, tend to install "everything" when installing their OS. Why? A number of reasons -- because they don't want to miss out on any cool toys or because if they need something later, they don't want to be forced to reboot to use it. Microsoft is aware of this.

Microsoft knows that a majority of its usership is not trained to understand the implications or potential problems of running services on the internet. These same users cannot be reasonably expected to understand beyond "if it ain't broke don't fix it." Unpatched, their servers appear to be working JUST FINE don't they? So the infected users probably don't believe they have a problem either because they don't see the symptoms or they don't realize they are running IIS at all.

Microsoft, as a mature and responsible technology company marketting to idiots must share more blame than they have been accepting at this time. This might be seen as Microsoft serving its "MS Coffee" too hot for its customers. (ref: the lawsuit where the woman sued McDonald's for serving coffee that was too hot and was negligent in affixing the lid on the container.) They have overestimated the intelligence of its usership for far too long and now this is the price we all pay.

Re:Fascinating... (Kill Whitey!)

[superdk]

Additionally, ISPs should start cutting off infected users without hesitation now.

Some ISPs do. I know because I get to cut them off after giving them a warning and ample time to fix the trouble. What's the problem with all of this?

Imagine the following...

Hi, this is Joe Tech from ISP X's Network center, we're seeing that your machine on x.x.x.x is infected with Nimda and this is affecting our network. Your service will be suspended if you don't take care of this.

Customer: uhhhh... how do I fix that? Will the guy at Dell fix it? Why can't you just fix my server and keep this from happening again?

My point, for every 10 business customer's I have only one of them knows A) they even have a web server on their connection B) they had their server's pants down to the whole world C) what nimda is.

besides, people paying business T1 prices don't like being shut off right or wrong.

Re:so why weren't they in criticalupdate?

[harvardian]

Criticalupdate is not for server admins. Hotfixes are for server admins.

If you're a server admin and you get your security updates from criticalupdate, your intranet is in big trouble.

We're NOT talking about server admins

[MemeRot]

Very shortly after the beginning of Code Red this ceased to be about server admins. The boxes being infected by these viruses now are home or non-power business users who have IIS enabled by default. Why by default? Because MS doesn't care about security. Why not throw in features most users won't need by default? What's the harm? Oh, we're destroying the stability of global routing? Oopsie.

The majority of the IP addresses spreading these viruses show the default homepage if you go to them. Because the home or casual business users running these boxes DON'T KNOW what IIS is, or that they have it enabled, they DON'T KNOW that they're vulnerable or infected. These are the people that criticalupdate would reach. These are the people that need the patches. By NOT pushing this patch, MS is leaving the situation as it is, and it will never get better. To repeat - security conscious server admins are having their network hammered by this virus not because other server admins are lazy - but because many non server admins have operating systems with IIS enabled by default, and MS is making no attempt at all to reach those people despite the fact that the situation has not improved.