Mailing List Archive

Standard list of exclusions and a private docker registry
Hi all

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

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.

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.

Thanks

Matt

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: Standard list of exclusions and a private docker registry [ In reply to ]
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.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: Standard list of exclusions and a private docker registry [ In reply to ]
I agree with Ged on scanning a Docker registry, what I would be more worried
about is software versions especially when pulling from something like
Docker Hub.
I've personally started playing around with VMware's integrated containers
which do vulnerability scans, but I'm sure there's probably something more
generalized that will do the same.

-----Original Message-----

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.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml



_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: Standard list of exclusions and a private docker registry [ In reply to ]
Ged, thanks so much for the response.


I believe it accurately highlights the lack of though that has gone into using clamav in our situation.


The env is not open to the public in any way shape or form, and the security to get a machine onto the network is very robust, although we do pull things from the internet into the env.


You've given me a lot of food for thought, I'm going to arrange speaking with the other team members and discuss this. Having an include list sounds like easily the best idea to start with. I think if we sat down and started trying to put that list together, the other questions you've asked will pop up naturally.


Scanning everything is completely bonkers.


Again, thanks for your input.


Matt


ps, if I've replied in some sort of crap way that makes it harder to read, please let me know, as I always get this wrong.

________________________________
From: clamav-users <clamav-users-bounces@lists.clamav.net> on behalf of eric-list@truenet.com <eric-list@truenet.com>
Sent: 29 September 2020 14:32:39
To: 'ClamAV users ML'
Subject: Re: [clamav-users] Standard list of exclusions and a private docker registry


EXTERNAL SENDER: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
EXP?DITEUR EXTERNE: Ne cliquez sur aucun lien et n?ouvrez aucune pi?ce jointe ? moins qu?ils ne proviennent d?un exp?diteur fiable, ou que vous ayez l'assurance que le contenu provient d'une source s?re.

I agree with Ged on scanning a Docker registry, what I would be more worried
about is software versions especially when pulling from something like
Docker Hub.
I've personally started playing around with VMware's integrated containers
which do vulnerability scans, but I'm sure there's probably something more
generalized that will do the same.

-----Original Message-----

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.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml



_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml