IDS / IPS Suricata. Entendiendo y configurando Suricata. Parte I

Hemos visto, en el anterior artículo dedicado a Suricata, su instalación, uso básico y algo sobre configuración.

En esta ocasión veremos algunas características de este IDS/IPS e iremos configurando cada una de las opciones de Suricata y así entenderemos mejor su funcionamiento.

Algunas características de Surticata.

Vamos a ir viendo de forma sencilla algunas características de Suricata. A lo largo de siguientes capítulos iremos avanzando. Entre ellas cabe destacar:

• Multi-Threaded Processing. Una de la  características más importantes de Suricata que permite la ejecución de varios procesos / subprocesos de forma simultánea. Podemos entonces asignar el número de subprocesos por CPU / Cores y qué subprocesos. De esta forma es capaz, entre otras cosas, de porcesar una gran cantidad de paquetes de forma simultánea aumentando así el rendimiento.

Tenemos 4 módulos de subproceso:

• captura de paquetes
• decodificador. Seguimiento del flujo de secuencias y conexiones para luego reensamblar de forma correcta la secuencia original. Inspección de la capa de aplicación.
• detección / comparación de firmas
• procesamiento de eventos y salida de alertas

Podemos configurar suricata de forma que cada CPU pueda dedicarse a un subproceso o módulo. Veremos como hacerlo en un captítulo dedicado a ello..

• Automatic Protocol Detection. A parte de los protocolos IP, TCP, UDP e ICMP, Suricata tiene palabras claves para otros protocolos como FTP, HTTP, TLS, SMB.  De esa forma podemos escribir reglas independientemente del puerto que un protocolo use, ya sea por defecto o no ya que éste es automáticamente detectado.
• Performance Statistics. Estadísticas y análisis de rendimiento. Estas estádísticas se vuelcan el en archivo /var/log/suricata/stat.log:

• HTTP Log Module. Suricata, independientemente de las alertas, vuelca todas las peticiones HTTP (tanto desde HOME_NET > EXTERNAl_NET como en el sentido ciontrario) en un archivo /var/log/http.log. El registro de estas peticiones se almacenan en formato de Log Apache:

Seguiremos en siguientes capítulos viendo otras características.

Las opciones más comunes en línea de comandos.

• -c para indicar ruta y archivo de configuración
• -i para indicar la interface de red
• -r leer fichero .pcap
• -s indicamos ruta y archivo de reglas
• -l ruta de logs de alertas
• -D para ejecutar como un servicio
• –pidfile para indicar PID en modo servicio
• –user / –group  usuario y grupo para ejecutar suricata

Por ejemplo:

suricata -i eth0 -c /etc/suricata/suricata.yaml -s /etc/suricata/rules -l /var/log/suricata -D –user suricata –group surucata

En el archivo de configuración se pueden establecer las rutas si necesitad de indicarlas en línea de comandos.

Configuración de Suricata. El archivo suricata.yaml

Vamos a ir poco a poco desgranando el archivo de configuración surticata.yaml que se encuentra en etc/suricata/surucata.yaml o /etc/nsm/eth0/suricata.yaml si se trata de Security-Onion.

max-pending-packets

Número de paquetes que es capaz de procesar de forma simultánea. Su configuración dependerá de las características de menoria, CPU/Cores etc.  Si tenemos un buen hardaware, podemos elevar el rendimiento elevando el número de paquetes a procesar, que usará más memoria y recursos. Por defecto se establece en 50 pero se puede llegar a establecer 50000, 20000..

• max-pending-packets: 500

action-order

Una regla suricata (compatible con Snort) está compuesta de 3 partes fundamentales:

• Action que puede ser pass, drop, reject y alert.
• Header cabecera de la regla
• Rule Options opciones de la regla

Pues bien, con action-order establecemos el orden de qué ocurre cuando se establece un conicidencia con una regla establecida. Es decir, que indpendientemente de como suricata carge los archivos de reglas, estas se procesarán en el orden establecido en esta directiva. Por defecto se establece en:

