Proactive Measures Can Protect Client Systems from Nimda

The recent Nimda virus outbreak again highlights the need for proactive management of your organization's client computers. When I wrote about the effect of the Code Red virus on client systems a few weeks ago, I received dozens of emails from readers who had either discovered that client computers were the source of infection or who used my suggestion to check their clients for Microsoft IIS; quite a few found unpatched IIS servers running on Windows 2000 Professional computers within their environments.

Nimda is more insidious than Code Red; it can propagate through servers and client systems and doesn't require IIS. Nimda combines the worst of Code Red and several other Microsoft Outlook email viruses and adds a self-executing hook for unpatched systems.

In my office environment, I found myself in the role of emergency virus security chief when our vice president of sales detected the Nimda virus on his notebook computer during a routine daily antivirus scan. Fortunately, the infection was restricted to a group of files in his Temporary Internet Files folder, and the virus had not executed.

When Nimda infects a Web server, the virus serves a file (readme.eml) that versions of Internet Explorer (IE) prior to 5.5 Service Pack 2 (SP2) will automatically download and execute. To make sure this type of virus can't propagate, you need to update local systems to a more secure version of IE and patch Outlook to prevent the virus from using Outlook as a Messaging API (MAPI) server to send email.

Here's a list of basic rules that I put together for our organization's users to follow:

  1. Upgrade to IE 5.5 SP2 or IE 6.
  2. Patch your version of Outlook to the current service pack and apply security fixes.
  3. Turn on file extensions.
    1. Never open an attachment with two extensions (e.g., readme.doc.pif).
    2. Never open any executable attachments.
    3. If you don't recognize the extension, ask for help.

I provided detailed instructions for performing these tasks and made sure that local copies of all necessary files were available on the network. The most annoying part of updating these client machines was that even though we have a standard vendor for desktop systems, not every user's machine ran the same version of Office 2000 (e.g., some had the Small Business version, and some had the Premium version), and because the computers came with the software preinstalled, we didn't have any network shares with all the setup files. When applying the fixes to Outlook, we had to find the Office installation disk specific to each Office 2000 installation.

Applying the security fixes to Outlook also caused a minor annoyance that I'm still explaining to users. The security patch doesn't let other applications use the Outlook MAPI server without permission from the local user. Many users in my company use a contact manager that synchronizes by sending an email message. I was flooded with calls from users worried about the new pop-up message they received when they tried to perform their daily synchronization. Although users grumbled a bit about the extra two mouse clicks now required to synchronize, everyone understood the need after I explained why it worked this way.

Keeping your users updated and informed can help you do your job. In this case, up-to-date information might have prevented a lot of last-minute scrambling to prevent Nimda from spreading. If you've been hit with Nimda, the only guaranteed way to remove the virus is a 100 percent reformat of the infected systems: I've been getting daily email reports of reinfections even after IT professionals have used the disinfectant tools that antivirus software vendors are providing. Better safe than sorry.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.