Drupal ClamAV module vs maldet to eliminate malware in uploaded files

Kubernetes are getting a lot of attention these days. When it comes to large projects and teams, it is a no-brainer choice – allowing to streamline testing and deployments.

When Kebernetes are combined with the Lagoon (by Amazee), it offers an inspiring hosting setup, allowing to run Docker containers in various Linux OS (and natively on MacOS, which is a very anticipated feature by many web developers). When development and testing are over, the same containers then moved to the production environment. Amazee offers a set of pre-built containers that are tailored for running Drupal CMS and they work simply great. Their documentation knowledgebase is an awesome collection of well written how-to articles.

What seems to be missing at the moment in the Amazee’s Kubernetes/OpenShift/Lagoon setup, is the ability to scan any uploaded files for virus and malware signatures. The good news are that there is the Drupal ClamAV module available. The ‘clamav’ package could be easily added to your containers.

In this article, I review the Drupal ClamAV module, along with an alternative way of scanning file uploads for Kubernetes and Docker by Maldet and ClamAV.

How to protect file uploads against virus and malware in Drupal

It is not a rocket science to integrate the Drupal ClamAV module, ClamAV and file upload fields in Drupal. The idea behind such integration is simple: users of the site upload files and every such uploaded file is scanned for virus/malware signatures so that the site is virus-free and malware-free.

Why Drupal ClamAV module is limited in protecting file uploads

The use case of Drupal ClamAV module could be somewhat limited, particularly in the way that it only scans files that are uploaded by the trusted users only, ignoring vulnerability exploitation via a web server, PHP binaries and a whole lot of other things. For the sake of this article, I assume it does not matter what vulnerabilities are exploited, how and where, whether we understand this or not. It is always a surprise to realise, as the new vulnerabilities are announced, to be found in unexpected places – software packages or even in hardware.

From my experience battling viruses and malware in production servers, a far better approach would be to ensure that any file – that is getting saved or updated – are getting scanned, regardless of how that file is getting into server’s file system. Such approach offers a much higher level of confidence and avoids configuration gaps (ahh…, we forgot to add our upload scanner configuration here – or there).

One of good ways to protect your production site in Kubernetes could be to create an additional Docker container. It would run the ClamAV in the daemon mode, with the Maldet package, running along together. This additional container would be scanning project files 100% of the time. Based on your cluster setup, this may not always be the best solution though, see the Using maldet or ClamAV with Docker containers section below.

How to protect all file uploads on your server globally

One of the great pieces of software that I came across in the past, was the Malware Detect, or “Maldet”, by the R-fx Networks. It runs as a tiny daemon and is capable of monitoring file paths or users, for any file activities (such as opening, saving and updating files). It connects to the clamd socket, if it is available, allowing to involve ClamAV in file scanning. I have explained in greater details of how to protect servers with maldet, in my blog post Securing your server with maldet.

Comparing Drupal ClamAV module with global malware scanning

When comparing the file uploads scanning, that is only available to the trusted users of your site, versus scanning of every file that is getting saved into the server’s file system – the benefits of the later sound obvious.

Using Maldet or ClamAV with Docker containers

There are some use cases, where using the Maldet (in a dedicated container) with Kubernetes may not be the best use case. When it comes to Lagoon, every branch that is pushed to the project’s Git repository becomes a hosting environment. This is great, but it also means that the Maldet and ClamAV container will be up, consuming cluster CPU resources. It may still be okay, but large deployments may lead to memory exhaustion easily, due to lots of ClamAV/Maldet containers running around. When running Maldet with ClamAV in a dedicated Docker container is a concern, the Drupal ClamAV module may be a good alternative (using the ClamAV in the executable mode).

Let’s review some Pros and Cons of both approaches.

Pros and cons of using Drupal ClamAV module

Pros:

1. Drupal ClamAV is simple to setup (activate a module), assuming ClamAV packages are installed and configured.
2. Drupal watchdog reporting is available on file scans or file blocks.
3. Clean messages are displayed to the user – whether the file gets blocked or not, a nicely formatted drupal message appears to the end user.

Cons:

1. Memory and CPU consumption may be high, comparable to the web server and PHP process running in a single Kubernetes pod. Under some conditions, it may put the uptime of a container at risk, where PHP, Nginx, ClamAV are battling for some free RAM. The end user impact – slow page loading (while containers are being continuously killed and rebuilt).
2. Running the ClamAV as executable has a performance impact, it is known to be up to 10x times slower, compared to the daemon mode.

Pros and cons of using Maldet

Pros:

1. Maldet scans all files in the configured directory (or for the configured user), at all times. The scan runs on a file during create or update operation.
2. Maldet is configurable to move infected files to quarantine or leave in place.
3. Maldet has configurable email notifications.
4. Maldet is configurable to run scheduled scans.
5. Manual scans on-demand available via terminal (over SSH).

Cons:

1. Maldet cannot block saving of an infected file. It only moves the file to the quarantine or leaves it as is in place.
2. Maldet doesn’t integrate with Drupal front-end (drupal messages) or back-end (watchdog reports). It has a dedicated log file, that could be displayed to system admins (for example, as a Kibana board).

Kubernetes and ClamAV performance considerations

Let’s consider a deployment, where a dedicated container is provisioned for ClamAV and maldet. It runs for every branch in a project and scans the filesystem of the project (either the docroot or media upload directory).

Due to the fact that a separate ClamAV container is getting deployed for every git branch (by Lagoon), it may occupy a considerably large cluster resources (RAM and CPU).

In the case where deployment has no separate ClamAV+maldet container, ClamAV has to run inside a PHP/Nginx pod and thus should be running in an executable mode. This mode is up to 10x times slower if compared to the daemon mode.

Vanilla ClamAV versus improved

Some server security software vendors use ClamAV but improve it – by adding a more recent and unique (custom) virus/malware signatures. One good example of such vendor that I used for many years is Atomicorp. Their ASL software has successfully blocked millions of attacks in the servers that I manage. Atomicorp packages their own ClamAV distribution and it comes with a much larger set of malware signatures. Moreover, their custom Linux kernel allows for significantly faster ClamAV operations, when compared to the vanilla Linux kernels, shipped with most Linux distributions by default. In many cases, I saw Atomicorp’s ClamAV detecting malware that was left undetected by the vanilla ClamAV.

I highly recommend using Atomicorp’s kernel and ClamAV packages for your Kubernetes cluster, it is proven to work better, with fewer resources. It works faster, using ASL’s secure Linux kernel. 

Maldet or ClamAV Drupal module? Conclusion

A maldet binary, combined with the ClamAV package, offers a powerful anti-malware server protection solution. It offers a considerably better level of malware protection in your server or containers cluster deployment. Based on your workload and type of cluster deployment, however, it may not be the best way to implement such malware protection. The costs of a dedicated, 100% running container with the ClamAV may be significant for large deployments. Based on your individual use case with Kubernetes, you may need to consider either implementation scenario. It would be great to see a dedicated ClamAV/maldet Docker container provided by Amazee.io as an optional feature. If the container run a hardened kernel (e.g. the one supplied by the Atomicorp), this would be a great beginning to a more secure web.