action-order:
– pass
– drop
– reject
– alert

Veremos más adelante las acciones.

outputs. Salida de eventos. tipos de alertas.

Aquí establecemos la configuración de la salida de los eventos de alertas.

si no se establece en línera de comandos, existe un adirectiva para indicar la carpeta donde se almacenaran las alertas:

• default-log-dir: /var/log/ids_1/

Os recuerdo que las alertas se almacenan en /var/log/suricata:

La forma más básica de archivo de alertas sería:

– fast:
enabled: yes
filename: fast.log
limit: 32

Con fast establecemos una alerta por línea.  Habilitamos con enable, y damos un nombre. Con append (yes) le decimos que cuando reincie suricata no se sobreescriba el archivo.

Establecimiento de log para su uso con barnyard:

– unified-log:
enabled: no
filename: unified.log

Podemos establecer un tipo de alerta Unified (para usar con barnyard):

– unified-alert:
enabled: no
filename: unified.alert
limit: 32

O en formato Unified2:

– unified2-alert:
enabled: yes
filename: snort.unified2
limit: 32

Con limit 32 establecemos un límite en MB. para los archivos.

Más arriba hemos hablado del archivo http.log en el que se vuelcan todos los Request HTTP. Pues bien este tipo de log, que NO son alertas, se establece de la siguiente manera:

– http-log:
enabled: yes
filename: http.log

En formato Apache-Log tendremos todos los Requests.

Hay otros tipos de salida para alertas pero los veremos más adelante.

Stats

Son las estádisticas que ya hemos comentado. Para activarlas y configurarlas:

– stats:
enabled: yes
filename: estadisticas.log
interval: 5
append: yes/no

Con interval indicamos el tiempo de refresco en segundos para la generación de las estadísticas.

Outputs. formas de visualización de eventos.

Podemos visualizar los eventos directamente en consola, en fichero o mediante syslog:

  – console:
enabled: yes
– file:
enabled: yes
filename: /var/log/suricata.log
– syslog:
enabled: no
facility: local5
format: «[%i] — «

Como veis no tiene mucha historia. Syslog lo veremos en un capítulo a parte.

Sobre syslog podéis consultar: Enviando alertas a un syslog remoto con snort.

Variables.

Similares a las variables de Snort. Tenemos dos tipos: address-groups y port-groups:

  address-groups:

    HOME_NET: «[192.168.1.0/24,172.16.1.0/24]»

EXTERNAL_NET: any

HTTP_SERVERS: «$HOME_NET»

SMTP_SERVERS: «$HOME_NET»

SQL_SERVERS: «$HOME_NET»

DNS_SERVERS: «$HOME_NET»

TELNET_SERVERS: «$HOME_NET»

AIM_SERVERS: any

  port-groups:

HTTP_PORTS: «80»

SHELLCODE_PORTS: «!80»

ORACLE_PORTS: 1521

SSH_PORTS: 22

Las reglas o suricata rules.

su ubicación se define por la directiva default-rule-path que por defecto quedaría:

• default-rule-path /etc/suricata/rules

Iniciamos la habilitamos las reglas de la forma:

• rule-files:

Y a continuación los ficheros de reglas. quedaría entonces de esta forma:

default-rule-path: /etc/suricata/rules/
rule-files:

– local.rules
– backdoor.rules
– bad-traffic.rules
– chat.rules
– ddos.rules
– nmap.rules

….

En Security Onion quedaría:

default-rule-path: /etc/nsm/rules/
rule-files:
– downloaded.rules
– local.rules

Además, configuramos también… como veis similar a Snort:

classification-file: /etc/suricata/classification.config
reference-config-file: /etc/suricata/reference.config

Relacionado.

Cómo instalar suricata:  IDS / IPS Suricata. Instalación, configuración y puesta en marcha.

======

Y hasta aquí por hoy. Aún queda bastante, asi que hasta la próxima.