network-security-snort

Laboratorio de Snort 3 IDS → IPS en Kali. Reglas de detección personalizadas + aplicación de iptables contra reconocimiento ICMP, escaneos SYN de Nmap, fuerza bruta FTP de Hydra y backdoor de vsftpd 2.3.4 (CVE-2011-2523).

Topología de Red

Todo el tráfico entre el Atacante y Metasploitable se fuerza a través del Analizador, convirtiéndolo en el punto de estrangulamiento natural tanto para el monitoreo como para la aplicación.

Reemplace este boceto ASCII con screenshots/01-network-topology.png una vez que tenga la figura en su lugar: Topology

Metodología

El laboratorio se ejecuta en dos etapas con una cadena de ataque idéntica de cuatro vectores en cada una:

1. Reconocimiento ICMP — ping para descubrimiento de host
2. Escaneo SYN de Nmap — nmap -sS para enumeración de puertos (1000 puertos)
3. Ataque de fuerza bruta FTP con Hydra — ataque de credenciales contra el servicio vsftpd
4. Puerta trasera vsftpd 2.3.4 — exploit de Metasploit para CVE-2011-2523

Etapa 1 (IDS) ejecuta Snort pasivamente en el Analizador con cinco reglas personalizadas — observe las alertas en tiempo real, confirme que la explotación continúa de todos modos.

Etapa 2 (IPS) combina Snort con una capa de aplicación de iptables utilizando reglas de descarte quirúrgicas — confirme que los ataques son bloqueados mientras que el ping ICMP y el inicio de sesión FTP legítimo permanecen funcionales.

Configuración previa al despliegue

1. Configure el Analizador con tres NICs en VMware (dos solo anfitrión, una NAT/puente).
2. Habilite el reenvío de IP y agregue reglas MASQUERADE + FORWARD para que el Analizador enrute entre subredes y hacia la WAN — consulte scripts/router_config.sh.
3. Verifique la conectividad integral desde cada VM con scripts/ping_check.sh antes de instalar Snort.

Configuración de Snort

Snort se instala a través del administrador de paquetes de Kali (sudo apt install snort -y) y se configura en /etc/snort/snort.conf:

HOME_NET cubre ambas subredes internas para que Snort trate todo el tráfico entre subredes en el Analizador como digno de inspección. alert_fast produce alertas compactas de una línea (el registro por paquete generaría un volumen excesivo).

Validación de configuración:

Reglas de Detección Personalizadas

Cinco reglas en /etc/snort/rules/local.rules (archivo completo en scripts/local.rules):

Etapa 1 — Modo IDS

Snort se ejecuta en modo pasivo en ambas interfaces internas:

La salida de inicio confirma pcap DAQ configured to passive — Snort ve cada paquete pero no puede descartar ni modificar ninguno.

Resultados del IDS

Después de ejecutar scripts/attack_simulator.sh desde el Atacante:

El IDS detectó todo y no detuvo nada. Esta es la lección central de la Etapa 1: un IDS funcional sin aplicación es un sistema de alarma, no una cerradura. Para cuando un analista de SOC lee las alertas, el atacante ya es root.

Una observación secundaria: las reglas integradas de Snort (116:408, 116:414) se disparan con tráfico de difusión DHCP — no es malicioso, pero en un despliegue de producción necesitarían reglas de supresión para mantener el registro de alertas accionable.

Etapa 2 — Modo IPS

La capa IPS se despliega con scripts/ips_setup.sh, que:

1. Vacía las reglas existentes de iptables
2. Vuelve a habilitar el reenvío de IP y reaplica el enrutamiento base
3. Aplica cuatro reglas de descarte quirúrgicas dirigidas a firmas de ataque específicas
4. Lanza Snort en modo demonio (-D) para registro continuo

Reglas de iptables

Resultados del IPS

El mismo script de ataque se volvió a ejecutar desde el Atacante:

Tráfico normal preservado

Dos verificaciones manuales confirmaron la aplicación selectiva:

