[ZendTo] ClamAV fail

Jules Field Jules at Zend.To
Thu Jul 26 16:13:18 BST 2018


Derek,

On 26/07/2018 16:07, Pedrosi, Derek G. wrote:
>
> Jules,
>
> I’m the only one with ANY access to this system (other than web), and 
> I was on vacation.
>
Hence my suggestion of some*thing*.
Such as your cron daemon, which appears to have been installing updates 
(they might well have been tagged as security updates, so got 
automatically installed).

Having read your lines below, have you tried this bit I suggested in my 
original reply to you?

If you want to test it by hand, you need to do this:
Edit the /etc/passwd file and give your apache or www-data user a real 
shell such as /bin/bash.
"pwconv" (that makes the /etc/shadow file).
"su - apache" (or "su - www-data") to properly become the web server user.
clamdscan /var/zendto/*
clamdscan --fdpass /var/zendto/*

What does that lot output?

You not only need to get the location of the LocalSocket correct enough 
for clamd to start and clamdscan to talk to it, but freshclam.conf needs 
to know where it is too, or else freshclam can't tell clamd that its 
signatures have been updated and hence needs to restart itself.

Cheers,
Jules.
>
> Nevertheless, I’ve comment out the stats lines in clamd.conf and then 
> I received this error.
>
> root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php
>
> ERROR: Could not connect to clamd on LocalSocket 
> /var/run/clamav/clamd.ctl: No such file or directory
>
> ----------- SCAN SUMMARY -----------
>
> Infected files: 0
>
> Total errors: 1
>
> Time: 0.000 sec (0 m 0 s)
>
> Likewise in ZendTo the log shows…
>
> Error: Virus scan of dropped-off files  /var/zendto/incoming/phpSAkd0U 
> for dgpedrosi failed with ERROR: Could not connect to clamd on 
> LocalSocket /var/run/clamav/clamd.ctl: No such file or directory 
> ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 
> Time: 0.000 sec (0 m 0 s)
>
> Then from clamd.conf I commented out these lines
>
> #LocalSocket /var/run/clamav/clamd.ctl
>
> #FixStaleSocket true
>
> And now I can run a command line scan without error:
>
> root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php
>
> ----------- SCAN SUMMARY -----------
>
> Infected files: 0
>
> Total errors: 1
>
> Time: 0.000 sec (0 m 0 s)
>
> root at ZendTo5:/opt/zendto/config#
>
> But ZendTo will still not AV scan, from the ZendTo log:
>
> Error: Virus scan of dropped-off files  /var/zendto/incoming/phpcz1Ojf 
> for dgpedrosi failed with  ----------- SCAN SUMMARY ----------- 
> Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s)
>
> Also, I’m running Ubuntu 16.04.4 LTS no clamd service to be found:
>
> root at ZendTo5:/opt/zendto/config# service --status-all
>
> [ + ]  acpid
>
> [ + ]  apache-htcacheclean
>
> [ + ]  apache2
>
> [ + ]  apparmor
>
> [ + ]  apport
>
> [ + ]  atd
>
> [ - ]  bootmisc.sh
>
> [ - ]  checkfs.sh
>
> [ - ]  checkroot-bootclean.sh
>
> [ - ]  checkroot.sh
>
> [ - ]  clamav-daemon
>
> [ + ]  clamav-freshclam
>
> [ + ]  console-setup
>
> [ + ]  cron
>
> But I did reboot the server, and I’m still seeing the issue.
>
> ???
>
> *From:*Jules Field [mailto:Jules at Zend.To]
> *Sent:* Thursday, July 26, 2018 10:27 AM
> *To:* Pedrosi, Derek G. <pedrosi at millercanfield.com>; ZendTo Users 
> <zendto at zend.to>
> *Subject:* Re: [ZendTo] ClamAV fail
>
> Derek,
>
> On 26/07/2018 14:50, Pedrosi, Derek G. wrote:
>
>     This is my production server, and no changes were made;
>
> Ah, the famous "But I didn't change anything" defence. :-) :-)
>
>     it just started throwing the error.
>
> Ah, but changes *were* made. Just possibly not by you. :-)
> Someone (or more likely some*thing*) did a "yum upgrade" or an "apt 
> upgrade", and replaced the copy of ClamAV that was running.
> You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? 
> That was modified yesterday morning, which is probably shortly before 
> it all stopped working.
>
> From your /etc/clamav/clamd.conf file, based on the output from 
> "clamdscan" below, you should remove the lines that start 
> "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd 
> service ("service clamd restart" will *probably* do the trick on 
> almost any Linux variant). Then try that clamdscan command again and 
> see if it gets further.
>
> Cheers,
> Jules.
>
>
>     Running clamdscan:
>
>     root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout
>     preferences.php
>
>     WARNING: Ignoring deprecated option AllowSupplementaryGroups at
>     line 11
>
>     ERROR: Parse error at line 79: Unknown option StatsEnabled
>
>     ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf
>
>     root at ZendTo5:/opt/zendto/config# clamscan --version
>
>     ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018
>
>     root at ZendTo5:/opt/zendto/config# nano  /etc/clamav/clamd.conf
>
>     root at ZendTo5:/opt/zendto/config# ls  /etc/clamav -la
>
>     total 36
>
>     drwxr-xr-x  5 root root 4096 Jul 26 09:49 .
>
>     drwxr-xr-x 94 root root 4096 Jul 25 06:06 ..
>
>     -rw-r--r--  1 root root 2059 Mar  5 10:19 clamd.conf
>
>     -rw-r--r--  1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist
>
>     -rw-r--r--  1 root root 2060 Mar  5 10:19 clamd.conf.zendto
>
>     -r--r--r--  1 clamav adm   702 Jul 25 06:06 freshclam.conf
>
>     drwxr-xr-x  2 root root 4096 Jan 29 11:14 onerrorexecute.d
>
>     drwxr-xr-x  2 root root 4096 Jan 29 11:14 onupdateexecute.d
>
>     drwxr-xr-x  2 root root 4096 Jan 29 11:14 virusevent.d
>
>     derek
>
>     *From:*ZendTo [mailto:zendto-bounces at zend.to] *On Behalf Of *Jules
>     Field via ZendTo
>     *Sent:* Wednesday, July 25, 2018 12:26 PM
>     *To:* Pedrosi, Derek G. via ZendTo <zendto at zend.to>
>     <mailto:zendto at zend.to>; ZendTo Users <zendto at zend.to>
>     <mailto:zendto at zend.to>
>     *Cc:* Jules Field <Jules at Zend.To> <mailto:Jules at Zend.To>
>     *Subject:* Re: [ZendTo] ClamAV fail
>
>     Derek,
>
>     Testing it with "clamscan" won't help. It's "clamdscan" that has
>     to work, which is a very different beast.
>     "clamscan" just does it all at once (which is why it takes so long).
>     "clamdscan" uses the "clamd" process to actually do the scanning,
>     and hence is much faster as there's no startup time while it loads
>     and compiles all the virus signatures.
>
>     If it works with a small text file, but not an archive or docx
>     file, then you've probably run out of disk space in wherever clamd
>     is trying to unpack the archive.
>
>     Otherwise, it is almost always permissions/ownership problems.
>     You shouldn't do any harm by fetching a new copy of the ZendTo
>     installer and *just* doing the "Setup ClamAV" section.
>
>     If you want to test it by hand, you need to do this:
>     Edit the /etc/passwd file and give your apache or www-data user a
>     real shell such as /bin/bash.
>     "pwconv" (that makes the /etc/shadow file).
>     "su - apache" (or "su - www-data") to properly become the web
>     server user.
>     clamdscan /var/zendto/*
>     clamdscan --fdpass /var/zendto/*
>
>     If both of those succeed, then start a big upload going in ZendTo.
>     This will force some data (with the right permissions) into
>     /var/zendto/incoming. While it's running, do "clamdscan
>     /var/zendto/incoming/*" and "clamdscan --fdpass
>     /var/zendto/incoming/*".
>
>     By the time you've done all that lot, you've probably got some
>     errors from ClamAV which will help narrow down the cause.
>
>     When you've fixed it, remember to put your "/etc/passwd" file back
>     so the shell says "/sbin/nologin" and run the "pwconv" command again.
>
>     Hope that helps,
>     Jules.
>
>
>     On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote:
>
>         Suddenly, my drops are no longer being scanned by AV and users
>         were unable to drop files.  No changes were made.
>
>         User see this…
>
>         *Upload Error*
>
>
>         	
>
>         *The attempt to virus-scan your drop-off failed. Please notify
>         the system administrator.*
>
>         I’ve since disable AV scan from the preferences.php (it was
>         'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and
>         now users can drop files.
>
>         The details…
>
>         From ZendTo log…
>
>         2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of
>         dropped-off files /var/zendto/incoming/phpLfUrV9
>         /var/zendto/incoming/phpf6ExDv for USER failed with
>
>         From the /var/log/clamav dir:
>
>         root at ZendTo5:/var/log/clamav# tail freshclam.log
>
>         Wed Jul 25 11:02:09 2018 -> --------------------------------------
>
>         Wed Jul 25 11:44:24 2018 -> Update process terminated
>
>         Wed Jul 25 11:44:25 2018 -> --------------------------------------
>
>         Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS:
>         linux-gnu, ARCH: x86_64, CPU: x86_64)
>
>         Wed Jul 25 11:44:25 2018 -> ClamAV update process started at
>         Wed Jul 25 11:44:25 2018
>
>         Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version:
>         58, sigs: 4566249, f-level: 60, builder: sigmgr)
>
>         Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version:
>         24781, sigs: 2024541, f-level: 63, builder: neo)
>
>         Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date
>         (version: 325, sigs: 90, f-level: 63, builder: neo)
>
>         Wed Jul 25 11:44:25 2018 -> --------------------------------------
>
>         root at ZendTo5:/var/log/clamav# tail clamav.log
>
>         Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK.
>
>         Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK.
>
>         Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK.
>
>         Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK.
>
>         Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav
>
>         Wed Jul 25 05:27:27 2018 -> Database correctly reloaded
>         (6584590 signatures)
>
>         Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK.
>
>         Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK.
>
>         Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK.
>
>         Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55
>         2018
>
>         Now, I can scan files manually via the command line…
>
>         clamscan --verbose  /var/log/
>
>         ----------- SCAN SUMMARY -----------
>
>         Known viruses: 6584590
>
>         Engine version: 0.100.1
>
>         Scanned directories: 1
>
>         Scanned files: 43
>
>         Infected files: 0
>
>         Data scanned: 8.88 MB
>
>         Data read: 1.75 MB (ratio 5.07:1)
>
>         Time: 19.976 sec (0 m 19 s)
>
>         Anywhere else to look?
>
>         derek
>
>
>
>
>
>         _______________________________________________
>
>         ZendTo mailing list
>
>         ZendTo at zend.to <mailto:ZendTo at zend.to>
>
>         http://jul.es/mailman/listinfo/zendto
>
>
>
>
>     Jules
>
>       
>
>     -- 
>
>     Julian Field MEng CEng CITP MBCS MIEEE MACM
>
>       
>
>     Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate,
>
>     becoming rough in west. Rain later. Good, occasionally poor.
>
>       
>
>     www.Zend.To <http://www.Zend.To>
>
>     Twitter: @JulesFM
>
>     PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
>
>
>
> Jules
> -- 
> Julian Field MEng CEng CITP MBCS MIEEE MACM
> 'Ensanguining the skies
>   How heavily it dies
>   Into the west away;
>   Past touch and sight and sound
>   Not further to be found,
>   How hopeless under ground
>     Falls the remorseful day.' - A.E.Houseman
> www.Zend.To <http://www.Zend.To>
> Twitter: @JulesFM
> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654

Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

'We face neither East nor West: we face forward.' - Kwame Nkrumah

www.Zend.To
Twitter: @JulesFM
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20180726/360a12a3/attachment-0001.html>


More information about the ZendTo mailing list