Snort ha sido durante mucho tiempo un líder entre los IDS de red de código abierto. Siendo prácticamente la única solución disponible y al mismo tiempo fácil de configurar y operar, ha recibido un merecido reconocimiento. Pero recientemente, cada vez más personas comenzaron a hablar sobre una alternativa: el proyecto Suricata, que implementa todas las tendencias modernas de IDS / IPS.
¿Por qué necesitamos otro IDS?
Las estadísticas dicen que el tráfico de usuarios aumenta cada año en un 50%. Debe estar preparado para tal carga de antemano. Incluyendo el procesamiento de un gran tráfico de red, enrutadores, firewalls y sistemas de detección/prevención de ataques deben estar listos. Con las soluciones de hardware comerciales, generalmente no hay preguntas, su poder se calcula y prueba de antemano, y los especialistas están involucrados en la implementación. Por lo tanto, puede proporcionar fácilmente un margen, pero no son baratos. Una alternativa son las soluciones de código abierto que han demostrado su eficacia y al mismo tiempo no requieren deducciones por software. Pero todos los problemas de implementación recaen sobre los hombros del administrador del sistema.
El popular Snort empezó a desarrollarse en 1998, cuando habitualmente se utilizaba un servidor con un único procesador de 32 bits para procesar el tráfico de red. Por lo tanto, se utilizó la única arquitectura de subproceso único que era relevante en ese momento; la otra no tenía sentido. Durante este tiempo, Snort es utilizado por unos 300.000 usuarios registrados y casi un centenar de proveedores lo utilizan en sus productos. La propia empresa de desarrollo de Sourcefire fue comprada por Cisco (junto con Snort, ClamAV y Razorback), y los ingenieros de esta corporación se unieron al trabajo de Snort.
Durante más de 17 años de desarrollo, mucho ha cambiado en el mundo de la informática: han aparecido procesadores multinúcleo, IPv6, ha aumentado la cantidad de aplicaciones de usuario y, lo más importante, ha aumentado el tráfico. Todo esto se refleja en Snort: soporte para IPv6, la capacidad de inspeccionar el nivel de la aplicación (el último, el preprocesador OpenAppID), un módulo de acceso a datos DAQ universal y mucho más.
Pero el motor base, aunque aprendió a trabajar con múltiples núcleos, siguió siendo de un solo subproceso. Y, de hecho, Snort no estaba listo para la transición a subprocesos múltiples reales. Dado que el kernel de Linux tarda varios ms en cambiar entre subprocesos, con algoritmos de procesamiento antiguos, un aumento en la cantidad de procesadores incluso ralentizaba el trabajo. La forma de salir de esta situación era limitar los núcleos en los parámetros de arranque maxcpus=2. Es decir, teníamos servidores potentes,
Cuando Snort no podía hacer frente a la carga, simplemente aumentaba la potencia de la CPU o usaba varias instancias con equilibrio de carga entre ellas (una especie de multitarea) usando el módulo DAQ para PF_RING. Pero esto no soluciona el problema, por lo que han surgido proyectos como Gnort , cuya tarea es aumentar la eficiencia de la detección de ataques de Snort portando el código encargado de comprobar las expresiones regulares a la GPU. Esto hizo posible casi duplicar el rendimiento de Snort. Pero el problema de los subprocesos múltiples requiere una revisión completa de todos los componentes importantes dentro de Snort.
La solución global fueron dos proyectos que comenzaron casi simultáneamente. Se trata de Snort 3.0, que lleva más de cinco años desarrollándose, pero aún está en alfa, es decir, sigue estancado en la etapa experimental y está ocupado probando algoritmos óptimos. Y el héroe del artículo de Suricata, escrito desde cero.
Proyecto Suricata
En 2009, varias empresas privadas y el Departamento de Seguridad Nacional de EE. UU. crearon la Open Information Security Foundation (OISF), cuya tarea principal era financiar y desarrollar una alternativa multihilo a Snort, llamada Suricata . El trabajo en el nuevo IDS/IPS fue mucho más rápido que con Snort 3.0, y la versión beta apareció en diciembre de 2009 y el primer lanzamiento oficial en el verano de 2010. El desarrollo se lleva a cabo con la participación activa de la comunidad, por lo que el ritmo es muy alto. El código se distribuye bajo la licencia GPLv2, pero los socios financieros tienen acceso a una versión del motor que no es GPL que pueden tomar prestada para sus productos.
Suricata tiene múltiples subprocesos de forma nativa, lo que permite un uso óptimo de múltiples CPU. Antes de la versión 1.3, había algunos problemas con la escalabilidad, por ejemplo, la cantidad de núcleos de más de cuatro no aumentaba la velocidad en las pruebas. Ahora todos los problemas están resueltos y Suricata funciona bastante bien con 24 o más procesadores. Además, Suricata puede usar computación del lado de la GPU (CUDA y OpenCL, parámetro de compilación –enable-cuda). Como resultado, este IDS puede hacer frente fácilmente a flujos de hasta 10 Gb/s en equipos convencionales.
Al igual que Snort, Suricata consta de varios módulos (captura, recopilación, decodificación, detección y salida), por defecto, antes de la decodificación, el tráfico capturado va en un solo flujo, esto es óptimo en términos de detección, pero carga más el sistema. Pero a diferencia de Snort, puede anular este comportamiento con configuraciones y, literalmente, una configuración en la configuración para dividir los subprocesos inmediatamente después de la captura, y otra para especificar cómo se distribuirán los subprocesos entre los procesadores. Esto brinda amplias oportunidades para optimizar el procesamiento del tráfico en equipos específicos en una red específica.
Existen herramientas avanzadas para inspeccionar el tráfico HTTP basadas en la biblioteca HTP creada por Ivan Ristic, el autor de ModSecurity. Admite la extracción y verificación de archivos transferidos a través de HTTP, el análisis de contenido comprimido, la capacidad de identificar por URI, cookies, encabezados, agente de usuario, solicitud y cuerpo de respuesta. Esta característica de Suricata, por cierto, se usa en algunas redes para registrar el tráfico HTTP sin detección. El contenido de la secuencia se puede distinguir detrás de una máscara y mediante expresiones regulares, la identificación del archivo es posible por nombre, tipo o suma de comprobación MD5.
La decodificación de IPv6 es compatible de forma nativa, incluidos IPv4-in-IPv6, IPv6-in-IPv6, túneles Teredo y algunos otros. El diseño modular del motor permite conectar rápidamente un nuevo elemento para capturar, decodificar, analizar o procesar paquetes. Se utilizan varias interfaces para interceptar el tráfico: NFQueue, IPFRing, LibPcap, IPFW, AF_PACKET, PF_RING. El modo Unix Socket le permite analizar automáticamente archivos PCAP capturados previamente por otro programa (un sniffer, por ejemplo).
En Snort, el modo IPS no apareció de inmediato, pero en Suricata, el modo de bloqueo de tráfico malicioso se implementa de forma inmediata y se realiza utilizando el filtro de paquetes estándar del sistema operativo.
En Linux, por ejemplo, se utilizan dos modos IPS: a través de la cola NFQUEUE, que se puede procesar a nivel de usuario, y a través del modo copia cero AF_PACKET (introducido a partir de la versión 1.4). El modo AF_PACKET es más rápido, pero requiere dos interfaces de red, el sistema debe actuar como puerta de enlace.
Si el paquete está bloqueado, simplemente no se reenvía a la segunda interfaz. En el caso de NFQUEUE, el algoritmo es simple. Después de que el paquete ingresa a iptables, se envía a la cola NFQUEUE, donde se ejecuta de acuerdo con las reglas. Pueden resultar tres acciones: NF_ACCEPT, NF_DROP y NF_REPEAT.
La característica principal de Suricata es que, además de sus desarrollos únicos, utiliza casi todo lo que ya se ha desarrollado para Snort. Por lo tanto, todos los conjuntos de reglas de Snort son adecuados: Sourcefire VRT, OpenSource Emerging Threats (ETOpen) y Emerging Threats Pro comerciales. La salida está unificada (Unified2), por lo que el resultado se puede analizar utilizando los backends habituales: Barnyard2, Snortsnarf, Snorby, Aanval, BASE, FPCGUI, Sguil NSM system y Squert. Posible salida a PCAP, Syslog, archivos y similares.
Por ejemplo, Suricata mantiene un registro de claves y certificados utilizados en conexiones TLS/SSL. En versiones recientes, apareció el registro de Eve, que genera una salida JSON para alertas. La presencia de JSON simplifica enormemente la integración de Suricata con aplicaciones de terceros, incluidos los sistemas para monitorear y visualizar registros (como Kibana).
Todas las configuraciones y reglas de Suricata se realizan en archivos de formato YAML, es más visual y simplifica el procesamiento automático.
Una de las fortalezas de Suricata es su procesamiento de capa 7 OSI, que mejora su capacidad para detectar malware para aplicaciones. El motor detecta y analiza automáticamente los protocolos (IP, TCP, UDP, ICMP, HTTP, TLS, FTP, SMB, SMTP y otros), por lo que en las reglas no puede vincularse estrictamente al número de puerto, como se hace en Snort. solo especifica el protocolo y la acción. Además, los propios módulos de Suricata se ocuparán del tráfico y detectarán el protocolo, incluso si se utiliza un puerto no estándar.
Te puede interesar:
Snort o Suricata. Parte 2: Instalación y configuración.
El formato de las propias reglas se parece al de Snort. La regla contiene componentes: acción (pasar, descartar, rechazar o alertar), encabezado (IP/puerto de origen y destino) y descripción (qué buscar). Hay pocas reglas nativas en la entrega actual, y algunas también están deshabilitadas (comentadas) en los propios archivos, por lo que por ahora debería concentrarse más en los conjuntos de reglas de Snort.
A veces no se abre una, sino varias conexiones TCP entre nodos. Algunos IDS no ven el panorama completo y procesan cada subproceso por separado. Las reglas de Suricata hacen un uso extensivo del concepto de flowbits.
Para realizar un seguimiento de la cantidad de activaciones de reglas, se usan varias variables de sesión (por ejemplo, usando flowint), lo que le permite crear contadores y banderas, y luego verificarlos.
Este enfoque hace frente fácilmente a un intento de adivinar una contraseña. En la versión 2.1, será posible rastrear fácilmente las reglas de enlace IP de origen – IP de destino (xbits) en las reglas, lo que hará que sea aún más fácil detectar el tráfico malicioso distribuido en varias conexiones.
En versiones recientes, apareció el subsistema de reputación de IP, que carga y utiliza datos de varias bases de datos que contienen listas de reputaciones de host en reglas. Un mecanismo especial proporciona búsqueda rápida y coincidencia con direcciones IP.
Instalación de Suricata en Ubuntu
Se admite la instalación de Suricata en Linux, BSD, OS X y Win. El proyecto ofrece fuentes y varios repositorios de Ubuntu (suricata-stable, suricata-beta y suricata-daily daily slice), y se han agregado paquetes de Suricata a Debian Backports. Aunque la mejor solución para una fácil implementación y soporte de Suricata es probablemente Ubuntu. En los paquetes para Ubuntu, el modo IPS se implementa a través de NFQUEUE, si necesita exactamente AF_PACKET, así como soporte para CUDA y otras cosas, deberá construir el paquete usted mismo.
La construcción y la instalación en varias distribuciones se describen en detalle en la Wiki del proyecto , aunque las configuraciones subsiguientes en la documentación se cubren de manera un tanto confusa, y muchos parámetros y subparámetros no están del todo claros, y en realidad hay muchos de ellos.
$ sudo add-apt-repository ppa:oisf/suricata-stable
$ sudo apt-get update
$ sudo apt-get install suricataJunto con la versión actual de las reglas enviadas con Suricata, la última versión de los conjuntos de reglas de ETOpen se descargará e instalará en /etc/suricata/rules en el camino. Para actualizar automáticamente las reglas, incluido VRT, debe instalar y configurar Oinkmaster. Se crearán tres subdirectorios certs, core y files en /var/log/suricata. Mira las opciones de construcción:
$ suricata -build-info
archivo de configuración de suricata
Todas las configuraciones básicas de trabajo se realizan en el archivo de configuración suricata.yaml, hay muchos parámetros aquí. La mayoría de las variables y parámetros de descubrimiento tienen el mismo nombre y propósito que los que se usan en Snort, lo que facilita la familiarización para aquellos que han trabajado previamente con este IDS. Solo difiere la sintaxis, aquí debemos admitir que el archivo de Suricata es realmente más fácil de leer. La entrega incluye un ejemplo preconfigurado y listo con comentarios (casi 50 Kb de tamaño).
Por lo tanto, puede ejecutar lo que está listo para usar, con un mínimo de adaptación, y luego ajustarlo a medida que se conocen. Por ejemplo, la sección de salidas es responsable de guardar eventos (configuración de registro en el registro), las 15 opciones de salida posibles ya están escritas en el archivo, además se muestran sus configuraciones.
La mayoría de ellos están deshabilitados (habilitados: no). De forma predeterminada, solo están habilitados Fast, eve-log (JSON), unified2-alert y http-log.
Por lo tanto, asegúrese de estudiar cuidadosamente las configuraciones e incluir aquellas que realmente se necesitan. Los ejemplos listos para usar de Internet no siempre funcionan y no siempre se adaptan bien a una situación particular. Si es necesario, la configuración se transfiere a archivos externos, que se incluyen mediante include o !include. El signo de exclamación en la segunda opción no significa, como comúnmente se cree, una negación. !include se utiliza para almacenar información en un archivo de una sección u opción en particular. Por ejemplo, todas las configuraciones de salida se colocan en un archivo outputs.yaml separado:
outputs: !include outputs.yamlHay muchas cosas en la configuración más comentarios, para ver las configuraciones y variables actuales es conveniente usar el parámetro –dump-config:
$ suricata --dump-config
Antes del primer lanzamiento, debe verificar el valor de las variables definidas en la sección vars; por su nombre, coinciden completamente con las de Snort:
vars:
address-groups:
HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
EXTERNAL_NET: "!$HOME_NET"
...
port-groups:
HTTP_PORTS: "80"
SHELLCODE_PORTS: "!80"
SSH_PORTS: 22
...El parámetro host-mode especifica el modo de operación de IDS/IPS. El valor predeterminado es automático, pero según la configuración y las tareas, es posible que deba volver a configurarse para enrutador (modo AF_PACKET IPS) o sólo rastreador (IDS). También se recomienda establecer el valor óptimo de tamaño de paquete predeterminado especificando la MTU de su red. Además, comprobamos las reglas conectadas. Todo es simple aquí. Miramos lo que hay en /etc/suricata/rules y escribimos lo que se necesita:
default-rule-path: @e_sysconfdir@rules
rule-files:
- drop.rules
- emerging-activex.rules
- emerging-attack_response.rules
....Políticas para sistemas operativos específicos:
host-os-policy:
windows: [0.0.0.0/0]
linux: [10.0.0.0/8, 192.168.1.100]Control de protocolo:
app-layer:
protocols:
tls:
enabled: yes
detection-ports:
dp: 443
…Podemos obtener la lista de protocolos de nivel de aplicación configurados para verificar usando –list-app-layer-protos :
$ suricata --list-app-layer-protos
Es recomendable ejecutar Suricata en modo de prueba antes de comenzar, verificar si hay errores en el archivo de configuración y los derechos de acceso a ellos:
$ sudo suricata -cT /etc/suricata/suricata.yaml
Si todo está en orden, solo recibiremos un mensaje sobre la versión del motor. De lo contrario, antes de comenzar a trabajar, debe lidiar con los errores. Los desarrolladores del paquete proporcionan una secuencia de comandos de inicio, pero la primera ejecución debe realizarse en modo interactivo para ver visualmente lo que sucede y no buscar problemas en los registros:
$ sudo suricata -c /etc/suricata/suricata.yaml -i eth0Debe considerar cuidadosamente todas las advertencias recibidas durante el proceso de lanzamiento. Tal vez la configuración de captura actual no sea del todo adecuada. Comprobemos nuestros IDS:
$ cd /var/log/suricata
$ sudo tail -f fast.log http.log
$ wget www.testmyids.comAparece una entrada en los registros:
==> http.log <==
04/22/2015-19:46:19.566412 www.testmyids.com [**] / [**] Wget/1.15 (linux- gnu) [**] 192.168.1.137:57535 -> 82.165.177.154:80
==> fast.log <==
04/22/2015-19:46:19.809340 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 82.165.177.154:80 -> 192.168.1.137:57535Podemos ver información sobre el tráfico en los registros:
$ sudo tail /var/log/suricata/stats.log -f | grep capture
capture.kernel_packets | RxPcapeth01 | 1179
capture.kernel_drops | RxPcapeth01 | 0
capture.kernel_ifdrops | RxPcapeth01 | 0Configuración de rendimiento de Suricata
Además de la configuración real del motor de descubrimiento, debe prestar atención a la configuración del archivo que afecta el rendimiento. Hay muchos de ellos aquí: subprocesamiento, detección de relación de subprocesos, desfragmentación, transmisión, modo de ejecución y otros. Los dos primeros están más relacionados con el hardware (en particular, la cantidad de CPU), la desfragmentación y la transmisión a la carga de la red, y el modo de ejecución afecta el algoritmo para iniciar subprocesos, colas, subprocesos. La lista y las características de los modos de ejecución se pueden ver usando la opción –list-runmodes.
$ suricata --list-runmodesActualmente se implementan cuatro modos: automático, autofp (el valor predeterminado de fijación de flujo automático, que es una mejora en automático), trabajadores y único.
La configuración predeterminada está optimizada para una mejor detección, pero requiere más recursos. En la variante autofp, los flujos van juntos hasta que sale el módulo decodificador, luego cada flujo de red es procesado por un subproceso de CPU separado (flujo> detectar> salida). Con el parámetro adicional autofp-scheduler, puede cambiar el balanceador de carga. De forma predeterminada, se utilizan los paquetes activos óptimos, que primero verifican si el subproceso de la CPU está ocupado, después de lo cual ya se le ha asignado la conexión de red capturada. Esto da como resultado una distribución de flujos y paquetes bastante adecuada.
runmode: autofp
autofp-scheduler: active-packetsLas opciones pueden ser round-robin o hash (usa una tabla hash, en realidad una distribución más aleatoria, era la predeterminada antes de la versión 1.2.1). En el caso de los trabajadores, cada subproceso se procesa por separado desde la captura hasta el registro, con solo, todo el procesamiento se realiza en un solo subproceso. Pero solo autofp y los trabajadores garantizan que la conexión de red siempre se dirigirá a la misma transmisión.
Suricata se puede utilizar para registrar HTTP, DNS y solicitudes similares. Un módulo de detección que consume muchos recursos se puede desactivar en la compilación (permanentemente) o temporalmente en la línea de inicio (parámetro –disable-detection).
conclusiones
Entonces, Suricata es un motor más rápido que Snort, capaz de aprovechar al máximo las capacidades de los procesadores y GPU modernos, mientras que es totalmente compatible con Snort en términos de reglas y backends. La desventaja es una gran cantidad de configuraciones y documentación que no es lo suficientemente clara en algunos aspectos. Aunque después de la instalación funciona bien con la configuración predeterminada, un administrador experimentado lo resolverá con ajustes finos sin ningún problema.