On 2013-02-17 at 20:44 +0000, [email protected] wrote: > If you think I'm wrong and I should be running AV software, I'd > appreciate that feedback as well, although I'd be really interested in > understanding why.
I'd hesitate to run A/V automatically on all Unix systems. All code has an attack surface. The more code you run that picks apart data, the greater the attack surface. Especially when the data you're looking for is data that's been written to violate protocols and exploit flaws. There have been a large number of security updates for ClamAV and for anything that does packet analysis. The impact of having "one security hole present on every system" is high. We all deliberately limit the ports that listen, use quality code written very defensively where we have no choice (OpenSSH) and freak out at kernel security holes which can be remotely exploited, prioritising those patches. If the incidence rate of Linux viruses, once you exclude those that exploit holes in A/V / IDS systems, is lower than the rate of holes in those systems, then the math is clean; I haven't checked lately. This does not mean "use no A/V" -- it makes sense in mail-servers, to add a layer of protective depth against holes in mail-clients, etc; even there, when I was an ISP postmaster, I put the A/V scanning on boxes that could only access the incoming mail flow and not boxes that had access to the mail-store, so that the impact of a flaw would be serious, but only impact mails for the duration of the problem; rather than "all your mail was potentially accessed", it would then be "all mail received in this time window might have been accessed". If you provide a file-store service, you don't want to run the A/V on the file-store. You should be running it on a dedicated VM somewhere, as a user-account that can't make outbound connections itself (unless using user-space access to the file-store, in which case bound to that), and generally treated as "almost as suspicious as network printers". You can then make sure that freshclam/whatever runs as a _different_ user, that can talk to the net; if you really can't separate users, you can whitelist outbound connections. It might be "easier" to lower system security on an ongoing basis to avoid arguments, but that's not a good reason. Lowering security should always be part of finding a balance, which typically means it should be for a clear business reason (eg, "we support remote workers"), as security is a means to an end: trustworthy systems which are available and maintain confidentiality as needed, under the control of the owners. -Phil _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