• ping -c 4 192.168.50.10 → 4 paquetes transmitidos, 4 recibidos, 0% pérdida
• ftp 192.168.50.10 con msfadmin:msfadmin → 220 (vsFTPd 2.3.4) … 230 Login successful

Prueba cuantitativa de los contadores de paquetes de iptables durante la ejecución: 2051 paquetes aceptados, 12 paquetes descartados por la regla connlimit de FTP, 808 paquetes ICMP aceptados — aplicación selectiva en números.

Registro continuo de Snort

Incluso en modo IPS, Snort continuó disparando alertas SID 1000002 / 1000003 en paquetes que llegaron a su punto de inspección pasiva antes de que iptables descartara los posteriores — lo que significa que iptables proporciona aplicación mientras Snort proporciona registro de auditoría, operando en conjunto.

IDS vs IPS — Resultados Comparativos

Discusión

¿Fueron detectados todos los ataques simulados en modo IDS?

Sí — cada uno de los SIDs 1000001–1000004 se dispararon correctamente durante la simulación de ataque:

• Ping ICMP (1000001) — alertas bidireccionales para cada eco/respuesta.
• Escaneo SYN de Nmap (1000003) — inundación de alertas en milisegundos, aleatorización característica del puerto de origen.
• Fuerza bruta FTP (1000002) — rastro de auditoría limpio de los intentos de conexión paralelos de Hydra con marcas de tiempo exactas.
• Puerta trasera vsftpd (1000004) — la coincidencia de contenido :) atrapó la secuencia exacta de bytes del exploit.

Pero detección ≠ prevención. El exploit de vsftpd abrió un shell Meterpreter como root mientras cada alerta se disparaba. Un analista de SOC observando el IDS en tiempo real habría visto el compromiso — pero con el atacante ya siendo root en segundos, la alerta por sí sola no es suficiente. Este es el núcleo operativo de por qué existe el IPS.

¿Qué tan efectivo fue el IPS para bloquear ataques sin romper el tráfico normal?

La implementación logró una mitigación completa de ataques con cero impacto observable en el tráfico legítimo. La efectividad proviene del diseño quirúrgico de reglas — cada regla de iptables apunta a una firma de comportamiento, no a un protocolo amplio:

• Límite de velocidad SYN rompe el patrón de inundación de escaneos de puertos sin afectar apretones de manos normales.
• connlimit por origen bloquea el paralelismo de herramientas de fuerza bruta sin romper FTP de sesión única.
• Coincidencia STRING descarta la carga útil exacta del exploit sin filtrar tráfico legítimo de inicio de sesión FTP.

Una limitación reconocida: ICMP está completamente permitido, lo que significa que un atacante aún puede confirmar que Metasploitable está activo mediante ping. En un entorno de mayor seguridad, esto se limitaría en velocidad o se restringiría a fuentes confiables. En este laboratorio, ICMP es el mecanismo principal de verificación de conectividad, por lo que permanece abierto.

Máquina Snort dedicada vs. complemento pfSense/OPNsense

Este laboratorio utiliza una máquina Snort dedicada. En comparación con ejecutar Snort como un complemento dentro de un dispositivo de firewall como pfSense u OPNsense:

Ventajas del enfoque dedicado:

• Aislamiento de rendimiento — CPU y RAM completos disponibles exclusivamente para inspección de paquetes; sin contención con enrutamiento, DHCP, VPN, DNS.
• Flexibilidad de posicionamiento — el IDS/IPS puede colocarse en línea, en un puerto SPAN/mirror, o en un límite de segmento interno para monitorear tráfico este-oeste que nunca llega al firewall perimetral.
• Control total de configuración — cada preprocesador, configuración DAQ, complemento de salida y programación de actualización de reglas es configurable a través de CLI. pfSense expone solo un subconjunto a través de su GUI.
• Resiliencia — la máquina IDS/IPS puede fallar-abierto o fallar-cerrado independientemente del router. En pfSense, un fallo de Snort derriba tanto el enrutamiento como la detección a la vez.

