[Rspamd-Users] Trouble with Antivirus in RspamD

[G.W. Haywood]

Hi there,

On Mon, 1 Jul 2024, christian via Users wrote:

> Good morning, it's me again ;-)

:)

> At the weekend I noticed that there was something wrong with my ClamAV ...

I can't remember the last time that a clamd daemon crashed here except
when I was experimenting with Yara rules - so I gave up with ClamAV's
Yara implementation and since then it's never crashed.

> ... I don't know if it has anything to do with the Debian update from 
> 12.5 to 12.6 and whether it's related in time. ...
> There was an update of ClamAV from 1.0.4 to 1.0.5 from Debian.

IMHO an update is always a prime suspect.  Especially a Debian update.
If it just hasn't started properly, maybe you need to tweak something
in the configuration?  Is there anything in the Debian upgrade notes?

I don't know what Debian is doing with ClamAV but the latest version
in Long Term Support (LTS) seems to be 1.0.6:

https://www.clamav.net/downloads

It might be worth checking that the version you're using is getting
the updates it needs for signatures.  I think the ClamAV team intended
at some time to prevent older versions from getting updates as a way
of encouraging people to upgrade.  It would be a bit pushy to block
updates for a release only one point older, but stranger things have
happened.

> [...]
> I checked whether the Clamav-deamon socket is active:
>
> lsof /run/clamav/clamd.ctl
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> systemd 1 root 46u unix 0x000000009dedbc6e 0t0 19184743 /run/clamav/clamd.ctl type=STREAM (LISTEN)
> clamd 1057788 clamav 3u unix 0x000000009dedbc6e 0t0 19184743 /run/clamav/clamd.ctl type=STREAM (LISTEN)
>
> So it looks like it's working.

If you say so.  I've no idea what systemd is doing with the socket,
but it does like to get its fingers into every possible pie. :(  I'd
suggest that you look into that at your leisure, but, for now, try to
connect to clamd manually.  It's useful to be able to do that for a
quick test any time.  Our clamd server is on the LAN, so below is an
example using telnet.  Using a shell on my local mail server I connect
to the remote clamd and send the 'PING' command.  The reply (if any)
will be 'PONG', and the clamd server should then close the connection.
If you don't get a connection, or you don't get a PONG, then the
problem is probably with clamd.  If you do get the expected response
the problem is very likely elsewhere.

8<----------------------------------------------------------------------
$ telnet 192.0.2.1 3310
Trying 192.0.2.1...
Connected to 192.0.2.1.
Escape character is '^]'.
PING
PONG
Connection closed by foreign host.
$ 
8<----------------------------------------------------------------------

Note that I've edited the IP address and port for this example.  We
don't actually use those values here.

Since you're using a local Unix socket you'll need to do something
slightly different to make the connection, for example Netcat:

8<----------------------------------------------------------------------
$ nc -U /run/clamav/clamd.ctl
PING
PONG
$
8<----------------------------------------------------------------------

Full disclosure:-  The above is what I'd expect.  I haven't actually
tested it on a server because ours isn't listening on a Unix socket. :/
If all else fails you could reconfigure clamd for a network connection
to test it, but that really shouldn't be necessary.

> What surprises me is that "sockstat | grep clam" doesn't find a socket.

You should definitely see something.  Here's our clamd server:

8<----------------------------------------------------------------------
# sockstat | grep clam | tr -s " "
clamav clamd 19954 tcp4 192.0.2.1:3310 *:* LISTEN
# 
8<----------------------------------------------------------------------

Again I've edited the IP/port.  Not that it really matters, as they're
all RFC1918 private IPs.

> It looks like Rspamd is not forwarding any emails to the socket. So "tail -f 
> /var/log/rspamd/rspamd.log | grep clam" doesn't output anything (debug is 
> on). Normally rspamd should pass all emails to the ClamAV, even the ham ones, 
> right?

This is beside the point at the moment but I like to scan mail which
is considered ham, because you never know when some normally trusted
supplier or customer will suddenly start sending malware.  It doesn't
happen often here but it does occasionally happen.

-- 

73,
Ged.