Detección de anomalías en tráfico de red

01Problema

Los sistemas de detección de intrusiones clásicos funcionan con firmas: reglas escritas a mano para cada ataque conocido. Son precisos, pero ciegos ante un ataque que nadie ha visto todavía. La alternativa es darle la vuelta al problema: aprender cómo es el tráfico normal y avisar de todo lo que se aparte de él.

02Datos

Dataset NSL-KDD (Universidad de New Brunswick, 2009), una versión depurada del clásico KDD Cup 99. Cada fila es una conexión de red descrita con 41 variables en cuatro grupos:

Lo que hace interesante este dataset: el test incluye 17 tipos de ataque que no aparecen en el entrenamiento (mscan, apache2, snmpguess, processtable…): 3.750 conexiones, el 29,2 % de los ataques del test. Es la situación real de un sistema en producción.

Limitación: NSL-KDD viene de un tráfico simulado de 1998. Sirve para aprender y comparar métodos, no para proteger una red actual. Para eso se usan datasets modernos como CIC-IDS2017 o UNSW-NB15, con la misma metodología de este proyecto.

03Exploración

Cada familia de ataques deja una huella distinta en las variables (medianas del entrenamiento):

Un DoS como neptune (inundación SYN) abre cientos de conexiones medio abiertas contra el mismo host: se ve a la legua en las variables de tráfico. En cambio, un ataque R2L es una única conexión con un aspecto parecido al normal: la diferencia está en su contenido (por ejemplo, contraseñas probadas), no en su forma. Esta observación anticipa el resultado principal del proyecto.

Otros hallazgos: los bytes tienen colas enormes (el 39,2 % de las conexiones envía 0 bytes y el máximo pasa de 1.300 millones), el 35,5 % de los escaneos usa ICMP (ping) y la variable num_outbound_cmds vale siempre 0, así que se descarta.

04Preprocesado

• Logaritmo (log1p) en las 13 variables de cola larga (bytes, duración, contadores), para que un millón de bytes no aplaste todo lo demás. Después, estandarización.
• One-hot de protocolo, servicio y estado: 76 columnas en total.
• El preprocesado se ajusta solo con tráfico normal: el detector no debe saber nada de los ataques.
• El tráfico normal del entrenamiento se divide en 53.874 conexiones para ajustar los modelos y 13.469 para fijar el umbral de alarma.

colas = ["duration", "src_bytes", "dst_bytes", "count", "srv_count", ...]
prep = ColumnTransformer([
    ("colas", Pipeline([("log", FunctionTransformer(np.log1p, feature_names_out="one-to-one")),
                        ("esc", StandardScaler())]), colas),
    ("num", StandardScaler(), resto),
    ("cat", OneHotEncoder(handle_unknown="ignore"), ["protocol_type", "service", "flag"]),
], sparse_threshold=0)

normal = train[train["ataque"] == 0]
n_fit, n_val = train_test_split(normal, test_size=0.2, random_state=42)
prep.fit(n_fit)

05Detectores

Cuatro formas de medir «lo raro» que es una conexión, de la más simple a la más elaborada:

ae = nn.Sequential(nn.Linear(76, 64), nn.ReLU(), nn.Linear(64, 16), nn.ReLU(),
                   nn.Linear(16, 64), nn.ReLU(), nn.Linear(64, 76))
for epoca in range(60):                           # 18 s en CPU
    for b in lotes(Xf, 256):
        loss = ((ae(b) - b) ** 2).mean()          # aprende a copiar el tráfico normal
        opt.zero_grad(); loss.backward(); opt.step()

anomalia = ((ae(X) - X) ** 2).sum(1)              # lo que no sabe copiar, es raro

El umbral de cada detector se fija sin mirar ningún ataque: es el percentil 99 de las puntuaciones del tráfico normal de validación. Por construcción, deberían saltar falsas alarmas en el 1 % de las conexiones normales.

La idea del autoencoder, comprimir y reconstruir, es la misma que la de las redes neuronales del portal con una capa estrecha en medio. Isolation Forest es primo del Random Forest.

06Evaluación

Primera lección: el ROC-AUC engaña aquí. Todos los detectores superan 0,94, pero con el presupuesto real de falsas alarmas el PCA solo detecta el 6,5 % de los ataques y el Isolation Forest, el 57,1 %. El AUC promedia todos los umbrales posibles, incluidos los que nadie usaría; en seguridad solo importa la esquina izquierda de la curva, la de muy pocas falsas alarmas.

Segunda lección: los detectores se complementan. Por eso el modelo final los combina: cada puntuación se convierte en su percentil dentro del tráfico normal (así son comparables) y se promedian. Con un 1 % de presupuesto detecta el 60,7 %, más que cualquiera de los dos por separado, aunque también da algo más de falsas alarmas reales (1,9 % frente a 1,6 % y 1,4 %).

