Not all of us can run the asl kernel on all our systems, which is a shame.

For those of us who can't, it would be nice if asl could scan files for malware "on modify", as per a certain competing product. This leverages the kernel's "inotify" support (apparently in RHEL kernels) to trigger a scan when a file has been modified.

Seems like a sensible thing at first glance, although I obviously don't know the details or performance hit, though I would assume you would limit scanning to /var/www/vhosts (on Plesk) and certain other sensitive areas.

We started with pure inotify() early on, but found it too unreliable. Right now the most reliable solution Ive found is the dazuko module (deprecated by fanotify in newer kernels, which I havent tested yet).

The HIDS will also hook inotify for the integrity and diff checks. You could use that against the /var/www/vhosts directory now, and get the changes emailed to you in alerts.

That's interesting. Thanks Scott.

What I'd like is to be able to scan using clamd whenever something changes as opposed to just being notified. Basically turn it into an on-change av scanner for non-ASL kernels, to get close to the on-access scanning that dazuko provides.

Of course a daily scan would be almost as good, and that's already available via ASL, so I guess we are almost there -- just not realtime.

True, a lot of damage can be done in a day.

Realtime is tough to do without the kernel extensions, for example I wrote a stand along daemon to do this using inotify, but what I learned is that not only is inotify limited (you have to set the maximum number of objects to modify in the kernel, its got a default thats pretty low, so once you go over it no other objects are monitored), but that its reliability varies MASSIVELY from kernel to kernel. It was so unreliable I could just race condition it with malware, upload, block, upload, block, upload, not blocked. It was so inconsistent between the vanilla kernels that there wasnt even consistency repeating it, so sometimes it was clean, other times it wasnt. Seems dangerous to put out something that rested on such an unreliable (and unpredictably unreliable) foundation, we couldnt even say "kernel X is bad, kernel Y isnt), it was crazy inconsistent.

Which is why we instead decided we needed absolute positive control through the kernels access control system. The new fanotify stuff shows promise too, and that as well is all kernel level, so theres a compromise system in the works that may work with non-ASL kernel, but they will have to include the new mainline fanotify capabilities, but older kernels absolutely do not. So unfortunately, even though I know some people have put out inotify based clamav tools, they are totally unreliable, and thats the best tool for the job if you arent going to use something dazuko (or possibly the upcoming fanotify capabilities).

I'm wide open to ideas, but thats actually how we started, and it just didnt meet our reliability requirements (its a shame too, because I put in a LOT of work on the daemon).