FWIW, if I may offer opinion: I would agree with Alex with the need to
source out better unofficial databases (such as sanesecurity,
securiteinfo etc): clam definitions are inherently slow on the uptake
of new threats, taking a day or more (at best) and in some cases never
(ive demonstrated this in other posts on this mail list). (I dont know
if I am breaking a rule here by advertising - apologies if so but I am
not affiliated in any way) sanesecurity definitions have proven
invaluable and EXTREMELY responsive regarding zero-hour threats
especially to the crytolocker and DOC-macro based threats (REALLY being
'zero hour' coverage by definition). (In my opinion. I also believe
that they the ONLY way you can use ClamAv is if you employ 3rd party
definitions given that most threats are at its highest danger level just
hours after release and its simply unproductive releasing signatures to
catch them days later (or never!). Clam always needs supplementing with
either 3rd party definitions (which Alex has), another realtime scanning
commercial Av product (which Alex has), or both (which Alex has).
I can bery well imagine, though that 9 million definitions are excessive
and probably over 70% have no point in existing any more (threat
probably been and gone).
Alex, I use standard defs and sane only (to cut down on definitions) and
have excellent coverage without the slow 'startup times' that you have
mentioned whilst being backed up with Bitdefender on the client PC's.
Might be worth changing your signatures if they are increasing your
start time without adding any noticeable benefit (or at least
experiemnting to see if it makes a difference. You can always revert
back to your current choice....and your " ' ' response " error. ;-)
Jim
On 22/02/2016 15:08, Alex wrote:
Hi,
Can’t be of much help with your primary issue, but to answer one or your
questions, the official ClamAV database is a bit over 4 million. I can’t
conceive of a situation where you would need every conceivable unofficial
database, but then I have no idea what you are doing with your setup, other
than it would appear to have some relationship to e-mail service.
It comes from complaints from users about zero-day and cryptowall
viruses making it through the mail gateway, then being caught by
Symantec as it reaches Exchange. Or a compromise being traced back to
not having caught a virus a few hours earlier.
There was a discussion less than a month ago concerning minimum essential
database subscriptions, so
suggest you search around in the archive for that thread
<clamav-user archives>.
I'll search around, thanks.
Assistance with my other issues would still very much be appreciated.
Thanks,
Alex
-Al-
On Sun, Feb 21, 2016 at 03:40 PM, Alex wrote:
Hi,
I have a clamav-0.99-2 installation on fedora23 and periodically I
receive a message when running clamav-notify-servers after having run
freshclam that reports:
# clamav-notify-servers
clamd server '/var/run/clamd.amavisd/clamd.sock' gave '' response
I have a script that periodically rsyncs the malwarepatrol db to the
/var/lib/clamav directory then runs the clamav-notify-servers. I
believe the problem is related to this occurring at the same time as
the regular freshclam-sleep script running clamav-notify-servers.
Is this the intended behavior for clamd?
I have about 9M signatures now, so it appears to take a long time to
reload the database every time the clamav-notify-servers signal is
sent.
Can someone provide some advice on the best way to do this? I don't
think I can control the timing of the clamav-notify-servers to make
sure it doesn't happen while another instance occurs. Should I just
redirect the output to /dev/null?
Is it common to have 9M entries?
It looks to take about 30s to reload the database:
Feb 21 03:22:15 mail03 clamd[1006]: Reading databases from /var/lib/clamav
Feb 21 03:22:46 mail03 clamd[1006]: Database correctly reloaded
(8888331 signatures)
Feb 21 03:22:46 mail03 clamd[1006]: Client disconnected (FD 23)
This is on a six-core 3Ghz system on SSD disks.
[root@mail03 clamav]# ls
badmacro.ndb foxhole_filename.cdb phishtank.ndb
spamattach.hdb
blurl.ndb foxhole_generic.cdb porcupine.hsb
spamimg.hdb
bofhland_cracked_URL.ndb hackingteam.hsb porcupine.ndb
spam.ldb
bofhland_malware_attach.hdb javascript.ndb rogue.hdb
spearl.ndb
bofhland_malware_URL.ndb junk.ndb safebrowsing.cvd
spear.ndb
bofhland_phishing_URL.ndb jurlbla.ndb sanesecurity.ftm
winnow.attachments.hdb
my_sigwhitelist.gdb jurlbl.ndb scamnailer.ndb
winnow_bad_cw.hdb
my_sigwhitelist.ign2 lott.ndb scam.ndb
winnow.complex.patterns.ldb
my_sigwhitelist.wdb main.cvd
securiteinfoascii.hdb winnow_extended_malware.hdb
bytecode.cld malwarehash.hsb securiteinfo.hdb
winnow_malware.hdb
crdfam.clamav.hdb malwarepatrol.ndb
securiteinfohtml.hdb winnow_malware_links.ndb
create_sig.txt mirrors.dat securiteinfo.ign2
winnow_phish_complete_url.ndb
daily.cld phish.ndb sigwhitelist.ign2
winnow_spam_complete.ndb
I think the commercial securiteinfo databases are entirely too large
and don't perform very well.
Of course I could cut down on the databases, but I'm more interested
in finding out why clamd produces the error message when multiple
signals are sent.
Thanks,
Alex
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