Tercera lección: el tráfico normal cambia. El umbral prometía un 1 % de falsas alarmas y en el test salen un 1,9 %: el tráfico normal del test no es idéntico al del entrenamiento. En producción pasa siempre; por eso hay que medir las falsas alarmas reales y reajustar el umbral.

07Por tipo de ataque

Tal como anticipaba la exploración: los ataques que cambian la forma del tráfico (DoS, escaneos) se detectan bien; los que se esconden en una conexión de aspecto normal (R2L: adivinar contraseñas, subir ficheros por FTP…) apenas se ven. Para esos hacen falta otras fuentes de datos, como los registros de autenticación de los servidores.

Comparación con un modelo supervisado

Un Random Forest entrenado con las etiquetas de ataque del entrenamiento tiene el mismo ROC-AUC (0,962), pero su comportamiento es muy distinto:

El supervisado es mejor con lo que ya ha visto y mucho peor con lo nuevo: aprendió «cómo son los ataques de 1998», no «cómo es lo normal». En la práctica se usan los dos juntos: el supervisado (o las firmas) para lo conocido y el detector de anomalías como red de seguridad para lo desconocido.

08Presupuesto de alertas

¿Cuántas falsas alarmas puede revisar el equipo de seguridad? Mueve el presupuesto y observa qué se detecta y qué precisión tendrían las alertas según lo frecuentes que sean los ataques en tu red.

La trampa de la tasa base. En el test, el 97,7 % de las alertas son ataques reales, pero es porque allí más de la mitad del tráfico es ataque. En una red real, donde los ataques son quizá el 0,1 % de las conexiones, solo el 3,1 % de las alertas sería un ataque real: el mismo fenómeno que los falsos positivos de un test médico del nivel 1. Con el presupuesto del 1 %, cada millón de conexiones normales genera unas 19.200 falsas alarmas.

Por eso ningún equipo revisa alertas sueltas: se agrupan por host y ventana de tiempo (un escaneo son cientos de conexiones anómalas seguidas desde la misma IP), se ordenan por puntuación y solo las más graves llegan a una persona.

09¿Por qué salta la alarma?

Una alerta sin explicación no sirve a un analista. El autoencoder permite ver qué variables no ha sabido reconstruir: son las que hacen rara a esa conexión.

Las dos explicaciones tienen sentido para un experto: el escaneo provoca rechazos y conexiones incompletas; el ataque de contraseñas, sesiones telnet largas y repetidas. Y el escaneo mscan no existía en el entrenamiento.

10Despliegue

1. Captura: un sensor (Zeek, NetFlow o CICFlowMeter) resume cada conexión en variables como las de este dataset.
2. Puntuación: un servicio aplica el mismo preprocesado y los dos detectores. Es barato: en nuestra prueba, preprocesado incluido, puntuó unas 60.000 conexiones por segundo en una CPU.
3. Agregación: las conexiones anómalas se agrupan por IP de origen y ventana de tiempo antes de crear una alerta.
4. SIEM: las alertas llegan a la consola del equipo de seguridad con su puntuación y sus variables explicativas.
5. Retroalimentación: lo que el analista confirma como ataque alimenta al modelo supervisado; lo que descarta ayuda a recalibrar el umbral.

UMBRAL = np.quantile(combinar(Xv), 0.99)               # 1 % de falsas alarmas previstas

def puntuar(conexiones: pd.DataFrame) -> pd.DataFrame:
    s = combinar(prep.transform(conexiones).astype(np.float32))
    return pd.DataFrame({"puntuacion": s.round(3), "alerta": s > UMBRAL})

#    puntuacion  alerta          real
#         0.990    True       neptune
#         0.378   False        normal
#         0.850   False   warezmaster     ← R2L: el punto débil
#         0.856   False  guess_passwd

Mantenimiento: el tráfico normal cambia (nuevas aplicaciones, teletrabajo, un servicio en la nube), y con él suben las falsas alarmas, como ya pasa entre el entrenamiento y el test. Hay que medir cada semana la tasa real de falsas alarmas y reentrenar con tráfico normal reciente, comprobando antes que ese tráfico no esté contaminado por un ataque en curso.

11Resultados y conclusiones

Lo que enseña este proyecto

1. Evalúa en el punto de operación. Un ROC-AUC de 0,96 puede esconder un detector que casi no detecta nada con un presupuesto realista.
2. Lo no supervisado protege frente a lo desconocido, a cambio de detectar peor lo conocido. Supervisado y no supervisado se complementan.
3. Los datos ponen el límite. Si un ataque no cambia las variables que mides (R2L), ningún modelo lo verá: hacen falta otras fuentes de datos.
4. La tasa base manda. Con ataques raros, incluso un buen detector genera sobre todo falsas alarmas.

Código completo, ejecutable en Colab (descarga NSL-KDD de una réplica pública):