Hi there,
On Wed, 7 Apr 2021, Sorin Petrut Niculae via clamav-users wrote:
A couple of things that I forgot to mentioned:
1. I cannot upgrade the system, I know that this version of rhel is
EoL but is impossible to upgrade it due too client policy.
Tell the client he's fired? :)
2. Is a offline system, is impossible to connect it to internet
due to client policy. ...
Does client policy state, under these circumstances, what are the
threats against which ClamAV is expected to protect?
So the questions are:
1. I need to do something special when I download the DDBB manually
and copy it on the clamav folder ?
As far as possible manual downloads should be restricted to testing.
There's nothing special about downloading, except that there may be
restrictions imposed because of ongoing abuse of the download servers
- so you need to use one of the two documented methods to fetch the
database (or you risk your IP being blocked by Cloudflare). In any
case you can't expect manual efforts to be as reliable as this kind of
thing needs to be. Perhaps you should be looking at
https://www.clamav.net/documents/private-local-mirrors
which specifically mentions for example the case of a scanner which is
not permitted Internet access and the permitted download methods.
2. The DDBB is the same for both architecture x32 and x64 or is
different ?
Exactly the same. The databases are identical for all architectures,
and in them there are signatures for threats to all architectures. Of
course the ClamaV code must be built separately for each architecture
on which it will run. That may be done by the ClamAV team (for a few
architectures) in which case there will be binaries available that you
can download, although for less mainstream architectures you may need
either to build it yourself or to find/get it built elsewhere. In the
latter cases you may need to be cautious; criminals will often try to
get you to install their own doctored versions of well-known software.
3. Which can be the source of the error "Malformed database" ?
$ grep -r -C1 'Malformed database' ./clamav-0.103.1 | grep -v 'Binary file'
--
libclamav/others.c- case CL_EMALFDB:
libclamav/others.c: return "Malformed database";
libclamav/others.c- case CL_ECVD:
That message appears in one place in the ClamAV code, it associates a
text string with the CL_EMALFDB flag which is used internally. Most of
the occurrences of this flag are in statements like
return CL_EMALFDB;
Which means that a section of the code has deduced that the database
is malformed and cannot be used. To count the number of occurrences
of this flag:
$ grep -r 'CL_EMALFDB' ~/clamav-0.103.1 | grep -v 'Binary file' | wc -l
288
There are almost three hundred places in the code which might give
rise to that error. More information would be needed to be able to
narrow it down. Knowing which of the ClamAV tools produces it, how
exactly it was persuaded to do that, and exactly what databases were
in use at the time would be a good start.
Here are the 'sigtool' test results on my local databases today:
$ sigtool -i /EXPORTS/clamav/databases/main.cvd
File: /EXPORTS/clamav/databases/main.cvd
Build time: 25 Nov 2019 08:56 -0500
Version: 59
Signatures: 4564902
Functionality level: 60
Builder: sigmgr
MD5: af6f9a95b19fcce8be2c84bde73b5db6
Digital signature:
VeNZg/gIMosAkDvAv5U4IezNpJzBILxyOIbrsmFVrQRpFEULdbLbRK1csHyDHu9nTzNOwX7fiDiZkM7eOoaF91JNtL0Hju3SHrzWzY0K6nV6NV2+y+RohIpjvHJDx98ViAuCou/b2O7ryjD1u31jhBwwckGU+DwdIzmjXNJu3Jb
Verification OK.
$ sigtool -i /EXPORTS/clamav/databases/daily.cld
File: /EXPORTS/clamav/databases/daily.cld
Build time: 06 Apr 2021 07:06 -0400
Version: 26132
Signatures: 3968913
Functionality level: 63
Builder: raynman
Verification OK.
$ sigtool -i /EXPORTS/clamav/databases/bytecode.cld
File: /EXPORTS/clamav/databases/bytecode.cld
Build time: 08 Mar 2021 10:21 -0500
Version: 333
Signatures: 92
Functionality level: 63
Builder: awillia2
Verification OK.
A very quick and easy check to test that the databases which you're
using are properly installed is running 'md5sum' on them. Here are
the three values here today for three primary ('official') databases:
ged@pi4b530214:/EXPORTS/clamav/databases $ md5sum main.cvd daily.cld bytecode.cld
0fdc6dc2135ebeb8289cca7bd6a69c43 main.cvd
61cd5237377bd670c91c1afcf94b2c51 daily.cld
bbdce24385bd4d715fc2d81d156ae0bb bytecode.cld
Note that the md5sum produced on the raw file is not the same as that
produced by sigtool. Obviously sigtools is looking at something else,
I don't know what nor why.
As you can see, only one of the official database files changes often:
pi4b:/EXPORTS/clamav/databases $ l main.cvd daily.cld bytecode.cld
-rw-r--r-- 1 clamav clamav 117859675 Feb 5 2020 main.cvd
-rw-r--r-- 1 clamav clamav 1438720 Mar 8 18:57 bytecode.cld
-rw-r--r-- 1 clamav clamav 321211904 Apr 6 14:46 daily.cld
Can you confirm that you have these files, that they're in the right
places for your system, and that they look similar?
--
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
