Servidor rack con escudo verde de proteccion antivirus ClamAV

ClamAV en servidor Linux: cuando vale la pena y cuando no

agosto 24, 2026 Alfonso Moreno | Sysadmin Senior 68 Visitas 12 min de lectura

En servidores Linux, la pregunta sobre si conviene instalar un antivirus suele provocar la misma respuesta refleja: “Linux no necesita antivirus”. Y para la mayoría de escritorios Linux personales, es cierto: el modelo de permisos, la separación de usuarios y la falta de ejecutables .exe convierten al malware tradicional de Windows en un problema ajeno. Pero un servidor que acepta uploads, comparte archivos por Samba con clientes Windows o recibe correo desde fuera del perímetro ya no es ese escritorio. Es un pasillo de tránsito de archivos que pueden llevar malware a otros sin que el propio server se vea afectado. Ahí es donde ClamAV entra como la opción obvia y libre para escanear ese tráfico antes de que llegue a su destino.

Este post revisa cuándo ClamAV realmente aporta valor en 2026 y cuándo es mejor no instalarlo. Vamos al grano: instalación mínima, configuración para los tres casos de uso que sí justifican el daemon (mail, Samba y uploads web), y los límites honestos de la herramienta.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Estado de ClamAV en 2026

ClamAV lo mantiene Cisco Talos desde hace años y tiene dos ramas activas. La rama 1.5.x es la estable más reciente (1.5.4 al cierre de agosto 2026) y trae los callbacks de escaneo nuevos, soporte de archivos firmados .cvd.sign y FIPS-limits en libclamav 12.1.0. La rama 1.4.x es la LTS (1.4.4 en marzo 2026, 1.4.5 con backport de los CVE de julio) y queda sobre libclamav 12.0.3. Si tu distribución está en Debian 11 bullseye o RHEL 8, vas a querer la LTS 1.4 porque la 1.5 pide Rust 1.87+ para compilar y glibc/OpenSSL más nuevos.

Lo concreto: en Debian 13 trixie y Ubuntu 24.04 ya tienes 1.5.x en repos; en Fedora 42 vas a ver 1.4.4; en Rocky/Alma 9+ suele entrar por EPEL. Para servers en producción, la recomendación operativa es LTS 1.4 salvo que necesites explícitamente las APIs nuevas (cl_scan*_ex() para callbacks custom). Los parches de seguridad de julio 2026 cerraron siete fallos en el scanner, incluido CVE-2026-20217 (crash en PESpin unpacker presente desde 2005) y CVE-2026-20213 (integer overflow en PE rebuild). Si tenías ClamAV antes de julio, ya toca actualizar.

Cuándo ClamAV no aporta nada

Antes de instalar nada, descarta los casos donde ClamAV es puro overhead. La heurística es simple: si tu server no recibe archivos del exterior ni los entrega a sistemas Windows/macOS que ejecuten esos archivos, ClamAV no te protege de nada relevante.

Servers estáticos sin uploads: nginx sirviendo HTML/CSS/JS, CDNs, reverse proxies que solo leen de su propia configuración. El malware para Windows no se ejecuta en Linux y los exploits web se previenen con hardening del servidor web, no con antivirus.
Endpoints Linux personales: una laptop con Ubuntu no se va a infectar con .exe ni con ransomware de Windows. Suma ClamAV y vas a gastar 50-80 MB de RAM en idle y vas a generar falsos positivos sin ningún beneficio real.
Contenedores Docker stateless: si tu contenedor se reconstruye en cada deploy y no tiene estado persistente, escanearlo en runtime es inútil. Mejor escanear las imágenes en el CI/CD antes de subirlas al registry.
Servidor que solo aloja sitios propios sin formulario de upload: el riesgo es el código que corre PHP/Python, no los archivos estáticos. Ahí necesitas RASP/SAST, no antivirus.

