> > There is nothing special about LINUX here. The whole "don't run > > services as root" business is just so much noise. It isn't about > > protecting the *server* it is about protecting the *data* which is > > accesses [hopefully] by services which are *not* root. It is about the > > data and the clients that connect to the server. > Yes, but the scan has to be specific for the kind of problem you want to > detect. The presence of a malware pattern - it is pretty straight forward. > > I've seen CLAMAV find malware on web servers (maybe it isn't common... > > because no one is checking). Someone's crappy PHP code [is there any > > other kind?] allows malware to get injected into, and served, from the > > server. > That tends to be more because someone isn't doing updates than that they > aren't checking. This doesn't make sense. No amount of updating will protect you from a flaw in the application code / method. One can't presume that the hosted application / service is perfect. 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. > 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 configuration? 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. It 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. > > No root access anywhere, or required. It isn't about > > protecting the OS or the system, it is about protecting the data, the > > applications [from exploit], and the end-users [so the server isn't an > > attack vector]. 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. > > and the exploiter does not need to > > "own" the server (aka have root) in order to do mischief. Access to > > your data is probably more valuable than whacking your server. > > The mantra "LINUX doesn't suffer from malware" is just bollocks. Lots > > of malware is served from LINUX servers. > That may be true, but the exploit that allowed it to be put there may be > unrelated. So? > For example, you may have virus-laden email being > transported through a Linux server that doesn't have anything else to do > with it. Or you may have a samba share where windows clients can infect > it. Or, someone might get access through brute-force ssh password guessing. 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. You can't perform highly specific tests for unexpected events. The entire principle of auditing is looking for the unexpected. > > Scanning a server for > > signatures is just another way to proof (not prove) that a server has > > not been compromised and that data accessed by the server is secure. > > Which is what things like PCI/DSS is about - protecting the *data*. > An occasional clamav scan can't hurt. > >> What do you think it protects you against on a linux server? > "against a linux server?" ? > 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.