Detección de Intrusiones 20 min de lectura

Detección de Intrusiones en Linux: Guía Completa con auditd, AIDE y Wazuh (2026)

Guía práctica para implementar detección de intrusiones en Linux combinando auditd, AIDE y Wazuh. Desde reglas de auditoría alineadas con MITRE ATT&CK hasta respuesta automatizada con Wazuh como SIEM/XDR.

Editorial Team

Introducción: El panorama de amenazas exige detección, no solo prevención

Hay una realidad incómoda que muchos administradores de sistemas prefieren ignorar: ninguna estrategia de prevención es infalible. Puedes endurecer SSH hasta el último parámetro, blindar tus contenedores con perfiles seccomp y ejecutar todo en modo rootless — y aun así, un atacante puede encontrar la forma de entrar. La pregunta no es si tu infraestructura será atacada, sino cuándo lo será y cuánto tardarás en darte cuenta.

Las estadísticas de 2025 son elocuentes. El kernel de Linux registró 5.530 CVE, un incremento del 28% respecto al año anterior. Eso equivale a entre 8 y 9 vulnerabilidades nuevas cada día. Los ataques de fuerza bruta contra SSH representan aproximadamente el 89% de los vectores de ataque contra servidores Linux, y los webshells suponen casi el 50% de todo el malware detectado en estos sistemas.

Depender exclusivamente de la prevención, en este contexto, es como cerrar todas las puertas de tu casa pero no tener alarma.

Aquí es donde entra la detección de intrusiones: la capacidad de identificar actividad maliciosa o no autorizada en tiempo real (o casi real). En esta guía vamos a implementar un sistema completo para Linux combinando tres herramientas que trabajan en capas complementarias:

  • auditd — El subsistema de auditoría del kernel de Linux que captura eventos a nivel de llamadas al sistema.
  • AIDE — Advanced Intrusion Detection Environment, un verificador de integridad de archivos que detecta cambios no autorizados.
  • Wazuh — Una plataforma de seguridad unificada (SIEM/XDR) que correlaciona eventos, detecta amenazas y automatiza respuestas.

La combinación de las tres proporciona una defensa en profundidad que cubre desde la auditoría a nivel de kernel hasta la correlación inteligente de eventos y la respuesta automatizada. Vamos a configurar cada una desde cero, con ejemplos prácticos y listos para producción.

auditd: Auditoría a nivel de kernel

El subsistema de auditoría de Linux (auditd) es probablemente la herramienta de seguridad más infravalorada de todo el ecosistema. Y lo digo en serio. Opera a nivel del kernel, interceptando llamadas al sistema y registrando eventos de seguridad con un nivel de detalle que ninguna herramienta de espacio de usuario puede igualar. Cuando un auditor te pregunta «¿quién modificó este archivo a las 3 de la madrugada?», auditd es quien tiene la respuesta.

Instalación y configuración base

En la mayoría de distribuciones empresariales, auditd viene preinstalado. Si no es tu caso:

# Debian/Ubuntu
sudo apt install auditd audispd-plugins

# RHEL/CentOS/Fedora
sudo dnf install audit audit-libs

# Verificar que el servicio está activo
sudo systemctl enable --now auditd
sudo systemctl status auditd

La configuración principal reside en /etc/audit/auditd.conf. Estos son los parámetros más relevantes para un entorno de producción:

# /etc/audit/auditd.conf - Configuración optimizada para seguridad

# Tamaño máximo del log antes de rotar (en MB)
max_log_file = 50

# Acción al alcanzar el tamaño máximo
max_log_file_action = ROTATE

# Número de archivos de log a conservar
num_logs = 10

# Acción cuando el disco está lleno
space_left_action = SYSLOG
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

# Formato del log (ENRICHED incluye nombres de usuario resueltos)
log_format = ENRICHED

# Flush frecuente para no perder eventos en caso de crash
flush = INCREMENTAL_ASYNC
freq = 50

# Nombre del log
log_file = /var/log/audit/audit.log

Reglas de auditoría alineadas con MITRE ATT&CK

Las reglas de auditoría son donde auditd realmente cobra vida. Una buena estrategia es organizarlas según las tácticas del framework MITRE ATT&CK, lo que facilita la correlación posterior con herramientas como Wazuh. Se definen en archivos dentro de /etc/audit/rules.d/.

Empecemos con las reglas fundamentales que todo servidor Linux debería tener:

# /etc/audit/rules.d/10-base.rules
# Configuración base del subsistema de auditoría

# Eliminar reglas anteriores
-D

# Establecer tamaño del buffer (aumentar en servidores con alta carga)
-b 8192

# Configurar la acción por fallo (1 = continuar, 2 = pánico del kernel)
-f 1

# Hacer las reglas inmutables después de cargarlas (requiere reinicio para cambiar)
# Descomentar en producción:
# -e 2
# /etc/audit/rules.d/20-identity.rules
# T1136 - Creación de cuentas | T1098 - Manipulación de cuentas

# Monitorizar cambios en archivos de identidad
-w /etc/passwd -p wa -k identity_modified
-w /etc/shadow -p wa -k identity_modified
-w /etc/group -p wa -k identity_modified
-w /etc/gshadow -p wa -k identity_modified
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation

# Monitorizar comandos de gestión de usuarios
-w /usr/sbin/useradd -p x -k user_management
-w /usr/sbin/userdel -p x -k user_management
-w /usr/sbin/usermod -p x -k user_management
-w /usr/sbin/groupadd -p x -k user_management
-w /usr/sbin/groupmod -p x -k user_management
# /etc/audit/rules.d/30-persistence.rules
# T1053 - Tareas programadas | T1543 - Servicios del sistema

# Monitorizar crontab y tareas programadas
-w /etc/crontab -p wa -k scheduled_tasks
-w /etc/cron.d/ -p wa -k scheduled_tasks
-w /etc/cron.daily/ -p wa -k scheduled_tasks
-w /etc/cron.hourly/ -p wa -k scheduled_tasks
-w /etc/cron.weekly/ -p wa -k scheduled_tasks
-w /var/spool/cron/ -p wa -k scheduled_tasks

# Monitorizar servicios systemd
-w /etc/systemd/system/ -p wa -k systemd_services
-w /usr/lib/systemd/system/ -p wa -k systemd_services

# Monitorizar módulos del kernel (rootkits)
-w /sbin/insmod -p x -k kernel_modules
-w /sbin/rmmod -p x -k kernel_modules
-w /sbin/modprobe -p x -k kernel_modules
-a always,exit -F arch=b64 -S init_module,finit_module -k kernel_modules
-a always,exit -F arch=b64 -S delete_module -k kernel_modules
# /etc/audit/rules.d/40-network.rules
# T1071 - Protocolo de capa de aplicación | T1095 - Protocolo no estándar

# Monitorizar conexiones de red salientes (detectar exfiltración/C2)
-a always,exit -F arch=b64 -S connect -F a2=16 -F success=1 -k network_connect_ipv4
-a always,exit -F arch=b64 -S connect -F a2=28 -F success=1 -k network_connect_ipv6

# Monitorizar cambios en configuración de red
-w /etc/hosts -p wa -k network_config
-w /etc/sysconfig/network -p wa -k network_config
-w /etc/network/ -p wa -k network_config
-w /etc/resolv.conf -p wa -k network_config

# Monitorizar cambios en reglas de firewall
-w /etc/nftables.conf -p wa -k firewall_rules
-w /etc/firewalld/ -p wa -k firewall_rules
# /etc/audit/rules.d/50-lotl.rules
# Detección de técnicas Living-off-the-Land (LOTL)
# Basado en advisories de CISA, FBI, NSA y NCSC-UK

# Herramientas de reconocimiento
-w /usr/bin/whoami -p x -k lotl_recon
-w /usr/bin/id -p x -k lotl_recon
-w /usr/bin/hostname -p x -k lotl_recon
-w /usr/bin/uname -p x -k lotl_recon
-w /usr/bin/netstat -p x -k lotl_recon
-w /usr/bin/ss -p x -k lotl_recon

# Herramientas de transferencia de datos
-w /usr/bin/curl -p x -k lotl_data_transfer
-w /usr/bin/wget -p x -k lotl_data_transfer
-w /usr/bin/scp -p x -k lotl_data_transfer
-w /usr/bin/rsync -p x -k lotl_data_transfer

# Herramientas de compresión (posible exfiltración)
-w /usr/bin/tar -p x -k lotl_archive
-w /usr/bin/gzip -p x -k lotl_archive
-w /usr/bin/zip -p x -k lotl_archive
-w /usr/bin/base64 -p x -k lotl_encoding

Para cargar las reglas sin reiniciar el servicio:

# Recargar reglas de auditoría
sudo augenrules --load

