Detecci贸n de ataques web mediante el codificador autom谩tico Seq2Seq

imagen

La detecci贸n de ataques ha sido una tarea importante en la seguridad de la informaci贸n durante d茅cadas. Los primeros ejemplos conocidos de implementaci贸n de IDS se remontan a principios de la d茅cada de 1980.

Despu茅s de varias d茅cadas, se form贸 una industria completa de herramientas de detecci贸n de ataques. Actualmente, hay varios tipos de productos, como IDS, IPS, WAF, firewalls, la mayor铆a de los cuales ofrecen detecci贸n de ataques basados 鈥嬧媏n reglas. La idea de utilizar t茅cnicas de detecci贸n de anomal铆as para detectar ataques basados 鈥嬧媏n estad铆sticas de producci贸n no parece tan realista como en el pasado. 驴O todo lo mismo?

Detecci贸n de anomal铆as en aplicaciones web


Los primeros cortafuegos dise帽ados espec铆ficamente para detectar ataques a aplicaciones web comenzaron a aparecer en el mercado a principios de la d茅cada de 1990. Desde entonces, tanto los m茅todos de ataque como los mecanismos de defensa han cambiado significativamente, y los atacantes pueden estar un paso adelante en cualquier momento.

Actualmente, la mayor铆a de los WAF intentan detectar ataques de la siguiente manera: existen algunos mecanismos basados 鈥嬧媏n reglas que est谩n integrados en el servidor proxy inverso. El ejemplo m谩s llamativo es mod_security, el m贸dulo WAF para el servidor web Apache, que se desarroll贸 en 2002. Identificar ataques usando reglas tiene varios inconvenientes; por ejemplo, las reglas no pueden detectar ataques de d铆a cero, mientras que un experto puede detectar f谩cilmente los mismos ataques, y esto no es sorprendente, porque el cerebro humano no funciona en absoluto como un conjunto de expresiones regulares.

Desde el punto de vista de WAF, los ataques se pueden dividir en aquellos que podemos detectar por la secuencia de solicitudes, y aquellos en los que una solicitud HTTP (respuesta) es suficiente para resolver. Nuestra investigaci贸n se centra en detectar los 煤ltimos tipos de ataques: inyecci贸n de SQL, secuencias de comandos de sitios cruzados, inyecci贸n de entidades externas XML, recorrido de ruta, comando del sistema operativo, inyecci贸n de objetos, etc.

Pero primero, prob茅monos a nosotros mismos.

驴Qu茅 pensar谩 el experto cuando vea las siguientes consultas?


Eche un vistazo a un ejemplo de solicitud HTTP para aplicaciones:

imagen

Si se le asign贸 la tarea de detectar solicitudes maliciosas a una aplicaci贸n, lo m谩s probable es que desee observar el comportamiento habitual del usuario durante alg煤n tiempo. Al examinar las consultas para varios puntos finales de la aplicaci贸n, puede obtener una idea general de la estructura y las funciones de las consultas no peligrosas.

Ahora obtienes la siguiente consulta para an谩lisis:

imagen

Es inmediatamente evidente que algo est谩 mal aqu铆. Tomar谩 alg煤n tiempo comprender c贸mo es realmente aqu铆, y una vez que identifique la parte de la solicitud que parece anormal, puede comenzar a pensar qu茅 tipo de ataque es. En esencia, nuestro objetivo es hacer que nuestra "inteligencia artificial para detectar ataques" funcione de la misma manera: para parecerse al pensamiento humano.

Lo obvio es que parte del tr谩fico, que a primera vista parece malicioso, puede ser normal para un sitio web en particular.

Por ejemplo, consideremos las siguientes consultas:

imagen

驴Esta consulta es anormal?

De hecho, esta solicitud es una publicaci贸n de un error en el rastreador Jira y es t铆pica de este servicio, lo que significa que la solicitud es esperada y normal.

Ahora considere el siguiente ejemplo:

imagen

A primera vista, la solicitud parece un registro de usuario normal en un sitio web basado en Joomla CMS. Sin embargo, la operaci贸n solicitada es user.register en lugar del registro.register habitual. La primera opci贸n est谩 desactualizada y contiene una vulnerabilidad que permite a cualquiera registrarse como administrador. Un exploit para esta vulnerabilidad se conoce como Joomla <3.6.4 Creaci贸n de cuenta / Escalada de privilegios (CVE-2016-8869, CVE-2016-8870).

imagen

Por donde empezamos


Por supuesto, primero examinamos las soluciones existentes al problema. Se han realizado varios intentos para crear algoritmos de detecci贸n de ataques basados 鈥嬧媏n estad铆sticas o aprendizaje autom谩tico durante d茅cadas. Uno de los enfoques m谩s populares es resolver el problema de clasificaci贸n, cuando las clases son algo as铆 como "consultas esperadas", "inyecciones SQL", XSS, CSRF, etc. De esta manera, puede lograr una buena precisi贸n para el conjunto de datos utilizando el clasificador Sin embargo, este enfoque no resuelve problemas muy importantes desde nuestro punto de vista:

  1. La selecci贸n de clase es limitada y predeterminada . 驴Qu茅 sucede si su modelo en el proceso de aprendizaje est谩 representado por tres clases, digamos "consultas normales", SQLi y XSS, y durante la operaci贸n del sistema encuentra CSRF o un ataque de d铆a cero?
  2. El significado de estas clases . Suponga que necesita proteger diez clientes, cada uno de los cuales ejecuta aplicaciones web completamente diferentes. Para la mayor铆a de ellos, no tienes idea de c贸mo se ve realmente la inyecci贸n SQL para su aplicaci贸n. Esto significa que de alguna manera debe crear artificialmente conjuntos de datos de entrenamiento. Este enfoque no es 贸ptimo, porque finalmente aprender谩 de los datos que difieren en la distribuci贸n de los datos reales.
  3. Interpretabilidad de los resultados del modelo . Bueno, el modelo produjo el resultado de la inyecci贸n SQL, 驴y ahora qu茅? Usted y, lo que es m谩s importante, su cliente, que es el primero en ver una advertencia y generalmente no es un experto en ataques web, debe adivinar qu茅 parte de la solicitud su modelo considera malicioso.

Teniendo en cuenta todos estos problemas, decidimos intentar entrenar el modelo clasificador de todos modos.

Dado que el protocolo HTTP es un protocolo de texto, era obvio que necesit谩bamos echar un vistazo a los clasificadores de texto modernos. Un ejemplo bien conocido es el an谩lisis de sentimientos en un conjunto de datos de revisi贸n de pel铆culas IMDB. Algunas soluciones usan RNN para clasificar las revisiones. Decidimos probar un modelo similar con arquitectura RNN con algunas peque帽as diferencias. Por ejemplo, la arquitectura RNN de lenguaje natural usa una representaci贸n vectorial de palabras, pero no est谩 claro qu茅 palabras ocurren en un lenguaje no natural como HTTP. Por lo tanto, decidimos usar la representaci贸n vectorial de s铆mbolos para nuestra tarea.

Las representaciones preparadas no resuelven nuestro problema, por lo que utilizamos asignaciones simples de caracteres en c贸digos num茅ricos con varios marcadores internos, como GO y EOS .

Despu茅s de que se complet贸 el desarrollo y las pruebas del modelo, todos los problemas previstos anteriormente se hicieron aparentes, pero al menos nuestro equipo pas贸 de supuestos in煤tiles a alg煤n resultado.

Que sigue


Luego, decidimos dar algunos pasos hacia la interpretabilidad de los resultados del modelo. En alg煤n momento, nos encontramos con el mecanismo de atenci贸n "Atenci贸n" y comenzamos a implementarlo en nuestro modelo. Y dio resultados prometedores. Ahora nuestro modelo comenz贸 a mostrar no solo etiquetas de clase, sino tambi茅n factores de atenci贸n para cada personaje que pasamos al modelo.

Ahora podr铆amos visualizar y mostrar en la interfaz web el lugar exacto donde se detect贸 el ataque de inyecci贸n SQL. Este fue un buen resultado, pero otros problemas de la lista segu铆an sin resolverse.

Era obvio que deber铆amos seguir avanzando para beneficiarnos del mecanismo de atenci贸n y alejarnos de la tarea de clasificaci贸n. Despu茅s de leer una gran cantidad de estudios relacionados sobre modelos de secuencia (sobre mecanismos de atenci贸n [2], [3], [4], sobre la representaci贸n vectorial, sobre las arquitecturas de autoencoders) y experimentos con nuestros datos, pudimos crear un modelo de detecci贸n de anomal铆as que finalmente funcionar铆a m谩s o menos como lo hace un experto.

Codificadores autom谩ticos


En alg煤n momento, qued贸 claro que la arquitectura de Seq2Seq [5] es la m谩s adecuada para nuestra tarea.

El modelo Seq2Seq [7] consta de dos LSTM multicapa: un codificador y un decodificador. El codificador asigna la secuencia de entrada a un vector de longitud fija. El decodificador decodifica el vector objetivo usando la salida del codificador. En el entrenamiento, un codificador autom谩tico es un modelo en el que los valores objetivo se establecen de la misma manera que los valores de entrada.

La idea es ense帽ar a la red a decodificar las cosas que vio o, en otras palabras, acercar la identidad. Si un codificador autom谩tico capacitado recibe un patr贸n anormal, probablemente lo recrea con un alto grado de error, simplemente porque nunca se ha visto.

imagen

Soluci贸n


