suricata

Motor de red IDS/IPS/NSM de código abierto para inspección de tráfico en tiempo real, detección y prevención de intrusiones, análisis de protocolos y búsqueda de amenazas basada en reglas.

Suricata es un software complejo que maneja entradas mayoritariamente no confiables. El manejo incorrecto de estas entradas tendrá consecuencias graves:

• en modo IPS, una caída puede dejar una red fuera de línea
• en modo pasivo, un compromiso del IDS puede provocar la pérdida de datos críticos y confidenciales
• una detección fallida puede provocar un compromiso no detectado de la red

En otras palabras, consideramos que lo que está en juego es bastante alto, especialmente porque en muchos casos comunes el IDS/IPS será directamente accesible por un atacante.

Por esta razón, hemos desarrollado un proceso de control de calidad (QA) bastante extenso. Una consecuencia es que contribuir a Suricata puede ser un proceso algo largo.

A grandes rasgos, los pasos son:

1. Comprobaciones basadas en GitHub-CI. Se ejecutan automáticamente cuando se realiza una solicitud de extracción (pull request).
2. Revisión por parte de desarrolladores del equipo y de la comunidad.
3. Ejecuciones de QA desde entornos de QA privados. Son privados debido a la naturaleza del tráfico de prueba.

Resumen de los pasos de QA de Suricata

Los miembros del equipo de OISF pueden enviar compilaciones a nuestro entorno de QA privado. Este ejecutará una serie de pruebas de compilación y una suite de regresión para confirmar que no se rompe ninguna funcionalidad existente.

La ejecución final de QA tarda como mínimo unas horas y, generalmente, se ejecuta durante la noche. Actualmente ejecuta:

• pruebas exhaustivas de compilación en diferentes sistemas operativos, compiladores, niveles de optimización y opciones de configuración
• análisis estático de código mediante cppcheck, scan-build
• análisis dinámico de código mediante valgrind, AddressSanitizer, LeakSanitizer
• pruebas de regresión para errores pasados
• validación de la salida de los registros (logging)
• pruebas de sockets Unix
• pruebas de fuzzing basadas en pcap utilizando ASAN y LSAN
• pruebas de IDS e IPS basadas en reproducción de tráfico

Además de estas pruebas, según el tipo de cambio de código, se pueden ejecutar más pruebas manualmente:

• pruebas de reproducción de tráfico (multi-gigabit)
• procesamiento de grandes colecciones de pcap (multi-terabytes)
• pruebas de fuzzing (pueden llevar varios días o incluso semanas)
• pruebas de rendimiento basadas en pcap
• pruebas de rendimiento en vivo
• varias otras pruebas manuales basadas en la evaluación de los cambios propuestos

Es importante comprender que casi todas las pruebas anteriores se utilizan como pruebas de aceptación. Si algo falla, depende de usted solucionarlo en su código.

Un paso del QA se ejecuta actualmente después de la fusión (merge). Enviamos compilaciones al programa Coverity Scan. Debido a las limitaciones de este servicio (gratuito), podemos enviar como máximo una vez al día. Por supuesto, puede ocurrir que después de la fusión la comunidad encuentre problemas. Para ambos casos, le pedimos que ayude a resolver los problemas a medida que surjan.

FAQ

P: ¿Aceptarán mi PR?

R: Depende de varias cosas, incluida la calidad del código. Con nuevas funcionalidades también depende de si el equipo y/o la comunidad consideran que la funcionalidad es útil, cuánto afecta a otro código y funcionalidades, el riesgo de regresiones de rendimiento, etc.

P: ¿Cuándo se fusionará mi PR?

R: Depende; si es una funcionalidad importante o se considera un cambio de alto riesgo, probablemente irá a la siguiente versión principal.

P: ¿Por qué se cerró mi PR?

R: Como se documenta en el flujo de trabajo de GitHub de Suricata, esperamos una nueva solicitud de extracción para cada cambio.

Normalmente, el equipo (o la comunidad) dará retroalimentación sobre una solicitud de extracción, después de lo cual se espera que sea reemplazada por un PR mejorado. Así que mire los comentarios. Si no está de acuerdo con los comentarios, aún podemos discutirlos en el PR cerrado.

Si el PR se cerró sin comentarios, probablemente se deba a un fallo de QA. Si las comprobaciones de GitHub-CI fallaron, el PR debe corregirse de inmediato. No es necesario discutirlo, a menos que crea que el fallo de QA es incorrecto.

P: El compilador/analizador de código/herramienta está equivocado, ¿qué hago?

R: Para ayudar en la automatización del QA, no aceptamos que queden avisos (warnings) o errores. En algunos casos, esto podría significar que agregamos una supresión si la herramienta lo admite (por ejemplo, valgrind, DrMemory). Algunos avisos se pueden desactivar. En algunos casos excepcionales, la única "solución" es refactorizar el código para evitar un falso positivo de un verificador estático de código. Aunque sea frustrante, lo preferimos a dejar avisos en la salida. Los avisos tienden a ignorarse y aumentan el riesgo de ocultar otros avisos.

P: Creo que su prueba de QA está equivocada

R: Si realmente lo cree, podemos discutir cómo mejorarla. Pero no llegue a esta conclusión demasiado rápido; más a menudo resulta que el código es el que está equivocado.

P: ¿Exigen la firma de un acuerdo de licencia de contribución?

R: Sí, lo hacemos para mantener la propiedad de Suricata en una sola mano: la Open Information Security Foundation. Consulte http://suricata.io/about/open-source/ y http://suricata.io/about/contribution-agreement/