Hello,

I decided to give dazuko a try this eavening.
Followed the instruction from the wikki: https://www.atomicorp.com/wiki/index.php/Anti_virus

I created the include and exclude folders & everything seemed to be working fine.
I then tested a few sites to see if there might be any issues.

Right away i started getting white screens on all the Joomla! hosted sites.
I found in /var/og/messages the following errors/rules

Here are just a few of the MalwareBlocklist (there are alot more)

Mar 24 23:37:24 sa1 clamd[1658]: Clamuko: /var/www/vhosts/xxxxx/httpdocs/plugins/system/cachecleaner.php: Atomicorp.MalwareBlocklist.nonumber.nl.UNOFFICIAL FOUND
Mar 24 23:37:25 sa1 clamd[1658]: Clamuko: /var/www/vhosts/xxxxx/httpdocs/plugins/system/cachecleaner.php: Atomicorp.MalwareBlocklist.nonumber.nl.UNOFFICIAL FOUND
Mar 24 23:37:26 sa1 clamd[1658]: Clamuko: /var/www/vhosts/xxxxx/httpdocs/plugins/system/cachecleaner.php: Atomicorp.MalwareBlocklist.nonumber.nl.UNOFFICIAL FOUND
Mar 24 23:37:29 sa1 clamd[1658]: Clamuko: /var/www/vhosts/xxxxx/httpdocs/plugins/system/cachecleaner.php: Atomicorp.MalwareBlocklist.nonumber.nl.UNOFFICIAL FOUND

I know the developer personally (Peter van Westen nonumber.nl) and over 90 Joomla! sites hosted with me use his extensions. I have alerted him to the errors and will also refer him to this post.

Any information will be greatly appreciated.

You might want to check to make sure your signatures are up to date, that domain is not part of the blocklists. The domain was added around the 20th, and removed the same day. It looks like some exploit engine was using that domain as an RFI destination. The attacker ironically was probing for the "NoNumber Framework Joomla! Plugin" file include vulnerability, and it looked something like this:

index.php?nn_qp=1&url=http://nonumber.nl

So RFI they were using was the nonumber.nl domain. Its strange that they would do that, as the payload was just to try and find the vulnerable scripts, so it may have just been some method for probing. We added new rules for this probe the same day as well. The honeypots havent seen it since the 20th so it only looks like they did for a day and the honeypots auto-removed it accordingly from the rules the same day.

Anyway, just make sure your rules are up to date and you should be good to go.

Thanks mikeshinn.

I re-loaded and re-started and everything seems to be working perfectly.

When dazuko finds and "offending" script is it normal to block the entire site from running?

Today a site running an old version of Jomsocial was blocked
*/components/com_community/libraries/videos.php: Atomicorp.PHP.Suspicious.shell_exec.20110103163901.UNOFFICIAL FOUND

I was unable to login to the admin - I kept on getting a 500 error

When I try to vi file as root, I get "videos.php" [Permission Denied]

I was however still able to access the frontend of the site.

The only way to get access to the backend was to add the httpdocs directory of the site to the /etc/asl/dazuko-exclude file.

Thank you for the question. The kernel module, dazuko, will prevent whatever action(s) it is configured to prevent. If you look at your ASL configuration you will see these options:

CLAMAV_SCANONOPEN
CLAMAV_SCANONCLOSE
CLAMAV_SCANONEXEC

These are also documented in the GUI for each option if you want to know more, but in short, open means to block a file from being opened (if it matches a signature), close means to block the file from being closed (written) and exec when to block its execution (which is different from open). The later only applies to an application when it executes, as in a binary, so things like PHP scripts would not fall into this category. PHP scripts do not execute, they are read like any other file by the web server and interpreted by the PHP module(s) you have configured in the web server to read and do something with them.

So assuming you have CLAMAV_SCANONOPEN set to "yes" then the kernel will not allow a file that is found to match a signature to be read. As to what effect this has on a site, thats hard to say, it depends on the code for the site. The kernel has no control over a site, just files. So its possible that a website may depend on a single file to work correctly and that blocking could prevent some or all of an application from running. It depends on the web sites design and code.