On Wed, 29 Apr 2009 15:29:28 EDT, you said: > What do you suggest to use on a server that must accept uploads of > binaries from users? Now that's a particular special-case instance. The original poster only differentiated as far as "Is it a different answer for your server and desktop". So I answered the original question at that same level of detail. > Should these binaries be scanned by an anti-virus? Can we trust that > end users have competent Anti-Virus? I don't know. *CAN* you trust that your end users have competent AV installed and up-to-date? If you can't, you probably need to be addressing *that* issue, since those end users are probably visiting a lot of *other* servers besides your upload server - and most of those are probably outside your control. > Because of the relative infancy of non-windows-based anti-virus > software would it be advisable to host a windows virtual machine that > shares a 'virtual disk' that is monitored by a robust a/v software to > use to host the binaries? Properly done security is about tradeoffs. How much will it cost to design/install/maintain/document the shared Windows server that does the AV scanning, and how much will it save you in infections that would not have been stopped *anyhow* by the end user's AV? > Which antivirus software would you > recommend? Let's say we have 2 AV products, FooBar and Quux. FooBar detects 20% more stuff which you estimate will save you $60K/year in infections you don't have to deal with, but the Quux site license will be $75K/year cheaper. Your best bet at that point is buying Quux and coming out $15K/year ahead. Now you discover that neither FooBar nor Quux will easily integrate into your binary-upload server environment - each will require another $20K in R&D to make that happen. Frobnoxx sucks in detection capability, but will drop right in for essentially free. In the real world, you *often* end up choosing a product that's not the best one rated solely on its main mission - things like licensing costs and integration issues often end up dominating the decision. > The easy out is to say "I don't need a/v and nobody does" perhaps you > might want to put a little more thought into your answers before you > hit send. Note that's *not* what I said - what I *said* was that if you designed things properly, you don't need "a/v" as a separate add-on because the things the a/v will do for you are *already* done by other stuff. > This, however, is not the point of the XKCD cartoon, the XKCD is > saying that you shouldn't have a contingency plan for something that > ISN'T A CONTINGENCY. Close, but no cee-gar. The XKCD is saying that if you designed it so that you need that as a contingency, you blew the design. > On a general purpose OS, especially a desktop, insane surface exists, > no matter what protection you've put in. Right. The point you're missing is that if you apply the protection *properly*, you shouldn't be needing a separate "a/v" add-on.
Attachment:
pgpCJOmkqX16e.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/