Cómo instalar OSSEC HIDS en Ubuntu 24.04

OSSEC es un sistema de detección de intrusiones basado en host (HIDS) de código abierto. Analiza los logs del sistema en tiempo real, vigila cambios en archivos críticos, busca rootkits y puede bloquear automáticamente direcciones IP que atacan el servidor. En este tutorial compilarás e instalarás OSSEC en Ubuntu 24.04 en modo local, comprobarás que detecta intentos de acceso por SSH y cambios en /etc, y verás cómo añadir otros servidores como agentes.

Requisitos previos

Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath, con al menos 1 GB de RAM.
Un usuario no root con privilegios sudo.
Opcional: un servidor SMTP (o relay) si quieres recibir alertas por correo.
Opcional: otros servidores Linux que quieras monitorizar como agentes.

Nota

OSSEC sigue publicando versiones, pero su desarrollo es lento. Wazuh es un fork de OSSEC con mantenimiento más activo e interfaz web propia. Los conceptos de esta guía (reglas, decodificadores, syscheck, respuesta activa) se aplican a ambos.

Paso 1: Instalar las dependencias de compilación

OSSEC no está en los repositorios de Ubuntu, así que se compila desde el código fuente. Instala el compilador y las bibliotecas que necesita:

sudo apt update
sudo apt install build-essential make zlib1g-dev libpcre2-dev libevent-dev libssl-dev libsystemd-dev wget

Paso 2: Descargar el código fuente

Consulta la última versión estable en la página de versiones del proyecto, https://github.com/ossec/ossec-hids/releases. Esta guía usa la 3.8.0; cambia el número si hay una más reciente:

cd ~
wget https://github.com/ossec/ossec-hids/archive/3.8.0.tar.gz -O ossec-hids-3.8.0.tar.gz
tar -xzf ossec-hids-3.8.0.tar.gz
cd ossec-hids-3.8.0

Comprueba que tienes el instalador:

ls install.sh

install.sh

Paso 3: Ejecutar el instalador

El script install.sh es interactivo: compila OSSEC, crea los usuarios del sistema y genera la configuración inicial en /var/ossec. Ejecútalo como root:

sudo ./install.sh

Responde a las preguntas así:

Pregunta	Respuesta recomendada
Idioma	`es` o `en`
Tipo de instalación	`local` (un solo servidor) o `server` (si vas a añadir agentes)
Directorio de instalación	`/var/ossec` (valor por defecto)
Notificación por correo	`y` con tu dirección y servidor SMTP, o `n`
Integrity check daemon (syscheck)	`y`
Rootkit detection (rootcheck)	`y`
Active response	`y`
Firewall-drop response	`y`
Lista blanca	Añade la IP desde la que administras el servidor

La compilación tarda unos minutos. Al terminar verás un resumen parecido a este:

 - Configuration finished properly.

 - To start OSSEC HIDS:
      /var/ossec/bin/ossec-control start

 - To stop OSSEC HIDS:
      /var/ossec/bin/ossec-control stop

 - The configuration can be viewed or modified at /var/ossec/etc/ossec.conf

Importante

Añade siempre tu IP de administración a la lista blanca. Si no lo haces y te equivocas varias veces con la contraseña de SSH, la respuesta activa puede bloquearte el acceso al servidor.

Paso 4: Arrancar OSSEC y comprobar su estado

Inicia los procesos de OSSEC:

sudo /var/ossec/bin/ossec-control start

Comprueba que todos los demonios están en marcha:

sudo /var/ossec/bin/ossec-control status

ossec-monitord is running...
ossec-logcollector is running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild is running...
ossec-execd is running...

El instalador también registra OSSEC para que arranque con el sistema. El log interno del propio OSSEC, útil para detectar errores de configuración, está en /var/ossec/logs/ossec.log:

sudo tail -n 20 /var/ossec/logs/ossec.log

Paso 5: Revisar la configuración principal

Toda la configuración está en /var/ossec/etc/ossec.conf, un archivo XML. Ábrelo para revisar las secciones clave:

sudo nano /var/ossec/etc/ossec.conf

La sección global controla el correo y la lista blanca:

<global>
  <email_notification>yes</email_notification>
  <email_to>admin@your_domain</email_to>
  <smtp_server>127.0.0.1</smtp_server>
  <email_from>ossec@your_domain</email_from>
  <white_list>127.0.0.1</white_list>
  <white_list>your_admin_ip</white_list>
</global>

La sección alerts define desde qué nivel se registran y se envían alertas. Los niveles van de 0 a 15; con 7 recibirás por correo solo lo relevante:

<alerts>
  <log_alert_level>1</log_alert_level>
  <email_alert_level>7</email_alert_level>
</alerts>

Las secciones localfile indican qué logs se analizan. En Ubuntu 24.04 los accesos por SSH y el uso de sudo quedan en /var/log/auth.log, que ya viene incluido:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

Si instalas Nginx, por ejemplo, añade su log de acceso con el formato adecuado:

<localfile>
  <log_format>apache</log_format>
  <location>/var/log/nginx/access.log</location>
</localfile>

Tras cualquier cambio en ossec.conf, reinicia OSSEC:

sudo /var/ossec/bin/ossec-control restart

Paso 6: Comprobar la detección de ataques por SSH

Las alertas se escriben en /var/ossec/logs/alerts/alerts.log. Déjalo abierto en una terminal:

sudo tail -f /var/ossec/logs/alerts/alerts.log

Desde otro equipo (no desde tu IP de la lista blanca si quieres ver también la respuesta activa), intenta entrar con un usuario que no existe:

ssh usuario_inexistente@your_server_ip

En pocos segundos aparecerá una alerta como esta:

** Alert 1790330400.1234: - syslog,sshd,invalid_login,authentication_failed,
2026 Sep 25 10:00:00 web01->/var/log/auth.log
Rule: 5710 (level 5) -> 'Attempt to login using a non-existent user'
Src IP: 198.51.100.77
Invalid user usuario_inexistente from 198.51.100.77 port 50412

Si repites el intento varias veces, OSSEC eleva el nivel con la regla de fuerza bruta y, si la respuesta activa está habilitada, bloquea la IP de origen. Las acciones de respuesta activa quedan registradas en:

sudo tail /var/ossec/logs/active-responses.log

Paso 7: Configurar la integridad de archivos (syscheck)

Syscheck calcula sumas de verificación de los archivos que le indiques y avisa cuando cambian. Busca la sección syscheck en ossec.conf y ajústala:

<syscheck>
  <frequency>43200</frequency>
  <alert_new_files>yes</alert_new_files>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes">/usr/bin,/usr/sbin,/bin,/sbin</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/adjtime</ignore>
</syscheck>

frequency: segundos entre escaneos completos (aquí, cada 12 horas).
realtime="yes": usa inotify para detectar cambios en /etc al momento, sin esperar al siguiente escaneo.
ignore: archivos que cambian a menudo de forma legítima y solo generarían ruido.

Reinicia OSSEC y espera a que termine el primer escaneo, que sirve como referencia:

sudo /var/ossec/bin/ossec-control restart
sudo grep -i "syscheck scan" /var/ossec/logs/ossec.log | tail -n 2

2026/09/25 10:05:12 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database).
2026/09/25 10:07:40 ossec-syscheckd: INFO: Ending syscheck scan (forwarding database).

Ahora modifica un archivo vigilado para comprobar la detección:

echo "# prueba ossec" | sudo tee -a /etc/motd

En alerts.log aparecerá una alerta de la regla 550 (Integrity checksum changed) con el archivo modificado y las sumas anteriores y nuevas. Deshaz el cambio de prueba con sudo nano /etc/motd.

Paso 8: Ajustar la respuesta activa

La respuesta activa ejecuta un script cuando una alerta alcanza cierto nivel. La configuración que crea el instalador es similar a esta:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <level>6</level>
  <timeout>600</timeout>
</active-response>

firewall-drop bloquea la IP de origen con iptables.
level es el nivel mínimo de la alerta que lo dispara.
timeout es el tiempo en segundos que dura el bloqueo; después se levanta solo.

