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 <[email protected]> on behalf of [email protected] <[email protected]> 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 [email protected] 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 [email protected] 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 [email protected] 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