Medido en VPS chicos (1-2 GB RAM), el daemon clamd consume entre 800 MB y 1.2 GB de RAM constantes cargando la base de signatures, más picos de CPU de 35-40% durante escaneos completos. Si tu server tiene menos de 2 GB libres después de lo que ya corre, clamd no es opción; usa clamscan bajo demanda en un cron semanal.

Los tres casos que sí justifican ClamAV

Ahora bien, hay tres escenarios donde ClamAV brilla y el costo de recursos vale la pena. Cada uno tiene su propia configuración y su propia vía de integración.

1. Mail server con Postfix

Si administras un servidor de correo que recibe adjuntos del exterior, ClamAV con clamav-milter es el patrón estándar. clamav-milter corre como filtro entre Postfix y el buzón y rechaza o pone en cuarentena los mensajes infectados antes de que lleguen al usuario. La integración es limpia: clamav-milter habla el protocolo Milter nativo de Postfix, no necesita Amavis ni Postfix en chroot.

El paquete clamav-milter viene separado en Debian/Ubuntu; en Fedora/RHEL lo trae EPEL. La instalación es directa.

# Debian/Ubuntu
sudo apt install clamav clamav-daemon clamav-milter postfix
sudo systemctl enable --now clamav-daemon clamav-milter
# Fedora/RHEL (EPEL)
sudo dnf install clamav clamav-daemon clamav-milter clamav-update postfix
sudo systemctl enable --now clamd@scan clamav-milter

El socket del milter tiene que vivir en un path accesible por Postfix. Debian deja el socket por defecto en /var/run/clamav/clamav-milter.ctl, pero Postfix corre chrooted en /var/spool/postfix/ y no llega a /var/run. Hay que mover el socket dentro del chroot editando /etc/clamav/clamav-milter.conf:

[milter]
MilterSocket unix:/var/spool/postfix/clamav/clamav-milter.sock
MilterSocketMode 660
MilterSocketUser postfix
MilterSocketGroup postfix

Fedora/RHEL vía EPEL sí lo deja en /run/clamav/clamav-milter.ctl por defecto y aplica una configuración equivalente automáticamente. Edita /etc/clamav/clamav-milter.conf y alinea el MilterSocket con lo que declare Postfix. Después, en /etc/postfix/main.cf:

# Anadir clamav-milter a la cadena de milters de Postfix
sudo postconf -e 'smtpd_milters = unix:/var/spool/postfix/clamav/clamav.sock'
sudo postconf -e 'milter_default_action = accept'
sudo postfix reload
# Verificar que Postfix esta hablando con clamav-milter
echo "test" | sendmail -i root@localhost
sudo tail -f /var/log/clamav/clamav.log
sudo journalctl -u clamav-milter -f

El clásico anti-false-positive: si clamav-milter está en modo OnInfected Reject y tienes un falso positivo crítico, cambia a OnInfected Quarantine en el .conf y reinicia. La base de signatures oficial (Cisco Talos) tiene una taza de falsos positivos baja, pero las firmas de terceros (MalwarePatrol, SecuriteInfo) son más ruidosas. Empieza solo con oficiales y agrega después.

2. File server Samba para clientes Windows

Acá es donde ClamAV cubre un hueco que ningún firewall ni parche cubre: los archivos que los usuarios Windows suben al Samba share y luego se llevan a sus máquinas. Samba expone el módulo VFS vfs_virusfilter que intercepta el open() y bloquea archivos infectados antes de que queden visibles en el share. Soporta backends clamav, sophos y fsav, pero clamav es el único libre.

El módulo viene en samba-vfs-modules en Debian/Ubuntu y en el paquete base de Samba en Fedora. La configuración va en la sección del share, no en [global].