# Verificar las reglas activas
sudo auditctl -l

# Ver el estado del subsistema
sudo auditctl -s

Análisis de eventos con ausearch y aureport

Seamos honestos: los logs de auditd no son exactamente legibles a simple vista. Aquí es donde ausearch y aureport se vuelven indispensables:

# Buscar eventos de escalación de privilegios en las últimas 24 horas
sudo ausearch -k privilege_escalation -ts recent

# Buscar intentos de login fallidos
sudo ausearch -m USER_LOGIN --success no -ts today

# Generar resumen de autenticaciones
sudo aureport -au --summary

# Generar informe de eventos por clave
sudo aureport -k --summary

# Buscar ejecuciones de comandos por un usuario específico
sudo ausearch -ua 1001 -x /usr/bin/sudo -ts this-week

# Ver eventos de carga de módulos del kernel
sudo ausearch -k kernel_modules -i

Un detalle importante sobre auditd en 2026: la versión 4.14.2 de Wazuh añadió la detección de la regla -a never,task en el módulo FIM whodata para Linux. Esta regla, si un atacante la inserta de forma maliciosa, puede desactivar silenciosamente toda la auditoría. Monitorizarla explícitamente es una buena defensa contra técnicas de evasión bastante sofisticadas.

AIDE: Verificación de integridad de archivos

Si auditd te dice qué está pasando en tiempo real, AIDE (Advanced Intrusion Detection Environment) te dice qué ha cambiado desde la última vez que miraste. Es un sistema de detección basado en host que funciona comparando el estado actual del sistema de archivos con una base de datos de referencia creada previamente.

La idea es simple pero poderosa.

Si un binario crítico como /usr/bin/ssh o un archivo de configuración como /etc/sudoers ha sido modificado sin que nadie lo autorizara, algo anda muy mal. Un rootkit típicamente reemplaza binarios del sistema con versiones troyanizadas, y AIDE detecta exactamente eso.

Instalación y configuración inicial

# Debian/Ubuntu
sudo apt install aide

# RHEL/CentOS/Fedora
sudo dnf install aide

# Verificar la versión instalada
aide --version

La configuración de AIDE reside en /etc/aide/aide.conf (Debian/Ubuntu) o /etc/aide.conf (RHEL). La clave está en definir qué directorios y archivos monitorizar, y qué atributos verificar para cada uno:

# /etc/aide/aide.conf - Configuración optimizada para detección de intrusiones

# Ubicación de la base de datos
database_in=file:/var/lib/aide/aide.db
database_out=file:/var/lib/aide/aide.db.new
database_new=file:/var/lib/aide/aide.db.new

# Definir grupos de atributos personalizados
# CRITICAL: binarios del sistema - hash completo + permisos + propietario
CRITICAL = p+u+g+s+b+sha512+acl+selinux+xattrs

# CONFIG: archivos de configuración
CONFIG = p+u+g+sha256+acl+selinux

# LOG: solo monitorizar crecimiento (no contenido)
LOG = p+u+g+i+n+S

# DATAONLY: solo verificar contenido
DATAONLY = sha256

# ============================================
# Directorios y archivos a monitorizar
# ============================================

# Binarios críticos del sistema
/usr/bin CRITICAL
/usr/sbin CRITICAL
/usr/lib CRITICAL
/usr/lib64 CRITICAL

# Archivos de configuración del sistema
/etc/passwd CONFIG
/etc/shadow CONFIG
/etc/group CONFIG
/etc/gshadow CONFIG
/etc/sudoers CONFIG
/etc/sudoers.d CONFIG
/etc/ssh/sshd_config CONFIG
/etc/pam.d CONFIG
/etc/security CONFIG
/etc/audit CONFIG
/etc/systemd CONFIG
/etc/crontab CONFIG
/etc/cron.d CONFIG

# Archivos de arranque (detección de bootkits)
/boot CRITICAL

# Módulos del kernel
/lib/modules CRITICAL

# ============================================
# Exclusiones (evitar falsos positivos)
# ============================================

# Logs (cambian constantemente)
!/var/log
!/var/spool

# Archivos temporales
!/tmp
!/var/tmp
!/run

# Sistemas de archivos virtuales
!/proc
!/sys
!/dev

# Caché del sistema
!/var/cache

Inicialización y uso de la base de datos

El paso más crítico es crear la base de datos de referencia en un sistema que sabes que está limpio. Idealmente, esto se hace justo después de la instalación y hardening inicial del servidor, antes de exponerlo a la red:

# Inicializar la base de datos de AIDE (puede tardar varios minutos)
sudo aide --init

# Mover la base de datos nueva como la referencia activa
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Ejecutar una verificación manual
sudo aide --check

# Comparar contra la base de datos (genera informe detallado)
sudo aide --check --report=stdout

La salida de una verificación típica muestra archivos añadidos, eliminados y modificados, junto con los atributos específicos que cambiaron. Por ejemplo, una detección de algo sospechoso podría verse así:

AIDE found differences between database and filesystem!!

Summary:
  Total number of entries:  45678
  Added entries:            2
  Removed entries:          0
  Changed entries:          1

---------------------------------------------------
Added entries:
---------------------------------------------------
f++++++++++++++++: /usr/local/bin/backdoor.sh

---------------------------------------------------
Changed entries:
---------------------------------------------------
f >b.. .......... : /usr/bin/sudo
  SHA512   : aBcDeF123456... | xYz789ModIfIeD...

Esto muestra dos señales de alarma claras: un archivo nuevo sospechoso en /usr/local/bin/ y una modificación del hash SHA-512 del binario sudo. En un servidor correctamente administrado, estos binarios no deberían cambiar fuera de las ventanas de actualización programadas. Si ves algo así, tienes un problema serio entre manos.

Automatización con cron y alertas

AIDE debe ejecutarse de forma periódica y automática. La práctica recomendada es una verificación diaria:

# /etc/cron.d/aide-check
# Ejecutar verificación de integridad diariamente a las 03:00
0 3 * * * root /usr/bin/aide --check --report=stdout | /usr/bin/mail -s "AIDE Integrity Report - $(hostname)" [email protected] 2>&1

# Alternativa: guardar el informe en archivo con timestamp
0 3 * * * root /usr/bin/aide --check > /var/log/aide/aide-check-$(date +\%Y\%m\%d).log 2>&1

Actualización segura de la base de datos

Después de actualizaciones legítimas del sistema (parches, instalación de software), necesitas actualizar la base de datos de AIDE para que los cambios autorizados no generen alertas en futuras verificaciones:

# Después de una actualización legítima del sistema:

# 1. Verificar que los cambios son esperados
sudo aide --check

# 2. Actualizar la base de datos (genera aide.db.new con el estado actual)
sudo aide --update

# 3. Revisar los cambios antes de aceptarlos
# (IMPORTANTE: nunca actualizar ciegamente)

# 4. Si todo es correcto, promover la nueva base de datos
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Práctica de seguridad crucial: La base de datos de AIDE debería almacenarse en un medio de solo lectura o en un sistema externo. Si un atacante compromete el servidor, podría modificar tanto los archivos como la base de datos de AIDE para ocultar sus cambios. Almacenar la base de datos en un servidor remoto (vía NFS de solo lectura o SCP automatizado) elimina este riesgo. Es un paso que muchos se saltan, pero marca la diferencia.

Wazuh: Plataforma unificada SIEM/XDR

Hasta ahora tenemos auditd generando eventos a nivel de kernel y AIDE verificando la integridad de archivos. Pero estas herramientas, por sí solas, generan datos. Lo que necesitamos es inteligencia: correlación de eventos, detección de patrones de ataque, alertas en tiempo real y respuesta automatizada.

Eso es exactamente lo que proporciona Wazuh.

Wazuh es una plataforma de seguridad de código abierto que funciona como SIEM (Security Information and Event Management) y XDR (Extended Detection and Response). En su versión 4.14, lanzada en el último trimestre de 2025, ofrece capacidades que honestamente rivalizan con soluciones comerciales que cuestan decenas de miles de dólares al año.

Arquitectura de Wazuh

Wazuh se compone de tres componentes centrales y un agente ligero:

  • Wazuh Manager (Servidor): Recibe y analiza los datos enviados por los agentes. Ejecuta el motor de correlación de reglas, detecta anomalías y genera alertas.
  • Wazuh Indexer: Basado en OpenSearch (actualizado a la versión 2.19.1 en Wazuh 4.12), almacena y permite buscar eventos y alertas de forma eficiente.
  • Wazuh Dashboard: Interfaz web para visualización, análisis y gestión. Incluye dashboards predefinidos para cumplimiento normativo, vulnerabilidades, integridad de archivos y más.
  • Wazuh Agent: Software ligero instalado en cada endpoint monitorizado. Recopila logs, eventos del sistema, datos de inventario y detecta anomalías localmente antes de enviarlas al manager.

