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