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 la red global Imunify, que abarca varias decenas de millones de dominios según el editor. 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. Requiere el PHP endurecido de CloudLinux (alt-php, «Hardened PHP») para funcionar.
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 integración documentada por Imunify360 cubre el kernel; las librerías del sistema (glibc, openssl) siguen las actualizaciones habituales del sistema. Las actualizaciones automáticas también cuentan para el propio Imunify360: el fallo del componente AI-Bolit (compartido por Imunify360, ImunifyAV e ImunifyAV+), que permitía ejecutar código arbitrario, hasta con privilegios root, al analizar un archivo manipulado, se corrigió en octubre de 2025 con la versión 32.7.4-1. El parche se distribuyó automáticamente a la gran mayoría de los servidores antes del aviso de seguridad publicado en 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 Usage, reduce el consumo de CPU y RAM (WebShield desactivado, juego de reglas WAF mínimo) — ú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 SU_CLAVE_DE_LICENCIA. La clave se obtiene desde su área de CloudLinux Network (CLN) después de la compra. En la prueba de 14 días, la clave de prueba recibida por correo se usa del mismo modo; con una licencia vinculada a la IP, ejecute el script sin argumentos:bash i360deploy.sh.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, abra la pestaña Proactive Defense y active el modo
Kill Mode(bloquea y detiene el script malicioso) en lugar deLog Only(solo registro, modo por defecto). EnKill Mode, una ejecución PHP sospechosa se detiene al instante. Quédese enLog Onlydurante unos días si tiene aplicaciones de negocio complejas, para identificar los falsos positivos antes de cambiar.Configurar el escaneo programado
En Settings → Malware Scanner, 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, por clave o por IP, se gestiona en el CloudLinux Network (CLN) — exactamente igual que una licencia de CloudLinux OS. En caso de migración, retire el servidor antiguo (o la IP antigua) de la licencia en CLN, registre el nuevo (
imunify360-agent register SU_CLAVE, oimunify360-agent register IPLpara una licencia por IP) y compruébelo conimunify360-agent rstatus.
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. En un servidor con SELinux activado, el script i360deploy.sh aplica por sí mismo el módulo de política SELinux de Imunify360; solo si instala directamente los paquetes RPM hay que compilarlo y cargarlo a mano (checkmodule, semodule_package, semodule -i) y después reiniciar imunify360 e imunify360-webshield.
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, la documentación oficial recomienda poner en Off, en la sección ModSecurity Vendors de WHM, todos los vendors de terceros salvo el ruleset de Imunify360 y, si este falta, reinstalarlo con imunify360-agent install-vendors.
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 el servicio está activo pero el panel sigue mostrando este mensaje justo después de la instalación, dele tiempo: la base SQLite del agente se sincroniza con la interfaz, y la documentación oficial aconseja esperar hasta 60 minutos. Si el problema persiste, reinicie manualmente:systemctl restart imunify360.«Connection refused» en un socket interno del agente
Este tipo de error (
Errno 111) indica que ningún proceso escucha en el socket de comunicación interna entre los componentes de Imunify360. La causa habitual es un agente detenido, o un demonio (comoimunify360-wafd) que no se reinició tras una actualización. Compruebesystemctl status imunify360y el registro (journalctl -u imunify360 -n 50) y reinicie el servicio:systemctl restart imunify360. Si el problema vuelve, fuerce la actualización a la última versión estable con el script oficialimunify-force-update.sh(wget -O imunify-force-update.sh https://repo.imunify360.cloudlinux.com/defence360/imunify-force-update.sh && bash imunify-force-update.sh).«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 el servidor alcanza en salida el servidor centralimunify360.cloudlinux.compor el puerto 443, un control que indica la documentación oficial. Los puertos 52223 y 52224, por su parte, son puertos locales de WebShield, no puertos de salida.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 y las firmas dejan de actualizarse. 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, compruebe primero que la licencia está registrada:
imunify360-agent rstatusdebe devolverOK; si no, registre el agente (imunify360-agent register SU_CLAVE) y actualice WHM. Compruebe también que el servicioimunify360está enactive (running)antes de diagnosticar la interfaz.
Licencias: cómo funcionan
La licencia Imunify360 se activa por clave o por la IP del servidor y se factura según el número de usuarios (cuentas cPanel, Plesk, etc. en el servidor). Los niveles se eligen según el número total de cuentas alojadas; las tarifas vigentes figuran en la página de precios del editor. 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 la red global Imunify |
| 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 | Sin equivalente integrado, hay que montarlo uno mismo | 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 (frecuente en 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. Este entorno combina aislamiento PHP (CloudLinux), protección en tiempo de ejecución (Imunify360 Proactive Defense) y escaneo antivirus en un único despliegue coherente.
