Stop Viruses in their Tracks
Novell Cool Solutions: Trench
Digg This -
Posted: 23 Jan 2004
We recently conducted a contest to find out how people are using ZENworks and other Novell products to battle viruses. Here are their experiences; you should be able to find some great nuggets in here that you can use now, before the next big one hits.
Thank you all for your excellent contributions. Congratulations to these three lucky winners of the Remote Control Watches:
- Patrick Farrell
- Wayne Lackey
- Mark Jacobson
How You Did It
While Lovsan/MSBLAST missed us, Nachi hit us square in the face; McAfee's product meekly rolled over and allowed infection, though the definition files advertised supposedly prevent it. In an effort to control the spread of the worm, I used ZENworks (along with online analyses of the worm, and the file KILL.EXE from the Win2K Resource Kit) to end the offending processes and delete the infected files. It took me about two minutes to create and push the application, and was a huge success (as were our previous uses of ZENworks to combat Bugbear, Goner, Melissa et al).
Apart from keeping our antivirus product updated and other things we do to keep the network safe, ZENworks has always been a key subject in our defence strategy against viruses.
When we get a virus infection, we can always quickly create an application object to terminate the virus' processes and delete virus' regkeys and files. We also make the removal tools available for the users, allowing them to disinfect the PC themselves.
We also use scheduled events in ZENworks User or Workstation Policies to rollout critical updates required to patch vulnerabilities, combining it with scripting languages such as AutoIT (www.hiddensoft.com/AutoIT) or KiX. We find this method very reliable and has excellent coverage, even in a heavily locked-down/limited-access environment.
Auckland University of Technology
We have been using ZfD since version one was in beta. In that time, we have stopped several virus problems, Tristate, Bugbear, etc. Fortunately, we use GroupWise so we do not get hit with a lot of the Exchange problems, but over the years, worms and other pesks have gotten in. As in the case of Nachi, we often find ourselves pushing down various security fixes to the users.
On the way back from lunch, we got a call about some users receiving messages from their virus scaner. McAfee was able to clean the files when the worm tried to write them to disk, but it was causing a lot of traffic on the network from unpatched machines and of course, the users were getting messages to alert them of the virus. As you can guess, this is not good.
We quickly assessed the situation and found the properties and fix for the worm, applying it via ZfD. Using Snort, Acid, nmap and a few other open source tools on our Linux workstations, we were able to track down the non-standard machines and patch them.
Over the years we have had several close calls like this that ZEN has helped with. In one of my classes, a fellow student was complaining that they spent a week manually patching 100 workstations after MSBlast. I, of course, recommended ZEN to him.
We used ZEN to install the initial hotfix to 700 office machines in order to prevent infection. We also used virtual CD's to get the hotfix to a dial-in sales force. This helped us to avoid significant infections of Blaster or Nachi.
We have 2000 computers running WinNT, Win2k and WinXP. We run f-secure non managed virus clients and distributes patches and virus updates with Novell ZENworks 3.2. We got the msblast virus inside through non managed laptops and had to come up with a fix fast. We deployed the hotfix and the remove tools from f-secure to all computers with force run and in less than 30 minutes we had no more problem.
It's simple with ZENworks!
We update VirusScan virus definitions each week by sending out the weekly updates using ZENworks.
Makes it simple and we don't have to visit each workstation (although with having only 55 workstations it's not really a problem), however, it frees up the IT staff for other problems.
We did not get infected with any of the recent viruses or worms, however we did have a couple get into user's inboxes, but they were quickly cleaned/deleted.
We used ZENworks to create an application object to deploy the patch for the MS RPC vulnerability, and force run it on every machine ahead of time. The app installed the patch in silent mode, then a post distribution script popped up a message box explaining what happened, and asking the user to reboot the computer.
In conjunction with ZENworks we used Symantec AV Corporate Edition to push virus definition updates to each machine on a daily basis.
As a result of our 30 minutes of work on the ZEN application, only 7 of over 100 machines in 12 locations were infected. 2 were infected before the patch was deployed, and the other five didn't have ZENworks installed! Other departments in our organization were hit very hard, but I just sat back and watched them battle the blaster worm for over a week. Thanks to ZENworks my job was done.
ZENworks saved me HOURS of work.
Brigham Young University
NetWare 5 servers, GroupWise 6, Sophos Anti-virus and a 3rd party product Footnote(www.stack.co.uk) . All viruses are blocked at the GWIA.
To date we have had no infections of SOBIG or BLASTER, in fact virus infections have become a thing of the past since the implementation of Footnote. This product allows me to block email by subject line, attachment extension and scan it for a virus.
It just makes life a little simpler!
I am a consultant currently working at a midsize company - about 1000 employees worldwide. I am just finishing up the cleanup from Nachi as I received the ZEN newsletter questioning whether other admins have gotten hit by viruses.
This company received a real rude awakening thanks to Nachi. For instance, when the lab PC's were first setup, antivirus was not a concern as people would not be using them - they are just instrument PC's and some of them do not even have a monitor attached. Nachi was able to get in the network by, I can only assume, someone connecting their work supplied laptop up to their broadband connection at home. Even the lab PC's were vulnerable to this worm.
We proactively installed the MS patch when Blaster crept into our network a couple of weeks ago so all the MS servers were fine. However, as the company has no push technology for installing patches on user's workstations, it was emailed out to everyone as a "request" to install immediately. Of course, people did not. When Nachi hit, it created havoc in the network. In fact, one of the smaller sites actually shut down for a few hours and wrestled with shutting down for the rest of the day.
After two days of work, I was able to control the worm. This time, users actually installed the patch and even called when there was a problem installing it. Of course, the thought of rolling out ZENworks is now in all the managers' minds. Hopefully it will become a reality soon.
Another round of MS Blaster seems to be making the rounds again. We headed it off here, using ZENworks. Microsoft patches were easily applied to nearly one hundred workstations with one simple application object in an afternoon, before we could become a victim.
We have Novell NetWare 5.1 and ZENworks for Desktops ver 3. All workstations were Win 2000.
No problem, even keeps track of who got the patches!
We found many computers infected with the Nachi virus which was causing a huge amount of traffic on our network. I was able to create a simple package that detected if the RpcPatch and RpcTftpd registry key existed (services that start the virus). If detected, the package notified the user of the infection, then deleted the two registry keys preventing the virus from starting on reboot. I added a runonce line in the windows registry to execute a simple .bat file that deleted the dllhost.exe and SVChost.dll and another statement that ran the RPC patch. This automated solution saved us many hours of manually cleaning and patching machines.
We also use ZENworks to detect a "top 10" list of virus. If a registry key or file exists on a computer that is a signature of a High/Medium risk virus, we push a registry key to the computer and then track all successful distributions with the reporting feature. Once users sign in, I sit back and watch to see if anyone shows up in the report and if so take appropriate measures to clean the system. This has really made a difference for us.
I'm using my ZEN to distribute the application and patches. For the msblast, your already know that we need to patch our machine with the patch that was provided by windows. So here is what I did to stop msblast using ZEN.
1. I create a .bat file.
net stop cryptsvc ren %systemroot%\system32\catroot2 oldcatroot2 net start cryptsvc \\Installer\WindowsXP-KB823980-x86-ENU.exe /u /q
- The first three lines are to make sure the patches can run succesfully because in some machines I've gotten an error when I run the patch.
- The fourth line is the command to run the patches without user action.
2. At the application properties I've set to have a report in csv format and from the file I can monitor patch deployment.
Thanks to ZEN because our company is SAVED from msblast attack.
PadiBeras Nasional Berhad
Like A Kiser, our McAfee AV did well to stop Blaster (7 infections), but failed to stop Nachi. Instead we used ZENworks to deploy the Microsoft patch and to run Stinger (smaller than the DAT) at the same time to delete the virus and reboot the machine.
The only problem was we had to get every workstation on the network to power off, while eDirectory synchronised the NAL out to all our remote sites. 48 hours later we had patched 1800 workstations and found 367 infections.
M J Gleeson Group
MSBLAST missed us, but W32.Sobig.F tagged a few users. We pushed out the fix and as usual it was a great success as were our previous uses of ZENworks to rid us from Goner, Hybris and Welchia.
STRAND ASSOCIATES, INC
In our environment it has been very difficult to get users to install updates without affecting their workflow. We are using ZENworks to install Windows patches as well as update our Norton Antivirus client packages on the desktops with no user intervention.
As a result of our approach, the recent spate of Blaster/Nachi worms has only infected 10 machines out of 1000 in our network, all 10 were older and hadn't had ZENworks installed on them previously.
University of Wisconsin Medical School
Hi, here's my tale of virus woe.
I used to work for a large University in New Zealand. Our system at the time was NT4 workstations, ZENworks for Desktops 3 and NetWare 5.1 with Inoculan as our antiVirus product.
Now this always happens, you can just about see the light at the end of the work-to-do tunnel and some major set back occurs, in this case it was a very early infection with the SirCam virus. Our virus definition files updated, via a ZENworks application, later that morning, and surprisingly that's when most of our problems started (not ZENworks' fault, don't worry!).
As with many viruses, SirCam modified the following registry key
to this, or similar.
HKEY_CLASSES_ROOT\exefile\shell\open\command\ C:\recycled\sirc32.exe "%1" %*"
Now this registry key controls what happens when an EXE file is run (usually executes it and passes any variables along). SirCam modifies this to call itself and therefore gets run any time an EXE file is run, then it executes the file as normal. So far, so good.
Inoculan, like most other virus checkers at the time, found the virus files and deleted them, however, <problem> it did not remove the registry entry </problem> So Windows would fail to run any Executable files, like, say, Explorer.exe. At this point all the desktops on campus stopped working, we also were not aware of the above registry problem, nor could we run regedit.EXE to find out!
Now for the ZEN Cool bit.
I took a fresh machine that hadn't been switched on all day, unplugged its network cable and powered it up. Then I burnt a snAppShot and the virus file to a CD. On my fresh machine I ran a 'before' snAppShot, installed the SirCam virus and, making sure it took hold nicely, ran an 'after' snAppShot.
As I was sure all I needed was the generated .AOT file to save day, I copied it to a floppy disc. Then I created an Application object with this AOT in my test tree, saw what the virus did to the registry and what files it placed on the system, then reversed it, making the registry key (above) not being \"%1" %* , the system requirement. Once tested I used ZENith to distribute the application round the live tree.
Now to run the file! Since the shell was not loading on the workstations that were infected and semi-cleaned with Inoculan, NALDESK also failed.
Using NALRUN32 from the NAL Toolkit I was able to modify the Login Script to run my newly created undo tool. The final thing to do was ask everyone to reboot and -- hey presto! -- SirCam was stopped in its tracks.
Without ZENworks, over 3,500 Workstations in several locations would have had to be visited in person by the 5 members of the Desktop team, which would have taken a week. Unfortunately for some of the students, ZENworks had them back in lectures by 1 o'clock the same day.
I've had success analysing several viruses with snAppShot since then, and ZENworks has saved the day many a time.
Who needs a custom Virus removal tool!
In order to stop the threat of RPC-related exploits, we needed to be sure that all Windows 2000/XP machines that we had were patched. We have ZENworks deployed to all of our machines, and this was a relatively simple task.
I downloaded the patches from Microsoft, and put them in my ZENworks application area on the server, and then created application objects for each.
I give each application a name based on the Microsoft number. For example, the latest RPC patch I named UPD824146. I put in the comments for the application what it's for, in this case the 3 rpc vulnerabilities. I created a simple application with no AOT/AXT file.
Under Path to file I put in T:\Win2kxp\updates\Windows2000-KB824146-x86-ENU.exe (T: being my area for updates), and set the paramaters to -q -u -z which is a quiet install without reboot. (Reboot depends on urgency. It will take effect when they shut down at the end of the day after it is pushed). Check the box that says "Force run as user if application is workstation associated".
In order to make certain that each machine gets it once, and only once, I add a registry key to the distribution options. I created a key under hklm\software called win2kxp_updates_zfd_push. Under that I added a binary value UPD824146 and set it to 1. I added a requirement under Availability that this key not exist in order to distribute.
Finally I associated this with the user container and the workstation container (I have mine separate) for users and workstations respectively and set force run.
This will ensure that when a user logs in, their machine automatically is updated with all current patches that you have setup, and that it doesn't continue to try and deploy it every time they log in. If the patch has been deployed, it will have created the registry entry, and thus not deploy again.
We are using ZENworks to roll out virus patches as well. At first we made a nal app that called a batch file that ran the stinger.exe (from vil.nai.com/vil) and then ran the patch for every operating system at the same time. The batch files didn't play nice with ZENworks 4, so we made the batch file out of the distribution scripts and it worked fine.
It ended up something like this:
#f:\public\stinger.exe @f:\public\rpcfixXP.exe @f:\public\rpcfix2000.exe @f:\public\rpcfixNT.exe
It ran, cleaned up our network and all was happy.
We also used the Microsoft and Eeye scanners to check for any the Nal App missed, and manually fixed them. Also if you use Cisco equipment, Cisco Works can watch for ARP broadcasts. This is pretty handy for finding left-over machines with viruses.
Because of the size of our company, each time we need to push an application or patch, we have to create 50+ App Objects for each OS. If we need to deploy to three OS's we would need to create over 150 App Objects. As you know the more App Objects that are created the greater chance of a syntax error and having the push fail on the WS's. To overcome multiple App objects in each container we came up with the following solution.
Dominion Resources, Inc.
We are using ZENworks 3.0 SP1. To deploy a Microsoft hotfix to all of our 500+ Windows 2000 workstations, we create an application object that copies the hotfix down to the local workstation into a designated folder and starts the application to run off the local workstation in the secure system user context.
This allows all workstations (even those not imported into eDirectory) as well as all users (even those not local administrators on their workstation) to receive the hotfix updates. Using the free Microsoft scanning tools, we have confirmed that better than 98% of our systems are successfully patched.
With all the Outlook exploiting viruses around these days I just have to stop, almost daily, and give thanks that we're using GroupWise and not MS Exchange! While we may still receive a virus from the outside world (Norton Anti-Virus and auto updates keep us as safe as possible) we can say with certainty that we are not broadcasting any of those viruses back to the world.
For Blaster, I created an app object that detects if MSBLAST.exe exists on the PC and if so it would automatically start and run Norton's Blaster Removal tool. I also had the removal tool to write its log file back to one of our servers so we can see just how many PCs were infected and who stopped the tool while it was scanning the hard drive.
This app of course is limited to those viruses that actually write a definitive file to the hard drive but I have created apps like this for several viruses and it has worked very well us.
NC State University
We got hit by MSBlast and force ran the patch on over 1000 machines. As MSBlast re-booted them and the user logged back in they were automatically patched, and the offending files were deleted. Although many were being re-infected in the minute or two it took to load the patch, nevertheless the next time they re-booted they were patched and fixed. The response time from the first report of the worm to the solution being deployed was 15 minutes. I cannot imagine the scale of the chaos we would have to deal with if we did not have ZENworks.
I made a patch job which ran F-Secure's BugBear-removal tool (Force Run in ZEN 2) and wrote the Result file to a specific folder in NW-server. The Result file got its name from the computer name (enu.txt for example). After that I used the Find command to search files which included word 'Infected' in that specific folder. That way I knew who had been hit by BugBear.
Heinolan kaupunki, Finland
We use python to execute a patches.txt file. In this patches.txt file you can edit plain text lines like:
w2kpatch.cmd : (if exist %systemroot%\$NtUninstallKB823980$\ole32.dll goto end \Nt\zen\w2k\Windows2000-KB823980-x86-ENU.exe -u -f :end
In the workstation policy object we added a policy "patches", which executes a python commandscript with patches.txt as inputfile at userlogon or system startup time.
For all type of workstations we can distibute or excute updates for virusdefs and hotfixes and more.
Universiteit Twente, Netherlands
We live and die by ZENworks! We use Symantec AV Corp Edition on our desktops, with Sophos on the email gateway. But when Blaster came out and we had reports from users that were getting it on their home machines, it's definitely cause for concern with the number of laptops we have.
Using ZENworks, we were able to push the MS fix easily, and TRANSPARENTLY to all our users. Now our corporate PCs were protected and patched with minimal effort on our part. We were able to boost our IT image by even having time to offer some phone support to a few users with their home PCs. Normally, we don't support these at all, but it turned out to be a plus for our department.
J.F. Ahern Co.
When the Blaster worm hit us, here is what we did:
1. To clean up infected workstations, we used the FixBlast.exe tool from Symantec. We copied this file to a common area on our network, then created an application object that pointed to this, with the /s switch to run silently in the background. We created a group object and associated this group with the FixBlast app object, and set it to force run, thereby disinfecting the workstations.
2. To patch the workstations, we downloaded the appropriate patch from Microsoft, then extracted it to a common area on our network. We created an application object to point to the update.exe, and set it to force run with the appropriate switches so the users could not interrupt the distribution, or stop it from rebooting the workstation. This would stop the worm from spreading to these workstations. This app object was filtered on the OS (Windows 2000) and set to distribute to all users in the NDS container in which we reside.
3. To prevent reinfection from occurring on new workstations, we created new workstation images using ZENworks Imaging, and patched them appropriately.
4. Additionally, we are using eTrust Antivirus v6 and v7. Some of these workstations were set up some time ago, and had incorrect settings (pointing to the wrong redistribution server, incorrect number of days to update, etc.). We created application objects to change the settings so that all workstations receive signature file updates from the correct redistribution servers in a timely manner.
Osceola County Information Technology Department
I work at a university on Long Island with about 4500 Windows 2000 and XP workstations. Dealing with the latest batch of viruses has been quite a challenge for the IT staff as infected PC's have been generating excessive network traffic and decreasing productivity for some of our employees. Although we do all we can to protect our PC's from viruses, sometimes these mischievous buggers get through.
One of the biggest challenges has been finding the virus infected workstations. ZENworks has greatly simplified this process. Each virus will make changes to the file system and/or registry key(s). ZENworks can be used to look for these changes and when found generate a report that includes user, MAC/IP address and subnet of the infected PC's. This can be done by creating an application object that inspects the PC for virus-made changes and using the application object reporting feature to log the information to a file. Once we find these infected PC's we disinfect them make sure their virus protection is running, they have the latest signature files and they are appropriately patched.
The following is an example of how to track down the MSBlaster virus on a PC's running Windows XP using ZENworks 3.2:
- Create a new application object. Use the manual option: Manually (no .aot/.axt or msi file)
- From the application object choose the System Requirements option under the Availability tab.
- Choose Add>Files>File Existence?
- Set ?Show application icon even if criteria are not met? to False
- Set the File path to c:\windows\system32\msblast.exe
- Select the File exists bullet
- Choose Reporting under the Common Tab
- Check the Log to file box next to Distribution Success
- Enter the location you want the log file stored in the Log file location box.
- Choose File Rights under the Common Tab
- Assign the following rights to the directory that will hold the report log: Create, File Scan, Read, Modify and Write
- Associate the Application Object to your users and/or workstation objects and set it to Force Run
We originally used ZENworks to distribute McAfee VirusScan to all the computers on our network, but that's not the best of it. Due to the high release rate of new viruses and the possibility of one sneaking past a computer that, for some reason, has the virus scan disabled, I came up with a simple method to detect if a virus had made it onto any computer on the network (whether the av scanner is running or not).
I created this small batch file that is accessible by everyone on the network:
@echo off cls echo Please wait... echo Network is checking current System software revision... smtpsend -f%USER_NAMEfirstname.lastname@example.org -email@example.com -hsmtp.domain.com.au -sAlert Email >nul
- The echo message is just to keep the user happy (and unaware of what is really happening).
- The SMTPSEND program is a small utility available on the Net that allows you to send an email via SMTP from the command line.
- The %USER_NAME% is just the DOS environment variable that contains the login name of the user.
I then created a NAL object to force run this batch file but set the availability of the NAL object to only run when certain files or registry entries exist. The NAL object was then associated with the Everybody group.
When a new super virus is pounding away at the Net all I have to do is find out what files or registry entries it drops on an infected machine and then I set the NAL object availability to only run if those files or reg entries exist and ..whalla! If any computer on our network is infected it will send us a nice short email with the subject line of 'Alert Email' and the From address will be the login name of the person currently using that machine.
It certainly provides that extra peace of mind.
Queensland Performing Arts Centre
I'm the Senior Enterprise Engineer for a large school district in Texas. We currently have over 26,000 workstations and laptops on our NetWare 5.1/ZENworks 3.2/eDirectory 85 network. A couple of weeks ago the Nachi virus snuck its way into our system. On stand-alone systems or small networks this wouldn't have been a problem. However, this virus does a lot of 'pinging' before it sends out its payload. When you've got thousands of machines pinging everything in site it can wreak havoc. What we noticed first was that our firewall was so busy processing all the internal pings that it basically shut down our Internet connection.
The image that was on our workstations was built in May and contained all of the Microsoft security patches that MS had released at that time. That left us vulnerable to any Windows security issues that were discovered after May. The Nachi virus used a Windows exploit that was not fixed until June or July.
Here's how we solved the problem. First, we disabled ping on all our enterprise-level switches. This contained the virus to a school campus and kept it from spreading from site to site. Next, we used a forced-run NAL application to distribute the patch that fixed the Windows security hole. As users logged in and ran NAL, their machines were patched silently in the background with no intervention from them at all. We also put an app in the login script to silently remove the virus from their machines, again with no intervention from or disruption to our users.
After a week or so of this, we re-enabled pinging on our switches. Other than a couple of hours where our Internet connection was down when we were first hit with the virus, our users were completely unaffected by the virus.
NAL enabled us to quickly and efficiently deploy the MS fix. We used Novell's technology to fix an MS problem!
One of the great benefits of running Novell in our environment is that we tend to be immune from most of the viruses and exploits that plague our brethren. Unfortunately every so often one gets past our scanners and we get hit swiftly and painfully. Thanks to ZFD we can force updates and patches as soon as available with a very short testing time. The testing process of ours also allows us to make sure the patches don't cause more problems than they fix.
Being in Oz we also manage to get notifications before users get into work and speed up the spread; we can force updates as soon as they login every morning. The hours might be long but it sure pays off in increased productivity. Sometimes our users seem annoyed that they can't swap stories with their friends about the incompetency of their IT masters :)
Holmesglen Institute of TAFE, Australia
We have 1,300 GroupWise 6.5 accounts for faculty and staff and 18,000 NetMail accounts using McAfee anti-virus. In one week using GWAVA with McAfee on our GroupWise system we caught 6,000 infected emails.
As a second level of protection on the 1,600 desktops and 15 servers (NetWare 6) we use Symantec for virus protection with them set to automatically update each other. When it comes to installing Symantec, installing hotfixes or critical updates, or just to check for infected machines we use ZEN 4.01 which we upgraded from 3. It works great to create an application to check for the existence of a file which the virus creates and then to remote control the machine and run the fix utility.
Parkland College Network Specialist
We, at Frederick County Public Schools in Winchester Virginia, were hit by Blaster and Nachi at the same time.
My solution was to use Application Explorer to push out the Microsoft updates and fixes to the local operating system.
I created an application object for both XP and 2000 operating systems with a file dependency to determine the operating system. As this was pushing, I was running a custom virus scanner, using a force run app, to kill the viruses that had gotten on some of the computers.
After the deployment of the fixes, we used a scanner that logged which machines had been patched. After finding a few that had not received the patch, I used Remote Wakeup and Remote Control to manually install the patch and clean the viruses on those machines.
We have over 3500 computers in 20 different locations. We had all operating systems patched and all viruses purged within 2 days. This would not have been possible without ZfD4 and the help of all of our staff.
We continue to install Windows updates this way and our users have lost no time on their computers, WAN or the Internet.
Frederick County Public Schools
We are a high school in Wellington, New Zealand. When I heard about Blaster, I did a ZEN4 snapshot of the patch and other critical updates, pushed the application object out as a forced run and all our stations were patched within minutes.
While we only have around two hundred stations I'm sure a similar concept would work for larger organisation.
When Blaster hit Wellington several Educational Institutions went down for about a week or more. We didn't blink. ZEN4 rocks!!
To combat Lovsan/MSBlast we used ZfD to push a .bat file that would force-run at login. It had three parts to it.
- First it installed the required patch from Microsoft to fill the vulnerability.
- Second, it ran an utility program called Stinger (it searches for a list of viruses/worms and terminates/removes them) to remove Lovsan/MSBlast.
- Third, the .bat file updated our McAfee virus definitions to bring them up to date and restart the computer. We put all the necessary components in a public folder and the .bat file would call them as needed.
Nachi also gave us a bit of a problem as well. We were able to respond quickly by using the same .bat file with a couple of modifications and push it out via ZfD.
Our first two attempts at this required user interaction which was another problem in itself. Now we edit the .bat file as needed and push out any new updates and virus definitions silently on a regular basis to 400+ workstations. No interaction is needed.
Needless to say, ZfD saved us an considerable amount of time and work.
Indiana School for the Deaf
We created a little ZEN application assigned to the sysadmins that would run a batch file at login. This batch file would check the current DAT file on McAfee's site and download it if needed.
It would then rename it to sdat.exe, once downloaded to a public location.
The users then have a policy assigned to them that twice a day would run "sdat.exe /f" to ensure our workstations were kept right up to the latest version.
It might be a little over the top but better safe than sorry.
We also ensure that every program is deployed through ZEN so if there is any issue whatsoever with a PC, such as a virus, we can quickly reinstall it. Being able to reinstall PCs through ZEN has removed days spend fixing or rebuilding broken PCs.
With all those new viruses and worms no anti-virus software is capable of cleaning them from the infected machines. We are using ZENworks to distribute and force-run the remove tools on infected PC's and upgrade them with the latest patches from Microsoft and other software with security holes.
We use ZEN4 as part of our standards to ensure that all of our systems (2000+) get the latest patches, the latest version of antivirus software, and the latest DAT deployment agents. In an emergency we can instantly address specific needs by creating application objects to push down registry changes or hotfixes etc. Couldn't manage this many clients with a staff of four without ZENWORKS.
Working for a school for the last 10 years, it doesn't surprise us when, even with all the updated patches and virus pattern files, a virus still sneaks in once in a while (last one which sneaked in was "LoveBug" and we lost about 10 image files).
Firstly, we have not been hit by any of the recent viruses which have created havoc in the industry, thanks to BorderManager, GWAVA and McAfee on our GroupWise server, and McAfee on all our workstations and Application servers, whose DAT files are updated twice a week.
Beyond the above tools, we also use "Recovery Genius", which resets the workstations to its original state once it's re-booted. Thus, even if a virus sneaks into one computer, the chance of it spreading are very low because all our students are trained to reboot the computers after every class, instead of just logging off.
It's important for us to have all the above tools as we offer several ways for our students to access their Home/Shared Directories and our Portal from any internet-ready computer.
Of course we do a full backup every night and have data from the last four months, when we start to recycle the SDLT Tapes.We are also looking to removing all floppy drives w.e.f the next school year.
Chinese International School
As a result of creating our policy such that ZFD would refresh every hour we were able to keep up with all of McAfee's DAT file updated through BLASTER/NACHI, it seemed that McAfee had a new DAT file every couple hours on a few of those days.
Additionally through application logging we were able to find the 10% of machines that did not apply the patch and immediately get those patched through other means.
State of Montana
Viruses, Hah! what viruses? Safely hunkered behind a BorderManager firewall, running GroupWise with POP turned off and having our incoming email virus scanned by our ISP we don't have no stinkin viruses. The jdbgmgr.exe hoax and user queries about false positive email alerts from internet mail servers too dumb to know that 'from' address are spoofed represent most of our virus headaches.
GroupWise Rocks! Even if someone does get a mail worm virus, it can't access the address books so it can't spread itself.
We use ZEN system policies to prevent downloads from Web pages or installation of programs, the firewall stops P2P and other traffic we don't want, so the only way users can get a virus is to bring in an infected disk. Desktop AV stops that, with Inoculan running on the servers scanning incoming files to double-check.
If you have any questions you may contact Lee at lgreeTAKETHISOUT@sd48.bc.ca
School District 48 (Howe Sound)
What I have done is this: Our customers use McAfee antivirus on their Windows 95/98/2000 workstations. To make the update of antivirus dat files more fluid and consistent, I created an update application through ZENworks that uses the superdat.exe file from McAfee. Whenever a user logs in to the tree, the application runs silent in the background and updates the dats.
I use other properties of the application object to check if the workstation is already up to the current dats. If so, it bypasses the update. This is so much better than using the scheduler built into McAfee antivirus.
The update does not kick-off when the end user is working, which has caused a degradation in performance, it happens during the login process. We have also created another object that proliferates the superdat.exe to the other servers across the wan to cut down on license issues and performance issues.
I don't know how to say this, but my department didn't have to stop any viruses. We try to keep infections of any type out.
We are running a Novell 6.0 Environment with a SMTP gateway on another side of a firewall, with a mail relay host. The SMTP is a Win2k machine running McAfee 4.5.1 which FTP's to McAfee and mirrors their FTP site. It downloads updated definitions every few hours, which is then sent to a created virus-definition app that is sent down by AppLauncher, which is also distributed every time someone logs on to the system, and needs to access network resources. The e-mail is scanned before and after it hits a machine, then soon after the users log on, a definition update is run in the background along with a system scan. It adds a few extra seconds to the boot process but it's worth it.
Our situation was a bit odd. We were hit by Welchia about a month after it was fixed. A laptop that had been on the road for a while, and without virus updates, was brought into the office and hooked up to the network. Suddenly people were getting virus quarantine messages and traffic on the network exploded.
Norton Antivirus protected most computers from infection. We had already used ZEN to patch several hundred workstations, but a few machines had apparently been missed. Using a scanner to find the IP addresses of the infected machines and simple "net use" commands to map to them, we were able to pinpoint and clean up the computers. If not for ZEN-pushed updates, the impact would've been devastating.
We are changing most of our districts to GroupWise. We recently had one person in one district using Outlook that was sending a virus out. With the time it took to find and repair we could have built a GroupWise server.
I used Snap32 to create Application object of MS Security Patch KB.
I associated this Application object with all our users that run Windows 2000 (plus I created an additional object for Windows NT).
This object was set to automatically reboot the PCs and was running with Secure System user credentials.
Then I created an additional object to run the Symantec virus removal tool on PCs where it was finding registry changes.
ZEN saved me a lot of time but unfortunately on some of the PCs we never installed the Novell Client so on some of the PCs we needed to work locally.
Following a number of recent virus attacks, we have used ZENworks to rollout numerous MS patches to ~3000 users. We also use ZENworks to run a daily PC audit program which reports back, amongst other things, the current MS patch status and Sophos configuration to a central Lotus Notes database. This allows us to monitor all our PCs to ensure that any updates we deliver via ZENworks have been properly installed and that Sophos is also up to date and properly configured on every PC.
United Kingdom Atomic Energy Authority
We have been using ZfD since version 3 with great success. We recently avoided the whole MS Blaster worm issue with ZfD 4. Our security administrator was notified of the vulnerability two days before the worm hit. Through the use of ZfD 4 and applications objects that I built, we were able to roll out the patches to all 1100 computers spread across 67 locations in four states the same day. We breathed a huge sigh of relief when two days later the worm hit. We have been fortunate enough not to have to use ZfD to help clean up virus outbreaks but without it on the front end we definitely would have been vulnerable. Thanks Novell.
I use ZENworks to distribute the McAfee VirusScan application and the weekly SuperDAT updates. When an update becomes available, I download it, update the application object for the SuperDAT and push it out. Each computer is updated silently. Our users aren't even aware that their computers are being updated.
I also use ZENworks to distribute certain Windows Service Packs and patches. I've been here for almost two years and a virus has never hit us!
Evanston Public Library
This one's kind of long, but pretty trouble free.
Here is what I do for McAfee Virusscan 4.51 and probably can be re-engineered for any virus software that allows updates via ftp.
Click here for Mark's article, which we've published separately because of its length.
We have been having problems with Nachi for a while now. Partly due to the way we set machines up.
We "have" a fully automated Imaging process,
Workstation boots to Image server, Pulls down:
- Client install Addon Image
- Driver Updates Addon Image
- Image for any local settings (import server etc)
The base image is sysprepd to do hardware detection, install the NetWare client and login with an Import user.
This import user then has all the application installs that we want on our workstations associated ForceRun.
The problem we had was that the MS patch & virus guard don't get installed till about the 3rd reboot (all automated) but the network is active from the second boot and so infection happens before we can install any patches.
We managed to clean up machines by ForceRunning the MSpatch & virus scanner as system user but this only gets to the workstations on about the 5th reboot. All the while they are infecting newly imaged machines.
Updating the core image is not easy. Ok, updating the image is, but the evaluation and testing is time consuming when you have several hundred machines to image in a week (We're a university and term started in a week.)
In the end a combination of SnappShot/AddonImage looks like the answer.
- SnappShot install of MSpatch (including reboot)
- Create addon image of files "application Files" that get updated during patching.
So far, fingers crossed, it's worked with no adverse effects. We still run the update via a policy on the workstations to ensure they get properly updated.
Kingston University, Kingston-Upon-Thames, England
One of my 'new' clients had spent ?80,000 throwing over 200 support staff at defeating Blaster, only to realise afterwards they already had ZENworks, which could have done the same job, with one support person, in a tiny fraction of the time.
The company had over 3000 desktops spread across one site. Each support person was given one CD with the Microsoft patch and new antivirus software, along with a procedure list to ensure the job was completed correctly. Needless to say that chaos ensued.
We have since come on board and introduced them to the wonderful features that their previous vendor had failed to mention. Now they're almost looking forward to the next virus hit, all thanks to ZENworks. Will keep you posted if they get hit again, so we can really put ZENworks through its paces.
I currently am using a Symantec Corporate Edition solution that is installed on all of my NetWare / W2K servers and all of our Win2000, 98 and 95 workstations.
Not only does this solution protect these devices, but one of them is assigned as the master a/v server. It's configured to go out to Symantec's site daily, search for a/v updates and if applicable, propagate any updates to all nodes on the network.
Now, for the gateway arena, I am using Symantec's Anti-virus for gateways. It is the only channel for email to get to our GroupWise system. Symantec's latest version not only destroys viruses, but also allows administrators to block Spam heuristically or by using a Spam blocking list. The degree of filtering for Spam is configurable, though there are chances of legitimate email getting blocked if the settings are too high.
Overall, I'm very pleased with Symantec's product and would recommend it to anyone.
Communications Family Credit Union
We're deploying a solution similar to that addressed by Michael McCaffery in this article-- deploying patches via NAL without going nuts with application objects.
We used a slight variation on ours by creating source subdirectories based on OS_Version, simplifying the patch filename, and incorporating a macro for a PATCH variable. This lets us put all the patches for a particular OS in one location, and use the same application object for future patches by just changing the macro. We restrict executables in our ZEN policies, so we needed to have the executable as the command line in the application object (i.e. no batch files allowed!).
We originally started pushing single patches to 600 NT and 2000 machines. Many of our 2000 machines are now utilizing the SUS server and are automatically updating but for those that are not and the NT workstations, I created a package for each operating system.
False: Windows NT/2000 less than 5.x.x
False: Windows NT/2000 greater than 4.x.x
False: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB824146 -- does not exist
This application will not run on any machine that has already received the update
Then the patches starting coming faster and multiple reboots were annoying for a machine that may have been turned off for a week, so I created a QCHAIN package to push out multiple packages. Since it does not hurt to run the package multiple times, it was easier to check for the latest patch and push them all. Sample batch file:
@echo off REM This batch files qchains together all the NT4.0 patch fixes. REM MS-039 REM MS-040 REM MS-041 REM MS-042 is not included in this patch it is a Windows 2000 only patch. REM MS-043 REM MS-044 REM MS-045 echo "Installing MS Security Patch MS039" m:\install\windows_security\NT\824146-MS039\WindowsNT4Workstation-KB824146-x86-ENU.EXE /Z /M echo "Installing MS Security Patch MS041" m:\install\windows_security\NT\823182-MS041\WindowsNT4Workstation-KB823182-x86-ENU.EXE /Z /M echo "Installing MS Security Patch MS043" m:\install\windows_security\NT\828035-MS043\WindowsNT4Workstation-KB828035-x86-ENU.EXE /Z /M echo "Installing MS Security Patch MS044" m:\install\windows_security\NT\825119-MS044\WindowsNT4Workstation-KB825119-x86-ENU.EXE /Z /M echo "Installing MS Security Patch MS045" m:\install\windows_security\NT\824141-MS045\WindowsNT4Workstation-KB824141-x86-ENU.EXE /Z /M m:\install\windows_security\QCHAIN\QCHAIN.exe echo "System will restart in 3 Minutes, please save all data - Any key to REBOOT NOW" e:\update\shutdown /Y /L /R /C /T:180 "This system is shutting down in 3 minutes please save all data"
Still need help with workstations not logged in or off.
FedEx Custom Critical
We used it to remove Kazaa from users computers when the Win32.Swen.A virus came out. Swen.A could spread through the KaZaa network by copying itself to the following locations:
%TempDir%\TIXTTVZ\ (sub folder name is a string of random letters) \Program Files\KaZaA\My Shared Folder\
A registry value is then created to share the folder it creates:
HKCU\Software\Kazaa\LocalContent\Dir99 = "012345:%TempDir%\tixttvz"
With the initial threat of Melissa and later Blaster came some new challenges: Seeing as not all our Desktop PC's are configured with the EPO Agent (Yes, we run McAfee), automatic updates were required on more than 1700 PC's on a weekly basis. ZEN for Desktops 3.2 was (and still is) used to create applications to automatically update all workstations upon login. Set per version number, I can ensure the same update doesn't run on any given PC more than once. The (supposed to work) Microsoft patches are also distributed to all PC's on the WAN, and applications replicated via ZEN for Server 3 country-wide.
Some customization is required for Nachi though (little bugger): McAfee just seemed to detect it, but that's where it stopped. I had to download the "Stinger" program and force that to the WAN PC's. Worked Great.
In addition we use GroupWise, so we're not prone to any of the regular "Wrote for Microsoft" e-mail viruses. I've already migrated to Linux on the desktop, running the full client and Groupwise JAVA interfaces. No viruses here any longer....hehehe....even ConsoleOne is four times faster than on XP. You gotta love Novell and Open Source.....
We use ZENworks to push out MS Windows security patches and we use a registry key to keep track of the roll-out. This has allowed us to install 27 updates using a single NAL object to patch NT workstations with the bulk of the patches. To us the patching of known security holes is just as important as protection against known threats.
Recently with the attack of the Nachi Virus, we used NAL to remove files and registry key entries made by the virus on a large scale. Within a few hours every computer that could successfully run a NAL object was clean. (About 5% of our workstations have problems that we are trying to resolve.) This is saying a lot because the virus was brought in on a laptop plugged directly into our network bypassing our firewall. Then it spread in a few hours to almost all of our 1000 workstations.
PSCU Financial Services
We had quite a time with the Nachi virus, if it weren't for ZENworks, we probably would still be running in circles.
We used ZEN to create an object to delete the infected files and did this as the first push as soon as users logged in. We then pushed out the Microsoft patch to stop up the holes Nachi was using to propagate. Finally we ran a forced application repeatedly to drop a dummy file on machines contingent on the fact that they were still infected. We logged the event so that we could specifically target any machines that did not get the patch, either because they were not registered or the user was gone during the major time of infection.
Once we utilized ZENworks, it took less than three days to bring the pesky Nachi to a halt. Previously, it had been a week trying to corral it with no end in sight.
City of Chandler (Arizona)
Part of dealing with viruses is being able to quickly and efficiently deploy patches for flaws exploited by a virus. Although a SUS server provides some help with distribution of patches, it does not support Windows NT 4.0 which many companies still utilize.
For distribution of NT 4.0 security updates I created an app object in ZfD 3.2 that will force run a Wsh script to distribute updates. Once the app object and script were created, all that is required is copying the latest security updates to a "update repository" on a shared drive and then updating the Wsh script with an entry for each patch similar to the following:
IF NOT WSHFileSystem.FolderExists("C:\Winnt\$NtUninstallKB824146$") THEN WSHShell.Run "Q:\UPDATES\WindowsNT4Workstation-KB824146-x86-ENU.exe -z -q", 1, TRUE END IF
The install directory for each specific critical update is used as a flag to determine if the critical update needs to be installed. If the specific patch "install directory" does not exist, the patch will be installed. This allows for some logic in the scripting process to keep current with distribution of patches and allows current updates to be pushed out as required. Reboot of the workstation after the install can be set as needed using the appropriate switch. The nice thing is that it only requires one app object, you just need to keep current with newly released critical updates and maintain the associated wsh script.
In an effort to centrally manage virus protection in the enterprise, Mcafee EPO was implemented. Migrating the enterprise to the new software was simplified by distributing the agent to all workstations using a force-run object. Using ZENworks eliminated failed installations 100%.
Prior to the deployment, dat definition objects were used to keep crucial workstations up to date...
While the obvious use of Novell products to prevent virus infections includes the use of ZENworks to distribute and install McAfee Virus Scan software included with the Novell Small Business Suite and the running of McAfee NetShield in our NetWare servers (also included with NSBS), there are several other even simpler techniques we use to assist in avoiding infection.
New McAfee DAT files are downloaded centrally to a common directory and installed silently via a simple command line in the network login script without any user even being aware of the update process.
Additionally, GroupWise rules are used to help empty "infected" massages before the user can "accidentally" open an infected attachment (avoiding the panic that ensues when McAfee detects the virus). In addition, this technique is extremely useful in dealing with virus "hoax" messages that can be almost as disruptive as real viruses at the user level.
The Royal Canadian Legion
I am IT Manager for a law enforcement agency. The Blaster and Welchia viruses could have hit us hard. Which is not only a problem for IT, but it is a public confidence issue as well. When other agencies were forced to shut down to address virus attacks, we did not.
With ZENworks in place, we went into action. We used the Inventory tool to determine which workstations needed the MS patches. We created application packages that were distributed to clients who needed the MS vulnerability patches.
We then distributed the Symantec Antivrus client installation package to our remote notebook users. We used the ZEN Inventory to determine patch levels for more than 2500 workstations. ZENworks was and has been the tool that we can count on to get the job done.
We use a multi-tiered approach to combatting viruses: First, e-mail is scanned at a SMTP relay using McAfee's excellent Webshield SMTP product. From there the GroupWise GWIA hands it off to Guinevere 2.x, which strips all executables, as well as MP3's, MPEG's, and other non-business related attachments. This is very good at catching new viruses we don't have DAT's for yet. There is very little reason for our users to be sending or receiving programs, so that's not a problem. Any legitimate attachments that are blocked can easily be sent on from the Admin account.
The desktops are all running McAfee virus scan, which we automatically update with the login script and when necessary, we create a ZEN object to run immediately to update the virus definitions. Most viruses are caught at the SMTP relay or Guinevere, but the desktops also catch them when people check their Hotmail or Yahoo accounts, and the firewall stopped all NACHI and Blaster worms.
So far, we haven't had a significant virus infection in over 5 years, thanks to a combination of ZENworks, Guinevere, BorderManager, GroupWise, and McAfee. Knock on wood.
ZENworks for Desktops proved to be a powerful tool for us in dealing with the latest Microsoft denial of service attack virus that circulated (MSBLAST).
Shortly after coming into work one morning, we received a couple of user calls that their workstations were performing slowly and soon discovered that their workstations had the MSBLAST.EXE virus. It took us a total of, say, 40 minutes from when we first became aware of the threat to having a solution and fix in place.
We simply created a ZENworks application object that looked for the virus exe on the user's workstation and, if found, deleted the file, registry key and applied the Microsoft supplied security patch all in one action and also logged any found viruses and logged our patch roll out.
All in all, we only had 10 infections that were quickly contained throughout our workstation base of over 1600 workstations in 14 different locations across Canada and the USA.
Without tools like ZENworks, this would not have been possible and we would have been like many other organizations in our area that were up into the wee hours of the morning fighting the spread of the virus and incurring some serious downtime!