Effects of MSBlaster Virus on IGSS
I have an antivirus software package installed, but some functionality has stopped working in IGSS, for instance, the generation of hour, day and month values. What could be the cause?
Read this even if you don't feel you are in the risk group! So far we've seen a couple of examples in IGSS installations which are using a Terminal Services solution. However, we can't be sure that the problem is restricted to that kind of installation.
The MSBlaster virus is on retreat, but until every MSBlaster is killed, and every system is patched, it still constitutes a risk.
Unfortunately, we have lately seen effects from MSBlaster that are - unpleasant. If a MSBlaster enters the network where your IGSS system is running, it is bound to attempt - sooner or later - to infect your IGSS server. Doing this COULD kill the "Remote Procedure Call (RPC)" service on the server which is very bad, as this is a vital component in Windows. IGSS itself is not affected by this (fortunately!), but if your hour, day and month values are located in an SQL server for instance, data reduction will stop working, and there may be other effects as well.
Note that this could happen even if you have an antivirus software package running on the server, telling you that no virus has entered the server - the mere attempt to infect the server is apparently enough to kill the RPC service.
So, what can be done about it?
First, if you experience odd things on your server, appearing out of the blue the first thing you should check is if the "Remote Procedure Call (RPC)" service is running. In the Control Panel under Administrative Tools (directly in the Control Panel on NT 4), you can find the Services applet, which can tell you this. If the service is stopped, you have most likely been blasted! Start the service, if you can't from the Services applet, try to execute the following command in a command prompt:
net start "Remote Procedure Call (RPC)"
If that doesn't work either, boot the PC! When running again, you can verify the presence of MSBlaster by looking for error messages in the Windows Event Viewer. There you should be able to find events from the Service Control Manager, telling you the RPC service has died. If these events go back to August 11-12 (where MSBlaster was released) and no further, you can be pretty sure you have a MSBlaster somewhere in your network! Remember to change the collection status in the GenHDM program, so that it can reduce the missing data. Rewind the dates to the day before you have noticed missing data to ensure that you have a full set of reduced data again. To change the collection status, do the following:
- Choose Start, then Run and type Genhdm.
- In the Action menu, choose Collection Status.
- Rewind the dates as described above.
Second, what can be done to prevent it from happening:
First of all, you should patch your machine! Microsoft has released a patch, for more information see http://www.microsoft.com/security/incident/blast.asp. Note that the symptoms described on Microsoft's page are NOT the same as the ones described above! The symptoms described by Microsoft are for infected machines, while the problems we have seen so far on IGSS servers come from infection attempts only.
Second, you should probably get yourself a firewall... You might argue that you are on a closed network without connection to the outside, but the MSBlaster got in, didn't it? If you install a firewall, you should close for all incoming communication on port 135. If you do this, it is actually not necessary to patch the machine, but you might want to do both anyway. A firewall can also be configured to protect against other problems, but that is a different story.
Third, - or actually first, if patch and firewall are not possible to install right away, you could program the service to restart, when crashed. This will not solve the problem, merely remove (almost) all the symptoms. In the Services applet, choose properties for the "Remote Procedure Call (RPC)" service. Go to the Recovery page. Select Restart the Service as action for both First, Second and Subsequent failures. This will make sure the service is restarted immediately when crashed, but it will not prevent it from crashing and messing up whatever was going on exactly at the time of the crash. Still, if you can't patch or protect the system right away, this is better than nothing.
Hopefully this is not going to be a big problem for too many IGSS users, and if it becomes a problem to you, here is what you can do about it.