Instalación del servidor Wazuh (all-in-one)

Para entornos de laboratorio, desarrollo o infraestructuras pequeñas-medianas, la instalación all-in-one es la forma más rápida de tener Wazuh operativo:

# Instalación all-in-one de Wazuh (manager + indexer + dashboard)
# Requisitos mínimos: 4 vCPU, 8 GB RAM, 50 GB disco
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

# Al finalizar, el script muestra las credenciales de acceso al dashboard
# Acceder vía navegador: https://IP_DEL_SERVIDOR:443

Para entornos de producción a gran escala, se recomienda una arquitectura distribuida donde cada componente (manager, indexer, dashboard) se ejecuta en servidores separados. La documentación oficial de Wazuh incluye guías detalladas para este tipo de despliegue.

Despliegue del agente en endpoints Linux

Una vez el servidor está operativo, toca instalar el agente en cada sistema que quieras monitorizar:

# En sistemas Debian/Ubuntu:
wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.3-1_amd64.deb

sudo WAZUH_MANAGER='192.168.1.100' \
     WAZUH_AGENT_NAME='servidor-web-prod-01' \
     WAZUH_AGENT_GROUP='servidores-web' \
     dpkg -i ./wazuh-agent_4.14.3-1_amd64.deb

# Habilitar y arrancar el servicio
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

# Verificar la conexión con el manager
sudo /var/ossec/bin/agent-control -i 000
# En sistemas RHEL/CentOS/Fedora:
sudo WAZUH_MANAGER='192.168.1.100' \
     WAZUH_AGENT_NAME='servidor-db-prod-01' \
     WAZUH_AGENT_GROUP='bases-de-datos' \
     rpm -ihv https://packages.wazuh.com/4.x/yum/wazuh-agent-4.14.3-1.x86_64.rpm

sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

Novedades de Wazuh 4.12–4.14 relevantes para detección de intrusiones

Las versiones más recientes de Wazuh han añadido capacidades especialmente interesantes para la detección de intrusiones en Linux:

  • FIM con soporte eBPF (4.12): El módulo de File Integrity Monitoring ahora puede utilizar eBPF en Linux para monitorizar who-data (quién modificó un archivo y cómo), proporcionando visibilidad sin precedentes sin la sobrecarga de rendimiento que tenía inotify.
  • Referencias CTI en CVE (4.12): El módulo de detección de vulnerabilidades incluye referencias de Cyber Threat Intelligence dentro de los detalles de cada CVE, enriqueciendo el contexto para la toma de decisiones.
  • Priorización CISA sobre NVD (4.11): El escáner de vulnerabilidades prioriza datos de CISA sobre los del NVD, reduciendo falsos positivos y mejorando la alineación con fuentes oficiales.
  • Políticas SCA independientes de distribución (4.12): Nuevas políticas de Security Configuration Assessment que funcionan en cualquier distribución Linux, lo que facilita enormemente las auditorías en entornos heterogéneos.
  • Detección de regla audit -a never,task (4.14.2): Detecta intentos de desactivar la auditoría del sistema, una técnica de evasión empleada por atacantes sofisticados.

Integración: Haciendo que todo trabaje en conjunto

Bien, aquí es donde las cosas se ponen realmente interesantes. El verdadero poder de este enfoque aparece cuando las tres herramientas trabajan de forma coordinada. Wazuh actúa como el cerebro central que consume datos tanto de auditd como de AIDE, correlaciona eventos y genera alertas inteligentes.

Integración de auditd con Wazuh

Wazuh consume los logs de auditd de forma nativa. El agente lee los eventos desde /var/log/audit/audit.log y los envía al manager para su análisis. La configuración del agente debe incluir:

<!-- /var/ossec/etc/ossec.conf en el agente -->
<ossec_config>
  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>
</ossec_config>

Wazuh incluye decodificadores y reglas predefinidas para eventos de auditd. Cuando se detecta un evento con la clave privilege_escalation (que definimos en nuestras reglas de audit), Wazuh genera automáticamente una alerta con el nivel de severidad apropiado.

Para crear reglas personalizadas que se disparen ante eventos específicos:

<!-- /var/ossec/etc/rules/local_rules.xml en el manager -->
<group name="linux,audit,custom">

  <!-- Alerta cuando se detecta carga de módulo del kernel -->
  <rule id="100010" level="12">
    <if_sid>80700</if_sid>
    <field name="audit.key">kernel_modules</field>
    <description>Carga de módulo del kernel detectada - posible rootkit ($(audit.exe))</description>
    <mitre>
      <id>T1547.006</id>
    </mitre>
  </rule>

  <!-- Alerta cuando se detecta actividad LOTL sospechosa -->
  <rule id="100011" level="10">
    <if_sid>80700</if_sid>
    <field name="audit.key">lotl_data_transfer</field>
    <description>Posible exfiltración de datos: ejecución de herramienta de transferencia ($(audit.exe))</description>
    <mitre>
      <id>T1048</id>
    </mitre>
  </rule>

  <!-- Alerta por modificación de sudoers -->
  <rule id="100012" level="14">
    <if_sid>80700</if_sid>
    <field name="audit.key">privilege_escalation</field>
    <field name="audit.file.name">sudoers</field>
    <description>Modificación del archivo sudoers detectada - verificar autorización</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>

</group>

Integración de AIDE con Wazuh

Wazuh incluye su propio módulo FIM (syscheck) que puede coexistir con AIDE o reemplazarlo en ciertos escenarios. Sin embargo, usar ambos proporciona una capa adicional de verificación (y en seguridad, la redundancia suele ser algo bueno). Para integrar los informes de AIDE con Wazuh:

<!-- /var/ossec/etc/ossec.conf en el agente -->
<ossec_config>
  <!-- Monitorizar el log de verificación de AIDE -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/aide/aide-check-*.log</location>
  </localfile>

  <!-- Activar el módulo FIM nativo de Wazuh como complemento -->
  <syscheck>
    <disabled>no</disabled>
    <frequency>43200</frequency> <!-- Cada 12 horas -->

    <!-- Directorios críticos con monitorización en tiempo real -->
    <directories check_all="yes" realtime="yes">/etc/ssh</directories>
    <directories check_all="yes" realtime="yes">/etc/sudoers.d</directories>
    <directories check_all="yes" realtime="yes">/etc/pam.d</directories>

    <!-- Directorios con verificación whodata (eBPF en 4.12+) -->
    <directories check_all="yes" whodata="yes">/usr/bin</directories>
    <directories check_all="yes" whodata="yes">/usr/sbin</directories>

    <!-- Exclusiones -->
    <ignore>/etc/mtab</ignore>
    <ignore type="sregex">.log$</ignore>
  </syscheck>
</ossec_config>

Respuesta activa automatizada

Una de las funcionalidades más potentes de Wazuh es la capacidad de ejecutar respuestas activas ante alertas específicas. Esto transforma tu sistema de un IDS pasivo a un IPS que puede tomar acciones correctivas de forma automática:

<!-- /var/ossec/etc/ossec.conf en el manager -->
<ossec_config>
  <!-- Bloquear IP después de múltiples intentos de SSH fallidos -->
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5763</rules_id> <!-- SSH brute force -->
    <timeout>3600</timeout> <!-- Bloquear por 1 hora -->
  </active-response>

  <!-- Notificar al equipo de seguridad ante modificación de binarios -->
  <active-response>
    <command>custom-notify</command>
    <location>server</location>
    <rules_id>100010,100012</rules_id>
  </active-response>
</ossec_config>

Detección de rootkits y amenazas avanzadas

Los rootkits siguen siendo una de las amenazas más peligrosas para servidores Linux. Aunque las detecciones disminuyeron un 11,6% año tras año (gracias a kernels más endurecidos), los ataques se han vuelto notablemente más sofisticados. Grupos como Curly COMrades han demostrado que actores de estado-nación tratan Linux como un objetivo prioritario.

Detección de rootkits con Wazuh

Wazuh incluye un módulo integrado de detección de rootkits (rootcheck) que busca archivos ocultos, procesos encubiertos, listeners de red no registrados e inconsistencias en las respuestas de llamadas al sistema:

<!-- /var/ossec/etc/ossec.conf - Configuración de rootcheck -->
<ossec_config>
  <rootcheck>
    <disabled>no</disabled>
    <frequency>36000</frequency> <!-- Cada 10 horas -->

    <!-- Bases de datos de firmas de rootkits -->
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>

    <!-- Verificar anomalías del sistema -->
    <check_files>yes</check_files>
    <check_trojans>yes</check_trojans>
    <check_dev>yes</check_dev>
    <check_sys>yes</check_sys>
    <check_pids>yes</check_pids>
    <check_ports>yes</check_ports>
    <check_if>yes</check_if>
  </rootcheck>