Compensaciones:

• Curva de aprendizaje más pronunciada — requiere competencia en CLI y gestión directa del conjunto de reglas.
• Sobrecarga de mantenimiento — actualizaciones de reglas, mejoras de versión, rotación de registros, todo manual.

Snort dedicado es la opción correcta para entornos empresariales que necesitan rendimiento, posicionamiento y personalización. El enfoque del complemento pfSense/OPNsense tiene más sentido para entornos de pequeñas empresas o laboratorios domésticos que priorizan la facilidad de uso.

Nota de Arquitectura

La Etapa 2 es técnicamente Snort pasivo + aplicación con iptables, no Snort ejecutándose en modo en línea verdadero — Snort mismo registra (pcap DAQ configured to passive), e iptables realiza el descarte basado en límites de velocidad, coincidencias de cadenas y conteos de conexiones.

Este es un patrón de despliegue legítimo y común (así es como funcionan muchas pilas IDS/IPS basadas en Linux en el mundo real). Un seguimiento natural sería migrar la Etapa 2 a una configuración en línea verdadera usando snort --daq nfq (o afpacket en modo en línea) con acciones de reglas reject / drop de Snort, para que Snort mismo realice el descarte basado en la coincidencia completa de firmas en lugar de delegar en iptables.

Estructura del Repositorio

Reproduciendo el Laboratorio

⚠️ Solo para uso en laboratorio. Estos scripts ejecutan exploits reales y herramientas de fuerza bruta contra un objetivo deliberadamente vulnerable. No los ejecute contra ningún sistema que no posea y para el cual no tenga autorización explícita por escrito para probar.

1. Construya tres VMs en VMware según la topología anterior (VMnet9 y VMnet10 como solo anfitrión).
2. En el Analizador: ejecute scripts/router_config.sh, luego scripts/ping_check.sh para confirmar la conectividad total.
3. Instale Snort 3 en el Analizador:
   root@kitploit:~

   sudo apt update && sudo apt install snort -y
   

4. Coloque scripts/local.rules en /etc/snort/rules/local.rules y configure HOME_NET = "10.10.10.0/24,192.168.50.0/24" en /etc/snort/snort.conf.
5. Valide: sudo snort -T -c /etc/snort/snort.conf — espere 652 reglas cargadas, 0 advertencias.
6. Etapa 1 — IDS:
   root@kitploit:~

   sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 -A alert_fast -l /var/log/snort/
   # En otra terminal:
   sudo tail -f /var/log/snort/alert_fast.txt
   

   En el Atacante: sudo ./scripts/attack_simulator.sh — observe las alertas disparándose y el shell Meterpreter.
7. Etapa 2 — IPS: en el Analizador, ejecute sudo ./scripts/ips_setup.sh, luego vuelva a ejecutar la cadena de ataque en el Atacante. Confirme los bloqueos, luego pruebe manualmente:
   root@kitploit:~

   ping -c 4 192.168.50.10        # debería tener éxito
   ftp 192.168.50.10              # msfadmin / msfadmin — debería tener éxito
   

Descargo de Responsabilidad Ético

Todas las actividades documentadas en este repositorio se llevaron a cabo exclusivamente dentro de un entorno de laboratorio virtual autónomo de VMware con fines académicos supervisados. No se atacaron, escanearon ni afectaron de ninguna manera sistemas externos, de producción o del mundo real. Metasploitable 2 es una máquina virtual intencionalmente vulnerable diseñada específicamente para capacitación en seguridad.

Este material no debe utilizarse para replicar estas actividades contra ningún sistema real sin autorización explícita por escrito del propietario del sistema. El escaneo de puertos no autorizado, los ataques de credenciales o la explotación de servicios de red son ilegales en la mayoría de las jurisdicciones.

Licencia

MIT — consulte LICENSE. El informe del laboratorio en sí se proporciona como referencia educativa.