Blocking malware

My usual rant: I consider virus scanners snake oil. If anyone wants to seriously infect a computer by sending an infected attachment then virus scanners won’t help you. They are based on patterns of known malware and (if you are lucky) a working heuristic algorithm trying to detect unusual behavior. It has been proven time and again that a custom-made virus – even a slightly altered variant of a well-known virus – goes easily undetected by your virus scanner. So why do they even exist? FUD. IT managers know well about the weaknesses of this approach. But if any Wind*ws computer gets infected they can tell senior management that they employed all common measures. I have talked to several managers and they all tell the same story. A german manager recently called yet another outbreak of Emotet a “digital natural disaster”. Nothing you could do against it, huh? Free hint: only allow known and verified types of attachments, educate your users and limit their access. The oletools can be integrated into rspamd to help with M$ office macros.

Pros and cons of ClamAV

As usual I prefer to stay with open-source components. So the obvious choice is the famous ClamAV virus scanner. But its detection rate is ridiculously low with its default signatures. Fortunately there are additional signatures to significantly improve that. And they is even a Debian package called clamav-unofficial-sigs that gets them. (Thanks for the hint, Pieter.)


Let’s get going and start ClamAV. First install the necessary package:

apt install clamav clamav-daemon clamav-unofficial-sigs

The daemon is a permanent process running on your system waiting for connections from other programs. That makes it faster than starting a process to scan email attachments time and again. The default configuration works well so there it nothing to do.

Check if the daemon is running already:

systemctl status clamav-daemon

Look for the “active” (running)” line in the output. Is it there? Very good.

Don’t worry about messages like…

WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.101.4 Recommended version: 0.102.1
DON'T PANIC! Read http://www.clamav.net/documents/upgrading-clamav

Do as it says: don’t panic. 🙂 Debian ships with a stable version and stays with it. That is perfectly fine. You do not need to do anything about it.

Let rspamd use ClamAV

Finally you have to tell rspamd how to talk to the ClamAV daemon. Unfortunately the documentation is pretty misleading. Unfortunately the principal developer once again acted childishly and refused to fix it. Oh, well.

The ClamAV daemon is by default creating a socket file on your server at /var/run/clamav/clamd.ctl. Sockets look like files and work as interfaces for interprocess communication. rspamd can communicate through that socket to ask ClamAV if a certain email contains a virus.

The default configuration can be seen in /etc/rspamd/modules.d/antivirus.conf. By default it will just raise the score if a virus was detected. I prefer to reject an email right away if ClamAV finds something. So let’s improve it a bit. Create a new file /etc/rspamd/override.d/antivirus.conf with this content to replace the default section:

