I've always thought that systems in production face a greater threat of protocol and application exploitation rather than what constitutes the bulk of malware that requires user interaction. Viruses and malware on end-user systems require someone to initially run an installer (either wittingly or unwittingly) to establish the infection vector. Most of this is due to user interaction within an application and not because of a network application or protocol directed attack. Even in the cases of application exploitation (Adobe Acrobat anyone?) a user still needs to actually open the file handle in the application.
NIDS, HIDS, SELinux, syslog management, rootkit detection; all good tools to detect and deter intrusions on servers. Different toolsets for different threat models. A/V has diminishing returns on servers, because servers have different types of threats that need to be defended against. Better to spend your time/attention/money on the most likely threats. And if we're talking about a theoretical doomsday 0-day that can, from a normal user account, override all file permissions and elevate itself to a Domain or Enterprise Admin account ... well then no amount of A/V will help you at that point anyway. ;-) On Tue, Feb 19, 2013 at 1:11 PM, Phil Pennock < [email protected]> wrote: > 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/ > -- Joseph A Kern [email protected]
_______________________________________________ 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/
