[clamav-users] Standard list of exclusions and a private docker registry

[G.W. Haywood]

Hi there,

Love the domain name. :)

On Tue, 29 Sep 2020, Davies, Matt via clamav-users wrote:

> We're running clamav 0.100.0-2.el7 on CentOS Linux release 7.5.180.

ClamAV 0.100.0 is old, it was released on 9th April 2018.  Upgrade
your ClamAV version.  The current release is 0.103.  Distro packages
tend to be very slow to catch up, so for anything like ClamAV where
there are obvious security implications I prefer to build from source.

> I was wondering if there are some standard templates of what folders
> to exclude, or if anyone has a link to someone's default exclusion
> list for me to take a look at?
> 
> I've inherited the systems and the scans are taking a very long time
> to run, I think I need to start excluding things.

I think I'm going to publish a FAQ about this.  Read my posts to the
list for that past year or so and you'll probably get the picture.  :)

I can't remember how many times I've seen people start by scanning '/'
and then complaining on this list about how long it takes.  It isn't
just that you might break something by doing that, it goes far deeper.
It means that little or no thought has gone into security.  I'm not
assuming that's the case here, but if your predecessor _did_ do that
then perhaps it's just as well that his(*) replacement is puttting a
bit of thought into it. :)  Then there's the question of why you might
want to scan a Linux box for literally millions of Windows viruses (by
far the majority of the signatures in the 'official' ClamAV database).
There could be a case for doing it, but it needs to be made.

Personally, I only scan mail with ClamAV.  Speaking now about Linux
and similar systems only, people do seem to spend a lot of time,
energy and money scanning filesystems and things like that, but I've
never felt that there's much point in doing it unless either you're
using systems to permit random uploads from untrusted sources (and I
suppose there could be justification for that in some circumstances)
or you have a very lax security posture.  If it's the latter then the
discussion is moot.

It's difficult to produce any kind of a 'standard' list for something
which is used in so many and varied situations as Linux.  There's no
substitute for thinking about it, using the knowledge that only you
can have about your systems, how they're used, to what they (and their
client systems!) might actually be vulnerable, and to what they might
be exposed or possibly expose their clients.  Although there are some
root-level directories to exclude I'd recommend not having an exclude
list, but an include list.  As I seem to say often on this list, that
means you need to think about the threats: what could get where, and
how it could get there.  That will of course depend on how you operate
the systems.  You should in any case exclude at least /dev/, /proc/,
/sys/ and I'd suggest /var/ and possibly /run/ too - although there
can be all kinds of things in the subdirectories of /var/ so there
will probably be a case for including parts of it.  But probably not
/var/log/. :)  You might want to look for all the sockets that might
be lying around, as it's unlikely that you'll get much joy out of
scanning those.  Sometimes there will be outlandish directories in /
that nobody's ever heard of, those will need to treated very much on
a case-by-case basis.

> Also, we're currently running a private docker registry on one
> machine.  Does anyone know if there's any point or benefit in
> scanning that?
> 
> The private registry folder structure is currently 140GB in size, so
> the scan of it takes some time to complete.  I'm just wondering if
> there's any point.

If you're confident of what goes into the registry and that you've
secured it from tampering, why scan it?  And if you're not, that begs
a bunch of other questions which you may need to answer first.

Also, I was wondering if there's any point in having one at all. :)
See e.g. 'Alternatives' in https://docs.docker.com/registry/

Have you evaluated the potential threats and risks?

What do you think you might be asking ClamAV to look for?

Do you know what it actually _does_ look for?

Have you estimated the chances ClamAV will find these things?

How do you feel about the numbers?

-- 

73,
Ged.
(*) Don't.