Seis capas de defensa, un solo producto
Imunify360 no se reduce a un antivirus. Apila seis niveles de protección complementarios que se refuerzan mutuamente: firewall de red, WebShield (protección frente a bots), WAF aplicativo, escáner antivirus con limpieza, Proactive Defense (runtime PHP) y detección de intrusiones (IDS/IPS). La fuerza de esta arquitectura es que una amenaza que sortea el WAF todavía puede ser detenida por la Proactive Defense, y una amenaza que atraviesa el runtime PHP será detectada en el siguiente escaneo antivirus. Cada capa es independiente, pero alimenta a las siguientes.
Las seis capas en detalle
- Firewall de red con threat intelligence: bloquea las IP maliciosas conocidas a partir de una base alimentada por más de 57 millones de dominios en la red global Imunify (datos de 2025). Cuando una IP ataca a un servidor de la red, queda bloqueada en todos los demás en unos minutos.
- WebShield y protección frente a bots: filtra el tráfico HTTP entrante antes de que llegue a la aplicación — CAPTCHA adaptativo, listas grises (Graylist), protección DDoS de capa 7.
- WAF aplicativo (ModSecurity + reglas Imunify): inspecciona cada petición HTTP y bloquea los exploits conocidos (inyecciones, inclusiones de archivos, XSS). Las reglas se actualizan automáticamente desde los servidores CloudLinux.
- Antivirus y escaneo de malware: escaneo en tiempo real de los archivos recién escritos, escaneo de fondo programable, limpieza automática — Imunify intenta eliminar el código malicioso conservando el resto del archivo.
- Proactive Defense: módulo PHP que analiza el comportamiento de los scripts en tiempo de ejecución (y no solo su contenido estático). Bloquea webshells ofuscados, reverse shells y exfiltración de datos incluso si el archivo supera el escaneo antivirus.
- IDS/IPS y patch management: detección de comportamientos anómalos en el sistema, junto con KernelCare para aplicar parches del kernel Linux sin reiniciar.
La Proactive Defense: detener el malware ofuscado
La Proactive Defense es la capa más difícil de sortear. No escanea los archivos en disco: intercepta la ejecución PHP en tiempo real y examina los patrones de comportamiento — intento de escritura de archivos fuera del webroot, llamadas a exec(), shell_exec(), system(), eval() sobre datos no saneados, inyecciones SQL desde un script que solo debería leer la base de datos. El módulo está disponible para Apache y LiteSpeed. Su principal interés está frente al malware ofuscado: un webshell que atraviesa las herramientas de escaneo estático porque su código está codificado en base64 y se decodifica en tiempo de ejecución será detenido por la Proactive Defense en cuanto intente una acción peligrosa. Desde diciembre de 2024, Imunify360 incorpora además mejoras significativas de memoria y rendimiento que reducen la huella de este módulo en los servidores con mucha carga.
KernelCare y el patch management sin reinicio
El patch management de Imunify360 se apoya en KernelCare (también desarrollado por CloudLinux). KernelCare aplica los parches de seguridad del kernel Linux en memoria viva, sin detener el servidor ni los sitios alojados. En un servidor compartido cPanel que aloja a 200 clientes, un reinicio impuesto por un parche de kernel crea una ventana de mantenimiento incómoda. KernelCare elimina esa limitación: el kernel pasa a su versión segura en unos segundos, sin downtime. La misma lógica se aplica a las librerías del sistema (glibc, openssl) mediante KernelCare.library. Este enfoque resulta especialmente pertinente para las vulnerabilidades críticas — entre ellas el fallo descubierto en octubre de 2025 en el componente AI-Bolit de ImunifyAV, que permitía una ejecución de código arbitrario en los servidores que analizaban archivos maliciosos. CloudLinux desplegó el parche (v32.7.4.0) automáticamente en los servidores Imunify360 activos antes de la divulgación pública de noviembre de 2025 — ilustración directa de la ventaja de las actualizaciones automáticas.
RapidScan y CloudAV: rendimiento de los escaneos a gran escala
En un servidor que aloja cientos de gigabytes de archivos de clientes, un escaneo antivirus completo y diario resulta costoso en CPU. Imunify360 responde con dos mecanismos. RapidScan acelera los escaneos repetidos hasta 20 veces respecto al primer escaneo completo: mantiene metadatos locales y hash en la nube para volver a escanear únicamente los archivos creados o modificados desde la última pasada. CloudAV traslada el análisis en profundidad a la infraestructura cloud de Imunify Security, sin consumir CPU local para los archivos sospechosos que merecen un examen más exhaustivo. La tercera palanca, Low Resource Mode, limita la huella de RAM a unos 100 MB — útil en VPS con recursos limitados donde Imunify360 comparte el servidor con MySQL, PHP-FPM y el resto del stack cPanel.
Despliegue: instalar Imunify360 en cPanel/WHM
La instalación oficial se realiza desde la línea de comandos SSH, como root. No hay ningún paquete yum que añadir manualmente: un script de despliegue descarga y configura todo automáticamente.
Instalación paso a paso
Descargar el script de instalación
Desde una sesión root:
wget https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh -O i360deploy.shLanzar el despliegue con la clave de licencia
Ejecute
bash i360deploy.sh --key VOTRE_CLE_LICENCE. La clave se obtiene desde su área de CloudLinux Network (CLN) después de la compra. Si está en la prueba de 14 días, utilicebash i360deploy.sh --key IPL(IP License — no requiere registro en CLN para la prueba).Comprobar el registro en WHM
Conéctese a WHM como root y vaya a Plugins → Imunify360. Acepte el contrato de licencia en el primer acceso. La interfaz muestra de inmediato el estado del firewall, los escaneos activos y los incidentes recientes.
Activar la Proactive Defense
En WHM Imunify360, vaya a Settings → Proactive Defense y active el modo
KILL(bloquea y detiene el script malicioso) en lugar deLOG(solo registro). En modoKILL, una ejecución PHP sospechosa se detiene al instante. Empiece porLOGdurante unos días si tiene aplicaciones de negocio complejas, para identificar los falsos positivos antes de cambiar.Configurar el escaneo programado
En Malware Scanner → Settings, defina la frecuencia (se recomienda diaria) y las exclusiones de directorios (cachés, copias de seguridad voluminosas). El primer escaneo completo puede durar varias horas según el volumen de los datos alojados.
Registrar la licencia en CLN
La licencia Imunify360 está vinculada a la IP del servidor y se registra a través del CloudLinux Network (CLN) — exactamente igual que una licencia de CloudLinux OS. En caso de migración a una nueva IP, hay que transferir la licencia desde el portal CLN antes de reinstalar; de lo contrario, el servicio pasa a modo degradado.
Imunify360 es compatible con AlmaLinux, Rocky Linux, RHEL, CloudLinux OS, Ubuntu 22/24 y Debian, y se integra con cPanel, Plesk, DirectAdmin o en modo standalone. Desde noviembre de 2024, Ubuntu 24 está oficialmente soportado. Si trabaja en un servidor con SELinux activado, instale manualmente el módulo de política SELinux de Imunify360 después de la instalación (imunify360-selinux mediante yum) — de lo contrario, algunos componentes del firewall no arrancan.
Gestión de las reglas WAF y conflictos con OWASP
El WAF de Imunify360 se apoya en ModSecurity con un juego de reglas propio mantenido por CloudLinux. Si su servidor utilizaba antes el juego de reglas OWASP (frecuente en configuraciones cPanel manuales), desactive OWASP antes de instalar Imunify360: los dos juegos de reglas provocan conflictos, bloqueos legítimos en cascada y falsos positivos masivos. Imunify360 gestiona sus propias reglas de forma autónoma — no está previsto para convivir con OWASP. En caso de conflicto tras la instalación, el procedimiento de resolución oficial es: eliminar el vendor ruleset de Imunify360, hacer una copia de seguridad del datastore de ModSecurity, reinstalar el vendor Imunify360, comprobar la configuración de Apache, reiniciar el servidor web y volver a probar el ruleset.
Resolución de problemas: mensajes de error frecuentes
Los problemas más habituales tras la instalación o la actualización de Imunify360 tienen causas precisas y soluciones documentadas.
Resolución de los errores más comunes
«Imunify agent is not running»
Causa más frecuente: el servicio
imunify360no ha arrancado tras un reinicio o una actualización. Compruébelo consystemctl status imunify360y despuésjournalctl -u imunify360 -n 50. Si apareceTried to start while migrations are not applied, espere de 2 a 5 minutos: las migraciones de la base SQLite se ejecutan al arrancar y bloquean temporalmente el servicio. Si el problema persiste, reinicie manualmente:systemctl restart imunify360.«Failed to connect to rpc socket [Errno 111] Connection refused»
Este mensaje (aparecido sobre todo en la v8.4.3) indica un fallo del socket de comunicación interna entre los componentes de Imunify360. La causa suele ser un crash del proceso principal durante una migración. Solución:
systemctl stop imunify360 && systemctl stop imunify360-pam && systemctl start imunify360. Si el problema vuelve, compruebe los permisos del directorio/var/run/imunify360/.«You must install the following extensions before you can edit their values: imunify360» (WHM)
Este mensaje de WHM aparece al editar un paquete cPanel en un servidor donde Imunify360 está instalado pero el feature management no está activado. Comando de resolución:
imunify360-agent feature-management native enable. La operación es inmediata y no requiere reinicio.Notificaciones «Malware detected» no recibidas
Imunify360 puede detectar malware sin enviar las alertas por correo configuradas. Compruebe primero que el servicio de notificación está activo en Settings → Notifications y que la dirección de correo configurada es alcanzable desde el servidor (pruébelo con
sendmailomail). Si la configuración es correcta, compruebe que los puertos 52223 y 52224 están abiertos en salida — Imunify360 los utiliza para comunicarse con los servidores cloud de CloudLinux. Un firewall aguas arriba que bloquee esos puertos corta silenciosamente las notificaciones.Conectividad perdida hacia `files.imunify360.com` o `imunify360.cloudlinux.com`
Las actualizaciones automáticas de las reglas WAF y de la base de firmas antivirus pasan por estos dos dominios. Si el servidor no puede alcanzarlos (firewall de salida restrictivo, proxy, DNS interno), las reglas dejan de actualizarse y el servicio vuelve a modo degradado. Compruébelo con
curl -v https://files.imunify360.comy añada una excepción de salida si es necesario.Plugin Imunify360 ausente de la interfaz WHM
Si la entrada de menú Imunify360 no aparece en WHM/cPanel pese a una instalación aparentemente correcta, el plugin de interfaz no está registrado. Ejecute
/usr/share/imunify360/scripts/register-plugin.sh(o el equivalente según la versión) y actualice WHM. Compruebe también que el servicioimunify360está enactive (running)antes de diagnosticar la interfaz.
Licencias: cómo funcionan
La licencia Imunify360 está vinculada a la IP del servidor y se factura según el número de usuarios (cuentas cPanel, Plesk, etc. en el servidor). Los planes empiezan en torno a 14 $/mes para un servidor con hasta 30 usuarios. También existe un plan standalone (sin panel de control) para servidores Nginx o Apache puros. El registro se realiza en el CloudLinux Network (CLN), el mismo portal que para las licencias de CloudLinux OS. En caso de migración a una nueva IP, la transferencia de licencia se gestiona directamente desde el portal CLN — no hace falta volver a comprarla. Las licencias de revendedor (5 servidores o más) se benefician de precios decrecientes. En ServOrbit, las licencias Imunify360 están disponibles directamente desde el área de cliente, vinculadas a la IP de su servidor dedicado o VPS cloud.
Imunify360 vs. herramientas separadas: lo que se evita
Desplace la tabla
| Necesidad | Sin Imunify360 | Con Imunify360 |
|---|---|---|
| Firewall de red + threat intelligence | CSF + LFD (configuración manual, sin red global) | Integrado, actualizado automáticamente desde 57M+ dominios |
| WAF aplicativo | ModSecurity + OWASP (reglas que hay que mantener manualmente) | Ruleset Imunify mantenido y distribuido automáticamente |
| Antivirus de malware | ClamAV (solo escaneo, sin limpieza automática) | Escaneo + limpieza automática + CloudAV |
| Protección runtime PHP | Ningún equivalente disponible por separado | Proactive Defense integrada |
| Parche de kernel sin reinicio | Actualización manual + ventana de mantenimiento | KernelCare integrado |
| Gestión centralizada en WHM | Herramientas dispersas, sin interfaz unificada | Plugin WHM nativo, vista unificada de los incidentes |
Si su servidor funciona con CloudLinux OS (el caso de la mayoría de los servidores cPanel compartidos), Imunify360 se beneficia de una integración reforzada con las jaulas PHP por usuario (CageFS). Cada cuenta cPanel ve un entorno PHP aislado: un malware que se ejecuta en el contexto del sitio de un cliente no puede leer los archivos de los demás clientes. Es el único entorno que combina aislamiento PHP (CloudLinux), protección en tiempo de ejecución (Imunify360 Proactive Defense) y escaneo antivirus en un único despliegue coherente.