Si detectas bloqueos indeseados, sube level o limita la respuesta a reglas concretas con <rules_id>5712,5720</rules_id> en lugar de <level>. Recuerda reiniciar OSSEC tras cada cambio.

Paso 9: Añadir reglas propias

No edites las reglas de /var/ossec/rules/ que trae OSSEC, porque se sobrescriben al actualizar. Las reglas propias van en local_rules.xml, con identificadores a partir de 100000:

sudo nano /var/ossec/rules/local_rules.xml

Este ejemplo eleva a nivel 10 (y por tanto envía correo) cualquier uso de sudo para ejecutar su:

<group name="local,syslog,">
  <rule id="100010" level="10">
    <if_sid>5402</if_sid>
    <match>COMMAND=/usr/bin/su</match>
    <description>Uso de sudo para abrir una shell con su</description>
  </rule>
</group>

Antes de reiniciar, prueba la regla con ossec-logtest, que procesa líneas de log sin afectar al servicio:

sudo /var/ossec/bin/ossec-logtest

Pega una línea de ejemplo y pulsa Intro:

Sep 25 10:10:00 web01 sudo:     marc : TTY=pts/0 ; PWD=/home/marc ; USER=root ; COMMAND=/usr/bin/su

La salida debe terminar indicando que la regla 100010 ha coincidido:

**Phase 3: Completed filtering (rules).
       Rule id: '100010'
       Level: '10'
       Description: 'Uso de sudo para abrir una shell con su'
**Alert to be generated.

Sal con Ctrl+C y reinicia OSSEC para cargar la regla.

Paso 10: Añadir agentes (instalación servidor)

Si instalaste OSSEC en modo server, puedes monitorizar otros servidores desde él. Los agentes se comunican con el servidor por UDP 1514, así que ábrelo solo para tus agentes:

sudo ufw allow from agent_ip to any port 1514 proto udp

En el servidor, registra el agente con manage_agents:

sudo /var/ossec/bin/manage_agents

Elige A para añadir un agente (nombre e IP) y después E para extraer su clave. Copia la clave que muestra.

En el servidor que será agente, repite los pasos 1 a 3 eligiendo agent como tipo de instalación e indicando la IP del servidor OSSEC. Después importa la clave:

sudo /var/ossec/bin/manage_agents

Elige I, pega la clave y confirma. Arranca el agente con sudo /var/ossec/bin/ossec-control start y, de vuelta en el servidor, comprueba que aparece conectado:

sudo /var/ossec/bin/agent_control -l

OSSEC HIDS agent_control. List of available agents:
   ID: 000, Name: ossec-server (server), IP: 127.0.0.1, Active/Local
   ID: 001, Name: web02, IP: 203.0.113.25, Active

Las alertas de todos los agentes se centralizan en el alerts.log del servidor.

Solución de problemas

Un demonio no arranca. Revisa /var/ossec/logs/ossec.log. La causa más habitual es un error de sintaxis XML en ossec.conf o local_rules.xml; el log indica el archivo y la línea.

No llegan correos. Comprueba que ossec-maild está en marcha, que el smtp_server acepta conexiones sin autenticación desde el servidor (OSSEC no soporta autenticación SMTP) y que las alertas alcanzan email_alert_level. Lo habitual es usar un relay local como Postfix.

El agente aparece como Never connected. Suele ser el puerto UDP 1514 cerrado, una IP mal registrada en manage_agents o una clave importada en otro agente. Revisa /var/ossec/logs/ossec.log en el agente.

Demasiado ruido de syscheck. Añade con <ignore> los archivos que cambian por diseño (cachés, bases de datos) o saca esos directorios de la vigilancia.

Conclusión

Tienes OSSEC analizando los logs del servidor, vigilando la integridad de /etc y los binarios del sistema y bloqueando automáticamente ataques de fuerza bruta. Como siguientes pasos, puedes añadir los logs de tus aplicaciones con nuevas secciones localfile, escribir reglas propias para eventos específicos de tu entorno y centralizar varios servidores con agentes.

On this page