[clamav-users] clamscan --disable-cache

[Andrew C Aitchison]

On Wed, 30 Sep 2020, Dave Sill via clamav-users wrote:

> "G.W. Haywood via clamav-users" <clamav-users at lists.clamav.net> wrote:
>>
>> In the second scan, how did clamscan manage to do what it claims to
>> have done in the time that it did it?
>
> OK, you could have just said that the cache is internal to each invocation
> of clamscan, but that helps.
>
>> For further enlightenment, on one of your systems try doing something
>> similar to what I did above but using 'clamdscan'.
>
> The problem with clamdscan is that it runs into permissions since it's
> not running as root.
>
>> Consider using a
>> central clamd server for all your scanning needs.
>
> How would that work? Clamd only scans files on the system on which it's
> running.

No. clamD scans data passed to it by clamdscan, usually over a socket or
pipe. As a special case,
     clamdscan --fdpass filename
passes an open file handle (the man page suggests that that is not
technically accurate) to clamd which means clamd can scan any file which
clamdscan can read, avoiding the running as root problem. --fdpass only
works over local (unix) sockets, not network (tcp) sockets.


>> I doubt anyone is doing that.  I'm sure it isn't necessary, as it's
>> already taken care of by both clamscan and clamd.  Perhaps if you can
>> be a bit more forthcoming about your use case(s) we may be able to
>> help reduce scan times.  One of the best ways of doing that is not to
>> scan so much junk so often.
>
> We've got about 3000 Linux systems that we'd like to periodically scan,
> primarily to ensure that they're not being used to redistribute
> Windows malware. We'd like to scan all of the local file systems for
> completeness. Any attempt to skip "junk" will potentially skip malware,
> and hand crafting scans for each system is not an option.
>
> Skipping multiple copies of the same file won't really help because
> the duplication is across systems, and because every file will be
> rescanned every time clamscan is run.
>
> We could do a full scan on the first run and then weekly scans of files
> modified in the past week. That's kludgy but may be the best we can do.

That does mean that any malware which is missed in the first run
will not be detected in subsequent runs.

3000 machines per week, gives you about 3.36 minutes for each machine to
send all its local data to the scanning machine.
Instead I would run a local, mirror, repository of the database
and use freshclam on each machine to keep its database in sync with your
mirror, then run clamd and a clamdscan cron? script on each machine.
I would also look at on-access scanning.
Scanning files as they are used might mean more or less work
than scanning every file every week.

-- 
Andrew C. Aitchison					Kendal, UK
 			andrew at aitchison.me.uk