How To Avoid a Botnet Infection?

Taco Cowboy writes "Two of the networks in the company I work for have been zombified by different botnets. They are taken off the grid as we speak. We thought we had taken precautions against infection, such as firewall and anti-viral programs, but for some reasons we have failed. Is there any list of precautionary steps available?" I'd suggest port blocking 80 for any computer that is detected running a web browser, but that might prevent some percentage of legitimate work.

Comments

XP

[Anonymous Coward]

Let me guess, all the computers are using xp. I work at a computer repair depot and i see alot of this on XP computers and rarely on vista/Windows 7 with uac turned on *sure its a pain but once everything is installed the user should never even see uac pop up. But i would guess if anything the computers are out of date for their OS patchs

In an ideal world...

[fuzzyfuzzyfungus]

You'd be running a lot fewer XP boxes, and much, much meaner firewall rules. In practice, of course, users crying about how they "need" to "get their work done" generally prevents this.

That being so, there are a few things to do: At present, our good buddies at Adobe are among the most popular and exciting vectors for infection. Where possible, ensure that neither Flash, nor shockwave, nor Acrobat are installed. Where not possible, make sure that they are kept up to date. Yes, this means updating all the bloody time and WSUS won't help(useful tip, with some poking around, you can find a utility from adobe, an .exe that, when run, removes all versions of flash, they hide it; but it lurks in the bowels of their site somewhere. You can also find .msi flash installers. Set up a network share, readable by all your administered machines, writeable only by admins, containing that utility, and the .msi for the latest flash player. Every time adobe updates, download the newer .msi, and run a script on all your administered PCs that runs the flash remover, and then msiexecs the newest flash MSI. It's a pain in the ass; but it will save you from some flash exploits). Updates for all other plugins you are using, plus OS components, should of course be adhered to with the same regularity.

Assuming that user pushback isn't excessive, stripping executables and .zips from emails will also save you from some common vectors of stupidity.

Re:Yeah...

[ByOhTek]

Yes, that's the general answer. Probably not the correct one.

*NOTHING* short of educating a user, or massively restricting their privileges on a computer can protect from this kind of problem. I worked at a place where we used Windows, and locked everything *really* tight, using a lot of sysinternals software (regmon/diskmon) to figure out where to allow nonprived users to write so that poorly written windows software would work for them. It's easier on Linux and MacOS, but it is still a problem.

Remember - even if it is only the user's account, and not the whole computer that is infected, it can still cause trouble (cleanup is easier though).

I've seen windows boxes go uncracked for years, and I've seen Linux and MacOS boxes cracked within weeks of being set up. With the proper security precautions, security flaws are mostly user based.

That being said, in a networked environment, once one computer behind a firewall gets cracked, the floodgates have been opened, whoever did the cracking just got a firewall bypass.

Re:No

[kainewynd2]

You HAD to save your files to your shared drive. If you rebooted the PC, the entire PC was reimaged back to a 'clean' state.

I love Deep Freeze, Centurion Guard, Drive Shield, etc... but it's not fool proof.

At one of my former employers, we had something like 700 Windows PCs out in various labs and all equipped with Drive Shield. If one of them got infected, reboot and all was well... right?

Well, kind of. Since we were not allowed to automatically reboot these machines (24/7 labs), some of these stayed up for weeks, which opened them up to all sorts of fun stuff. In short, I spent about 200-300 man hours manually rebooting machines, convincing the administration to change the policies on automatic reboots, and working with the guy in charge of our PC lab image to implement security features to protect against this sort of thing in the future (automatic A/V update on boot, for example).

Comparably, it took me about 40 hours to build a Terminal Server and another 60 to build and install Thin Clients to replace a bunch of those machines...