# /etc/samba/smb.conf - seccion del share
[shared]
    path = /srv/samba/shared
    read only = no
    browseable = yes
    guest ok = no
    valid users = @smbusers
    # Activar escaneo on-access con ClamAV
    vfs objects = virusfilter
    virusfilter:scanner = clamav
    virusfilter:socket path = /var/run/clamav/clamd.ctl
    virusfilter:max file size = 100000000
    # Bloquear acceso cuando clamd no responde (false = leer igual)
    virusfilter:block access on error = false
    # Mover infectados a cuarentena
    virusfilter:quarantine directory = /srv/samba/.quarantine
    virusfilter:infected file errno on open = EACCES
    # Timeout para no colgar Samba si clamd se cuelga
    virusfilter:connect timeout = 30000
    virusfilter:io timeout = 60000
# Verificar que la configuracion carga sin errores
testparm -s

El punto crítico: si clamd no está corriendo, Samba puede rechazar todos los accesos (depende de block access on error). En producción, mantén clamd monitoreado. Un buen patrón es monit o systemd watchdog que reinicie clamd si el socket deja de responder.

3. Uploads web en PHP/Python

Si tu aplicación web (Nextcloud, WordPress con wp-content/uploads activo, Drupal, una app custom en Flask o Laravel) acepta archivos del público, escanearlos antes de almacenarlos evita que tu server se convierta en el origen de malware para los visitantes. La forma más limpia es hablar con clamd por socket Unix o TCP local desde el código, no por CLI (que es 100x más lento porque relanza el proceso y recarga la DB).

# clamd.conf: limitar threads para no saturar bajo carga concurrente
# /etc/clamav/clamd.conf
MaxThreads 20
MaxRecursion 10
MaxFileSize 100M
StreamMaxLength 100M
ReadTimeout 300
# Reiniciar clamd despues de cambiar
sudo systemctl restart clamav-daemon
# Verificar que el daemon carga las signatures y responde
clamdscan --ping
clamscan --debug 2>&1 /dev/null | grep "loaded"

En el código de la aplicación, clamd expone su protocolo nativo sobre el socket (Unix o TCP): comandos en texto plano como INSTREAM, SCAN, CONTSCAN, PING, STATS. Librerías como pyclamd (Python) y clamscan (Node.js) lo envuelven; no hay REST nativo. Para Node.js existen librerías como clamscan (npm, mantenedor principal) o clamscan-ng como fork mantenido.; para Python, pyclamd. La regla de oro: si vas a escanear muchos archivos concurrentes, limita la concurrencia al 80-90% de MaxThreads para no saturar clamd con su housekeeping interno. Si escaneas archivos grandes (PDFs, videos), agrega timeouts explícitos: 5 MB → 5s, 50 MB → 20s, archivos de 100 MB+ → 30s+. Sin timeout, un clamd colgado bloquea todo tu upload handler.

Configuración recomendada de producción

Una vez que tienes el caso de uso claro, la configuración que separa un setup amateur de uno en producción pasa por cinco puntos.

Mirrors de freshclam seguros

Por defecto freshclam (el actualizador de signatures) contacta database.clamav.net:443. Funciona, pero si tu server está detrás de un proxy estricto o un egress firewall cerrado, los updates fallan silenciosamente. Apunta a un mirror oficial cercano y verifica la firma.

# /etc/clamav/freshclam.conf - secciones clave
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net
CompressLocalDatabase yes
ScriptedUpdates yes
NotifyClamd yes
SafeBrowsing yes
Bytecode yes
# Updates cada 2 horas (default 12 chequeos/dia)
Checks 12
# Probar que freshclam llega a los mirrors
sudo freshclam -v
sudo systemctl restart clamav-daemon

Signatures de terceros de calidad

La base oficial de Cisco Talos cubre el grueso del malware conocido, pero hay firmas adicionales que suben la detección. clamav-unofficial-sigs (extremeshok, GitHub) automatiza la descarga y validación de firmas de Sanesecurity, FOXHOLE, Porcupine, SecuriteInfo, MalwarePatrol, Linux Malware Detect, URLhaus y Yara-Rules. Cada descarga se valida con clamscan antes de instalar, así no rompes clamd con una base corrupta.

