COnfiguring ClamAV on CentOS 7

I have installed and configured ClamAV on a CentOS 7 server and then activated ClamAV scanning in Filecloud, but I can’t determine whether it is actually scanning anything. An upload of the EICAR file did not trigger an alert.

Has anyone used CentOS 7/ClamAV/Filecloud and can give me a clue on whether I have it set up correctly. The Filecloud documentation is for an Ubuntu setup which is rather different to CentOS.

Cheers

Michael Lightfoot
Delivery Engineer
Sliced Tech

@michael

Please navigate to Admin Portal > Settings > Third Party Integrations > Anti Virus > Clam AV tab, then click on the ClamAV Test button and let us know the result.

Yes, I did all that and it tested as “connected”. That doesn’t tell me whether scanning is actually working, just that Filecloud is connected to ClamAV on port 3310.

So the corollary to my question is whether I can look at logs anywhere that will tell me if scanning is actually happening.

Cheers

Michael

Hello @michael

Please change the server log level to DEV from Admin Portal > Settings > Server tab > " Log Level " option.

After changing the log level, please check the logs present in the location " /var/www/html/scratch/logs/ " whether the files are getting scanned by ClamAV.

Thanks Anand.

I was concerned because an upload of the EICAR file wasn’t detected and nothing has appeared in the Audit Logs reports for either “Virus Removed” or “No Virus Found”.

The log is now showing:

# tail -f log_2021-05-26.txt|grep -i ClamAV
2021-05-27 8:53:35.971103 DEBUG: processBackgroundJobs : Getting class CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback
2021-05-27 8:53:36.020836 DEBUG: BACKGROUND : [56817][PARALLEL] Calling : CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback:onEvent
2021-05-27 8:53:36.024973 DEBUG: SKIPPING CLAMAV Callback because this is not an UPLOAD FILE event

so it appears at least the Callback is happening.

I’ll get the customer to try an upload again.

Cheers

Michael

I just got this:

2021-05-27 9:00:20.440193 DEBUG: processBackgroundJobs : Getting class CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback
2021-05-27 9:00:20.455764 DEBUG: BACKGROUND : [43246][PARALLEL] Calling : CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback:onEvent
2021-05-27 9:00:20.460033 DEBUG: CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback::onEvent Event: ADDFILE

Does this show that a file was scanned?

Cheers

Michael

I can confirm that Filecloud ClamAV scanning is not detecting the EICAR file. It is logging the upload as an ADDFILE event but not finding any problem with that file:
2021-05-28 10:07:37.093840 DEBUG: processBackgroundJobs : Getting class CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback
2021-05-28 10:07:37.109099 DEBUG: BACKGROUND : [56817][PARALLEL] Calling : CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback:onEven t
2021-05-28 10:07:37.124071 DEBUG: CodeLathe\Core\Subsystem\Integration\AV\ClamAV\ClamAVCallback::onEvent Event: ADDFILE

If I run sigtool it finds the EICAR signature in the database which should be triggering the appropriate reaction.
This is all on CentOS 7 which (like RHEL) uses a packaged installation of ClamAV. Is it possible that even though Filecloud is reporting a successful connection to clamd it isn’t actually doing anything useful?

Cheers

Michael

Hello @michael

Thank you for your time and patience with this.

Please try the below test file and let us know how it goes.

http://www.eicar.org/download/eicar_com.zip

Solved!

The solution was to have a non-zero number for the maximum file size in the scanning configuration. My incorrect assumption was that 0 meant unlimited as it does in most other cases. Setting it to 2GB has resulted in the EICAR file being detected as both itself and within a zip archive.

Thanks for your help.

Cheers

Michael Lightfoot
Delivery Engineer
Sliced Tech

Hello @michael

We are happy to hear that the issue has been resolved.