</ossec_config>

Detección conductual a nivel de kernel

La detección basada en firmas tiene sus limitaciones — no puede detectar rootkits zero-day. Un enfoque complementario es la detección conductual, que identifica comportamientos anómalos independientemente de la firma del malware.

Las reglas de auditd que definimos anteriormente para monitorizar init_module y finit_module son un buen ejemplo: cualquier intento de cargar un módulo del kernel genera una alerta, sin importar qué módulo sea. Combinado con las verificaciones de integridad de AIDE sobre /lib/modules/, tenemos dos capas independientes que un atacante tendría que evadir simultáneamente.

Para una protección adicional a nivel de kernel, vale la pena considerar Linux Kernel Runtime Guard (LKRG). Es un módulo del kernel que verifica la integridad de las estructuras del kernel en tiempo de ejecución y puede detectar exploits de escalación de privilegios incluso sin conocer el CVE específico que se está explotando.

Auditoría de cumplimiento con SCA

El módulo Security Configuration Assessment (SCA) de Wazuh permite verificar automáticamente si tus sistemas cumplen con estándares como CIS Benchmarks, PCI DSS o STIG. En la versión 4.12, Wazuh añadió políticas SCA para Linux independientes de distribución, lo que simplifica bastante las auditorías en entornos heterogéneos.

<!-- /var/ossec/etc/ossec.conf - Configuración de SCA -->
<ossec_config>
  <sca>
    <enabled>yes</enabled>
    <scan_on_start>yes</scan_on_start>
    <interval>12h</interval>

    <!-- Políticas a evaluar -->
    <policies>
      <policy>cis_debian_linux_12.yml</policy>
      <policy>cis_distribution_independent_linux.yml</policy>
    </policies>
  </sca>
</ossec_config>

El dashboard de Wazuh muestra los resultados del SCA con un desglose claro de controles aprobados, fallidos y no aplicables, junto con instrucciones de remediación para cada hallazgo. Lo que antes era un proceso manual que podía llevar días se convierte en una verificación automatizada y continua.

Centralización de logs y retención segura

Un sistema de detección de intrusiones es tan bueno como sus logs. Si un atacante puede borrar o modificar los logs del sistema comprometido, toda la cadena de detección se rompe. Así de simple. La centralización de logs en un servidor remoto es una medida de seguridad fundamental.

Envío seguro de logs a Wazuh

El agente de Wazuh envía todos los eventos al manager a través de un canal cifrado y autenticado por defecto. Pero para los logs de auditd y AIDE, hay algunas consideraciones adicionales:

# Configurar rsyslog para enviar logs de audit a un servidor remoto como respaldo
# /etc/rsyslog.d/60-audit-remote.conf

# Cargar módulo de salida TCP con TLS
module(load="omfwd")

# Enviar logs de auditoría al servidor de logs centralizado
if $programname == 'audispd' then {
    action(
        type="omfwd"
        target="siem.tudominio.com"
        port="1514"
        protocol="tcp"
        StreamDriver="gtls"
        StreamDriverMode="1"
        StreamDriverAuthMode="x509/name"
    )
}

Inmutabilidad de logs

Para garantizar que los logs no puedan ser manipulados, considera estas prácticas:

  • Almacenamiento WORM (Write Once Read Many): Algunos sistemas de almacenamiento soportan modo WORM que impide la modificación o eliminación de datos una vez escritos.
  • Atributo inmutable del filesystem: Utiliza chattr +a en los archivos de log para que solo se puedan agregar datos, sin posibilidad de modificar o eliminar los existentes.
  • Servidor de logs dedicado: Mantén un servidor cuya única función sea recibir y almacenar logs, con acceso restringido al equipo de seguridad.
  • Retención adecuada: La regulación PCI DSS exige conservar logs de auditoría al menos 12 meses, con los 3 meses más recientes disponibles para análisis inmediato.
# Hacer los archivos de log de auditoría append-only
sudo chattr +a /var/log/audit/audit.log

# Verificar el atributo
lsattr /var/log/audit/audit.log
# Salida esperada: -----a--------e--- /var/log/audit/audit.log

Despliegue automatizado con Ansible