Nuestra soluci贸n consta de varias partes: inicializaci贸n del modelo, capacitaci贸n, pron贸stico y verificaci贸n. Esperamos que la mayor parte del c贸digo ubicado en el repositorio no requiera explicaci贸n, por lo que nos centraremos solo en las partes importantes.

El modelo se crea como una instancia de la clase Seq2Seq, que tiene los siguientes argumentos de constructor:

imagen

A continuaci贸n, se inicializan las capas de codificador autom谩tico. Primer codificador:

imagen

Luego el decodificador:

imagen

Como el problema que estamos resolviendo es detectar anomal铆as, los valores objetivo y la entrada son los mismos. Entonces nuestro feed_dict se ve as铆:

imagen

Despu茅s de cada era, el mejor modelo se guarda como un punto de referencia, que luego se puede descargar. Con fines de prueba, se cre贸 una aplicaci贸n web que defendimos con un modelo para verificar si los ataques reales tuvieron 茅xito.

Inspirado por el mecanismo de atenci贸n, tratamos de aplicarlo al modelo de codificador autom谩tico para marcar las partes anormales de esta consulta, pero notamos que las probabilidades derivadas de la 煤ltima capa funcionan mejor.

imagen

En la etapa de prueba de nuestra muestra retrasada, obtuvimos muy buenos resultados: la precisi贸n y la recuperaci贸n son cercanas a 0,99. Y la curva ROC tiende a 1. Se ve incre铆ble, 驴no?

imagen

Resultados


El modelo propuesto del codificador autom谩tico Seq2Seq pudo detectar anomal铆as en las solicitudes HTTP con una precisi贸n muy alta.

imagen

Este modelo act煤a como una persona: solo estudia las solicitudes de usuario "normales" para una aplicaci贸n web. Y cuando detecta anomal铆as en las solicitudes, selecciona la ubicaci贸n exacta de la solicitud, que considera an贸mala.

Probamos este modelo en algunos ataques en una aplicaci贸n de prueba y los resultados fueron prometedores. Por ejemplo, la imagen de arriba muestra c贸mo nuestro modelo detect贸 una inyecci贸n SQL dividida en dos par谩metros en un formulario web. Dichas inyecciones SQL se denominan fragmentadas: partes de la carga 煤til de ataque se entregan en varios par谩metros HTTP, lo que dificulta la detecci贸n de WAF basados 鈥嬧媏n reglas, ya que generalmente prueban cada par谩metro individualmente.

El c贸digo del modelo y los datos de entrenamiento y prueba se publican como una computadora port谩til Jupyter para que todos puedan reproducir nuestros resultados y sugerir mejoras.

En conclusi贸n


Creemos que nuestra tarea fue m谩s bien no trivial. Nos gustar铆a, con un m铆nimo de esfuerzo (en primer lugar, evitar errores debido a la complejidad de la soluci贸n), encontrar una forma de detectar ataques que, como por arte de magia, hayan aprendido a decidir qu茅 es bueno y qu茅 es malo. En segundo lugar, quer铆a evitar problemas con el factor humano, cuando exactamente un experto decide qu茅 es un signo de un ataque y qu茅 no. En resumen, me gustar铆a se帽alar que el codificador autom谩tico con la arquitectura Seq2Seq para el problema de la b煤squeda de anomal铆as, en nuestra opini贸n y para nuestro problema, hizo un excelente trabajo.

Tambi茅n quer铆amos resolver el problema con la interpretaci贸n de los datos. El uso de arquitecturas complejas de redes neuronales suele ser muy dif铆cil. En una serie de transformaciones, ya es dif铆cil decir al final qu茅 exactamente qu茅 parte de los datos influy贸 m谩s en la decisi贸n. Sin embargo, despu茅s de repensar el enfoque de la interpretaci贸n de datos por el modelo, result贸 suficiente para nosotros obtener las probabilidades para cada s铆mbolo de la 煤ltima capa.

Cabe se帽alar que esta no es una versi贸n de producci贸n. No podemos revelar los detalles de la implementaci贸n de este enfoque en un producto real, y queremos advertir que simplemente tomar e incorporar esta soluci贸n en alg煤n producto no funcionar谩.

Repositorio de GitHub: goo.gl/aNwq9U

Autores : Alexandra Murzina ( murzina_a ), Irina Stepanyuk ( GitHub ), Fedor Sakharov ( GitHub ), Arseniy Reutov ( Raz0r )

Referencias


  1. Comprender las redes LSTM
  2. Atenci贸n y redes neuronales recurrentes aumentadas
  3. La atenci贸n es todo lo que necesitas
  4. La atenci贸n es todo lo que necesitas (anotado)
  5. Tutorial de traducci贸n autom谩tica neuronal (seq2seq)
  6. Autoencoders
  7. Secuencia a secuencia de aprendizaje con redes neuronales
  8. Construcci贸n de codificadores autom谩ticos en Keras

Source: https://habr.com/ru/post/439202/


All Articles