Re: [clamav-users] Clamav error using YARA
I'm not entirely familiar with yara, but based on https://yara.readthedocs.io/en/latest/modules/elf.html , there is no such function as "is__elf". Based on a whole search in the yara doc, there's only is_dll, is_32bit and is_64bit. Further googling shows this: https://github.com/Yara-Rules/rules/commit/8130cda6a3cd1b470b59e29a769162600bf1efab It seems is__elf is a private function now, so you can't use it directly anymore I guess. Franky Op Maandag, 11-11-2019 om 09:10 schreef Philippe Lefèvre: Hello, thanks for your reply :-) here is: = # grep -n is__elf /var/lib/clamav/rfxn.yara 9112: is__elf and all of ($s*) = Le 11/11/2019 à 01:02, G.W. Haywood via clamav-users a écrit : > grep -n is__elf /var/lib/clamav/rfxn.yara ___ 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: [clamav-users] Could not watch path /var/lib/docker/overlay2 error
Your bug was already reported by me. See this bug: https://bugzilla.clamav.net/show_bug.cgi?id=12306 (and it contains a workaround too) Franky Op Woensdag, 09-10-2019 om 17:32 schreef Arthur Ramsey via clamav-users: Hello, I’m trying to implement on access scanning for docker containers using overlayfs by running ClamAV outside of a container. I’m using Amazon Linux 2 which is currently at 0.101.4. If I set "OnAccessMountPath /“ an eicar test file downloaded and read via a container isn’t detected. If I read the file created within the container from outside the container it is detected. If I set “OnAccessIncludePath /var/lib/docker/overlay2” I get: Tue Oct 8 15:22:12 2019 -> ScanOnAccess: Protecting directory '/var/lib/docker/overlay2' (and all sub-directories) Tue Oct 8 15:22:12 2019 -> ERROR: ScanOnAccess: Could not watch path '/var/lib/docker/overlay2', Success I also tried "OnAccessIncludePath /var/lib/docker/overlay2//merged“ which isn’t practical because the uuid is generated when the container starts but it does work. I see that 0.102.0 has significant changes to on access scanning so I’m trying to test that but the configure script isn’t detecting fanotify support. I have kernel-devel and glibc-headers installed. I’ve also confirmed fanotify support with "cat /boot/config- | grep FANOTIFY”. I get an error from the configure script: ./configure: line 30024: auto=yes: command not found Here’s the full configure output: https://pastebin.com/0xYqhr2V. This was my attempt to fix it but it didn’t work: https://pastebin.com/k2kCrmHP. Thanks, Arthur ___ 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: [clamav-users] [Clamav-devel] ClamAV(R) blog: ClamAV 0.102.0 Release Candidate is now available
I'm always willing to test. However, I don't think freshclam and clamsubmit need newer libcurl versions, so I guess - if changes are need - that only clamonacc needs to be reviewed (for the linking part). With friendly regards, Franky Op Maandag, 07-10-2019 om 16:08 schreef Micah Snyder (micasnyd): Perhaps there is something we can do to make it easier to statically link libcurl, specifically, with freshclam, clamsubmit, and clamonacc. Regards, Micah On 10/7/19, 9:22 AM, "clamav-users on behalf of Franky Van Liedekerke via clamav-users" wrote: Op Maandag, 07-10-2019 om 14:18 schreef J.R. via clamav-users: > > This particular hard requirement (libcurl) affects the communication channel > > which is different than causing the code to fail to run at all. So the question > > is do the new libcurl requirements immediately break existing systems that are > > not yet updated with new libcurl functionality. It is kind of a big deal to > > update a widely used library and creates knock-on problems from ripple effect > > for production systems subject to strong configuration management policies. > > It's only a requirement for a new feature... > I'd like to disagree here: it is a new implementation for an existing feature (on-access scanning). There was already a remark in a redhat bugzilla request to disable on-access for the epel-build for 0.102 (on which I commented, since that would impact a lot of users). I won't go into the discussion of supporting "old" libraries on "old OS's" again, but for enterprise users (RHEL 6/7, Centos, Ubuntu LTS, ...) this is a bit of a problem (since the libcurl lib is also provided by the OS vendor itself). Franky ___ 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: [clamav-users] [Clamav-devel] ClamAV(R) blog: ClamAV 0.102.0 Release Candidate is now available
Op Maandag, 07-10-2019 om 14:18 schreef J.R. via clamav-users: > > This particular hard requirement (libcurl) affects the communication channel > > which is different than causing the code to fail to run at all. So the > > question > > is do the new libcurl requirements immediately break existing systems that > > are > > not yet updated with new libcurl functionality. It is kind of a big deal to > > update a widely used library and creates knock-on problems from ripple > > effect > > for production systems subject to strong configuration management policies. > > It's only a requirement for a new feature... > I'd like to disagree here: it is a new implementation for an existing feature (on-access scanning). There was already a remark in a redhat bugzilla request to disable on-access for the epel-build for 0.102 (on which I commented, since that would impact a lot of users). I won't go into the discussion of supporting "old" libraries on "old OS's" again, but for enterprise users (RHEL 6/7, Centos, Ubuntu LTS, ...) this is a bit of a problem (since the libcurl lib is also provided by the OS vendor itself). Franky ___ 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: [clamav-users] [Clamav-devel] ClamAV(R) blog: ClamAV 0.102.0 Release Candidate is now available
Op Maandag, 30-09-2019 om 15:27 schreef Franky Van Liedekerke via clamav-users: > Op Maandag, 30-09-2019 om 15:14 schreef J.R. via clamav-users: > > > While I applaud the re-use of existing components, requiring this > > > (minimum) version of libcurl will be a problem for redhat/centOS 7 > > > users: everybody is still on RHEL7 (RHEL8 is "just" released and still > > > lacks support from many vendors). > > > In RHEL/Centos, clamav is only packaged in EPEL, and EPEL packages > > > will never include packages that the base OS also provides (in this > > > case libcurl + libssh2 as a dependancy). This would mean that 0.102 > > > will never be available in RHEL7 (that is here until 2024). > > > So, maybe a solution could be to include libcurl in the clam distro > > > itself and build/use a static lib version of that (and not a shared > > > .so) in case the OS-version of libcurl is not sufficient? If not, EPEL > > > will never create an rpm for clamav 0.102, and that would leave a lot > > > of existing users "in the cold" and force them into using an "old" > > > version. > > > > Franky, > > > > As has been stated numerous times, the minimum requirement for curl is > > ONLY to build with the OPTIONAL argument for on-access scanning. > > > > The ClamAV team is not responsible for 3rd party packages, if you want > > a static libcurl built you would need to contact the PACKAGE > > MAINTAINER. Which for RHEL appears to be a couple people. > > > > Look at the changelog: > > https://centos.pkgs.org/7/epel-x86_64/clamav-0.101.4-1.el7.x86_64.rpm.html > > > > Sure, it can be done for RHEL 6 they built a static version of > > zlib in the ClamAV package due to a bug with the OS version. But it is > > up to YOU to tell THEM... i.e. on Redhat's Bugzilla... Alternatively > > now that you know exactly what feature is being used, instead of > > building a full static version with clamav, you could request that > > feature be backported into the existing curl package (as a different > > route to achieve the same end-goal)... > > > > Additionally, you *can* install the latest Curl from a 3rd party repo: > > > > https://mirror.city-fan.org/ftp/contrib/sysutils/Mirroring/ > > > > And if you want to add the repo to yum: > > > > http://www.city-fan.org/ftp/contrib/yum-repo/ > > > > Ironic you are complaining about not getting a new version, when > > almost all packages in a RHEL distro are frozen versions (ex: curl) > > and merely receive backported bug fixes and features... > > > > It's not hard to update curl, I already did it on my EL6 system. I > > haven't updated ClamAV yet, I'm waiting for the stable release. > > I think you misunderstand me, I'm merely stating a fact here. Epel won't do > anything about libcurl, and redhat won't just backport new features "because > of". Even so, backport requests take a long time at redhat. Maybe the epel > guys will include a static version of libcurl for clamav, I hope so. > I do know that this requirement is for clamonacc, that's just the feature I'm > interested in. > Of course I know how to replace libcurl (I already did it and built clamav > myself), but clamav packages would need to be done/provided/maintained by a > recommended third-party (like epel) for the company I'm currently working at > (maintaining own rpms is fine and I could even do it myself if clamav would > provide/maintain a spec-file). > > An extra thing is that the blog article states "This is only relevant if you > are installing from source", so I hope that all this is just a non-issue > (I'll need to rebuild myself later today again to verify). To continue this: it is not only relevant if installing from source, the clamonacc binary currently indeed needs the newer libcurl library (so just copying the resulting clam binaries to another server would not be sufficient). Franky ___ 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: [clamav-users] [Clamav-devel] ClamAV(R) blog: ClamAV 0.102.0 Release Candidate is now available
Op Maandag, 30-09-2019 om 15:14 schreef J.R. via clamav-users: > > While I applaud the re-use of existing components, requiring this > > (minimum) version of libcurl will be a problem for redhat/centOS 7 > > users: everybody is still on RHEL7 (RHEL8 is "just" released and still > > lacks support from many vendors). > > In RHEL/Centos, clamav is only packaged in EPEL, and EPEL packages > > will never include packages that the base OS also provides (in this > > case libcurl + libssh2 as a dependancy). This would mean that 0.102 > > will never be available in RHEL7 (that is here until 2024). > > So, maybe a solution could be to include libcurl in the clam distro > > itself and build/use a static lib version of that (and not a shared > > .so) in case the OS-version of libcurl is not sufficient? If not, EPEL > > will never create an rpm for clamav 0.102, and that would leave a lot > > of existing users "in the cold" and force them into using an "old" > > version. > > Franky, > > As has been stated numerous times, the minimum requirement for curl is > ONLY to build with the OPTIONAL argument for on-access scanning. > > The ClamAV team is not responsible for 3rd party packages, if you want > a static libcurl built you would need to contact the PACKAGE > MAINTAINER. Which for RHEL appears to be a couple people. > > Look at the changelog: > https://centos.pkgs.org/7/epel-x86_64/clamav-0.101.4-1.el7.x86_64.rpm.html > > Sure, it can be done for RHEL 6 they built a static version of > zlib in the ClamAV package due to a bug with the OS version. But it is > up to YOU to tell THEM... i.e. on Redhat's Bugzilla... Alternatively > now that you know exactly what feature is being used, instead of > building a full static version with clamav, you could request that > feature be backported into the existing curl package (as a different > route to achieve the same end-goal)... > > Additionally, you *can* install the latest Curl from a 3rd party repo: > > https://mirror.city-fan.org/ftp/contrib/sysutils/Mirroring/ > > And if you want to add the repo to yum: > > http://www.city-fan.org/ftp/contrib/yum-repo/ > > Ironic you are complaining about not getting a new version, when > almost all packages in a RHEL distro are frozen versions (ex: curl) > and merely receive backported bug fixes and features... > > It's not hard to update curl, I already did it on my EL6 system. I > haven't updated ClamAV yet, I'm waiting for the stable release. I think you misunderstand me, I'm merely stating a fact here. Epel won't do anything about libcurl, and redhat won't just backport new features "because of". Even so, backport requests take a long time at redhat. Maybe the epel guys will include a static version of libcurl for clamav, I hope so. I do know that this requirement is for clamonacc, that's just the feature I'm interested in. Of course I know how to replace libcurl (I already did it and built clamav myself), but clamav packages would need to be done/provided/maintained by a recommended third-party (like epel) for the company I'm currently working at (maintaining own rpms is fine and I could even do it myself if clamav would provide/maintain a spec-file). An extra thing is that the blog article states "This is only relevant if you are installing from source", so I hope that all this is just a non-issue (I'll need to rebuild myself later today again to verify). Franky F. ___ 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: [clamav-users] [Clamav-devel] ClamAV® blog: ClamAV 0.102.0 Release Candidate is now available
Hi Micah, While I applaud the re-use of existing components, requiring this (minimum) version of libcurl will be a problem for redhat/centOS 7 users: everybody is still on RHEL7 (RHEL8 is "just" released and still lacks support from many vendors). In RHEL/Centos, clamav is only packaged in EPEL, and EPEL packages will never include packages that the base OS also provides (in this case libcurl + libssh2 as a dependancy). This would mean that 0.102 will never be available in RHEL7 (that is here until 2024). So, maybe a solution could be to include libcurl in the clam distro itself and build/use a static lib version of that (and not a shared .so) in case the OS-version of libcurl is not sufficient? If not, EPEL will never create an rpm for clamav 0.102, and that would leave a lot of existing users "in the cold" and force them into using an "old" version. Franky PS: I need to rebuild my clamav test-version, so I'll check the lib-dependancy later on. Op Vrijdag, 27-09-2019 om 19:16 schreef Micah Snyder (micasnyd) via clamav-users: Hi Franky, Unlike clamdscan, which has the network socket code written by hand, clamonacc depends on libcurl for all of its network code to communicate with clamd. The specific feature that we used which bumps the libcurl version requirement to 7.45.0 is "CURLINFO_ACTIVESOCKET". See https://curl.haxx.se/libcurl/c/CURLINFO_ACTIVESOCKET.html for details. Your clamonacc binary should show a link to libcurl and libcurl's dependencies. Mine does. Here is the ldd output from one of my test VMs: micasnyd@oreos:~/clamav-devel/build/install$ ldd bin/clamonacc linux-vdso.so.1 (0x7ffc7bb61000) libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7f112967a000) libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x7f11293fb000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f11291dc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1128deb000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1128be7000) libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x7f11289c2000) libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x7f11287a5000) librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x7f1128589000) libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x7f112837b000) libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x7f11280ee000) libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f1127ea3000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x7f1127c51000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x7f1127a43000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f1127826000) /lib64/ld-linux-x86-64.so.2 (0x7f1129d93000) libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x7f11274a8000) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x7f1127143000) libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x7f1126f0f000) libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x7f1126cd9000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f1126a58000) libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f1126782000) libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7f112655) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f112634c000) libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f1126141000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f1125f26000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x7f1125d0b000) libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x7f1125aca000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f112579b000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x7f1125588000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7f1125384000) libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x7f112517b000) libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x7f1124eee000) libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x7f1124c4c000) libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x7f1124a16000) libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x7f112480) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f11245f8000) libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x7f11243cf000) libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x7f11241c) libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x7f1123f76000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f1123c6d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7f1123a35000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f1123697000) -Micah On 9/27/19, 8:01 AM, "clamav-devel on behalf of Franky V
Re: [clamav-users] OnAccessExcludePath being ignored.
Op Donderdag, 26-09-2019 om 20:14 schreef Franky Van Liedekerke: > Op Donderdag, 26-09-2019 om 19:17 schreef G.W. Haywood via clamav-users: > > Hello again, > > > > On Thu, 26 Sep 2019, CROFT Ian via clamav-users wrote: > > > > > ... making sure they are all strings looks better now in most cases. > > > > > > So I now have these :- > > > > > > OnAccessIncludePath /var/log > > > ( Only added to include to get around the bug previously mentioned ) > > > > > > OnAccessIncludePath /var > > > > > > OnAccessExcludePath /var/log > > > > > > However eicar test as /var/log/test.txt is still being picked up. > > > > > > Its working fine on other real sub directories ( not separate munts ), > > > feels like this is falling foul of the fact /var/log is a sub mount > > > point perhaps. > > > > H. Bugs or no bugs it seems rather willful having both of these: > > > > OnAccessIncludePath /var/log > > OnAccessExcludePath /var/log > > > > and I'm not surprised that things seem a bit insane if you do. :) > > > > Unfortunately on bugzilla, issue 12306 itself is restricted access. > > Because of that I didn't even know of its existence - I've trawled > > through every issue listed in the components pages at > > > > https://bugzilla.clamav.net/describecomponents.cgi?product=ClamAV > > > > and AFAICT it doesn't appear in any of them. So I don't think I can > > add anything useful to what I've already said. To repeat what I've > > already said, I think scanning /var/log isn't a great idea. > > Well, I reported the bug, so I can summarize it with this example: > == > This works to monitor /opt (assuming /opt/openv is a submount): > > OnAccessIncludePath /opt/openv > OnAccessIncludePath /opt > > but this doesn't: > OnAccessIncludePath /opt > OnAccessIncludePath /opt/openv > == > > The thing is of course: what to do if you want to monitor /opt and not > /opt/openv while /opt/openv is a submount? > Maybe the new 0.102 version has a workaround for it (I do know that you still > need this OnAccessIncludePath workaround, but maybe with the new onaccess > method, the standard excludes also apply and that would help then ... > something I need to test (but I need to compile clamav for that first). Ok, good news: the new 0.102 version works as expected. While it still has the bug with the OnAccessIncludePath-part, you can just exclude /opt/openv in clamd itself using the standard ExcludePath-option. Reason why this works: clamonacc is a new client daemon in 0.102 which in fact is just being told what should be monitored in on-access mode and gives those files to clamd as a client. Clamd itself then checks al its regular options, so excludepath is validated too. This is very cool in the fact that you could now once again use the mount-option for onaccess too and let all the excludes be handled via regular clamd. This has an overhead of course (you should understand that OnAccessMountPath has less possibilities), but I like the choices now. Franky ___ 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: [clamav-users] [Clamav-devel] ClamAV® blog: ClamAV 0.102.0 Release Candidate is now available
I'm replying to this because of the blog entry concerning the new version: CURL (VERSION >= 7.45) REQUIRED FOR INSTALLATION: This is only relevant if you are installing from source, but it is worth noting. It seems a new curl is needed, even on fully patched rhel7 servers. While this is not unsolvable, I'm trying to understand why. Reason for asking: - I'm compiling clamd 0.102-rc from source. It refuses to compile clamonacc if libcurl is not new enough - the blog says it is only needed for compilation, but if I look at the ldd-output of the binaries after compiling, the clamonacc binary has no link to libcurl, but freshclam does So: why would clamonacc during compilation need libcurl? And why would freshclam need such a new curl version (in rhel7 the version is libcurl-7.29.0-51.el7_6.3.x86_64) to just download some files? I can't justify newer clamav version to need to install non-rhel libcurl and libssh2 (dependancy) versions on a server just like that to my manager ... With friendly regards, Franky Op Maandag, 16-09-2019 om 18:13 schreef Joel Esler (jesler): https://blog.clamav.net/2019/09/clamav-01020-release-candidate-is-now.html ClamAV 0.102.0 Release Candidate is now available Today we are publishing the release candidate for ClamAV 0.102.0 (clamav-0.102.0-rc). There have been some bug fixes and minor improvements since the 0.102.0 beta. We do not expect any additional changes should be necessarily before publishing the 0.102.0 stable release. Please take this opportunity to validate that the 0.102.0 release candidate works for your application and that there are no major issues blocking your upgrade to 0.102.0. Release materials for 0.102.0-rc can be found on the ClamAV's downloads site. Release Notes ClamAV 0.102.0 includes an assortment improvements and a couple of significant changes. Major changes * The On-Access Scanning feature has been migrated out of clamd and into a brand new utility named clamonacc. This utility is similar to clamdscan and clamav-milter in that it acts as a client to clamd. This separation from clamd means that clamd no longer needs to run with root privileges while scanning potentially malicious files. Instead, clamd may drop privileges to run under an account that does not have super-user. In addition to improving the security posture of running clamd with On-Access enabled, this update fixed a few outstanding defects: * On-Access scanning for created and moved files (Extra-Scanning) is fixed. * VirusEvent for On-Access scans is fixed. * With clamonacc, it is now possible to copy, move, or remove a file if the scan triggered an alert, just like with clamdscan. For details on how to use the new clamonacc On-Access scanner, please refer to the user manual on ClamAV.net, and keep an eye out for a new blog post on the topic. * The freshclam database update utility has undergone a significant update. This includes: * Added support for HTTPS. * Support for database mirrors hosted on ports other than 80. * Removal of the mirror management feature (mirrors.dat). * An all new libfreshclam library API. Notable changes * Added support for extracting ESTsoft .egg archives. This feature is new code developed from scratch using ESTsoft's Egg-archive specification and without referencing the UnEgg library provided by ESTsoft. This was necessary because the UnEgg library's license includes restrictions limiting the commercial use of the UnEgg library. * The documentation has moved! * Users should navigate to ClamAV.net to view the documentation online. * The documentation will continue to be provided in HTML format with each release for offline viewing in the docs/html directory. * The new home for the documentation markdown is in our ClamAV FAQ Github repository. * To remediate future denial of service conditions caused by excessive scan times, we introduced a scan time limit. The default value is 2 minutes (12 milliseconds). To customize the time limit: * use the clamscan --max-scantime option * use the clamd MaxScanTime config option * Libclamav users may customize the time limit using the cl_engine_set_num function. For example: cl_engine_set_num(engine, CL_ENGINE_MAX_SCANTIME, time_limit_milliseconds) Other improvements * Improved Windows executable Authenticode handling, enabling both whitelisting and blacklisting of files based on code-signing certificates. Additional improvements to Windows executable (PE file) parsing. Work courtesy of Andrew Williams. * Added support for creating bytecode signatures for Mach-O and ELF executable unpacking. Work courtesy of Jonas Zaddach. * Re-formatted the entire ClamAV code-base using clang-format in conjunction with our new ClamAV code style specification. See the clamav.net blog post for details. * Integrated ClamAV with Google's OSS-Fuzz automated fuzzing service with the help of Alex
Re: [clamav-users] OnAccessExcludePath being ignored.
Op Donderdag, 26-09-2019 om 19:17 schreef G.W. Haywood via clamav-users: > Hello again, > > On Thu, 26 Sep 2019, CROFT Ian via clamav-users wrote: > > > ... making sure they are all strings looks better now in most cases. > > > > So I now have these :- > > > > OnAccessIncludePath /var/log > > ( Only added to include to get around the bug previously mentioned ) > > > > OnAccessIncludePath /var > > > > OnAccessExcludePath /var/log > > > > However eicar test as /var/log/test.txt is still being picked up. > > > > Its working fine on other real sub directories ( not separate munts ), > > feels like this is falling foul of the fact /var/log is a sub mount > > point perhaps. > > H. Bugs or no bugs it seems rather willful having both of these: > > OnAccessIncludePath /var/log > OnAccessExcludePath /var/log > > and I'm not surprised that things seem a bit insane if you do. :) > > Unfortunately on bugzilla, issue 12306 itself is restricted access. > Because of that I didn't even know of its existence - I've trawled > through every issue listed in the components pages at > > https://bugzilla.clamav.net/describecomponents.cgi?product=ClamAV > > and AFAICT it doesn't appear in any of them. So I don't think I can > add anything useful to what I've already said. To repeat what I've > already said, I think scanning /var/log isn't a great idea. Well, I reported the bug, so I can summarize it with this example: == This works to monitor /opt (assuming /opt/openv is a submount): OnAccessIncludePath /opt/openv OnAccessIncludePath /opt but this doesn't: OnAccessIncludePath /opt OnAccessIncludePath /opt/openv == The thing is of course: what to do if you want to monitor /opt and not /opt/openv while /opt/openv is a submount? Maybe the new 0.102 version has a workaround for it (I do know that you still need this OnAccessIncludePath workaround, but maybe with the new onaccess method, the standard excludes also apply and that would help then ... something I need to test (but I need to compile clamav for that first). Franky ___ 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: [clamav-users] OnAccessExcludePath being ignored.
Indeed, I'm having this problem too. Probably the include wins over the exclude, even with this in the logs: clamd[4940]: ScanOnAccess: Protecting directory '/var/log' (and all sub-directories) clamd[4940]: ScanOnAccess: Protecting directory '/var' (and all sub-directories) clamd[4940]: ScanOnAccess: Excluding directory '/var/log' (and all sub-directories) The way I do it currently is via a small script (and I don't do /var/log) to precisely indicate via OnAccessIncludePath what I want ... F. Op Donderdag, 26-09-2019 om 11:53 schreef CROFT Ian: It's a fair point Ged well made. And making sure they are all strings looks better now in most cases. So I now have these :- OnAccessIncludePath /var/log ( Only added to include to get around the bug previously mentioned ) OnAccessIncludePath /var OnAccessExcludePath /var/log However eicar test as /var/log/test.txt is still being picked up. Its working fine on other real sub directories ( not separate munts ), feels like this is falling foul of the fact /var/log is a sub mount point perhaps. Cheers Ian -Original Message- From: clamav-users On Behalf Of G.W. Haywood via clamav-users Sent: 26 September 2019 10:22 To: ClamAV users ML Cc: G.W. Haywood Subject: Re: [clamav-users] OnAccessExcludePath being ignored. Hi there, On Thu, 26 Sep 2019, CROFT Ian wrote: > But when I put an EICAR test txt file in /var/log/test.txt it is getting picked up by the OnAccess scanner. > > I have tried ^/var/log/ and ^/var/log/* - same issue the test.txt is still picked up by the OnAccess scanner when it should in my mind be being ignored. > > Any ideas ? You really do need to get used to reading the 'man' pages. In this case the man page for clamd.conf states OnAccessExcludePath STRING which means that the argument is a STRING, not a REGEX. You must not put things like '^' and '*' in a STRING argument because a STRING is taken literally. You are excluding names which do not exist on your system. -- 73, Ged. ___ 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 Sopra Steria is the trading name of the following companies (all registered in England & Wales): (i) Sopra Steria Limited (No. 04077975) (ii) Sopra Group Ltd (No. 01643041) (iii) Sopra Group Holding Ltd (No. 01588948) ___ 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: [clamav-users] OnAccessExcludePath being ignored.
Op Donderdag, 26-09-2019 om 11:22 schreef G.W. Haywood via clamav-users: > Hi there, > > On Thu, 26 Sep 2019, CROFT Ian wrote: > > > But when I put an EICAR test txt file in /var/log/test.txt it is getting > > picked up by the OnAccess scanner. > > > > I have tried ^/var/log/ and ^/var/log/* - same issue the test.txt is still > > picked up by the OnAccess scanner when it should in my mind be being > > ignored. > > > > Any ideas ? > > You really do need to get used to reading the 'man' pages. > > In this case the man page for clamd.conf states > > OnAccessExcludePath STRING > > which means that the argument is a STRING, not a REGEX. > > You must not put things like '^' and '*' in a STRING argument > because a STRING is taken literally. You are excluding names > which do not exist on your system. While Ian just followed my example (which was wrong apparently), it is kind of confusing in clamd.conf: ExcludePath REGEX OnAccessExcludePath STRING Easy enough to miss ... Franky ___ 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: [clamav-users] RHEL ScanonAccess includepaths
While it is not recommended to scan everything under /var (or /var at all), the reason it fails is because you have /var submounts (/var/log, /var/tmp). This is currently a known bug in clamav (I reported it: https://bugzilla.clamav.net/show_bug.cgi?id=12306 ), and the workaround in your case is: OnAccessIncludePath /var/log OnAccessIncludePath /var/tmp OnAccessIncludePath /var and then, if you don't want /var/log and /var/tmp, add these in the exclude: ExcludePath ^/var/log ExcludePath ^/var/tmp Franky Op Dinsdag, 24-09-2019 om 15:30 schreef CROFT Ian: Hi We have a need to have OnAccessScanning on our RHEL servers but with some path exclusions. So as I read the manuals etc it seems I have to use the OnAccessIncludePath rather than the OnAccessMountPath. So the filesystem layout is as such :- / /boot /home /var /var/log /var/tmp /var/log/audit So I have set up the following IncludePath entries in scan.conf OnAccessIncludePath /boot OnAccessIncludePath /dev OnAccessIncludePath /etc OnAccessIncludePath /home OnAccessIncludePath /opt OnAccessIncludePath /usr OnAccessIncludePath /var When then starting the clamd:scan service all path seem to be ok apart from /var which gave the following error ERROR: ScanOnAccess: Could not watch path ‘/var’, No space left on device. So I increased the number in /proc/sys/fs/inotify/max_user_watches from 8192 to 32768 ( Only 21551 total directories in the whole of the server so should cover it ) So now it doesn’t give me the message about space but gives this message :- ERROR: ScanOnAccess: Could not watch path ‘/var’, Success And is still not monitoring for anything under /var ( eicar test files not being picked up. ) All other paths seem to be working ok. Does anybody know where I am going wrong ? Cheers Ian Ian CROFT Senior Infrastructure Support Analyst Sopra Steria Sopra Steria 101 Dalton Avenue Birchwood Park, Cheshire Warrington WA3 6YF - United Kingdom Phone: 07966 825245 ian.cro...@soprasteria.com - www.soprasteria.co.uk [1] [2] [3] [4] Before printing, think about the environment. The content of this message may be confidential, legally privileged and protected by law. Unauthorized use, copying or disclosure of any of it may be unlawful. If you are not the intended recipient please notify the sender and remove it from your system. While attachments to this e-mail are checked for viruses, we do not accept any liability for any damage sustained by viruses. Sopra Steria is the trading name of the following companies (all registered in England & Wales): (i) Sopra Steria Limited (No. 04077975) (ii) Sopra Group Ltd (No. 01643041) (iii) Sopra Group Holding Ltd (No. 01588948) Links: -- [1] http://www.soprasteria.co.uk [2] https://www.linkedin.com/company/soprasteria [3] https://twitter.com/SopraSteria_uk [4] http://blog.soprasteria.co.uk/ ___ 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: [clamav-users] OnAccess and regular scanning
To be complete: I'm running clamav 0.101.4 on RHEL7 (fully patched) Franky Op Dinsdag, 24-09-2019 om 13:22 schreef Al Varnell via clamav-users: I suspect it will depend on what platform you are running it on. -Al- On Sep 24, 2019, at 04:20, Franky Van Liedekerke via clamav-users wrote: Hi all, currently I have onaccess scanning up and running just fine in clamav. However, some people claim this can be bypassed (so access a file and not force it to be scanned), so I have some questions: - is this true? Can onaccess be bypassed? - if so: can I force a scan of all files that should be protected by onaccess once a week or so? I know clamdscan exists, but you need to provide a folder to it, and via cron it seems too much to scan "/". Or maybe force a scan of all files that should be protected by onaccess but haven't been accessed/scanned yet? With friendly regards, Franky ___ 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] OnAccess and regular scanning
Hi all, currently I have onaccess scanning up and running just fine in clamav. However, some people claim this can be bypassed (so access a file and not force it to be scanned), so I have some questions: - is this true? Can onaccess be bypassed? - if so: can I force a scan of all files that should be protected by onaccess once a week or so? I know clamdscan exists, but you need to provide a folder to it, and via cron it seems too much to scan "/". Or maybe force a scan of all files that should be protected by onaccess but haven't been accessed/scanned yet? With friendly regards, Franky ___ 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: [clamav-users] connect clamscan output to journal with systemd-cat
Do you want the info in journald or just in syslog? Because rsyslog can monitor logfiles directly too. Your call to clamscan from cron might refuse to output info (because no tty perhaps), maybe first try to get logs from clamscan via cron directly? Franky Op Donderdag, 04-04-2019 om 09:46 schreef Kretschmer, Jens: I probably should have mentioned that this was a minimum non-working example, which would _never_ be used on a production system. I thought that that was pretty obvious... The output is actually stored in a separate log file and not with the syslog. If you knew the complete setup, you would agree with my use of systemd-cat. Does anybody have any ideas how I can solve my problem? Best regards, Jens -Original Message- From: Dave Nelson * Sent: Wednesday, April 3, 2019 5:21 PM To: ClamAV users ML Subject: Re: [clamav-users] connect clamscan output to journal with systemd-cat Also, it should be totally unnecessary to scan your filesystem every minute, and will place an unnecessary load on your server. Postfix (or whatever) will run clamav when it needs to. And you can maybe run a full scan on your filesystem once every 24 hours if you feel paranoid. (IMHO.) Postfix will log every detection of an incoming virus, so you can watch that log, too, for a fuller view of what's happening (/var/log/mail.log by default on an Ubuntu system). Dave On 2019-04-03 17:48, Dave Nelson via clamav-users wrote: > You can configure a log specially for clamav, and that should be > plenty. Also, you can install logwatch and get mail updates once a day > or more often. You can also install netdata if you want to monitor in > real time, or simply watch the output of 'tail -f > /var/log/clamav/clamav.log' it's every server admin's pleasure > and duty to watch his/her server's logs roll by in a terminal window > periodically. ;-) Dave > > On 2019-04-03 15:58, SCOTT PACKARD via clamav-users wrote: >> Logfiles are a place where a sysadmin notices a host running smoothly >> (lack of anything in logs) or has problems (error messages about the >> programs show up in the logs). >> >> Looks like you are trying to misuse logfiles as a place to put >> successful/unsuccessful output that's produced by a program. >> >> You'll want to create a separate log for your program, foo.log, and >> write it to /var/log/ directory. >> >> Others can comment about scanning a host every minute. >> >> Regards, Scott >> >> FROM: clamav-users ON BEHALF >> OF Kretschmer, Jens >> SENT: Wednesday, April 03, 2019 1:34 AM >> TO: clamav-users@lists.clamav.net >> SUBJECT: [External] [clamav-users] connect clamscan output to journal >> with systemd-cat >> >> Hi, >> >> I would like to redirect the output of clamscan to the journal, which >> should by possible by >> >> /usr/bin/clamscan -r /root/ 2>&1 | /usr/bin/systemd-cat >> --identifier="clamscan" >> >> or >> >> /usr/bin/systemd-cat --identifier="clamscan" /usr/bin/clamscan -r >> /root/ >> >> While both commands work when executed manually in the terminal, the >> output is not redirected when executed by a cronjob. If I put the >> following line into the file /etc/cron.d/clamav >> >> * * * * * root /usr/bin/systemd-cat --identifier="clamscan" >> /usr/bin/clamscan -r /root/ >> >> I can see that the clamscan process is started every minute, but the >> output is not redirected to the journal. >> >> If I put the line >> >> * * * * * root /usr/bin/systemd-cat --identifier="clamscan" ls /root/ >> >> Into the file /etc/cron.d/clamav, it is executed every minute as well >> and I can see the output of ls in the journal. >> >> Do you have any idea what could be causing the issue? >> >> Best regards, >> Jens >> >> ___ >> >> 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 > > -- > With all best wishes, > Dave > > ___ > > 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 -- With all best wishes, Dave ___ 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
Re: [clamav-users] rpm files question [was: ClamAV 0.101.2 announcement?]
If you want the version to appear in EL7 stable, go to https://apps.fedoraproject.org/packages/clamav/ and add karma. Franky Op Vrijdag, 29-03-2019 om 19:01 schreef G.W. Haywood via clamav-users: Hi there, On Fri, 29 Mar 2019, Micah Snyder wrote: > This won't help you right now, but our team has been discussing > publishing ClamAV on Linux using Snapcraft at the time of each > release. Snapcraft sounds like it may be a good option to make > ClamAV accessible faster. Would you, and others here, be interested > in installing a ClamAV snap in the future? Not if it wants me to install systemd... laptop3:~# >>> cat /etc/debian_version 9.8 laptop3:~# >>> apt-get install snapd Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: snapd : Depends: systemd ... -- 73, Ged. ___ 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: [clamav-users] Database updated over unencrypted connection?
I'm sorry if I lead you to believe that I don't know development costs time. I'm a developer myself and contributed to lots of open source projects in the past (openldap, mail, squid, nroe, zabbix, ooenmoko and others). I just can't contribute to every project and currently I am happy with the promised https support in a future version (and with the http support now). Franky - Oorspronkelijk bericht - Van: Leonardo Rodrigues Aan: clamav-users@lists.clamav.net Verzonden: Fri, 15 Mar 2019 19:56:14 +0100 (CET) Onderwerp: Re: [clamav-users] Database updated over unencrypted connection? Em 15/03/2019 14:39, G.W. Haywood via clamav-users escreveu: > Hi there, > > On Fri, 15 Mar 2019, Franky Van Liedekerkewrote: > >> Certifcates cost nothing ... > > CPU cycles don't. > developers time do cost their ... time, basically. How about contributing with the code instead of blaming ? That would be useful. Discussing about http x https, believing that http is always insecure, is useless. -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it ___ 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: [clamav-users] Database updated over unencrypted connection?
Op Vrijdag, 15-03-2019 om 16:04 schreef instaham--- via clamav-users: > Leonardo Rodrigues wrote: > > the databases are digitally signed, and any modification, such in > > a man-in-the-middle attack, would break the signature and freshclam > > would refuse to run the files. > > Sounds good. Can you please explain how this works in detail? > > Apt places GPG keys in the system and uses them to verify downloaded > data. > > It doesn't seem that ClamAV placed any GPG keys in my system. So how is > the verification happening? > I wonder why the http/https discussion is still relevant. Almost all sites use https now, http is getting slowly banned and a lot of companies just don't want to allow incoming http traffic towards a server. Certifcates cost nothing anymore (you have free ones), so that's no longer an issue too. And the cpu issue might've been relevant years ago, but it shouldn't be now (offloading https to a high-performant frontend server can help if you really have issues). Just my 2 cents here ... Franky ___ 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] onaccess scanning and selinux
When using onaccess scanning together with selinux, it seems these 2 are not sufficient: setsebool -P antivirus_can_scan_system 1 setsebool -P clamd_use_jit 1 Onaccess scanning will still fail to initialize (at least when launched via systemd). Currently I added this: semanage permissive -a antivirus_t But I presume that's in fact a little too much. There's no real doc found at clamav concerning selinux either, so could someone shed a light on this? Franky ___ 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] ScanOnAccess: ... (null) FOUND
Hi, I seem to be encountering the same issue someone described here: https://www.mail-archive.com/clamav-users@lists.clamav.net/msg46022.html For me the null-message arrived when switching to root: ScanOnAccess: /root/.bash_history: (null) FOUND I'm running on RHEL7 server, latest updates with versions: clamd-0.101.1-1.el7.x86_64 The accompanying files (coming from clamav-data rpm): -rw-r--r--. 1 clamupdate clamupdate199693 Jan 10 06:14 bytecode.cvd -rw-r--r--. 1 clamupdate clamupdate 53834626 Jan 10 06:14 daily.cvd -rw-r--r--. 1 clamupdate clamupdate 117892267 Jan 9 2018 main.cvd It seems the main.cvd is old, but I haven't run freshclam against this yet. Could that be the reason? Since it is an internal server, I first need to setup a proxy etc ... for freshclam to work. With friendly regards, Franky ___ 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
