[CentOS] Antivirus for CentOS? (yuck!)
lesmikesell at gmail.com
Thu Jan 22 22:54:33 UTC 2009
Adam Tauno Williams wrote:
>> Yes, but the scan has to be specific for the kind of problem you want to
> The presence of a malware pattern - it is pretty straight forward.
Only for known instances of malware.
> This doesn't make sense. No amount of updating will protect you from a
> flaw in the application code / method.
Of course it will.
> One can't presume that the
> hosted application / service is perfect.
Which is why things are fixed and updated.
> Applications are compromised
> much more frequently than Operating Systems which is why the fact that
> it is a LINUX server doesn't matter. A scanner will potentially tell
> you when an application has been compromised.
No, a scanner will only tell you when known patterns are present.
>> Before a scan can help you, the scanner has to know
>> about the problem. After someone knows about the problem there will
>> likely be an update to fix it at least as soon as a scanner that will
>> detect it after the fact. Which makes more sense to install?
> Someone is going to release an update for your local application and
Yes, you can create your own problems that no one else can fix, but you
are also probably running php, ssh, bind and an assortment of standard
services that have known vulnerabilities if not updated.
> Emphasis on the "likely" in "likely be an update to fix
> it". And a scanner doesn't detect the security flaw, it detects that
> the server has been breached enough to contain malicious patterns.
> has nothing to do with updates; relying on being up-to-date to prove
> your system is secure is akin to covering it with stickers of unicorns
> to protect it.
That's not quite the way it works. When anyone else has noticed an
exploit and figures out how it happened, or examines some code and finds
how one could happen, it is reported and fixed. And the next update
will prevent it. Not quite the same as stickers - but similar to the
way the known patterns for scanners become known.
>>> Assuming none of the services on you server can be
>>> exploited is just wrong headed;
>> But expecting a scanner to know about the exploit long before the
>> exploit is known and fixed seems misguided as well.
> This has nothing to do with knowing about exploits in the way you are
> using the term "exploit" (as a method of exploiting a service). It is a
> way to know about exploits OF a server's service. The scanner doesn't
> need to know anything at all about how the malicious content got there -
> it alerts you of it's presence.
But it does have to know the content itself, and there's not much reason
to think you will know this content without knowing how to stop the
> We are talking about completely different things. I'm talking about
> using a scanner to indicate that a server does not contain malware
> patterns indicating it has been [potentially] exploited - which is an
> *UNEXPECTED* event.
No, scanners only scan for known and sort-of expected things.
> You can't perform highly specific tests for
> unexpected events. The entire principle of auditing is looking for the
But scanning doesn't do that. There is some value in knowing that you
do have those known patterns present, but you can't deduce that you
don't have any unexpected problems if you don't find them.
>> Doing frequent updates is what keeps you safe - and maybe turning off
>> ssh password access.
> It isn't about "being safe". It is about having configuration and
> policies that ***tests*** the integrity of your systems; detecting
> malware patterns is a critical component of that.
As long as you realize that it is only a test for certain known patterns
that don't have much to do with linux problems, fine. Just don't assume
that it proves anything about integrity when you don't find them. Your
real problem may be that someone has guessed your ssh password and
installed a rootkit that hides itself from all normal scans (remember,
running programs continue to run even if the filename is erased so scans
don't find it).
lesmikesell at gmail.com
More information about the CentOS