clamav {
 symbol = "CLAM_VIRUS";
 type = "clamav";
 action = "reject";
 servers = "/var/run/clamav/clamd.ctl";

So what does this mean?

  • symbol… If a virus is found by ClamAV then rspamd adds a symbol named CLAM_VIRUS. You may remember that these symbols can be assigned scores or added as email headers to see which criteria matched. You can call it whatever you want.
  • type… sets a few defaults in the antivirus module that tell rspamd how to talk to ClamAV
  • action… is an optional parameter that we use to instantly reject the email if a virus is found. We do not add a value to the spam score. Instead we refuse to accept the email during the incoming SMTP connection.
  • servers… defines the way to communicate with ClamAV. In this case we define the path of the socket that the ClamAV daemon opened for us.

Restart rspamd:

systemctl restart rspamd

Virus scanning should now be working. Let’s see if it works as expected.


As mentioned earlier there exists a test signature for virus scanners called EICAR. It is not a virus – just a file that can be fed to your virus scanner to see if it is generally working. Download the test file from their website:

wget https://secure.eicar.org/eicar.com

If you installed the swaks tool as suggested earlier you can use it to send a test email with EICAR attached:

swaks --to john@example.org --attach - --server localhost < eicar.com

One of the last lines should read…

<** 554 5.7.1 clamav: virus found: \"Eicar-Test-Signature\"

This proves that Postfix send the email through rspamd which in turn checked the email using ClamAV which again found the test signature and rejected the email.

You can also test updating your signatures:

chown -R clamav.clamav /var/cache/clamav-unofficial-sigs /var/lib/clamav-unofficial-sigs/configs

If the update worked successfully you can now check which additional signatures ClamAV recognizes:

clamscan --debug 2>&1 /dev/null | grep "loaded"

It may take a few seconds but then it should show you the various signatures it loaded.

Could not resolve host: clamav.<br>securiteinfo.com

The xxx package still uses a source that is not available any more. The issue is recorded as Ubuntu bug #1643172. This leads to daily error emails telling you that clamav.securiteinfo.com could not be resolved. To work around this issue edit the /usr/share/
unofficial-sigs.conf file and remove the si_dbs and si_update_hours definitions.

19 thoughts on “Blocking malware

  • 2019-12-29 at 16:31

    cp systemd/* /etc/systemd/
    Shouldn’t this command be “cp systemd/* /etc/systemd/system/ ?

      • 2019-12-29 at 18:36

        Yes, there is a reason I did not endorse the official Debian package: my stupidity. 🙂 Let me simplify this page a bit…

        • 2019-12-29 at 19:21

          Well apart from some teething problems I’m finding this a great guide!

          I tried to use the same approach just now, but did encounter a bug when running `sudo clamav-unofficial-sigs`:

          curl: (6) Could not resolve host: clamav.securiteinfo.com

          On Launchpad, I found a bug report describing this problem as well:

          Commenting out this part in `/usr/share/clamav-unofficial-sigs/conf.d/00-clamav-unofficial-sigs.conf` seems to solve the issue:

          # SecuriteInfo Database(s)
          # ========================
          # Add or remove database file names between quote marks as needed. To
          # disable any SecuriteInfo database downloads, remove the appropriate
          # lines below. To disable all SecuriteInfo database file downloads,
          # comment all of the following lines.

          # Since the SecuriteInfo databases are only updated a few time each
          # month, set a time interval to do database update checks.
          si_update_hours=”4″ # Default is 4 hours (6 update checks daily).

          • 2020-01-01 at 11:02

            Thanks, added.

    • 2019-12-29 at 18:29

      Totally. Fixed. Thanks.

  • 2019-12-30 at 15:57

    The setup command results in a fail :

    root@debian-xxx:~# systemctl status clamav-daemon
    ● clamav-daemon.service – Clam AntiVirus userspace daemon
    Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/clamav-daemon.service.d
    Active: inactive (dead)
    Docs: man:clamd(8)

    Dec 30 16:54:44 debian-4gb-fsn1-1 systemd[1]: Condition check resulted in Clam AntiVirus userspace daemon being skipped.

    • 2019-12-30 at 16:01

      Well strange enought but removing the packages with –purge and install a second time results in daemon starting without pb

      systemctl status clamav-daemon
      ● clamav-daemon.service – Clam AntiVirus userspace daemon
      Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
      Drop-In: /etc/systemd/system/clamav-daemon.service.d
      Active: active (running) since Mon 2019-12-30 17:00:26 CET; 4s ago
      Docs: man:clamd(8)
      Main PID: 21189 (clamd)
      Tasks: 1 (limit: 4585)
      Memory: 278.4M
      CGroup: /system.slice/clamav-daemon.service
      └─21189 /usr/sbin/clamd –foreground=true

      • 2019-12-31 at 14:21

        That is caused by the fact that freshclam first needs to run and complete. After that has completed, clamav-daemon will successfully start.

        • 2020-02-23 at 17:30

          I was having the exact same problem. Freshclam would never finish the daemon would never start. I tried rebooting, and that changed the problem…. but after a apt purge clam… and then apt install over again, everything was working fine. Something is happening between the two installs.

          • 2020-02-29 at 14:01

            I had the same issue–Clamav was not running after I installed it. However, all I had to was:

            root@altopl1: /root
            ==> systemctl stop clamav-daemon

            root@altopl1: /root
            ==> systemctl start clamav-daemon

            and then it was active, running.

          • 2020-07-16 at 18:20

            Running the freshclam command manually gave me the hint I needed. The file /varlog/clamav/freshclam.log was locked (in use by another process).
            Deleting the file and running freshclam again finished the “first time” run and I could start the clamav-daemon service afterwards.
            Btw. purge didn’t help me. I tried that before tracking down the locked file.

  • 2020-01-08 at 10:03

    First of all thanks for your great tutorial, i configured my centos server and everything is working fine, except the virus scanning part 🙁
    Perhaps you can help me out, I always get a permission denied in rspamd.log file:

    rspamd_inet_address_connect: connect unix:/var/run/clamd.scan/clamd.sock failed: 13, ‘Permission denied’
    lua_tcp_make_connection: cannot connect to /var/run/clamd.scan/clamd.sock (/var/run/clamd.scan/clamd.sock)

    clamd.sock permissions:
    srw-rw-rw-. 1 clamscan virusgroup 0 Jan 8 10:37 /var/run/clamd.scan/clamd.sock

    I can not figure out which permissions to set

  • 2020-01-11 at 14:43

    I have an error “relay access denied”

    root@ispmail:~# swaks –to john@example.org –attach – –server localhost < eicar.com
    perl: warning: Setting locale failed.
    perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LC_TERMINAL = "iTerm2",
    LC_CTYPE = "UTF-8",
    LANG = "en_US.UTF-8"
    are supported and installed on your system.
    perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
    === Trying localhost:25…
    === Connected to localhost.
    EHLO ispmail
    <- 250-ispmail
    <- 250-PIPELINING
    <- 250-SIZE 10240000
    <- 250-VRFY
    <- 250-ETRN
    <- 250-STARTTLS
    <- 250-8BITMIME
    <- 250-DSN
    <- 250-SMTPUTF8
    RCPT TO:
    <** 554 5.7.1 : Relay access denied
    -> QUIT
    <- 221 2.0.0 Bye
    === Connection closed with remote host.

    • 2020-01-14 at 11:55

      What does your /var/log/mail.log say while you try that?

  • 2020-01-12 at 12:45

    It should also be possible to change the configuration via /etc/clamav-unofficial-sigs.conf.d/ directory, overriding e.g. the si_dbs parameter.

  • 2020-01-15 at 11:32

    Based on my experience running a mailserver on a small €5,- 1 GB VPS, I’d advise against using the Clamav integration.
    I tried to integrate the instructions on this page into my mailserver, but unfortunately ran into some problems.

    Running Clamav without extras is about o.k. (300 MB RAM), but when you also load the unofficial signatures, RAM usage of clamd goes up to around 800 MB, causing a lot of swapping, instability and slow response times. This apparently cannot be resolved, it is caused by the fact that it needs to load all the virus signatures into RAM in order to scan files / messages. The problem with not loading the unofficial signatures though is that the detection rates of Clamav become very low.
    This might be good to add for people using similar low-power setups.

  • 2020-04-12 at 21:27


    on the mailserver I’m currently setting up, clamav floods root’s mailbox with e-mails of the following type:

    “Clamscan reports MalwarePatrol mbl.ndb database integrity tested BAD – SKIPPING”

    Does anybody else have a similar issue?
    I could, of course, just disalbe MalwarePatrol in /usr/share/clamav-unofficial-sigs/conf.d/00-clamav-unofficial-sigs.conf as stated in [1], but first I wanted to be sure, I didn’t screw up anything in my config…

    Thanks in advance!


    [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831607


Leave a Reply

Your email address will not be published. Required fields are marked *