Editorial: Don’t Let Viruses Knock You Out

If your network goes down due to a virus, or stays offline for any extended period of time due to disrupted communications, you’re not doing your job. Maybe that’s a bit harsh, but the fact of the matter is that these issues need to be dealt with before they occur, and you should have a plan in place to recover from it.

Whenever a virus of some form or other strikes, there are media stories (more often than not mainstream media, as opposed to the computer press) about enterprises being knocked offline by the virus, and how many millions of dollars it costs. And each time, I wonder why. Just what does the virus do that’s so destructive? Viruses, Trojans, or worms don’t take the servers or gateways down by themselves. In that respect, the worst they can do is create a lot of port scanning and cause what amounts to a Denial of Service (DoS) attack. In such instances, the IT Department has usually made the decision to take the network offline. I believe that often enough, it is OK to leave the network running and eradicate the virus.

“Mass Mailers” like Melissa can jam e-mail gateways, but even if you don’t nip that in the bud and allow the macro to run and send huge amounts of e-mail, just what does that do to your network? (I’m not suggesting folks should let this pass — just that many of these events are oversold.) Take the e-mail gateway down briefly and enable a filter to stop all mail with attachments for the time being. This way, the more critical communications will continue unhampered.

What To Do?
If your server(s) have been infected, you have a bigger task ahead. In that case, you can take the server(s) down, disconnect machines which attach to them, cleanse the server(s), and then attach the machines serially, putting an anti-virus scan into the network login script. In this manner, you then know that everything connecting to your servers is copasetic.

After you have the mission critical aspects of your network running, use the intervening time to assess which local PCs, if any, may require a Restore (you do back up regularly, right?) or a rebuilding of their software. Assuming you have most data on the network drives, users can continue their work from another station, if needs be. (I always like to have a couple on carts that can be deployed in minutes for such occasions.) Establish a schedule to have them dealt with, and inform the users when they can expect their original workstations to be returned. (Be conservative — you need to properly manage their expectations. Your end-users will be happier if you tell them it might take three days and restore them in two, than if you tell them it’ll take one day and end up needing two.)

After all is restored, do another, very complete, antivirus check after hours — let everyone know that you’re taking the system down at say, 6:00 PM, and then run a scan on everything. If needs be, deploy a few folks with floppy disks to do local scans. These should be boot disks so that all the workers have to do is insert the disk and let it run. Your autoexec.bat or bootup instructions might even connect to the network as Guest, and then run a virus check from there. If you want everything self-contained, consider using boot CDs or some other form of write-protected, large removable media.

But First…
This is all worst-case scenario stuff. By all rights you shouldn’t be struck to begin with, and ought to be able to contain viral outbreaks. Take, for example, the most recent malicious software attack, the Nimda worm. It’s a nasty one, because it uses a blended approach to propagating itself and does so aggressively. It exploits mass mailing, network share, and can append Javascript code to Web pages to offer itself as a download to the unwary. Even this can be headed off.

First, make sure that you have a filter on your e-mail gateway that examines any kind of MIME attachment or executable. Next, don’t allow any e-mail clients to launch attachments without user intervention. (Don’t forget that these attachments can be made to look as if they’re innocuous — Nimda, while carry a payload named “readme.exe”, set it up as a MIME attachment that made it look like a .WAV sound file. And also don’t forget that .dll files are executables.) Similarly, be aware of any and all users who are set up with network sharing or other peer-to-peer capabilities. These can be major points of failure in network security.

Then, make sure that your users are well-informed. Talk to your HR department about including a FAQ sheet regarding e-mail attachments and viruses when they give out their Welcome Wagon kits, along with their company manuals and insurance information. Send out regular notices (at least quarterly) to all users advising them on how to stay clean. Consider using system recovery software on local machines, such as Microsoft’s System Restore, built into Windows ME and other recent Windows variations, or Roxio’s GoBack. These programs of late have become transparent background processes to run, and can effect a speedy return of the system and data.

And most importantly, make sure that you scan and backup, backup, backup. Be sure that you are acquiring and deploying all the latest security patches for servers and end-user computers.

At worst, you might have to take a network offline for a couple of hours. But I have to wonder why I continue to read headlines about how many businesses were knocked out by viruses for so long. Again, in most every instance, it is the IT Department who took the network offline — not the virus itself. I read those headlines as meaning that somebody simply wasn’t doing their job.

Regarding larger threats involving telecommunications disruptions, see our article, Assuring Business Data Continuity.

Jim Freund is the Managing Editor of CrossNodes.

Get the Free Newsletter!
Subscribe to Daily Tech Insider for top news, trends & analysis
This email address is invalid.
Get the Free Newsletter!
Subscribe to Daily Tech Insider for top news, trends & analysis
This email address is invalid.

Latest Articles

Follow Us On Social Media

Explore More