Captura de tráfico y VPC Flow Logs

Leer tráfico es la forma más rápida de pasar de “creo que pasa esto” a “esto es lo que pasa”. Un handshake que no completa, un puerto que no esperabas, una conexión saliente a una IP rara: todo está en los paquetes. En este nota trabajas siempre sobre tu propia máquina o tu laboratorio autorizado —capturar tráfico ajeno sin permiso es ilegal— y aprendes a leer dos fuentes muy distintas: la captura de paquetes del cable y los VPC Flow Logs de la nube.

Capturar en tu propia máquina#

Capturar es copiar los paquetes que entran y salen de una interfaz. No intercepta ni modifica nada: hace una copia para que la mires. Las dos herramientas de referencia son tcpdump (línea de comandos, ideal en servidores) y Wireshark (gráfico, ideal para analizar).

Capturar tu propio tráfico: del cable al Flow Log

Redes · Captura y análisis

Paso 1 de 5Tráfico en el cable

Entre tu máquina y el servidor viajan paquetes en ambos sentidos. En tu propio equipo o laboratorio puedes observarlos sin tocar la conexión.

# Capturar tráfico HTTPS de una interfaz y guardarlo a fichero
sudo tcpdump -i en0 -n 'tcp port 443' -w captura.pcap

# Leerlo filtrando por un host, sin resolver nombres (-n)
tcpdump -n -r captura.pcap 'host 198.51.100.24'

El fichero .pcap que generas lo abres luego en Wireshark para analizarlo con calma.

Filtros: el 90 % del trabajo#

Una captura tiene miles de paquetes; los filtros te dejan solo lo tuyo. Ojo con la diferencia:

Filtros de captura (sintaxis BPF, al capturar): deciden qué se guarda. tcp port 443, host 10.0.3.15, udp port 53.
Filtros de visualización (sintaxis de Wireshark, al analizar): filtran lo ya capturado sin descartarlo. http.request.method == "POST", tcp.flags.syn == 1 && tcp.flags.ack == 0, dns.

Ver un handshake TLS (cifrado)#

Si filtras por tcp.flags.syn == 1 verás el inicio de cada conexión: el SYN, el SYN-ACK y el ACK del handshake TCP. Justo después, en una conexión HTTPS, viene el handshake TLS: Client Hello, Server Hello, el certificado y el intercambio de claves. A partir de ahí, los paquetes aparecen como Application Data y no puedes leer su contenido: están cifrados.

Leer VPC Flow Logs#

En la nube no tienes acceso al cable. La fuente equivalente —y de un nivel distinto— son los VPC Flow Logs: AWS registra los flujos de red (la 5-tupla agregada por intervalos) de una interfaz, subred o VPC. No es captura de paquetes: es un resumen de metadatos.

El formato por defecto (versión 2) tiene estos campos, en orden:

version account-id interface-id srcaddr dstaddr srcport dstport \
  protocol packets bytes start end action log-status

2 111122223333 eni-0a1b2c3d 10.0.1.20 10.0.3.15 50314 443 \
  6 12 3456 1760140800 1760140860 ACCEPT OK

Los campos que más usarás:

Campo	Qué te dice
`srcaddr` / `dstaddr`	IP de origen y destino del flujo
`srcport` / `dstport`	puertos (el `dstport` revela el servicio: 443, 53, 3306…)
`protocol`	número IANA (6 = TCP, 17 = UDP)
`action`	`ACCEPT` o `REJECT`, según lo permitieran los security groups y las NACL
`log-status`	`OK`, `NODATA` (sin tráfico) o `SKIPDATA` (registros omitidos)
`pkt-srcaddr`	(v3+) IP original antes del NAT; con `srcaddr` identifica la instancia real

Un action = REJECT te dice que algo intentó una conexión que tus controles bloquearon: útil para ver escaneos y reglas mal puestas. Un pico de REJECT desde una IP hacia muchos puertos es un escaneo; muchos ACCEPT salientes hacia una IP desconocida puede ser exfiltración.

Qué NO te dicen los Flow Logs#

Esta es la limitación que más confunde, y por eso la repetimos:

Correlacionar con la detección#

Ninguna de estas fuentes es una detección por sí sola: son la materia prima. El valor aparece al correlacionar.

Los Flow Logs alimentan GuardDuty, que los analiza junto a los logs de DNS y de CloudTrail para generar hallazgos (comunicación con IPs maliciosas conocidas, patrones de exfiltración, puertos inusuales) sin que tú escribas las reglas.
Una alerta de GuardDuty es el “qué”; los Flow Logs son el “con quién y cuándo”; CloudTrail es el “quién lo hizo en el plano de control”. Juntas, las tres reconstruyen un incidente.
En tu laboratorio, una captura con Wireshark te da el detalle fino que los Flow Logs no tienen, pero solo de la ventana que capturaste.

Tu turno

Captura un handshake en tu laboratorio y descríbelo

En tu propia máquina (nunca en una red ajena), captura una conexión HTTPS y analízala.

Captura con tcpdump -i <interfaz> -n 'tcp port 443' -w lab.pcap mientras abres una web; corta con Ctrl+C.
Ábrelo en Wireshark, filtra tcp.flags.syn == 1 y localiza el SYN, SYN-ACK y ACK. ¿Cuánto tardó el handshake?
Sigue el stream TCP: ¿a partir de qué punto solo ves Application Data cifrado? ¿Qué metadatos sigues pudiendo leer (SNI, IPs, tamaños)?
Ahora imagina el mismo flujo como un Flow Log: escribe a mano su línea v2 (srcaddr dstaddr srcport dstport protocol ... action). ¿Qué información de tu captura no aparecería en ese registro?

Reto

Ves en los Flow Logs muchos ACCEPT salientes al puerto 443 hacia una IP que no reconoces. ¿Puedes confirmar con los Flow Logs que es una exfiltración de datos?

▸Mostrar solución

No con certeza. Los Flow Logs te dicen que hubo conexiones aceptadas, cuántos bytes y a qué IP y puerto, pero no ven el payload: no sabes si eran datos legítimos, una actualización o una exfiltración. Son una señal fuerte para investigar (bytes salientes altos a un destino desconocido), pero para confirmar el contenido necesitas otra fuente: Traffic Mirroring, los logs de la aplicación, o correlación con un hallazgo de GuardDuty sobre esa IP.

En resumen#

Captura siempre sobre tu propia máquina o laboratorio autorizado. tcpdump captura, Wireshark analiza; los filtros (de captura vs de visualización) son el 90 % del trabajo.
“Follow TCP Stream” reconstruye una conversación; con tcp.flags.syn ves los handshakes.
Con TLS ves los metadatos (IPs, puertos, tamaños, SNI) pero no el payload: para filtrar contenido hay que terminar TLS en un punto de confianza.
Los VPC Flow Logs resumen flujos (v2: srcaddr, dstaddr, srcport, dstport, protocol, action = ACCEPT/REJECT, log-status). No ven el payload y agregan por ventanas; para paquetes completos, Traffic Mirroring.
El valor está en correlacionar: Flow Logs + DNS logs + CloudTrail alimentan a GuardDuty y reconstruyen un incidente.