Proyecto de fin de carrera · Universidad de Dublín · 2024—2025
Cortafuegos de SMS para 5G
Los mensajes de texto siguen transportando códigos de un solo uso, alertas bancarias y enlaces de recuperación de cuentas, lo que convierte al SMS en una de las superficies más atacadas de una red móvil. Este es un cortafuegos que inspecciona el SMS dentro de un núcleo 5G, bloquea el smishing en tiempo real y se construyó y midió contra una simulación funcional de la red en la que iría instalado.
- OMNeT++ / C++
- Flask
- DistilBERT
- PostgreSQL
- Google Cloud Run
- React
- Periodo
- 2024 — 2025
- Contexto
- Proyecto de fin de carrera, Grado en Ingeniería Informática
- Institución
- Universidad de Dublín (DCU)
- Despliegue
- Google Cloud Run, alimentado por una simulación en OMNeT++
- 81,8/s
- Mensajes sostenidos
- 1.100 ms
- Percentil 95
- <100 ms
- Inferencia del modelo
- 0 %
- Tasa de fallo
Con ocho instancias del Message Processor bajo el perfil de tráfico alto, sin ninguna petición fallida.
Latencia en el peor caso a carga máxima, frente a 2.800 ms con una sola instancia.
Tiempo medio de clasificación de DistilBERT devuelto desde Cloud Run.
En todos los perfiles de carga y configuraciones de servicio probados.
01El problema
El SMS es antiguo, se confía en él y sigue siendo la vía más fácil
Casi cualquier cuenta que tengas se puede alcanzar mediante un mensaje de texto. Códigos de un solo uso, avisos de entrega, alertas bancarias, restablecimientos de contraseña: todo llega por un protocolo diseñado en los años ochenta, sin autenticación del remitente y sin ninguna forma nativa de distinguir a un banco de alguien que finge serlo.
Los atacantes lo saben. El smishing —phishing enviado por SMS— funciona porque el mensaje aterriza en el mismo hilo que los legítimos, en un dispositivo en el que la gente confía sin pensarlo. A medida que el 5G traslada la mensajería a infraestructura basada en IP y aumenta el volumen que soportan las redes, esa superficie no deja de crecer.
Las herramientas que los operadores suelen aplicar al problema son estáticas: coincidencias de patrones fijas y listas negras mantenidas a mano. Detienen la campaña de ayer. No detienen un mensaje que nunca se ha visto antes, escrito por alguien que sabe qué buscan los filtros.
Este proyecto plantea cómo sería un filtro pensado para ese problema: uno que inspeccione los mensajes dentro del núcleo 5G, combine comprobaciones deterministas baratas con un modelo de lenguaje que entiende la formulación, y aun así entregue un mensaje legítimo lo bastante rápido como para que nadie note que fue leído.
Smishing
Phishing entregado por mensaje de texto, aprovechando la confianza que la gente deposita en su bandeja de mensajes.
Cebo de urgencia
Mensajes diseñados para forzar un clic inmediato: una cuenta suspendida, un pago fallido, un envío retenido.
Inundación de SMS
Ráfagas de alta frecuencia desde un único remitente, usadas para campañas de spam o para agotar los recursos de la red.
URLs maliciosas
Enlaces acortados o que imitan a otros y llevan a páginas de robo de credenciales.
- UE
- gNodeB
- AMF
- Cortafuegos
- SMSF
- UDM
02Pruébalo
Pasa un mensaje por la tubería de decisión
El cortafuegos llega a su decisión en cinco etapas. Las tres primeras se ejecutan en paralelo y pueden detener un mensaje de inmediato; solo lo que las supera se puntúa, y solo una puntuación lo bastante alta llega a un modelo de lenguaje. Todo lo de abajo ejecuta esa misma lógica real en tu navegador.
Ejemplos
Enviados en la ventana: 0/8
Envía varias veces desde el mismo número para activar la regla de inundación.
Elige un ejemplo o escribe tu propio mensaje y después inspecciónalo.
- 01—
Filtrado por reglas
MSISDN en lista negra y prefijos de país o de red bloqueados, leídos del conjunto de reglas en caché.
- 02—
Detección de inundación
Mensajes por remitente dentro de una ventana deslizante. Superarla inicia un periodo de enfriamiento durante el cual se descarta todo.
- 03—
Comprobación de URLs
Toda URL presente en el mensaje se extrae y se contrasta con Google Safe Browsing.
- 04—
Motor de puntuación de palabras
Palabras clave ponderadas, más penalizaciones por secuencias largas de dígitos y mensajes inusualmente cortos.
- 05—
Clasificador DistilBERT
Un modelo DistilBERT afinado con el conjunto de datos SMS Spam Collection, al que solo se llega por encima del umbral.
03Arquitectura
Tres planos, unidos por una sola llamada HTTP
El sistema se divide en tres planos que escalan, se despliegan y fallan por separado. Un núcleo 5G simulado transporta el tráfico. Un conjunto de microservicios en la nube decide qué hacer con él. Un panel del lado del operador define las reglas y observa el resultado.
El único acoplamiento entre la red y el motor de decisión es una única llamada HTTP síncrona. Fue deliberado: el módulo de cortafuegos dentro de la red no sabe nada de puntuaciones, aprendizaje automático ni bases de datos. Hace una pregunta y actúa según la respuesta, lo que permite reescribir o redesplegar cualquier servicio de la nube sin que la red se entere.
Las reglas viajan en sentido contrario, y nunca de forma síncrona. Un administrador las edita en local, las sincroniza con Cloud SQL a través de un servicio intermedio y se exportan como JSON a un bucket de almacenamiento que el Message Processor consulta periódicamente. Nada en el camino del mensaje espera jamás a una base de datos.
Núcleo 5G simulado
01
Módulos propios de OMNeT++ en C++ y NED que implementan las funciones de red que un SMS atraviesa realmente, más una interconexión IPX para que los mensajes puedan cruzar fronteras entre operadores.
- UE
- gNodeB
- AMF
- Firewall
- SMSF
- UDM
- IPX
Plano de decisión en la nube
02
Servicios Flask sobre Google Cloud Run: el Message Processor que toma todas las decisiones, el clasificador DistilBERT al que escala y un servicio intermedio que sincroniza reglas y devuelve registros. El estado vive en Cloud SQL y en una caché de reglas en Cloud Storage.
- MessageProcessor
- DistilBERT service
- RuleLogInterface
- Cloud SQL
- GCS rule cache
Plano de administración del operador
03
Un panel Django y React en contenedores donde las reglas se escriben y revisan antes de entrar en producción, con Redis y Celery absorbiendo el flujo de registros para que la ingesta nunca bloquee la interfaz.
- Django
- React
- PostgreSQL
- Redis
- Celery
04La red
Un núcleo 5G construido para ser atacado
Probar un cortafuegos requiere tráfico, y el tráfico requiere una red. En lugar de simularla superficialmente, construimos un modelo funcional del plano de control 5G en OMNeT++: cada módulo escrito desde cero en C++ y NED, siguiendo las definiciones de funciones de 3GPP TS 23.501 y TS 33.501.
Los mensajes recorren el camino real. Un terminal se registra en la red, las tablas de enrutado anotan tras qué estación base y función de acceso se encuentra, y después un SMS atraviesa la red de acceso radio, la función de acceso, el cortafuegos, la función de SMS y la de gestión de datos antes de bajar de nuevo hasta el destinatario.
Se modelaron dos operadores conectados mediante nodos de interconexión IPX, de modo que la entrega entre operadores pudiera ejercitarse junto al tráfico interno: el caso en el que un mensaje llega desde una red que no controlas, que es de donde procede la mayor parte del abuso.
La topología, el enrutado y la planificación de mensajes se controlan desde ficheros CSV y .ini. Añadir doce terminales, un segundo operador o un nuevo patrón de spam es un cambio de configuración, no una recompilación.
- UE (Actor)
- Un terminal, parametrizado con un IMSI, un MSISDN y la sección de la red radio a la que está conectado. Envía y recibe según una planificación leída de fichero.
- gNodeB
- La estación base 5G. Resuelve si un mensaje llegó de un terminal o del núcleo por el nombre de la puerta y no por su índice, de modo que la topología puede cambiar sin tocar el código.
- AMF
- Gestión de acceso y movilidad. Consulta tras qué estación base está el destinatario y encamina el mensaje, o lo deriva al cortafuegos para su inspección.
- Cortafuegos
- Un proxy entre el núcleo y la nube. Serializa el mensaje a JSON, lo envía mediante libcurl y lo reenvía a la función de SMS o lo descarta.
- SMSF
- La función de SMS. Entrega internamente de vuelta por la función de acceso, o entrega el mensaje al IPX para el enrutado entre operadores.
- UDM
- Gestión unificada de datos. Guarda los registros de abonado y confirma la ruta antes de la entrega final.
- IPX
- La interconexión entre operadores. Retransmite mensajes a través de las fronteras de red y entrega el tráfico entrante al cortafuegos del operador receptor.
Hacer que C++ hable con un servicio en la nube
OMNeT++ no tiene cliente HTTP. El módulo de cortafuegos usa libcurl para hacer un POST síncrono al Message Processor en Google Cloud, construye el JSON a mano y extrae el veredicto de la respuesta antes de decidir si reenvía o descarta. Es una pieza de pegamento poco vistosa, y es justo lo que convierte una simulación en una prueba de extremo a extremo de servicios en producción.
05Motor de decisión
Primero lo barato; el modelo, solo cuando se lo gana
Todo mensaje que llega al Message Processor debe responderse dentro de la misma petición. Ese presupuesto condiciona todo el diseño: el trabajo caro tiene que ser poco frecuente y nada que pueda ejecutarse en paralelo debería ejecutarse en secuencia.
Tres comprobaciones independientes se despachan juntas sobre un pool de hilos, y gana el primer bloqueo: si un remitente ya está en lista negra, no hay razón para esperar a que termine la consulta de URLs. Solo los mensajes que superan las tres se puntúan, y solo los que alcanzan el umbral se envían al modelo de lenguaje. En la práctica, la gran mayoría del tráfico nunca lo toca.
La aplicación de la política es deliberadamente indulgente. Una sola infracción no mete a nadie en la lista negra: los avisos se cuentan por categoría y solo se bloquea al remitente que cruza el umbral, escribiéndolo además directamente en la caché de reglas en memoria, para que surta efecto en el siguiente mensaje y no en la siguiente actualización.
- Filtrado en paralelo. La coincidencia de reglas, la detección de inundación y la consulta de URLs se ejecutan a la vez sobre un pool de hilos, devolviendo en cuanto cualquiera de ellas dice bloquear.
- Puntuación de palabras. Palabras clave ponderadas, editables desde el panel en una escala de uno a diez, más penalizaciones por secuencias largas de dígitos y mensajes inusualmente cortos. Veinte puntos escalan.
- Escalado. Un modelo DistilBERT afinado con el conjunto de datos SMS Spam Collection, alojado como su propio servicio Flask para poder escalar, y fallar, de forma independiente.
- Sistema de avisos. Infracciones contadas por categoría. Cruzar el umbral mete al remitente en la lista negra y actualiza la caché de reglas al instante.
- Limitación de frecuencia. Una ventana deslizante por remitente con enfriamiento posterior, mantenida en memoria tras contadores seguros frente a concurrencia, sin ningún limitador externo en el camino de la petición.
- Caché de reglas. Reglas descargadas de un bucket de almacenamiento al arrancar y refrescadas cada diez minutos, conservando el último conjunto válido si la descarga falla.
- Colas no bloqueantes. Las escrituras en base de datos y el envío de webhooks se delegan a un pool de hilos después de devolver el veredicto, de modo que un consumidor lento no puede frenar el procesamiento.
- Pool de conexiones. Un pool compartido de hasta cuarenta conexiones PostgreSQL, introducido después de que las primeras versiones agotaran el servidor abriendo una por mensaje.
06Resultados
Qué hace bajo carga
Las pruebas de carga usaron Locust contra los servicios desplegados, con dos perfiles de tráfico y varias configuraciones de servicio. Se informa del percentil 95 en lugar de la media: lo que importa es el peor mensaje, no el promedio.
50 usuarios concurrentes, con 10/s de arranque
Rendimiento
req/s · ↑
- ×120.020.0
- ×237.737.7
- ×459.259.2
- ×881.881.8
Instancias del Message Processor
Latencia percentil 95
ms · ↓
- ×12,8002,800
- ×21,9001,900
- ×41,8001,800
- ×81,1001,100
Instancias del Message Processor
| Instancias MP | Servicio de IA | Rendimiento (pet/s) | Latencia p95 (ms) | Fallos |
|---|---|---|---|---|
| ×1 | 1 × 2 vCPU | 20.0 | 2,800 | 0% |
| ×2 | 1 × 2 vCPU | 37.7 | 1,900 | 0% |
| ×4 | 2 × 4 vCPU | 59.2 | 1,800 | 0% |
| ×8 | 2 × 4 vCPU | 81.8 | 1,100 | 0% |
- El cuello de botella no era el modelo. La suposición de partida era que el clasificador sería la limitación. Las métricas de la nube mostraron lo contrario: el servicio de IA nunca alcanzó su cuota de instancias ni siquiera en ráfagas, mientras que el Message Processor se saturaba. El límite estaba en la entrada, la evaluación de reglas y el enrutado.
- El escalado fue casi lineal. Pasar de cuatro a ocho instancias del Message Processor, sin tocar el servicio de IA, elevó el rendimiento un 39 % y redujo la latencia del percentil 95 en más de un 35 %.
- Se mantuvo correcto bajo tensión. Ninguna petición fallida en ninguna configuración ni en ninguno de los dos perfiles. Nada se descartó por la lentitud de un servicio dependiente.
- De ahí sale el criterio de dimensionado. Bajo carga, añadir réplicas del Message Processor rinde más que añadir réplicas del modelo, hasta que el propio modelo se satura, algo que estas pruebas nunca llegaron a provocar.
07Resiliencia
Toda dependencia tiene permiso para fallar
Un cortafuegos que deja de pasar mensajes cuando una base de datos no responde se ha convertido él mismo en la incidencia. A cada dependencia se le asignó un comportamiento de fallo definido, y la entrega de mensajes no depende de ninguna.
| Si esto falla | El sistema hace esto |
|---|---|
| El almacenamiento de reglas no está disponible | Recurre al último conjunto de reglas en caché que tiene en memoria. El procesamiento continúa sin cambios; no se pierde ninguna regla, solo se retrasa la actualización. |
| Cloud SQL inalcanzable | Las decisiones se toman con las reglas en memoria y se devuelven con normalidad. Las escrituras de registro fallan en silencio y se anotan como errores en lugar de bloquear el veredicto. |
| Clasificador de IA caído | Se omite el paso de escalado y el mensaje se deja pasar solo con su puntuación. El evento queda registrado para que el hueco sea visible después. |
| Destino del webhook inalcanzable | El envío es de tipo «dispara y olvida» en un hilo secundario. Los fallos de entrega se registran; el panel se queda atrás, el cortafuegos no. |
| Un remitente inunda la red | La ventana deslizante bloquea al remitente infractor en el cortafuegos, antes de que el mensaje llegue a las funciones de acceso, SMS o gestión de datos, manteniendo el tráfico de inundación completamente fuera del núcleo. |
08Operación
La parte que un operador usa de verdad
Un cortafuegos vale lo que valga la capacidad de ver qué hizo y de cambiar qué hará después. El panel de administración es una aplicación Django y React en contenedores: Django sirve las APIs y custodia el conjunto de reglas autorizado, React lo representa, y Redis y Celery se sitúan entre la ingesta de registros y su procesamiento para que una ráfaga de tráfico se encole en vez de bloquear.
Las reglas se editan en local y se revisan antes de salir a ninguna parte. Una sincronización envía el conjunto actual —incluidas las entradas borradas de forma lógica, para que las eliminaciones queden versionadas y no se pierdan en silencio— a Cloud SQL a través del servicio intermedio, y un paso de despliegue aparte recarga el Message Processor.
Los registros llegan de forma continua por webhook, con una descarga manual como reserva si el flujo se interrumpe. Cada entrada anota la etapa que decidió el resultado, la regla infringida, la puntuación y la predicción del modelo, de modo que cualquier bloqueo se puede rastrear hasta su motivo.
- Tabla de registros en vivo. Todos los mensajes procesados con su etapa, infracción de regla, puntuación y predicción del modelo, filtrables por país, estado, motivo y regla.
- Etapas de procesamiento. Un desglose por mensaje que muestra qué componente tomó la decisión y cómo llegó a ella.
- Vista geográfica. Volumen bloqueado por país sobre un mapa interactivo, con los registros subyacentes a un clic.
- Análisis de palabras. Qué términos aparecen en el tráfico bloqueado y la proporción de bloqueo frente a permiso de cada uno: el bucle de realimentación para ajustar los pesos.
- Gestión de reglas. Umbrales de spam, palabras ponderadas y redes de países bloqueadas, con acciones explícitas de sincronizar y desplegar.
- Gráficas de tendencia. Volumen por hora, tasa de bloqueo en el tiempo, evolución de las puntuaciones y frecuencia de coincidencia de reglas.
09Ingeniería
Qué se rompió y qué lo arregló
La parte interesante de una construcción rara vez es el diseño. Estos son los problemas que solo aparecieron con el sistema en marcha, y lo que cambió cada uno.
01
Se agotaron las conexiones a la base de datos
Problema
Las primeras versiones abrían una conexión PostgreSQL nueva por cada mensaje. Bajo carga, el servidor alcanzaba su límite de conexiones y el procesamiento se detenía por completo: tiempos de espera agotados, fallos, cero rendimiento.
Solución
Un pool compartido de hasta cuarenta conexiones reutilizadas. El agotamiento dejó de ser posible y el comportamiento con carga concurrente se volvió predecible.
02
Los webhooks bloqueaban el camino de la petición
Problema
El envío de webhooks y el registro en base de datos se ejecutaban dentro del hilo que atendía el mensaje. Un único destino externo lento retrasaba todos los mensajes encolados detrás.
Solución
Ambos pasaron a un pool de hilos y se despachan después de devolver el veredicto. Un fallo se registra y nada en el camino del mensaje lo espera.
03
BERT era demasiado pesado para servirlo
Problema
El primer clasificador usaba bert-base-uncased. Su huella de memoria y su tiempo de inferencia lo hacían inviable para filtrado en tiempo real sobre infraestructura sin servidor.
Solución
Se cambió a distilbert-base-uncased y se limitó la entrada a 25 tokens, acorde con la longitud de un SMS. La inferencia bajó de 100 ms manteniendo la calidad de clasificación.
04
Las reglas se consultaban por cada mensaje
Problema
Cada mensaje disparaba una consulta a la base de datos para obtener el conjunto de reglas vigente. Añadía latencia a todas las peticiones y cargaba la base de datos en proporción directa al tráfico.
Solución
Las reglas se exportan como JSON a un bucket de almacenamiento, se cargan en memoria al arrancar y se refrescan cada diez minutos. La carga de la base de datos dejó de escalar con el tráfico.
05
Un solo error te metía en la lista negra
Problema
Cualquier infracción aislada metía al remitente en la lista negra de inmediato. Un falso positivo, o un mensaje descuidado, cortaba permanentemente a un abonado legítimo.
Solución
Un sistema de avisos que cuenta infracciones por categoría y solo bloquea al cruzar un umbral. La aplicación de la política siguió siendo firme sin volverse frágil.
06
Los bloqueos tardaban diez minutos en verse
Problema
Un remitente bloqueado por el sistema de avisos se escribía en la base de datos, pero la caché de reglas en memoria no se enteraba hasta su siguiente actualización programada. Durante hasta diez minutos, un remitente bloqueado podía seguir enviando.
Solución
Las infracciones se escriben ahora también en la caché activa, cerrando la ventana entre la infracción y su aplicación.
07
La simulación se rompía al cambiar la topología
Problema
Los módulos de la función de acceso y de la estación base encaminaban por índices de puerta fijos. Cambiar el número de terminales o de estaciones base en el fichero .ini provocaba pérdidas silenciosas de mensajes o caídas directas.
Solución
El enrutado resuelve las puertas por nombre y no por posición. La simulación escala a cualquier topología sin cambios de código, que es lo que hizo posibles los escenarios mayores con varios operadores.
08
El simulador no sabía hablar HTTP
Problema
OMNeT++ no admite HTTP, pero el motor de decisión vivía en Google Cloud tras una API REST. Sin un puente, la simulación solo habría podido probar un sustituto.
Solución
Un cliente libcurl dentro del módulo de cortafuegos, que construye el JSON a mano y extrae el veredicto de la respuesta. La simulación acciona los servicios reales desplegados.
10Siguiente
Lo que todavía no hace
El sistema cumplió lo que se propuso. Estos son los límites que abordaríamos a continuación, y quedaron anotados como límites en lugar de descubrirse como sorpresas.
- Confianza, no solo etiquetas. El clasificador devuelve spam o legítimo. Devolver además una puntuación de confianza y los tokens que la motivaron permitiría poner en cuarentena los mensajes dudosos en vez de decidirlos.
- Propagación de reglas versionada. Sustituir la actualización cada diez minutos por ficheros de reglas versionados, cambiando de versión en un valle de tráfico y no por temporizador.
- Avisos que caducan. Los avisos son permanentes hasta reiniciarlos. Ponderar por gravedad y decaer con el tiempo modelaría la reputación mejor que un contador plano.
- Puntuación más rica. El motor de puntuación busca palabras sueltas. Los n-gramas o la ponderación TF-IDF captarían formulaciones que las palabras aisladas dejan pasar, sin cambiar nada más de la tubería.
- Reentrenamiento con tráfico real. El modelo se afinó una vez con un conjunto de datos público. Reentrenarlo periódicamente con el tráfico observado es el paso evidente, y el registro ya captura lo que haría falta.
- Pruebas de integración automatizadas. Las pruebas unitarias y de sistema están automatizadas; la integración entre los servicios desplegados se probó a mano. Automatizarlo es sencillo y quedó pendiente por tiempo.
Tecnologías
Construido con
Simulación
- OMNeT++
- INET
- Simu5G
- C++
- NED
- libcurl
Servicios
- Python
- Flask
- Django
- React
- Celery
- Redis
Aprendizaje automático
- DistilBERT
- Hugging Face Transformers
- PyTorch
Infraestructura
- Google Cloud Run
- Cloud SQL
- Cloud Storage
- PostgreSQL
- Docker
- GitLab CI/CD
Créditos
Equipo y documentación
Realizado como proyecto de fin de carrera entre dos personas para el Grado en Ingeniería Informática de la Universidad de Dublín, trabajado de forma conjunta en la simulación, los servicios en la nube y el panel de administración.
- Junto a
- Jack Keenan
- Tutor
- Prof. Mohammed Amine Togou
- Institución
- Universidad de Dublín (DCU), 2024—2025
- Normativa
- 3GPP TS 23.501, TS 24.501, TS 33.501
- Conjunto de datos
- SMS Spam Collection (Kaggle), usado para afinar el clasificador
- Documentación
- Especificación funcional, especificación técnica, documento de pruebas y manual de usuario: disponibles a petición.