# Instalacion desde el repo oficial
git clone https://github.com/extremeshok/clamav-unofficial-sigs.git /opt/clamav-unofficial-sigs
cd /opt/clamav-unofficial-sigs
sudo cp config/{master,user,os}.conf /etc/clamav-unofficial-sigs/
# Activar solo las firmas que queremos (user.conf)
sudo sed -i 's/^sanesecurity_enabled="no"/sanesecurity_enabled="yes"/' /etc/clamav-unofficial-sigs/user.conf
sudo sed -i 's/^malwarepatrol_enabled="no"/malwarepatrol_enabled="yes"/' /etc/clamav-unofficial-sigs/user.conf
# Configurar el cron de actualizacion
sudo ln -s /opt/clamav-unofficial-sigs/clamav-unofficial-sigs.sh /etc/cron.daily/
sudo /opt/clamav-unofficial-sigs/clamav-unofficial-sigs.sh
# Verificar que clamd ve las nuevas firmas
sudo systemctl restart clamav-daemon
clamscan --debug 2>&1 /dev/null | grep -E "loaded|FOUND"

Logs y monitoreo

Por defecto ClamAV loguea a syslog. Para producción conviene un archivo dedicado con rotación para poder correlacionar con Postfix/Samba logs.

# /etc/clamav/clamd.conf
LogFile /var/log/clamav/clamav.log
LogFileMaxSize 100M
LogRotate yes
LogTime yes
LogSyslog yes
LogFacility LOG_LOCAL6
# Logrotate (ya incluido en el paquete Debian)
/etc/logrotate.d/clamav-daemon:
/var/log/clamav/clamav.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    postrotate
        systemctl reload clamav-daemon > /dev/null 2>/dev/null || true
    endscript
}

Para alertas en tiempo real, exporta los logs a un SIEM (Wazuh, Elastic, Graylog) y dispara regla cuando aparezca FOUND. En mail servers, grep "FOUND" /var/log/clamav/clamav.log | tail te da el top de amenazas del día en tres segundos.

Lo que ClamAV no va a detectar

Para no vender humo: ClamAV detecta malware conocido por firma. No es EDR, no detecta ataques fileless, no mira el comportamiento del proceso, no bloquea exploits zero-day. Lo que sí hace bien: bloquear archivos maliciosos subidos o recibidos, dar una segunda capa cuando algo se te pasó por delante (un patch no aplicado, una contraseña filtrada), y generar evidencia forense de qué archivos circularon.

Si lo que necesitas es detección de comportamiento en runtime, mira Falco o un agente EDR de pago (CrowdStrike, SentinelOne). ClamAV es la red de pesca al fondo del lago: no atrapa todo lo que pasa, pero atrapa mucho de lo que llega.

Resumen: una decisión de cinco segundos

¿Recibe archivos del público y los entrega a sistemas Windows/macOS? (mail, Samba, uploads web) → Instala ClamAV con clamd + clamav-milter/vfs_virusfilter.
¿Solo sirve contenido estático o contenedor stateless? → No instales ClamAV. Escanear imágenes en el CI/CD si te preocupan.
¿Tienes menos de 2 GB de RAM libre? → Usa clamscan bajo cron, no clamd. Acepta el costo de CPU una vez por semana.
¿Mail server que ya tiene rspamd/amavis? → ClamAV se enchufa vía clamav-milter o dentro de amavisd-new con AllowSupplementaryGroups.
¿Quieres detección de comportamiento? → ClamAV no es la herramienta. Suma Falco/EDR aparte.

Preguntas frecuentes

¿Por qué ClamAV en servidor Linux: cuando vale la pena y cuando no es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con ClamAV en servidor Linux: cuando?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con ClamAV en servidor Linux: cuando?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar ClamAV en servidor Linux: cuando y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a ClamAV en servidor Linux: cuando?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.