El control de salud tradicional opera desde la capa de protocolo: 'puerto abierto', 'devuelve HTTP 200', quizá 'el contenido de la página incluye esta palabra'. Estas respuestas dicen que el servidor presta servicio, pero no dicen CON QUÉ contenido presta servicio.
Los problemas modernos viven justo en esta brecha. Si un atacante ha superado el WAAP y ha dejado un webshell en el servidor, el probe de salud sigue diciendo 'el servidor está sano'. Si un despliegue ha salido defectuoso, el servidor responde con el binary antiguo pero para el probe de protocolo sigue siendo 200 OK. Si un operador ha modificado manualmente el archivo config, la desviación respecto al baseline opera en silencio.
A escala de cluster la situación es aún peor. De 10 servidores, 9 tienen la nueva versión y 1 no; el probe de salud los ve a todos sanos, y la solicitud del usuario cae por mala suerte en el servidor desactualizado. O al revés, en 1 servidor el atacante ha dejado un archivo nuevo; el resto del cluster está limpio pero no se retira el tráfico de ese único servidor porque nadie mira.
ETM Integridad de Servidor e Inteligencia de Despliegue llena esta brecha: el estado de los archivos, directorios, binary y config en el servidor se monitorea de forma continua; los cambios fluyen como eventos al ADC y al SOC; la decisión de routing va más allá de la cáscara exterior.
El agente en el servidor realiza un control continuo a nivel de archivo; detecta cambios y se vincula en vivo a la decisión de routing del ADC y al sistema de eventos del SOC.
Se calcula un hash periódico para los archivos críticos seleccionados (contenido del webroot, application binary, archivos config, certificados TLS). Para los árboles de directorios se genera un hash agregado al estilo Merkle. El cambio se detecta al instante mediante la comparación de hash.
La adición de un archivo nuevo fuera del baseline esperado, la modificación de un archivo existente o la eliminación de un archivo esperado genera un evento instantáneo. Un nuevo archivo .aspx/.php/.jsp dejado en el webroot se marca como sospecha de webshell.
Se realiza una comparación de hash entre los servidores que prestan el mismo servicio de aplicación. Un único servidor que queda fuera de la distribución esperada (drift o comprometido) se separa del cluster; el tráfico se dirige a los servidores consistentes.
Cuando se detecta un cambio, la política de tráfico del ADC puede reaccionar automáticamente: periodo de warm-up, routing gradual, aislamiento temporal. Cuando se detecta un nuevo despliegue, el tráfico transita de forma suave; cuando se detecta un cambio no autorizado, se corta el tráfico.
La integridad de archivos y la inteligencia de despliegue no son solo seguridad, sino parte del mecanismo de decisión operativa.
Para los archivos de contenido mantenidos en las raíces vhost del servidor web (HTML, ASP, ASPX, PHP, JSP, JS, CSS, imágenes) se calcula un hash periódico y la integridad del árbol de directorios. El operador define mediante política qué directorios se monitorean y qué extensiones se consideran sensibles. Un cambio inesperado se refleja como un evento instantáneo.
Cuando un atacante supera el WAAP e intenta colocar un webshell en el servidor, ETM captura al instante la nueva extensión ejecutable (p. ej. .aspx, .php, .jsp) dejada en el webroot. El servidor puede ponerse automáticamente en cuarentena, puede cortarse el tráfico, el SOC recibe una alarma. Es la última capa de defensa DESPUÉS del WAAP.
El cambio de hash del application binary o artifact se interpreta como un evento de despliegue. El ADC espera este evento: se dirige poco tráfico al servidor hasta que los indicadores de salud sean estables, y cuando se completa el warm-up se abre el tráfico completo. Los pasos manuales de 'saca del load balancer, despliega, vuelve a meterlo' se automatizan.
Cuando los archivos de configuración como el config de Apache, el config de Nginx, el application config de IIS, las unidades de systemd o las definiciones de cron se desvían del baseline, se genera una alarma. El operador puede intervenir antes de un cambio no autorizado; los cambios planificados se atienden con una actualización del baseline.
El hash de los binary críticos del sistema, los archivos de biblioteca y las herramientas auxiliares se compara con el baseline. Un cambio de binary resultado de rootkit, supply-chain compromise o intervención manual se detecta al instante; el servidor se pone en aislamiento, se mantiene abierto para el forense.
Cuando cambia el propietario, los permisos o las entradas ACL de los archivos y directorios críticos, se genera un evento. La escalada de privilegios no autorizada, el cambio de propiedad de un archivo o la apertura de permiso de escritura en una configuración sensible se hacen visibles al instante.
Se realiza una comparación de hash de baseline entre los servidores que prestan el mismo servicio de aplicación. Si 9 de 10 servidores coinciden y 1 es diferente, el diferente es sospechoso de drift o comprometido. Puede aplicarse cuarentena automática o aislamiento con la aprobación del operador.
Cuando el operador abre una ventana de mantenimiento, los cambios dentro de esa ventana no generan alarma; el baseline se actualiza según la política. Un evento de despliegue esperado no se interpreta como un 'cambio real'; un cambio sorpresa dispara una alarma.
Si tras la nueva versión la telemetría de ETM (tiempo de GC, error rate, frecuencia de restart) muestra deterioro, ETM lo relaciona con el evento de despliegue. El routing del ADC puede dar prioridad a los servidores con la versión anterior; el equipo de rollback se informa automáticamente.
Cada cambio de archivo/configuración/binary se escribe en el registro de auditoría; se transmite al SIEM. En qué servidor, cuándo, qué archivo cambió de qué hash a qué hash — la cadena de evidencias completa está lista para la auditoría. Soporte en vivo para el GDPR Art 32 y los requisitos de auditoría sectoriales.
El monitoreo de integridad no es solo una función técnica, sino la capa de gestión viva de los procesos corporativos de despliegue y seguridad.
Qué directorios se monitorean, qué extensiones de archivo se consideran sensibles y qué archivos se ignoran (log, cache, archivos temporales) se definen mediante política. Pueden definirse perfiles diferentes para el servidor web, el servidor de aplicaciones y el servidor de base de datos.
Los archivos críticos (system binary, TLS cert) pueden hashearse del orden de segundos; los de prioridad media (archivos config) en minutos; los de baja prioridad (contenido estático) a intervalos horarios. La carga de IO de disco se mantiene bajo control.
Los eventos de integridad se vinculan en vivo a la política de routing del ADC. Reglas de política como 'archivo nuevo detectado + hay contexto de ataque WAAP → aislamiento', 'hash drift detectado → baja prioridad', 'despliegue detectado → warm-up' son definidas por el operador.
El pipeline CI/CD puede notificar un evento de despliegue a la API de ETM; ETM interpreta este evento como un cambio esperado, dispara una coordinación de routing en lugar de una alarma. Cuando termina el despliegue, ETM firma el nuevo baseline.
Los eventos de alta prioridad como la sospecha de webshell, el binary tampering o el cluster drift se transmiten directamente al SOC con una alarma. El evento se enriquece: qué servidor, qué archivo, resultado de comparación de hash, última hora de modificación, recomendación de acción.
Cada evento de integridad se registra en el registro de auditoría. Cuando el auditor pregunta '¿qué archivo cambió en qué servidor en los últimos 30 días?', se responde en vivo. La cadena de evidencias se automatiza para PCI DSS, el GDPR Art 32 y los requisitos de auditoría sectoriales.
Aunque el WAAP no haya detectado el ataque, el nuevo archivo ejecutable colocado en el directorio vhost de IIS del servidor es capturado al instante por ETM. El servidor se retira automáticamente del cluster, se corta el tráfico, el SOC recibe una alarma instantánea; el dispositivo se mantiene abierto para el forense.
Cuando el equipo DevOps publica una nueva versión, ETM detecta el cambio de hash del application binary; el ADC realiza un routing gradual al servidor. Cuando las métricas de salud (CPU, tiempo de GC, error rate) permanecen estables, se abre el tráfico completo. Los procesos manuales de 'saca del load balancer, despliega, vuelve a meterlo' desaparecen.
De los 10 servidores del cluster de producción, 9 coinciden con el hash de baseline; 1 muestra un hash diferente. ¿Versión desactualizada, intervención manual o comprometido? ETM pone ese servidor automáticamente en cuarentena; el operador investiga la causa. La solicitud del usuario no cae por mala suerte en la versión incorrecta.
Tras la nueva versión, la telemetría de ETM muestra que el tiempo de GC se ha alargado, el error rate ha aumentado y la frecuencia de restart ha subido. ETM lo relaciona con el evento de despliegue; el routing del ADC da prioridad a los servidores con el hash de la versión anterior. El equipo de rollback se informa automáticamente; la decisión de despliegue se respalda con datos.
Cuando el hash de un system binary crítico de un servidor se desvía del baseline — sospecha de rootkit, supply-chain compromise o cambio no autorizado — el servidor se separa del cluster, se corta el acceso a internet, solo se mantiene abierto el canal de gestión de ETM. El SOC realiza la investigación remota para el forense.
Veamos ETM Integridad de Servidor en vivo en su propio backend — planifiquemos una sesión de instalación que abarque la definición de baseline, la vinculación con el ADC y el flujo SIEM sobre un grupo de servidores piloto.