Fundamentos y Organización del Sistema

SNORT opera como una plataforma NIDS/NIPS que inspecciona tráfico en tiempo real cruzando flujos de red contra un repositorio de firmas deterministas. La lógica básica de evaluación se ilustra mediante una directiva de detección:

alert tcp $RED_EXTERNA any -> $RED_LOCAL 443 (msg: "Conexión HTTPS Identificada"; sid:2001; rev:1;)

La estructura se compone de la acción desencadenante (alert), el protocolo de transporte, los extremos de comunicación, el operador de dirección (-> o <->) y un bloque semántico entre paréntesis que define comportamientos. Este enfoque permite analizar paquetes sin interromper el flujo nativo.

Jerarquía de Archivos y Configuración Central

La distribución estándar en /etc/snort segmenta responsabilidades operativas:

/etc/snort
 ├── snort.conf                  # Archivo maestro de configuración
 ├── classification.config       # Definición de clases de amenaza
 ├── reference.config            # Catálogo de referencias externas
 ├── threshold.conf              # Filtros de umbral y anti-spam
 ├── gen-msg.map / sid-msg.map   # Mapeo de identificadores a descripciones
 ├── unicode.map                 # Transformador de codificaciones
 ├── preproc_rules/              # Firmas internas de decodificación
 │    └── decoder.rules
 ├── so_rules/                   # Bibliotecas compartidas dinámicas
 └── rules/                      # Conjunto principal de detección
      ├── web-iis.rules
      └── local.rules (personalizado)

El núcleo operativo reside en snort.conf. Su procesamiento secuencial sigue estas prioridades:

1. Declaración de variables de red para abstracción de direcciones.
2. Inicialización del subsistema de decodificación.
3. Carga del motor de correlación base.
4. Vinculación de módulos externos (Shared Objects).
5. Parametrización de preprocesadores.
6. Configuración de conectores de salida.
7. Inclusión del repositorio de reglas locales.
8. Habilitación de reglas específicas para preprocesamiento.
9. Integración de conjuntos de reglas SO.

Pipeline Interno de Procesamiento

Los datos siguen un flujo de four-stage pipe:

• Captura y Decodificación: Intercepta frames brutos desde interfaces pasivas/activas y los reconstruye en estructuras anidadas siguiendo la pila TCP/IP.
• Preprocesamiento y Normalización: Mitiga técnicas de evasión clásicas (fragmentación IP maliciosa, sessions split, shellcode polimórfico) reensamblando streams y estandarizando payloads para garantizar coherencia en el motor.
• Motor de Correlación: Opera sobre una base tridimensional de reglas. Cuando una sección del paquete coincide con un patrón activo, inyecta una señal al subsistema de gestión.
• Persistencia y Notificación: Interpreta la acción solicitada (log, alert) y rotea el evento hacia sistemas de archivo plano o gestores relacionales.

Sistemas de Decodificación y Preprocesadores

Estas capas ejecutan transformaciones preventivas antes de que el motor aplique firmas complejas. La configuración inicial en snort.conf puede optimizar la tolerancia a errores y controlar alertas genéricas:

# Suprime notificaciones rutinarias de inconsistencia de cabecera
config disable_decode_alerts
# Activa monitoreo de sobredimensionamiento en UDP/TCP/IP
config enable_decode_oversized_alerts
# Invoca reglas nativas de validación
include $PREPROC_RULE_PATH/decoder.rules

Para entornos web, http_inspect resulta crítico. Se ajusta definiendo profundidades de descompresión, mapas de caracteres y extracción contextual:

preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 65535 decompress_depth 65535
preprocessor http_inspect_server: server default \
    http_methods { GET POST PUT SEARCH MKCOL HEAD OPTIONS TRACE CONNECT PATCH DELETE } \
    normalize_uri \
    normalize_javascript \
    enable_cookie \
    overlap_limit 100

Las directivas vinculadas a este nivel generalmente carecen de especificaciones de IP/puerto, pues actúan como filtros contextuales transparentes gestionados internamente por el daemon.

Motor de Detección y Sintaxis de Reglas

La gramática se partition en metadatos operativos y cláusulas lógicas de emparejamiento. Las acciones soportadas incluyen alert (registra y notifica), log (persiste silenciosamente), pass (ignora flujo), activate (dispara contexto) y dynamic (modo espera/reactivación).

Las direcciones admiten notation CIDR, listas delimitadas por coma dentro de corchetes, exclusión con !, y el comodín universal any. Los puertos aceptan rangos semiabiertos (80:, :1024) o rangos completos.

Opciones de Regla

• Generales: sid (identificador único, >1000000 reserva para scripts propios), gid (fuente del detector: 1=Engine, valores distintos = preprocessors/decoders), rev (versionado), msg (cadena legible sincronizada vía sid-msg.map), reference (hipervínculos a CVE/BID integrados en alertas), classtype y priority (severidad gestionada en classification.config).
• Payload (Carga Útil): content busca bytes específicos o texto. Soporta modificadores como nocase, depth, offset, distance, within, y extractores HTTP (http_header, raw_url). Permite regex compatibles con PCRE mediante pcre. protected_content aplica hash MD5/SHA para cifrar firmas sensibles en repositorios públicos. rawbytes fuerza coincidencia saltando capas de normalización previa.
• No-Payload (Metadatos/Estructura): Filtrado directo sobre campos de cabecera: ttl, tos, ipopts, dsize, flags, seq, ack, window, e identificadores ICMP.
• Post-Detección: logto redefine ruta de salida, tag agrega etiquetas temporales, resp devuelve replies TCP/RST para abortar conexiones, count limita frecuencia de disparo, y replace muta datos en vuelo.

Ejemplo práctico refactorizado demostrando composición avanzada:

alert tcp $RED_LOCAL any -> $RED_EXTERNA any 80 \
    (msg:"Reconocimiento de Rutas Administrativas"; \
     flow:to_server,established; \
     content:"/dashboard"; http_uri; depth:40; \
     classtype:attempted-admin; \
     priority:1; sid:40015; rev:2;)

Gestión de Logs e Integración Relacional

Para entornos productivos, el formato binario unified2 reduce latencia y overhead de disco:

config logdir: /var/log/snort_prod
output unified2: filename snort_u2.log, limit 128

El daemon Barnyard2 consume este stream y lo transforma en inserciones SQL eficientes. Su configuración tipica incluye control de offsets y credenciales de conexión:

# Barnyard2 config
config waldo_file: /var/log/snort_prod/waldo.snort
output database: log, mysql, user=auditor_db pass=contraseña_fuerte dbname=nids_history host=db_central

El modelo de datos resultante organiza la telemetría mediante tablas especializadas:

• sensor: Metadatos físicos del agente (hostname, interfaz, nivel de detalle fast/full, encoding binario).
• event: Registro atómico por incidente (PK compuesto por sid y contador cid). Contiene timestamp y firma vinculada.
• signature: Diccionario maestro de reglas vivas (sig_id, nombre, categoría, prioridad, versión, identificador Snort).
• reference y sig_reference: Tablas puente que asignan IDs internos a catálogos de vulnerabilidades abiertas.
• sig_class: Diccionario de grupos operativos de alarma.
• iphdr, tcphdr, udphdr, icmphdr: Espejos de cabeceras extraídas en el momento del cruce.
• data y opt: Almacenan payload utilizable y extensiones de protocolo respectivamente.