Configurar manualmente auditd, AIDE y Wazuh en cada servidor es viable cuando tienes cinco máquinas. Cuando tienes cincuenta o quinientas, necesitas automatización. Ansible es ideal para esto porque no requiere agentes adicionales (usa SSH) y los playbooks son declarativos y relativamente fáciles de mantener.

# playbook-ids-completo.yml
---
- name: Desplegar sistema de detección de intrusiones
  hosts: servidores_linux
  become: yes
  vars:
    wazuh_manager_ip: "192.168.1.100"
    aide_cron_hour: "3"
    aide_cron_minute: "0"

  tasks:
    # ============ auditd ============
    - name: Instalar auditd
      package:
        name:
          - audit
          - audit-libs
        state: present

    - name: Desplegar reglas de auditoría
      copy:
        src: "audit-rules/{{ item }}"
        dest: "/etc/audit/rules.d/{{ item }}"
        owner: root
        group: root
        mode: '0640'
      loop:
        - 10-base.rules
        - 20-identity.rules
        - 30-persistence.rules
        - 40-network.rules
        - 50-lotl.rules
      notify: Recargar reglas audit

    - name: Habilitar y arrancar auditd
      systemd:
        name: auditd
        enabled: yes
        state: started

    # ============ AIDE ============
    - name: Instalar AIDE
      package:
        name: aide
        state: present

    - name: Desplegar configuración de AIDE
      template:
        src: aide.conf.j2
        dest: /etc/aide.conf
        owner: root
        group: root
        mode: '0600'

    - name: Inicializar base de datos de AIDE
      command: aide --init
      args:
        creates: /var/lib/aide/aide.db.new

    - name: Activar base de datos de AIDE
      copy:
        src: /var/lib/aide/aide.db.new
        dest: /var/lib/aide/aide.db
        remote_src: yes

    - name: Configurar verificación diaria de AIDE
      cron:
        name: "AIDE daily check"
        hour: "{{ aide_cron_hour }}"
        minute: "{{ aide_cron_minute }}"
        job: "/usr/bin/aide --check > /var/log/aide/aide-check-$(date +\\%Y\\%m\\%d).log 2>&1"
        user: root

    # ============ Wazuh Agent ============
    - name: Instalar agente Wazuh
      apt:
        deb: "https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.3-1_amd64.deb"
      environment:
        WAZUH_MANAGER: "{{ wazuh_manager_ip }}"
        WAZUH_AGENT_NAME: "{{ inventory_hostname }}"
      when: ansible_os_family == "Debian"

    - name: Habilitar y arrancar Wazuh Agent
      systemd:
        name: wazuh-agent
        enabled: yes
        state: started
        daemon_reload: yes

  handlers:
    - name: Recargar reglas audit
      command: augenrules --load

Conclusión: Defensa en profundidad que realmente funciona

Implementar un sistema de detección de intrusiones efectivo en Linux no es cuestión de instalar una herramienta y olvidarse. Se trata de construir capas complementarias de visibilidad que se refuercen mutuamente:

  • auditd proporciona la capa más profunda — auditoría a nivel de kernel con registro inmutable de llamadas al sistema, accesos a archivos y eventos de red. Es tu testigo silencioso.
  • AIDE añade verificación criptográfica de la integridad del sistema de archivos. Si alguien reemplaza un binario por una versión troyanizada, AIDE lo detectará comparando hashes. Es tu detector de manipulaciones.
  • Wazuh unifica todo en una plataforma inteligente que correlaciona eventos, detecta patrones de ataque y puede responder automáticamente. Es tu cerebro analítico.

La clave es que estas tres capas son independientes entre sí. Un atacante que logre evadir auditd modificando las reglas de auditoría será detectado por AIDE cuando verifique la integridad de los archivos de configuración. Un rootkit que esquive la detección de AIDE será capturado por Wazuh al correlacionar comportamientos anómalos reportados por auditd. Un atacante tendría que evadir las tres capas simultáneamente — algo exponencialmente más difícil que evadir cualquiera de ellas por separado.

No existe la seguridad perfecta, eso lo sabemos todos. Pero con estas herramientas correctamente configuradas, integradas y monitorizadas, puedes reducir drásticamente el tiempo de detección de una intrusión — pasando de semanas o meses a minutos u horas. Y en seguridad, el tiempo de detección es frecuentemente la diferencia entre un incidente contenido y una catástrofe.

Sobre el Autor Editorial Team

Our team of expert writers and editors.