How do you check that servers/pcs are not infected

Question

Simple question. Developers PCs have to have free access to network, including servers etc., and they have to have administrative access to perform work effectively.

However developers also use a lot of non-Microsoft tools which are available as GPL, LGPL, MIT, free-for-all etc.

Any of them can actually contain harmful code. Even LGPL libraries someone might use for, say, parsing XML.

And we all know that the the very moment someone clicks "yes" on UAC prompt, or does "sudo", the PC/Server can get compromised. And compromised servers can do a lot of bad things, including information leakage, data loss, etc.

How do system administrators battle these problems? Do you trust antivirus software, other tools?

Answer 1

This is a constant battle that you will never win, but you must keep fighting. A few things any Microsoft shop should definitely do:

• Have a corporate anti-virus software that is enforced using GPO and other means and cannot be disabled or bypassed. The minute you allow users to turn it off, you're not protected.
• Always filter inbound and outbound traffic. Many malicious applications attempt to "phone home".
• Use a proxy for web traffic. Even if you don't install web filtering software on it, it's handy to see what sort of traffic patterns are emerging (a lot of requests to an unknown asiapac page using the POST method might indicate malicious software, for example).
• Lastly, and perhaps most importantly, educate your users. Really good developers are not always paying attention to security concerns while performing their job duties. It's helpful to remind people that UAC isn't just a test to see how fast you can click "Yes", and that sudo isn't just a polite way to start all of your commands.

Good luck.. :)

Answer 2

I sincerely hope these devs have local admin only and have only regular user accounts in the Active Directory.

Devs may need access to servers etc, but if you're not doing so already, you can use a separate VLAN for the dev environment; no access to production servers, only to dev/qa/staging. Have the devs use another workstation to access regular, production servers.

Alternatively, and less securely, you can try to separate things at the logical level (e.g. different Active Directory forest, maybe domain).

If devs do have/get access to production systems, increase your logging and monitoring of prod systems and do some user education: "Why did you log on to that production database and copy the table with all password hashes?" kind of thing.

Note: this obviously depends on size & complexity of your organization.

Just a remark: you seem to suspect open source tools as being dangerous. They can be, but the real issue is not controlling the storage and use of executable code on dev pcs. Can be closed source too ;)