Tráfico malicioso en redes 5G

AUTOR: ALEJANDRO MUÑIZ DA COSTA

TÍTULO: DISEÑO Y EVALUACIÓN DE MECANISMOS DE DETECCIÓN DE TRÁFICO MALICIOSO EN REDES 5G

INTRODUCCIÓN

En este documento vamos a resumir el trabajo de fin de máster realizado el pasado curso gracias a la colaboración de la beca 5G Francisco Ros – Qualcomm. Este trabajo se engloba a su vez dentro del contexto de proyecto europeo SPIDER: “a cyberSecurity Platform for vIrtualiseD 5G cybEr Range services”, del cual participé formando parte del grupo de investigación RSTI (Redes y Servicios de Telecomunicación e Internet) de la facultad de telecomunicaciones de la UPM.

El principal objetivo de este proyecto fue la identificación de tráfico malicioso a través de mecanismos de Machine Learning, siendo mi parte la encargada de la generación de tráfico sintético para la realización de los entrenamientos de los algoritmos. En este proyecto hemos contado con dos escenarios de ataque: el primero de ellos es el de un secuestro de capacidades para criptominado y el segundo es el uso de la red para realizar un ataque de denegación de servicio a un servidor de resolución de nombres (DNS). Para ello hemos contado con los siguientes esquemas de red:

Arquitectura de red del Escenario 1.
Arquitectura de red del Escenario 2.

Preparación de entorno y pruebas

La primera fase del proyecto consistió en integrar los clientes con el core ya definido por mis compañeros, comprobando así la capacidad de la red y terminando de realizar el despliegue. Estos clientes contenían las herramientas que serían utilizadas posteriormente para realizar los ataques DoS, además de un generador de tráfico que nos serviría para inyectar tráfico realista alrededor de los ataques. Además, tuvimos que realizar modificaciones en la configuración del core 5G para poder realizar un envío de tráfico suficientemente grande como para ser identificable.

Una vez el entorno ya estaba operativo, comenzamos con la preparación de los ataques. En el primer escenario utilizamos un cliente de minado Monero[1], XMRig, del cual generamos tres instancias una vez comprobamos que todo funcionaba correctamente. Estas instancias sirvieron para introducir una mayor cantidad de tráfico de red (estos clientes realizan un gran esfuerzo computacional pero apenas realizan comunicaciones de red, haciéndolos más difíciles de ver mediante herramientas que evalúen esto) y a su vez para contar con uno de los clientes sin tráfico cifrado.

En el segundo escenario, instalamos la herramienta dnscrypt-proxy para poder realizar peticiones DoH (DNS over HTTPS) y lo pusimos como método por defecto. De esta manera pudimos realizar evaluaciones de estrés al servidor DNS con la herramienta flamethrower instalada previamente. Una vez contamos con los parámetros necesarios para realizar un ataque que se ajustase a las necesidades del algoritmo de Machine Learning para realizar su entrenamiento, pudimos realizar las pruebas con tráfico de fondo.

.

Una vez tuvimos los dos escenarios operativos, procedimos a realizar las capturas de red. En el Escenario 1 realizamos dos tipos de ataques, para así contar con densidades distintas y con el objetivo de utilizar las capturas más densas para el aprendizaje y el otro tipo para la evaluación.

En cambio, en el Escenario 2 realizamos tres tipos de ataque, modificando el porcentaje de tráfico que corresponde con HTTPS legítimo junto peticiones DNS, peticiones DoH y ataques de inundación DoH. Además, en ambos escenarios realizamos una medida del estrés soportado en las víctimas y del cómo varió el tráfico de red.

RESULTADOS

Los resultados obtenidos fueron que, en el Escenario 1, el estrés computacional de la víctima (el core 5G) no dependía del número de clientes, dado que solamente con uno ya se podían saturar todos los núcleos del sistema (aunque ese escalado sí tenía efecto sobre el uso de la RAM), mientras que al escalar los clientes también aumentaba el tráfico de red, siendo más fácil su detección. En el Escenario 2, al realizar pruebas libres obtuvimos una saturación de hasta un 80% en los dos núcleos de la víctima (el servidor DNS), pero este porcentaje se vio reducido notablemente al realizar las pruebas con los porcentajes de carga que requería el algoritmo de ML. Este problema es debido al escaso alcance del entorno, dado que en un escenario real contaríamos con una gran cantidad de dominios de red dentro del tráfico de una celda 5G, pero dado que ese nivel de precisión no era posible de reproducir, decidimos ajustar los valores de tráfico generado.

Con estos resultados, el equipo de inteligencia artificial que colaboró en este proyecto pudo realizar satisfactoriamente el entrenamiento de su algoritmo, el cual fue implementado posteriormente en un entorno de CyberRange de manera exitosa. Además, como complemento dentro del alcance del TFM pero fuera del alcance del proyecto SPIDER, hemos realizado un análisis de los resultados con herramientas de detección de tráfico basado en reglas SURICATA.  En estas pruebas hemos visto como, en el mejor de los casos, los resultados obtenidos son similares a los del ML pero dependiendo mucho de que los pools de minado accedidos no varíen o de que no se utilicen métodos de ofuscación del tráfico (como clientes proxy o VPNs).

CONCLUSIÓN

Como conclusión, en este trabajo hemos podido formar parte de un grupo de investigación en un proyecto europeo, cumpliendo con los objetivos propuestos en el proyecto. Además, hemos estudiado algunas de las principales vulnerabilidades que puede traer consigo la quinta generación de las comunicaciones móviles, así como el diseño de un método de detección basado en inteligencia artificial. Por último, cabe destacar la ciberseguridad como una unidad integral, donde no se puede descuidar ni la seguridad física, ni la seguridad de los sistemas ni la de las redes, dado que, como en una cadena, nuestro sistema siempre será tan débil como el más vulnerable de sus componentes.

AUTOR

Alejandro Muñiz da Costa

Tutor: José Ignacio Moreno

Mecanismos de detección de tráfico malicioso en redes 5G

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *