> For the complete documentation index, see [llms.txt](https://novahacking.gitbook.io/anonymous17/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://novahacking.gitbook.io/anonymous17/articulos/ids-ips-suricata.md). # IDS - IPS (Suricata) TAG -> Artículos Un **IDS (Sistema de Detección de Intrusiones)** y un **IPS (Sistema de Prevención de Intrusiones)** son tecnologías fundamentales en la **ciberseguridad** para supervisar actividades sospechosas y proteger redes o sistemas. Aunque comparten mecanismos de inspección y detección, **se diferencian principalmente en su capacidad para intervenir sobre el tráfico**. En este artículo explico sus conceptos y documento un laboratorio práctico con **Suricata**. ## IDS (Sistema de Detección de Intrusiones) Un **IDS** monitoriza el tráfico de red o los eventos de un sistema para identificar **patrones de ataques, comportamientos anómalos o indicadores de compromiso**. Su función principal es **detectar, registrar y generar alertas** sin bloquear directamente las comunicaciones. Puede operar **en tiempo real**, por lo que no debe confundirse su capacidad de alerta con una detección exclusivamente posterior al incidente: * **Registra eventos y genera alertas** cuando el tráfico o las actividades coinciden con firmas, reglas o criterios de detección. * **No interviene directamente** en el tráfico que inspecciona, de modo que los administradores o sistemas de respuesta pueden investigar las alertas y decidir cómo actuar. * Es útil en entornos donde necesitamos **visibilidad y análisis de amenazas** sin alterar el flujo del tráfico, ya sea para monitorización continua, auditoría o investigación posterior. ### Existen dos tipos principales de IDS: 1. **NIDS (Network-based IDS)**: supervisa el **tráfico de red** que puede observar desde una interfaz o punto de captura, e identifica firmas y anomalías. Su visibilidad depende de dónde esté conectado y del tráfico que efectivamente reciba. 2. **HIDS (Host-based IDS)**: funciona en **equipos individuales (hosts)** y monitoriza elementos como registros, procesos, archivos o eventos del sistema para detectar posibles intrusiones. ## IPS (Sistema de Prevención de Intrusiones) Un **IPS** combina la detección de amenazas con la capacidad de **prevenir o bloquear determinados paquetes o conexiones** de acuerdo con las reglas configuradas. Para intervenir necesita estar integrado **en línea (inline)** en la ruta del tráfico o mediante un mecanismo equivalente. A diferencia de un IDS pasivo, puede afectar las comunicaciones si detecta un patrón que requiere una acción preventiva: * **Bloquear o descartar paquetes** que coincidan con reglas de prevención antes de que continúen hacia su destino. * **Rechazar o interrumpir conexiones** cuando la configuración y el mecanismo de captura lo permitan; no todas las acciones son equivalentes a modificar los paquetes. * **Aplicar medidas automáticas** ante amenazas conocidas, como intentos de explotación o propagación de malware. Su eficacia contra **DDoS** y otros ataques depende de la capacidad, la posición del sensor y las reglas: no garantiza detener cualquier ataque. ## Diferencias clave entre IDS e IPS | Característica | IDS | IPS | | ----------------------- | ----------------------------------------------- | ----------------------------------------- | | Objetivo | Detectar y alertar sobre actividad sospechosa | Detectar y aplicar acciones de prevención | | Enfoque | Monitorización y generación de alertas | Inspección y prevención en línea | | Actuación en el tráfico | Observa sin bloquear directamente | Puede descartar o rechazar tráfico | | Uso típico | Visibilidad, auditoría y respuesta a incidentes | Protección de tráfico en tiempo real | ## Suricata **Suricata** es un motor de **detección y prevención de intrusiones** de alto rendimiento y de código abierto, desarrollado por la **Open Information Security Foundation (OISF)**. Puede funcionar como **IDS** o como **IPS**, analizar tráfico de red y generar eventos y alertas basados en firmas y protocolos. Su arquitectura multihilo facilita el procesamiento de grandes volúmenes de tráfico, siempre que el hardware y el despliegue estén dimensionados correctamente. ### **Características principales de Suricata:** 1. **Funcionalidad dual (IDS/IPS)**: puede configurarse para **observar y alertar** en modo IDS o para **descartar/rechazar tráfico** en modo IPS. El bloqueo requiere que el tráfico pase efectivamente por el motor inline y que existan reglas con acciones de prevención. 2. **Análisis de tráfico multicapa**: inspecciona distintos niveles de la comunicación, incluidos encabezados de red, sesiones y protocolos de aplicación. Esto permite correlacionar eventos que no se identifican únicamente mediante los puertos. 3. **Compatibilidad con reglas Snort**: admite muchas firmas con una sintaxis similar a la de **Snort**, lo que facilita reutilizar conjuntos de reglas. No obstante, **no todas las opciones de reglas son necesariamente compatibles** entre versiones y motores. 4. **Rendimiento y escalabilidad**: permite el procesamiento multihilo para aprovechar los recursos disponibles y adaptarse a redes con volúmenes de tráfico elevados, según la configuración y la capacidad del equipo. 5. **Análisis de protocolos específicos**: incluye analizadores para protocolos como **HTTP, DNS, SMB y TLS**, que ayudan a detectar comportamientos sospechosos y a generar eventos. El tráfico cifrado limita la visibilidad del contenido si no se dispone de mecanismos adicionales autorizados. ### **Ejemplos de uso de Suricata:** * **Empresas y organizaciones**: lo utilizan para supervisar la red y detectar indicios de intrusión, **exfiltración de datos** o accesos no autorizados; en modo IPS también pueden aplicar acciones de bloqueo. * **Proyectos de investigación y auditoría de seguridad**: permite estudiar paquetes, crear reglas y evaluar la detección de distintas técnicas en laboratorios y entornos autorizados, por lo que también resulta útil para el **Blue Team**. *** ### **Creación del laboratorio** Me conectaré por **SSH** a un servidor de mi red para configurar **Suricata como IDS**. El equipo del ejemplo utiliza una interfaz llamada `enp0s3` y la IP **192.168.43.45**. Primero actualizaré los paquetes instalados mediante los siguientes comandos. Aunque en mis notas lo llamo «contenedor», la salida también muestra características de un entorno Linux con interfaz de red y servicio propios; los pasos concretos dependen de cómo esté desplegado. ```python [root@template]-[~]# apt update && apt upgrade -y ``` A continuación, instalaremos las herramientas que utilizaremos, incluido **Suricata**, con el gestor de paquetes del sistema: ```python [root@template]-[~]# apt install net-tools lsb-release vim suricata ``` Con esto tendremos los componentes necesarios para empezar a preparar el laboratorio, pero todavía debemos **seleccionar la interfaz, configurar las redes, cargar las reglas y comprobar el servicio**. Primero comprobaremos las interfaces de red disponibles en el sistema y la dirección IP asignada a cada una: ```bash [root@template]-[~]# ifconfig enp0s3: flags=4163 mtu 1500 inet 192.168.43.45 netmask 255.255.255.0 broadcast 192.168.43.255 inet6 fe80::a00:27ff:fed9:aae7 prefixlen 64 scopeid 0x20 ether 08:00:27:d9:aa:e7 txqueuelen 1000 (Ethernet) RX packets 63310 bytes 91293368 (87.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 13421 bytes 1157711 (1.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@template]-[~]# ``` La salida muestra que nuestra interfaz de red es **`enp0s3`**, con IP **192.168.43.45**. Revisaremos `/etc/default/suricata` mediante `vim` para observar los parámetros de arranque que utiliza **esta instalación**; estos archivos y opciones pueden cambiar según la versión y el paquete de Suricata. ```bash [root@template]-[~]# vim /etc/default/suricata ``` **Contenido:** ```php # Default config for Suricata # set to yes to start the server in the init.d script RUN=no # Configuration file to load SURCONF=/etc/suricata/suricata.yaml # Listen mode: pcap, nfqueue or af-packet # depending on this value, only one of the two following options # will be used (af-packet uses neither). # Please note that IPS mode is only available when using nfqueue LISTENMODE=nfqueue # Interface to listen on (for pcap mode) IFACE=eth0 # Queue number to listen on (for nfqueue mode) NFQUEUE=0 # Load Google TCMALLOC if libtcmalloc-minimal4 is installed # This _might_ give you very very small performance gain.... TCMALLOC="YES" # Pid file PIDFILE=/var/run/suricata.pid ``` En el archivo del ejemplo aparece **`IFACE=eth0`**, mientras que la interfaz real es **`enp0s3`**. Si usamos captura mediante **pcap** y este archivo controla el arranque, debemos corregirla. También aparece `RUN=no`, que puede impedir iniciar el servicio a través de este mecanismo. **Atención:** aquí figura `LISTENMODE=nfqueue`; en ese modo `IFACE` no selecciona automáticamente el tráfico inspeccionado. Para usar NFQUEUE se necesita además una configuración que envíe paquetes a la cola. Después revisaremos `/etc/suricata/suricata.yaml`, el archivo principal de configuración. Al abrir `/etc/suricata/suricata.yaml` con `vim`, buscaremos los apartados de captura que contengan `interface`. En este laboratorio sustituiremos el nombre **`eth0`** por **`enp0s3`** en la sección que corresponda al modo de captura realmente utilizado. También revisaremos **`HOME_NET`**, que define las **direcciones o subredes consideradas internas para las reglas**, no necesariamente el único tráfico que Suricata puede capturar. Como la IP del servidor es **192.168.43.45** y la máscara es **255.255.255.0**, la subred del ejemplo es **192.168.43.0/24**: ```python vars: address-groups: HOME_NET: "[192.168.43.0/24]" ``` Revisaremos además `default-log-dir: /var/log/suricata/`, que establece la **ubicación predeterminada de los registros**. Podemos mantener esta ruta o utilizar otra que tenga los permisos adecuados. Más adelante consultaremos `fast.log` para confirmar que se generan alertas. Después de guardar la configuración, ejecutaré **`suricata-update`** para **descargar, actualizar y preparar las firmas**. Este comando no equivale a reiniciar el servicio ni garantiza por sí solo que las nuevas reglas estén activas en el proceso que ya está ejecutándose: ```bash [root@template]-[~]# suricata-update 4/11/2024 -- 01:04:11 - -- Using data-directory /var/lib/suricata. 4/11/2024 -- 01:04:11 - -- Using Suricata configuration /etc/suricata/suricata.yaml 4/11/2024 -- 01:04:11 - -- Using /etc/suricata/rules for Suricata provided rules. 4/11/2024 -- 01:04:11 - -- Found Suricata version 6.0.10 at /usr/bin/suricata. 4/11/2024 -- 01:04:11 - -- Loading /etc/suricata/suricata.yaml 4/11/2024 -- 01:04:11 - -- Disabling rules for protocol http2 4/11/2024 -- 01:04:11 - -- Disabling rules for protocol modbus 4/11/2024 -- 01:04:11 - -- Disabling rules for protocol dnp3 4/11/2024 -- 01:04:11 - -- Disabling rules for protocol enip 4/11/2024 -- 01:04:11 - -- No sources configured, will use Emerging Threats Open 4/11/2024 -- 01:04:11 - -- Fetching https://rules.emergingthreats.net/open/suricata-6.0.10/emerging.rules.tar.gz. 100% - 4572160/4572160 4/11/2024 -- 01:04:17 - -- Done. 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/app-layer-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/decoder-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/dhcp-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/dnp3-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/dns-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/files.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/http-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/ipsec-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/kerberos-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/modbus-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/nfs-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/ntp-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/smb-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/smtp-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/stream-events.rules 4/11/2024 -- 01:04:17 - -- Loading distribution rule file /etc/suricata/rules/tls-events.rules 4/11/2024 -- 01:04:17 - -- Ignoring file rules/emerging-deleted.rules 4/11/2024 -- 01:04:19 - -- Loaded 53906 rules. 4/11/2024 -- 01:04:20 - -- Disabled 14 rules. 4/11/2024 -- 01:04:20 - -- Enabled 0 rules. 4/11/2024 -- 01:04:20 - -- Modified 0 rules. 4/11/2024 -- 01:04:20 - -- Dropped 0 rules. 4/11/2024 -- 01:04:20 - -- Enabled 136 rules for flowbit dependencies. 4/11/2024 -- 01:04:20 - -- Backing up current rules. 4/11/2024 -- 01:04:20 - -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 53906; enabled: 40261; added: 53906; removed 0; modified: 0 4/11/2024 -- 01:04:20 - -- Writing /var/lib/suricata/rules/classification.config 4/11/2024 -- 01:04:20 - -- Testing with suricata -T. 4/11/2024 -- 01:04:50 - -- Done. [root@template]-[~]# ``` La salida indica que se descargaron las firmas de **Emerging Threats Open** y que `suricata-update` generó **`/var/lib/suricata/rules/suricata.rules`**. Es importante conservar la diferencia: los archivos enumerados posteriormente en **`/etc/suricata/rules/`** corresponden a reglas suministradas con el paquete, mientras que el conjunto descargado y combinado en este ejemplo quedó en **`/var/lib/suricata/rules/`**. Las reglas que el motor carga efectivamente dependen de `default-rule-path` y `rule-files` en `suricata.yaml`. ```bash [root@template]-[/etc/suricata/rules]# ll total 132 -rw-r--r-- 1 root root 1858 ene 31 2023 app-layer-events.rules -rw-r--r-- 1 root root 20880 ene 31 2023 decoder-events.rules -rw-r--r-- 1 root root 468 ene 31 2023 dhcp-events.rules -rw-r--r-- 1 root root 1221 ene 31 2023 dnp3-events.rules -rw-r--r-- 1 root root 1041 ene 31 2023 dns-events.rules -rw-r--r-- 1 root root 4003 ene 31 2023 files.rules -rw-r--r-- 1 root root 2128 ene 31 2023 http2-events.rules -rw-r--r-- 1 root root 13390 ene 31 2023 http-events.rules -rw-r--r-- 1 root root 2717 ene 31 2023 ipsec-events.rules -rw-r--r-- 1 root root 585 ene 31 2023 kerberos-events.rules -rw-r--r-- 1 root root 2078 ene 31 2023 modbus-events.rules -rw-r--r-- 1 root root 2187 ene 31 2023 mqtt-events.rules -rw-r--r-- 1 root root 558 ene 31 2023 nfs-events.rules -rw-r--r-- 1 root root 558 ene 31 2023 ntp-events.rules -rw-r--r-- 1 root root 4346 ene 31 2023 smb-events.rules -rw-r--r-- 1 root root 5167 ene 31 2023 smtp-events.rules -rw-r--r-- 1 root root 719 ene 31 2023 ssh-events.rules -rw-r--r-- 1 root root 12992 ene 31 2023 stream-events.rules -rw-r--r-- 1 root root 6861 ene 31 2023 tls-events.rules [root@template]-[/etc/suricata/rules]# ``` Estos son archivos de **reglas incluidos con la instalación de Suricata**. Podemos examinar uno de ellos para comprender el formato de las firmas. No debemos confundir **un archivo presente en disco** con una regla que ya esté **habilitada y cargada** en el motor: ```python [root@template]-[/etc/suricata/rules]# cat dns-events.rules # Malformed data in request. Malformed means length fields are wrong, etc. alert dns any any -> any any (msg:"SURICATA DNS malformed request data"; flow:to_server; app-layer-event:dns.malformed_data; classtype:protocol-command-decode; sid:2240002; rev:2;) alert dns any any -> any any (msg:"SURICATA DNS malformed response data"; flow:to_client; app-layer-event:dns.malformed_data; classtype:protocol-command-decode; sid:2240003; rev:2;) # Response flag set on to_server packet alert dns any any -> any any (msg:"SURICATA DNS Not a request"; flow:to_server; app-layer-event:dns.not_a_request; classtype:protocol-command-decode; sid:2240004; rev:2;) # Response flag not set on to_client packet alert dns any any -> any any (msg:"SURICATA DNS Not a response"; flow:to_client; app-layer-event:dns.not_a_response; classtype:protocol-command-decode; sid:2240005; rev:2;) # Z flag (reserved) not 0 alert dns any any -> any any (msg:"SURICATA DNS Z flag set"; app-layer-event:dns.z_flag_set; classtype:protocol-command-decode; sid:2240006; rev:2;) [root@template]-[/etc/suricata/rules]# ``` > La presencia de estas firmas en `/etc/suricata/rules/` **no demuestra que estén cargadas**. Para comprobarlo debemos revisar `rule-files`, el conjunto de reglas generado por `suricata-update` y los mensajes de inicio o prueba de Suricata. Ahora crearé mi primera **regla personalizada** en el archivo `regla_1.rules`, con el objetivo de generar una alerta cuando el sensor observe determinadas solicitudes ICMP: ```python [root@template]-[/etc/suricata/rules]# vim regla_1.rules ``` **Contenido**: ```python alert icmp any any -> any any (msg:"ALERTA: Trafico ICMP detectado"; itype:8; sid:10000001; rev:1;) ``` * **`alert`**: especifica la **acción de la firma**. Si coincide, Suricata genera una alerta; **no bloquea** ese tráfico por sí sola. * **`icmp`**: define el protocolo que se analizará. En este caso se utiliza **ICMP**, que incluye mensajes como las solicitudes y respuestas de eco de `ping`. * **`any any`**: define el **origen** de la comunicación según el formato de una regla de Suricata. * Primer `any`: representa **cualquier dirección IP de origen**. * Segundo `any`: corresponde al campo de **puerto de origen** del encabezado de regla. En ICMP los puertos TCP/UDP no existen; aquí `any` actúa como un comodín sintáctico. * **`->`**: establece la **dirección de coincidencia de la regla**, desde el origen hacia el destino; no significa que el paquete vaya a reenviarse. * **`any any`** (después de la flecha): define la **dirección y el puerto de destino**, en este caso sin restringirlos. * Primer `any`: representa **cualquier dirección IP de destino**. * Segundo `any`: utiliza un comodín para el campo de puerto; en el protocolo **ICMP** no existe un puerto de destino como en TCP o UDP. * **`msg:"ALERTA: Trafico ICMP detectado"`**: es el **mensaje literal** que aparecerá en la alerta cuando coincida la firma. Mantengo exactamente el texto utilizado en el ejemplo y en sus salidas. * **`itype:8`**: filtra el **tipo ICMP 8**, que en **ICMPv4** representa una **solicitud de eco (Echo Request)**, como la que envía normalmente `ping`. * **`sid:10000001`**: identifica de forma única la **firma** en el conjunto de reglas cargado. El valor **10000001** es el que utilizo en esta regla de laboratorio. * **`rev:1`**: indica la **revisión de la firma**. Aquí estamos trabajando con la revisión **1**, que puede incrementarse cuando modificamos su lógica. Después añadiré el archivo `regla_1.rules` a la sección **`rule-files`** de `/etc/suricata/suricata.yaml`. También hay que comprobar que la ruta del archivo coincida con `default-rule-path`; conviene **conservar las reglas distribuidas que necesitemos** en lugar de sustituirlas sin evaluar su efecto. ```python rule-files: - regla_1.rules ``` > En ocasiones también debemos ajustar **`default-rule-path`**, porque determina dónde buscará Suricata los archivos de reglas **indicados por nombre** en `rule-files`. Si el archivo está en otra carpeta, podemos usar una **ruta absoluta**. Es importante probar la configuración antes de reiniciar el servicio. Con las modificaciones realizadas, intentaremos **reiniciar el servicio** para aplicar la configuración. Si falla, analizaremos el mensaje de error en lugar de asumir que la nueva regla ya se cargó: ```python [root@template]-[/etc/suricata/rules]# service suricata restart suricata disabled, please adjust the configuration to your needs ... failed! and then set RUN to 'yes' in /etc/default/suricata to enable it. ... failed! [root@parrot]-[/etc/suricata/rules]# ``` Si aparece el mensaje mostrado, el mecanismo de arranque indica que Suricata está **deshabilitado en esta instalación**. Revisaremos el siguiente archivo y su opción correspondiente: * Editar `/etc/default/suricata`, que es el archivo de configuración de arranque utilizado en este ejemplo. * Buscar `RUN=no` y cambiarlo a **`RUN=yes`** cuando esa opción sea la requerida por el servicio instalado. También debemos comprobar que `LISTENMODE` corresponda al modo de captura configurado. Si hemos actualizado el conjunto de firmas, podemos ejecutar nuevamente `suricata-update`. Sin embargo, **esto no corrige por sí solo los errores de sintaxis del YAML ni habilita automáticamente el servicio**: ```python [root@template]-[~]# suricata-update ``` A continuación, intentaremos iniciar **Suricata** y consultar el estado del servicio. Debemos verificar no solo que aparezca **active (running)**, sino también qué **interfaz, modo de captura y archivos de reglas** está utilizando: ```python [root@template]-[~]# service suricata start [root@template]-[~]# service suricata status ● suricata.service - Suricata IDS/IDP daemon Loaded: loaded (/lib/systemd/system/suricata.service; enabled; preset: enabled) Active: active (running) since Mon 2024-11-04 01:53:59 CST; 7min ago Docs: man:suricata(8) man:suricatasc(8) https://suricata-ids.org/docs/ Process: 501 ExecStart=/usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid (code=exited, status=0/SUCCESS) Main PID: 621 (Suricata-Main) Tasks: 7 (limit: 1099) Memory: 62.1M CPU: 4.150s CGroup: /system.slice/suricata.service └─621 /usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid nov 04 01:53:49 template systemd[1]: Starting suricata.service - Suricata IDS/IDP daemon... nov 04 01:53:57 template suricata[501]: 4/11/2024 -- 01:53:57 - - This is Suricata version 6.0.10 RELEASE running in SYSTEM mode nov 04 01:53:59 template systemd[1]: Started suricata.service - Suricata IDS/IDP daemon. [root@template]-[~]# ``` Para comprobar las alertas generadas, podemos seguir en tiempo real el registro **`fast.log`** de Suricata con el siguiente comando: ```python [root@template]-[~]# tail -f /var/log/suricata/fast.log ``` Desde **otra máquina de la red del laboratorio**, realizaremos una prueba enviando una solicitud **ICMP Echo Request** mediante `ping` hacia **192.168.43.45**: * Ejemplo: ```bash ❯ ping -c 1 192.168.43.45 -R PING 192.168.43.45 (192.168.43.45) 56(124) bytes of data. 64 bytes from 192.168.43.45: icmp_seq=1 ttl=64 time=0.463 ms RR: 192.168.43.58 192.168.43.45 192.168.43.45 192.168.43.58 --- 192.168.43.45 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.463/0.463/0.463/0.000 ms ``` Si el tráfico llega a la interfaz monitorizada y la regla ICMP está cargada, en el servidor podremos observar una alerta como la siguiente: ```python [root@template]-[~]# tail -f /var/log/suricata/fast.log 11/04/2024-02:04:58.989467 [**] [1:10000001:1] ALERTA: Trafico ICMP detectado [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.43.58:8 -> 192.168.43.45:0 ``` La salida confirma que **Suricata ha registrado una coincidencia con nuestra regla ICMP**, identificada mediante el **SID 10000001**. Es evidencia de **detección en modo IDS**, no de que se haya bloqueado el `ping`. A continuación prepararé más reglas para observar otros tipos de tráfico: ```python [root@template]-[~]# cat /etc/suricata/rules/regla_1.rules alert icmp any any -> any any (msg:"ALERTA: Trafico ICMP detectado"; itype:8; sid:10000001; rev:1;) alert tcp any any -> any 80 (msg:"ALERTA: Trafico HTTP entrante detectado"; sid:10000002; rev:1;) alert tcp any any -> any any (msg:"ALERTA: Escaneo de puertos detectado"; sid:10000003; rev:1; flags:S; flow:stateless; threshold: type both, track by_src, count 3, seconds 3;) alert http any any -> any 80 (msg:"ALERTA: Acceso al directorio /gestion_usuarios detectado"; content:"/gestion_usuarios"; http_uri; sid:10000004; rev:1;) [root@template]-[~]# ``` * **Regla 1: Detección de tráfico ICMP (Ping)**. Esta firma identifica solicitudes **ICMPv4 de tipo 8** que atraviesan el sensor. * **Tipo**: `alert icmp` * **Condición**: Cualquier dirección IP y puerto origen a cualquier IP y puerto destino. * **Descripción**: Genera una alerta cuando detecta tráfico ICMP tipo 8 (solicitud de eco o "ping"). * **Mensaje**: "ALERTA: Trafico ICMP detectado" * **SID**: 10000001 (identificador único de regla). * **Revisión**: 1 * **Regla 2: Detección de tráfico hacia el puerto 80 (HTTP)**. Identifica tráfico TCP dirigido al puerto **80**, aunque no demuestra que el contenido sea una solicitud HTTP válida. * **Tipo**: `alert tcp` * **Condición**: Cualquier IP y puerto origen hacia cualquier IP en el puerto 80 (HTTP). * **Descripción**: Genera una alerta cuando detecta tráfico TCP entrante hacia el puerto HTTP (80). * **Mensaje**: "ALERTA: Trafico HTTP entrante detectado" * **SID**: 10000002 * **Revisión**: 1 * **Regla 3: Detección de posibles escaneos de puertos**. Examina paquetes TCP con el flag **SYN** y aplica un umbral temporal. * **Tipo**: `alert tcp` * **Condición**: Cualquier IP y puerto origen hacia cualquier IP y puerto destino. * **Flags**: la regla identifica paquetes con el flag **SYN (`S`)**, usado al iniciar conexiones TCP. También aparece en tráfico legítimo. * **Descripción**: alerta al alcanzar un umbral de **3 paquetes SYN en 3 segundos** por IP de origen. Este patrón puede indicar un escaneo, pero también producir **falsos positivos**. * **Mensaje**: "ALERTA: Escaneo de puertos detectado" * **SID**: 10000003 * **Revisión**: 1 * **Regla 4: Detección de acceso a un directorio específico (`/gestion_usuarios`) mediante HTTP**. Busca una URI concreta en las solicitudes que procesa Suricata. * **Tipo**: `alert http` * **Condición**: Cualquier IP y puerto origen hacia cualquier IP en el puerto 80 (HTTP). * **Contenido**: `content:"/gestion_usuarios"; http_uri;` busca la cadena en la **URI HTTP** examinada por el motor, según la sintaxis y la versión utilizadas. * **Descripción**: alerta si la URI contiene `/gestion_usuarios`; no confirma que el recurso exista ni que la solicitud haya conseguido acceder. * **Mensaje**: "ALERTA: Acceso al directorio /gestion\_usuarios detectado" * **SID**: 10000004 * **Revisión**: 1 Ahora mostraré varias opciones de **Nmap** para comparar cómo afectan a las alertas. En el laboratorio **no conseguí evitar la detección del tráfico hacia el puerto 80**, coherente con una regla que identifica conexiones hacia ese puerto de forma muy general. La ausencia de alertas no garantiza evasión: depende también de la ubicación del sensor, las reglas y la visibilidad del tráfico. *** ```bash nmap -Pn -F --open 192.168.43.45 ``` * **`-Pn`**: omite la fase de **descubrimiento previo de hosts** y asume que el objetivo está activo. No evita las sondas que se enviarán durante el escaneo. * **`-F`**: utiliza un conjunto reducido de puertos frecuentes (habitualmente unos **100 puertos TCP**), reduciendo la duración y el número de puertos analizados, pero no garantizando evasión. * **`--open`**: filtra la **visualización de resultados** para mostrar los puertos abiertos o posiblemente abiertos, sin modificar por sí sola la detectabilidad de los paquetes. **Propósito**: identificar rápidamente los servicios accesibles en puertos frecuentes. La menor cantidad de sondas puede disminuir el volumen de tráfico, pero **no asegura que Suricata deje de detectarlas**. *** ```bash nmap -sS -Pn -D 10.10.10.1,10.10.10.2,ME -F --open 192.168.43.45 ``` * **`-sS`**: realiza un escaneo **TCP SYN (*****half-open*****)** sin completar normalmente el establecimiento de la conexión. Sigue siendo observable para un IDS/IPS y no es indetectable. * **`-D 10.10.10.1,10.10.10.2,ME`**: configura dos direcciones como **señuelos (decoys)** y conserva la IP real mediante `ME`. Permite estudiar cómo el sensor registra orígenes simulados, pero **no garantiza ocultar la IP real**. * **`-F`**: utiliza un conjunto reducido de puertos frecuentes (habitualmente unos **100 puertos TCP**), reduciendo la duración y el número de puertos analizados, pero no garantizando evasión. * **`--open`**: filtra la **visualización de resultados** para mostrar los puertos abiertos o posiblemente abiertos, sin modificar por sí sola la detectabilidad de los paquetes. **Propósito**: evaluar cómo los **señuelos** influyen en la interpretación de las alertas. El IDS todavía puede registrar los paquetes y observar orígenes reales y simulados. *** ```bash nmap -sS -Pn -D RND,RND,ME -F --open 192.168.43.45 ``` * **`-D RND,RND,ME`**: emplea **dos direcciones IP aleatorias como señuelos**, además de la IP real. Es útil para estudiar cómo se presentan diferentes direcciones de origen en los registros. **Propósito**: comparar las alertas asociadas a **direcciones simuladas y reales**. La aleatorización no convierte el escaneo en anónimo ni garantiza pasar desapercibido. *** ```bash nmap -sS -Pn --proxies http://192.168.43.1:8080 -F --open 192.168.43.45 ``` * **`--proxies`**: permite encaminar **determinadas conexiones TCP compatibles** mediante proxies. **No redirige en general los paquetes crudos de un escaneo SYN (`-sS`)**; combinar ambas opciones no significa que el SYN atraviese ese proxy. **Propósito**: observar las diferencias de visibilidad entre conexiones que **sí admiten proxy** y sondeos de paquetes crudos. Debemos verificar que el tipo de escaneo seleccionado realmente utiliza el proxy. *** ```bash nmap -sS -Pn -T1 --scan-delay 500ms --max-retries 1 --max-scan-delay 1000ms -f -F 192.168.43.45 ``` * **`-T1`**: selecciona el perfil de temporización **lento (Sneaky)**, que reduce la frecuencia de los sondeos y permite comprobar cómo afectan a las reglas con umbrales temporales. * **`--scan-delay 500ms`**: establece al menos **500 ms entre sondas al mismo host**. Esto puede cambiar el comportamiento de las reglas basadas en frecuencia, pero no impide todas las detecciones. * **`--max-retries 1`**: limita las retransmisiones por falta de respuesta, reduciendo paquetes adicionales y pudiendo afectar a la precisión del escaneo. * **`--max-scan-delay 1000ms`**: limita el retraso adaptativo máximo a **1000 ms**; no garantiza que el escaneo resulte invisible. * **`-f`**: solicita la fragmentación de determinados paquetes IPv4. Su efecto depende del tipo de escaneo y de la red, y los IDS modernos pueden **reensamblar fragmentos**. **Propósito**: comparar un escaneo **más lento, con menos retransmisiones y paquetes fragmentados**. Son variables útiles para evaluar las firmas, no una garantía de evasión; deben probarse únicamente en una red autorizada. *** Cada prueba modifica características como **velocidad, temporización, cantidad de paquetes y orígenes observados**. Comparar estas diferencias con las alertas permite evaluar las reglas del laboratorio sin confundir un cambio de resultado con una evasión confirmada. *** Para evaluar otra forma de acceder al servicio HTTP del laboratorio, utilizaremos un **túnel SSH local**. Esto requiere disponer de credenciales autorizadas en la máquina remota y permite analizar cómo cambia el tráfico observable por el IDS: ```python ❯ ssh -L 8080:localhost:80 test@192.168.43.45 test@192.168.43.45's password: Linux template 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Nov 4 08:35:02 2024 from 192.168.43.58 test@template:~$ ``` Una vez creado el túnel, podemos acceder desde nuestro equipo a **`localhost:8080`**, que reenviará la conexión al puerto **80** del servidor a través de **SSH**. Un sensor que únicamente vea la parte cifrada no podrá inspeccionar el HTTP interno, **pero sí puede detectar la conexión SSH**. Otro sensor en el host o en el punto de salida del túnel podría ver la solicitud HTTP, por lo que **no garantiza evitar la detección**. *** ## **Reglas más específicas para detectar y bloquear escaneos** Podemos utilizar condiciones como **flags TCP, flujo y umbrales** para analizar posibles escaneos realizados con **Nmap**. A continuación se documenta una regla de `regla_2.rules` y sus opciones. **Detectar no equivale a bloquear**: para impedir el paso de paquetes necesitamos que Suricata esté en **modo IPS inline**, reciba efectivamente el tráfico y aplique una regla de prevención como `drop` o `reject`. ### **Ejemplo de Regla**** ****`regla_2.rules`**** ****en Suricata** ```python alert tcp any any -> any any (msg:"ALERTA: Escaneo de puertos (SYN y ACK) detectado"; \ sid:2000001; rev:1; flags:SA; flow:stateless; \ classtype:attempted-recon; priority:2; detection_filter:track by_src, count 1, seconds 10;) ``` ### **Explicación de la Regla** 1. **`msg`**: determina el mensaje de la firma, aquí "ALERTA: Escaneo de puertos (SYN y ACK) detectado". El texto describe el patrón buscado, **no prueba que todo paquete coincidente pertenezca a un escaneo**. 2. **`sid`**: identifica la firma mediante el valor **`2000001`**, que debe ser único en el conjunto de reglas. 3. **`rev`**: indica la revisión de la firma. El ejemplo utiliza **`rev:1`** para esta primera versión. 4. **`flags`**: con `flags:SA` buscamos paquetes TCP con **SYN y ACK**. Estos paquetes pueden ser respuestas legítimas a intentos de conexión, **no únicamente escaneos**. 5. **`flow`**: `flow:stateless` permite evaluar la firma **sin exigir un estado concreto de la conexión**. No desactiva globalmente el seguimiento de flujos que realiza Suricata. 6. **`classtype`**: asigna la categoría de alerta **`attempted-recon`**, cuya descripción depende del archivo de clasificaciones configurado. 7. **`priority`**: establece la **prioridad de la alerta**, donde normalmente un número menor indica mayor urgencia. El valor `2` no confirma que la actividad sea realmente maliciosa. 8. **`detection_filter`**: aplica un umbral por **IP de origen**, aquí `count 1, seconds 10`. Al ser tan bajo, puede generar alertas por tráfico legítimo **SYN/ACK**, por lo que no garantiza reducir falsos positivos. ### **Consideraciones Adicionales** * **Detección de otros tipos de escaneo**: para estudiar paquetes FIN, NULL o XMAS pueden añadirse firmas con las combinaciones de flags correspondientes, comprobando cada caso mediante pruebas. * **Optimización de las reglas**: es importante ajustar `detection_filter` y `threshold` según el tráfico habitual y los **falsos positivos**. En este laboratorio se usan valores sensibles para ilustrar las alertas, pero podrían generar demasiado ruido en producción. ### **Opciones Adicionales para Personalizar la Regla** Para ajustar la **detección y la posible prevención** de tráfico en Suricata, podemos utilizar opciones adicionales dentro de las firmas. Es importante distinguir entre **metadatos**, **condiciones de coincidencia** y **acciones de la regla**: * **`action`**: Suricata admite acciones como **`alert`**, **`drop`**, **`reject`** y **`pass`**. `alert` genera una alerta, mientras que `drop` o `reject` pueden impedir el paso de tráfico **si el motor está operando correctamente en modo IPS inline**. El fragmento siguiente es solo un esquema: contiene `...` y **no es una regla completa ni válida para cargar directamente**. ```python drop tcp any any -> any any (msg:"BLOQUEADO: Escaneo de puertos detectado"; ...) ``` Si la regla se completa correctamente y está **cargada en un Suricata inline que realmente intercepta los paquetes**, `drop` podrá descartar el tráfico coincidente. Por sí sola, una línea de ejemplo no garantiza bloqueo alguno. * **`reference`**: añade una **referencia externa** a una firma, por ejemplo a una página de documentación o a un identificador público. El siguiente fragmento ilustra el formato de la opción: ```python reference:url,https://nmap.org ``` * **`metadata`**: permite añadir **información contextual** a la firma, como el autor, una etiqueta de objetivo o la fecha de creación. Estos campos no determinan por sí solos si el tráfico coincide con la regla: ```python metadata:author "Anon"; attack_target any; created_at 2024-11-04; ``` * **`ttl`**: permite definir condiciones sobre el valor **Time To Live (TTL)** de paquetes IP; puede servir para estudiar patrones concretos, pero los valores normales varían entre sistemas y rutas: ```bash ttl: 128; ``` * **`ip_proto`**: permite restringir el **protocolo IP** al que se aplica una firma, cuando su sintaxis es compatible con el encabezado de regla correspondiente. Aquí se presenta un ejemplo con **ICMP**: ```js ip_proto: icmp; ``` ### **Configuración de Bloqueo Activo en Suricata** Para bloquear tráfico de forma activa, **Suricata debe estar en modo IPS inline**, de modo que los paquetes circulen por el mecanismo de captura configurado, como **NFQUEUE** o un despliegue **AF\_PACKET inline**. Además, la firma debe utilizar una acción de prevención (`drop` o `reject`) y estar **correctamente cargada**. En el bloque siguiente se muestra la intención de crear una regla `drop`, pero contiene `...` y **no puede utilizarse literalmente como configuración ejecutable**: ```python drop tcp any any -> any any (msg:"BLOQUEADO: Escaneo de puertos detectado"; ...) ``` Con una **regla válida, cargada y coincidente**, Suricata podrá bloquear el tráfico si se encuentra en la ruta **inline**. En cambio, **las reglas `alert` y las capturas de `fast.log` de este artículo demuestran detección, no bloqueo**. Un mismo conjunto de reglas puede producir falsos positivos, por lo que conviene probarlo antes de activarlo en producción. > **Verificación del archivo de configuración (`suricata.yaml`)**: > > Entre los errores más habituales están los **archivos de reglas mal referenciados**, las **opciones incorrectas de `suricata.yaml`**, una interfaz inexistente o reglas con sintaxis inválida. Es recomendable ejecutar la prueba de configuración antes de iniciar el servicio: > > ```python > suricata -T -c /etc/suricata/suricata.yaml > ``` > > Esta prueba permite validar los archivos y las firmas cargadas, y puede mostrar errores de sintaxis o configuración. **No prueba que NFQUEUE esté recibiendo paquetes, que la interfaz vea tráfico ni que el IPS bloquee realmente**: esas condiciones requieren verificaciones adicionales. **Reglas documentadas en los archivos del laboratorio** → todas utilizan la acción **`alert`**, por lo que estos ejemplos corresponden a **detección IDS**. Que aparezcan en `cat` no demuestra por sí solo que todas estén cargadas y activas; hay que comprobar la configuración y el arranque. ```python [root@template]-[~]# cat /etc/suricata/rules/regla_1.rules alert icmp any any -> any any (msg:"ALERTA: Trafico ICMP detectado"; itype:8; sid:10000001; rev:1;) alert tcp any any -> any 80 (msg:"ALERTA: Trafico HTTP entrante detectado"; sid:10000002; rev:1;) alert tcp any any -> any any (msg:"ALERTA: Escaneo de puertos detectado"; sid:10000003; rev:1; flags:S; flow:stateless; threshold: type both, track by_src, count 3, seconds 3;) alert http any any -> any 80 (msg:"ALERTA: Acceso al directorio /gestion_usuarios detectado"; content:"/gestion_usuarios"; http_uri; sid:10000004; rev:1;) [root@template]-[~]# cat /etc/suricata/rules/regla_2.rules alert tcp any any -> any any (msg:"ALERTA: Escaneo de puertos (SYN y ACK) detectado"; \ sid:2000001; rev:1; flags:SA; flow:stateless; \ classtype:attempted-recon; priority:2; detection_filter:track by_src, count 1, seconds 10;) [root@template]-[~]# ``` **Ataque** ```python ❯ nmap -sS -Pn -T0 --scan-delay 5000ms --max-retries 1 --max-scan-delay 5000ms -f -p 21,22,80 192.168.43.45 Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-04 11:42 EST Nmap scan report for 192.168.43.45 Host is up (0.0015s latency). PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http MAC Address: 08:00:27:D9:AA:E7 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 20.30 seconds ``` **IDS** ```python [root@template]-[~]# tail -f /var/log/suricata/fast.log 11/04/2024-10:42:29.394927 [**] [1:10000002:1] ALERTA: Trafico HTTP entrante detectado [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.43.58:56893 -> 192.168.43.45:80 11/04/2024-10:42:29.395011 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 192.168.43.58:56893 ``` {% hint style="info" %} Detectado {% endhint %} *** **Ataque** ```python ❯ nmap -sS -Pn -D RND,RND,ME -F --open --proxies http://192.168.43.1:8080 192.168.43.45 Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-04 12:02 EST Nmap scan report for 192.168.43.45 Host is up (0.031s latency). Not shown: 87 filtered tcp ports (no-response), 8 filtered tcp ports (admin-prohibited), 2 closed tcp ports (reset) Some closed ports may be reported as filtered due to --defeat-rst-ratelimit PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http MAC Address: 08:00:27:D9:AA:E7 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 2.55 seconds ``` **IDS** ```python [root@template]-[~]# tail -f /var/log/suricata/fast.log 11/04/2024-11:02:24.227066 [**] [1:10000003:1] ALERTA: Escaneo de puertos detectado [**] [Classification: (null)] [Priority: 3] {TCP} 31.40.191.95:37868 -> 192.168.43.45:111 11/04/2024-11:02:24.228435 [**] [1:10000003:1] ALERTA: Escaneo de puertos detectado [**] [Classification: (null)] [Priority: 3] {TCP} 169.194.164.191:37868 -> 192.168.43.45:111 11/04/2024-11:02:24.229719 [**] [1:10000003:1] ALERTA: Escaneo de puertos detectado [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.43.58:37868 -> 192.168.43.45:111 11/04/2024-11:02:24.243360 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 169.194.164.191:37868 11/04/2024-11:02:24.244718 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 192.168.43.58:37868 11/04/2024-11:02:24.295444 [**] [1:10000002:1] ALERTA: Trafico HTTP entrante detectado [**] [Classification: (null)] [Priority: 3] {TCP} 31.40.191.95:37868 -> 192.168.43.45:80 11/04/2024-11:02:24.295475 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 31.40.191.95:37868 11/04/2024-11:02:24.296724 [**] [1:10000002:1] ALERTA: Trafico HTTP entrante detectado [**] [Classification: (null)] [Priority: 3] {TCP} 169.194.164.191:37868 -> 192.168.43.45:80 11/04/2024-11:02:24.296763 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 169.194.164.191:37868 11/04/2024-11:02:24.298065 [**] [1:10000002:1] ALERTA: Trafico HTTP entrante detectado [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.43.58:37868 -> 192.168.43.45:80 11/04/2024-11:02:24.298093 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 192.168.43.58:37868 11/04/2024-11:02:24.302819 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 31.40.191.95:37868 11/04/2024-11:02:24.304056 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 169.194.164.191:37868 11/04/2024-11:02:24.305403 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 192.168.43.58:37868 11/04/2024-11:02:25.254129 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 169.194.164.191:37868 11/04/2024-11:02:25.254177 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 31.40.191.95:37868 11/04/2024-11:02:25.318099 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 169.194.164.191:37868 11/04/2024-11:02:25.318147 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 31.40.191.95:37868 11/04/2024-11:02:25.318160 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 169.194.164.191:37868 11/04/2024-11:02:25.318171 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 31.40.191.95:37868 11/04/2024-11:02:27.270117 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 31.40.191.95:37868 11/04/2024-11:02:27.270166 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 169.194.164.191:37868 11/04/2024-11:02:27.334192 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 31.40.191.95:37868 11/04/2024-11:02:27.334248 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 169.194.164.191:37868 11/04/2024-11:02:27.334278 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 31.40.191.95:37868 11/04/2024-11:02:27.334293 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 169.194.164.191:37868 11/04/2024-11:02:31.494176 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 169.194.164.191:37868 11/04/2024-11:02:31.494236 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 31.40.191.95:37868 11/04/2024-11:02:31.494275 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 169.194.164.191:37868 11/04/2024-11:02:31.494287 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 31.40.191.95:37868 11/04/2024-11:02:31.494300 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 169.194.164.191:37868 11/04/2024-11:02:31.494312 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 31.40.191.95:37868 11/04/2024-11:02:39.686396 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 169.194.164.191:37868 11/04/2024-11:02:39.686496 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 31.40.191.95:37868 11/04/2024-11:02:39.686528 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 169.194.164.191:37868 11/04/2024-11:02:39.686554 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 31.40.191.95:37868 11/04/2024-11:02:39.686720 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 169.194.164.191:37868 11/04/2024-11:02:55.814301 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:22 -> 31.40.191.95:37868 11/04/2024-11:02:55.814319 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 169.194.164.191:37868 11/04/2024-11:02:55.814333 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:80 -> 31.40.191.95:37868 11/04/2024-11:02:55.814349 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 169.194.164.191:37868 11/04/2024-11:02:55.814364 [**] [1:2000001:1] ALERTA: Escaneo de puertos (SYN y ACK) detectado [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.43.45:21 -> 31.40.191.95:37868 ``` {% hint style="info" %} Detectado y por Mucho {% endhint %} *** **Suricata** permite asociar una **clasificación (`classtype`)** y una **prioridad** a las alertas para facilitar su interpretación. A continuación conservo una lista de etiquetas que pueden aparecer en diferentes conjuntos de reglas o configuraciones. **No todas tienen por qué existir de manera predeterminada en cada instalación**: el catálogo efectivo depende de `classification.config`. Además, una clasificación como `successful-*` describe una categoría asignada a la firma, **no constituye por sí sola una prueba forense de que el ataque haya tenido éxito**. ## Clasificaciones comunes en Suricata 1. **`attempted-recon`**: clasifica actividad compatible con **intentos de reconocimiento**, como determinados escaneos o sondeos. La alerta no demuestra automáticamente intención maliciosa. 2. **`successful-recon`**: etiqueta relacionada con **reconocimiento presuntamente exitoso**; su disponibilidad y significado dependen de las clasificaciones instaladas. 3. **`attempted-dos`**: hace referencia a una actividad que podría constituir un **intento de denegación de servicio**. 4. **`successful-dos`**: identifica una categoría de **denegación de servicio presuntamente exitosa**; no debe interpretarse como confirmación de indisponibilidad sin otras evidencias. 5. **`attempted-user`**: categoría que se puede utilizar para **intentos de compromiso de cuentas o recursos de usuario**. 6. **`successful-user`**: etiqueta asociada a posibles compromisos de **usuarios**. Su presencia no verifica por sí sola que se haya accedido a una cuenta. 7. **`attempted-admin`**: representa intentos de obtener **privilegios administrativos** o de afectar recursos privilegiados. 8. **`successful-admin`**: corresponde a eventos clasificados como un posible compromiso **administrativo**; exige verificación adicional. 9. **`malware-activity`**: identifica patrones o indicadores relacionados con **malware**, como comunicaciones sospechosas o intentos de descarga, según la firma concreta. 10. **`policy-violation`**: describe un posible **incumplimiento de las políticas de seguridad** definidas para el entorno. 11. **`bad-traffic`**: puede utilizarse para **tráfico anómalo o malformado**, cuya interpretación requiere revisar la firma y el contexto. 12. **`trojan-activity`**: indica actividad relacionada con firmas de **troyanos o software potencialmente malicioso**. 13. **`data-theft`**: hace referencia a patrones asociados con un posible **robo o exfiltración de datos**, sin confirmar necesariamente que se hayan extraído archivos. 14. **`exploit`**: etiqueta que puede clasificar indicios de **explotación de vulnerabilidades** cuando se utiliza en un conjunto de reglas. 15. **`shellcode`**: se relaciona con patrones de **instrucciones o payloads** que podrían corresponder a código utilizado en una explotación. 16. **`policy-violation`**: es la **misma clasificación incluida en el punto 10**; la mantengo para conservar la enumeración original, pero no representa una categoría distinta. Puede referirse, por ejemplo, a usos contrarios a una política definida. 17. **`compromise`**: puede indicar señales compatibles con un **sistema comprometido**, que deben correlacionarse con otros registros. 18. **`suspected-botnet`**: clasifica actividad **posiblemente relacionada con una botnet**; no demuestra por sí sola que el equipo pertenezca a ella. 19. **`scan`**: etiqueta que puede utilizarse para **actividad de sondeo o escaneo**; debemos confirmar que exista en las clasificaciones configuradas. ### Clasificación Personalizada Además de las categorías disponibles en su configuración, **Suricata permite definir clasificaciones personalizadas** mediante el archivo de clasificación correspondiente y referenciarlas desde una firma con `classtype`. Esto puede ayudar a adaptar el significado y la prioridad de las alertas a las necesidades del laboratorio o de una organización. ### Usos de las Clasificaciones Las clasificaciones ayudan a los analistas de seguridad a **organizar, correlacionar e interpretar las alertas**, siempre junto con la evidencia del tráfico y el contexto del entorno: * **Filtrar y priorizar alertas** según su clasificación, firma y urgencia. * **Investigar y responder con mayor rapidez** a actividades que pueden representar un incidente, evitando asumir que toda alerta equivale a una intrusión confirmada. * **Generar informes y estadísticas** sobre patrones de tráfico, reglas activadas y eventos relevantes para la seguridad de la red. *** ## Script para visualizar mejor los logs El siguiente script de **Python** mejora la presentación de algunas alertas de **`/var/log/suricata/fast.log`**, utilizando colores para resaltar fechas, direcciones, clasificación y prioridad. Lo conservo tal como está escrito en el laboratorio. Requiere la biblioteca **`colored`** y utiliza una **expresión regular diseñada para un formato concreto de alertas IPv4 que comienzan con `ALERTA:`**; por tanto, no interpretará necesariamente todas las variantes de `fast.log`, mensajes `BLOQUEADO:` ni los eventos estructurados de `eve.json`. Para ampliar el monitor a otros formatos, convendría procesar también los eventos JSON y gestionar la rotación del archivo. {% code lineNumbers="true" %} ```python #!/usr/bin/python3 # coding: utf-8 import re import time import colored # Función para formatear colores def colored_text(text, color): """Devuelve el texto en el color especificado.""" return colored.fg(color) + text + colored.attr('reset') # Función para procesar cada línea de log def process_line(line): # Expresión regular para extraer los datos relevantes de la línea de log pattern = r'([0-9]{2}/[0-9]{2}/[0-9]{4}-[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]+) +\[\*\*\] +\[(\d+:\d+:\d+)\] +ALERTA: (.+) +\[\*\*\] +\[Classification: (.+?)\] +\[Priority: (\d+)\] +\{(\w+)\} +([\d\.]+:\d+) -> ([\d\.]+:\d+)' match = re.match(pattern, line) if match: fecha_hora, alerta_id, mensaje_alerta, clasificacion, prioridad, protocolo, atacante, destino = match.groups() # Mostrar la alerta formateada print(colored_text("\n========== ", 'blue') + colored_text("Alerta de Suricata", 'yellow') + colored_text(" ==========", 'blue')) print(f"{colored_text('Fecha y Hora:', 'white')} {colored_text(fecha_hora, 'cyan')}") print(f"{colored_text('Alerta ID:', 'green')} {colored_text(alerta_id, 'magenta')}") print(f"{colored_text('Msj de Alerta:', 'red')} {colored_text(mensaje_alerta, 'yellow')}") print(f"{colored_text('Clasificación:', 'magenta')} {colored_text(clasificacion, 'blue')}") print(f"{colored_text('Prioridad:', 'yellow')} {colored_text(prioridad, 'cyan')}") print(f"{colored_text('Protocolo:', 'cyan')} {colored_text(protocolo, 'green')}") print(f"{colored_text('Atacante:', 'blue')} {colored_text(atacante, 'white')}") print(f"{colored_text('Destino:', 'blue')} {colored_text(destino, 'white')}") print(colored_text("========================================", 'blue')) def tail_f(file_path): """Función para hacer tail -f al archivo de logs.""" with open(file_path, 'r') as f: # Ir al final del archivo f.seek(0, 2) try: while True: # Leer una nueva línea line = f.readline() if not line: time.sleep(0.1) # Esperar antes de intentar leer otra línea continue process_line(line) except KeyboardInterrupt: print(colored_text("\n========== Fin de las Alertas ==========", 'red')) if __name__ == "__main__": log_file_path = '/var/log/suricata/fast.log' print(colored_text("=============== ", 'cyan') + colored_text("SURICATA", 'red') + colored_text(" ===============", 'cyan')) tail_f(log_file_path) ``` {% endcode %} **Resultado** ```python [root@template]-[~]# ./suricata_alerts.py =============== SURICATA =============== ========== Alerta de Suricata ========== Fecha y Hora: 11/04/2024-18:09:50.995385 Alerta ID: 1:10000001:1 Msj de Alerta: Trafico ICMP detectado Clasificación: (null) Prioridad: 3 Protocolo: ICMP Atacante: 192.168.43.58:8 Destino: 192.168.43.45:0 ======================================== ========== Alerta de Suricata ========== Fecha y Hora: 11/04/2024-18:10:20.091243 Alerta ID: 1:2000001:1 Msj de Alerta: Escaneo de puertos (SYN y ACK) detectado Clasificación: Attempted Information Leak Prioridad: 2 Protocolo: TCP Atacante: 192.168.43.45:22 Destino: 192.168.43.58:43656 ======================================== ========== Alerta de Suricata ========== Fecha y Hora: 11/04/2024-18:11:51.073289 Alerta ID: 1:10000002:1 Msj de Alerta: Trafico HTTP entrante detectado Clasificación: (null) Prioridad: 3 Protocolo: TCP Atacante: 192.168.43.58:58262 Destino: 192.168.43.45:80 ======================================== ^C ========== Fin de las Alertas ========== [root@template]-[~]# ``` El mundo de los **IDS e IPS** es muy amplio. Este laboratorio es una introducción práctica a la **detección de tráfico, las firmas de Suricata y la interpretación de alertas** para quienes estamos interesados en **Blue Team**. Aún quedan aspectos por estudiar, como las reglas de producción, los falsos positivos, la integración con **SIEM**, la inspección inline y la respuesta ante incidentes.