Modsecurity y OWASP Core Rule Set: tu web app es segura?
Recientemente el equipo Geko estuvo de visita en la RootedCON, la conferencia de ciberseguridad más importante del país, y entre otras cosas, se habló mucho de uno de los puntos más débiles de la cadena de desarrollo: las personas.
Uno de los mantras más importantes a tener en cuenta para crear un modelo de ciberriesgo es que nunca se va a tener un ecosistema de aplicaciones completamente seguro. Por muchas pruebas de penetración que se practiquen, por muchos tests de código seguro se implementen, siempre queda algo por el camino. A veces es porque el Return of Investment de arreglarlo es muy reducido cuando se diagnostica el problema, a veces es porque los tests no llegan a detectar el problema porque depende de muchos componentes distintos interactuando entre ellos. Los sistemas complejos fallan, y eso es algo que no se puede evitar. Podemos controlar las versiones de software que se utilizan, el código que se ejecuta, pero un desliz es cuestión de tiempo.
¿De qué me sirve intentar protegerme entonces?
Para eso se implementan en los planes de desarrollo y seguridad las medidas de contención y aislamiento: si asumes que algo va a ocurrir, prepara tu entorno para que este incidente tenga el menor impacto posible. ¿Usuario con un shell a través de tu web? No sirve de mucho si sólo se ejecuta como usuario de webserver. ¿Acceso a la base de datos de producción? Bueno, pero sólo para una base de datos y tablas concretas. Minimización de área de impacto y control de daños, son piedras angulares de la lucha contra los ataques informáticos.
Una de las maneras de implementar este control de deslices es el uso de herramientas especializadas de seguridad que protejan contra prácticas comunes que utilicen los atacantes. Que de forma sencilla y modular tu entorno sea capaz de detectar, alertarte o incluso detener ataques externos, sean de bots o de atacantes sofisticados. Una medida más que, si no detenerlo del todo, podría ahorrar más de un susto, o cortar una cadena de vulnerabilidades de múltiples pasos. Todo sin necesidad de que tu equipo de seguridad tenga que atender a cada pequeña alerta que aparezca y puedan dedicar su tiempo a más trabajo de calidad.
¿Por qué parte de mi entorno empiezo?
El caso con mayor superficie de ataque que se suele tratar es el de las páginas web. Toda empresa tiene alguna aplicación web hoy en día, sea interna o de cara al usuario. Un panel de gestión interno, un wordpress corporativo, sea cual sea, puede suponer un punto de pivotaje en un incidente. Para evitar esto pueden protegerse estos entornos web con las herramientas apropiadas que detecten ataques comunes y los detengan. En el caso de Geko Cloud, tras analizar las opciones disponibles para este escenario, nos hemos topado con el ModSecurity Core Rule Set de OWASP.
El ModSecurity Core Rule Set es, en resumidas cuentas, un gran conjunto de normas mantenidas por la Open Web Application Security Project Foundation que se mantiene actualizado en base a las que esta organización mundialmente reconocida considera como los vectores de ataque más importantes para las aplicaciones web actuales. Estas normas se cargan en el módulo de ModSecurity en tu servidor web o proxy (nginx, apache2, iis server) e intercepta y analiza cada petición y respuesta que le llega al sistema, y toma decisiones de alerta o bloqueo en base a sus prioridades y puntuaciones de peligro.
¿Debo migrar mi servidor web a una versión con ModSecurity?
Gracias a la implementación modular de ModSecurity esta herramienta puede implementarse en servidores web de manera sencilla y sin crear una gran cantidad de overhead en la arquitectura de la web. Se implementa en el entorno que ya tienes funcionando de forma rápida y permite empezar a recoger alertas y ver bloqueos de forma immediata. Como no modifica el núcleo de tu webserver puedes aprovechar gran cantidad de tu configuración actual, haciendo su implementación a un entorno existente una opción con muy poca fricción.
¿Cómo activo este set-up en mi imagen pre-existente?
Si no tienes un set-up de webserver monolítico, eso no es un problema, aún puedes aplicar esta configuración de seguridad sin problemas. Gracias a que todos estos componentes son de código abierto y tienen una comunidad activa detrás, hay configuraciones y opciones pre-existentes para casi cualquier escenario que puedas necesitar.
¿Levantando entorno en un docker-compose? la imagen de docker modsecurity-crs mantenida en el repositorio de owasp implementa las normas preconfiguradas en el contenedor de nginx que ya conoces y dominas. ¿Fan de Kubernetes? Habrás notado que en esta casa también lo somos, y casualmente descubirmos que el helm de nginx-ingress-controller trae soporte integrado para ModSecurity, simplemente se necesita activar un flag y sin siquiera downtime, con un helm apply y un par de tags en tus ingress empezarás a dormir más tranquilo sabiendo que has puesto una piedra más en el camino de tus adversarios.
¿Cómo funcionan estos bloqueos exactamente?
ModSecurity trata cada petición a través de 4 fases de controles de seguridad. En la primera fase se comprueban las normas del CoreRuleSet que se aplican a las cabeceras de una petición HTTP. Detalles como utilizar un PUT donde sólo debería haber GET’s, protocolos no permitidos o inyecciones SQL en la URL son ejemplos de las comprobaciones implementadas en el paquete. Tras esto, si no se han acumulado puntuaciones como para bloquear la petición, se continúa a comprobar el cuerpo de la petición con normas como la detección de envío de datos maliciosos cuando se envía un POST. Si estas comprobaciones son correctas, la petición se enviará a la aplicación para que la procese.
Pero eso es sólo la ida, y podrían no detectarse ciertas peticiones lo suficientemente ofuscadas, como un base64 codificando comandos. Para evitar estos osibles agujeros de detección, también se analiza lo que la aplicación le va a devolver al usuario. Detección de cabeceras con información sensible, o un body anormalmente grande que podría ser un dump de SQL o una ejecución de un binario, o un data leakage, nunca llegarán al atacante, ya que ModSecurity descartará esta respuesta.
¿Cómo de sensibles son estas detecciones? ¿Puedo controlarlas?
ModSecurity implementa dos elementos para controlar la cantidad de bloqueos, detecciones y falsos positivos generados: la Score y el Paranoia Level. La primera es una puntuación asignada a cada norma del CoreRuleSet que identifica cómo de grave es su detección: No es igual de peligrosa una petición de PUT a un endpoint que va con GET, que una inyección de comandos de log4java. Para esto se van acumulando puntuaciones por normas que salten en una comunicación, y si sobrepasan un límite, ModSecurity alerta del incidente o corta la conexión.
Para controlar la puntuación necesaria para que se bloqueen peticiones o se envíen alertas se utiliza el Paranoia Level, una variable de entorno de ModSecurity que, en un nivel del 1 al 4, se configura como más o menos sensible, siendo el nivel 1 el más bajo que requiere 5 puntos acumulados para bloquear peticiones (sólo las normas de más alto peligro), y el nivel 4, que sólo requiere 1 punto, el cual te dará cualquier norma. A más alto el paranoia level, más seguro el entorno, pero más falsos positivos se generarán.
Pero no siempre se quieren bloquear o dejar pasar los mismos niveles de normas. Para esto se implementa una separación del paranoia level: el Executing Paranoia Level. Esta variable establece el nivel de puntuación que provocará una alerta, pero sin llegar a bloquear la petición. Por ejemplo, configurar el executing paranoia level a un nivel 3 para que nos alerte de ciertas detecciones que no veríamos normalmente, pero con el Paranoia Level a 4 para no ser tan agresivo y no romper partes del entorno de producción mientras se detectan y arreglan los falsos positivos.
Eso suena a muchas cosas que controlar…
Desde Geko, Consultoria Cloud, ya nos hemos estado peleando con el tuning y configuración del CoreRuleSet un tiempo. Si quieres implementar esta suite de seguridad a tu entorno pero no tienes el tiempo para hacer la gestión de falsos positivos, tengamos una charla y nosotros nos ocuparemos de hacer tu entorno más seguro para que tu equipo pueda dedicar tiempo a sus tareas sin tener que preocuparse tanto de si se les ha colado una implementación de aplicación insegura. ModSecurity verá y parará cosas que tú aún no sabes que existen.