Analizador de paquetes - ¿Cómo usarlo en hacking ético?

Un analizador de paquetes permite ver qué circula por una red, qué protocolos intervienen y dónde se rompen muchas comunicaciones antes de que el problema escale. Lo que mucha gente llama sniffer de red no es solo una herramienta para mirar tráfico: bien usado sirve para diagnosticar fallos, auditar configuraciones y comprobar si hay datos sensibles viajando donde no deberían. En hacking ético, su valor real está en la visibilidad que aporta, pero también en saber exactamente sus límites y las condiciones en las que la captura tiene sentido.

Qué problema resuelve de verdad

Yo no veo este tipo de herramienta como una solución “mágica”, sino como una forma de responder preguntas que otros instrumentos no contestan con suficiente precisión. Un sistema puede decirte que un servicio falla, pero el analizador de paquetes te ayuda a ver si el fallo está en la resolución DNS, en el handshake TCP, en una negociación TLS, en una regla de filtrado o en una respuesta mal formada. Esa diferencia importa mucho en auditoría y en soporte, porque evita discutir síntomas y obliga a mirar la causa.

También conviene separar conceptos. Un sniffer observa y registra tráfico; un IDS detecta patrones sospechosos; un IPS intenta bloquearlos. En la práctica, yo uso la captura como una lupa forense y el IDS como una alarma. Son piezas distintas, y confundirlas lleva a expectativas poco realistas sobre lo que una sola herramienta puede hacer.

La pregunta siguiente es más práctica: cómo llega realmente ese tráfico a la captura y qué puedes esperar ver cuando la red ya no es un laboratorio pequeño.

Cómo llega el tráfico a la captura

La captura solo ve lo que alcanza la interfaz que escucha. En una red antigua y compartida, eso podía significar una visibilidad bastante amplia. En una red moderna con switches, la historia cambia: una tarjeta en modo promiscuo no “rompe” el switch ni descubre todo el tráfico por arte de magia. Solo recibe mejor lo que ya le llega o lo que se le entrega mediante una copia controlada.

Cuando necesito visibilidad real sobre tráfico entre terceros, pienso en tres escenarios:

• Promiscuous mode: útil para ver mejor lo que entra y sale por tu propia interfaz, pero no para vigilar toda la red conmutada.
• SPAN o port mirroring: el switch copia tráfico desde uno o varios puertos o VLAN hacia un puerto de monitorización. Es una opción muy práctica cuando está bien dimensionada.
• TAP de red: entrega una copia física del tráfico y suele ser más estable para análisis serio, aunque añade coste y requiere más planificación.

En Wi-Fi el matiz es distinto. Para ver tramas 802.11 completas, a menudo necesitas modo monitor, y eso depende del adaptador, del sistema operativo y del tipo de captura que quieras hacer. Además, si el tráfico viaja cifrado, la captura no convierte por sí sola los datos en legibles. A veces verás metadatos muy útiles; otras veces solo verás el esqueleto de la comunicación.

Con ese terreno claro, la siguiente decisión ya no es “si capturar”, sino con qué herramienta y con qué nivel de detalle trabajar.

Qué herramienta usaría según el caso

Yo suelo empezar por una elección simple: si necesito entender lo que pasa a fondo, prefiero una interfaz visual; si necesito rapidez, ligereza o automatización, me voy a la terminal. En ese reparto, Wireshark, tcpdump y TShark cubren la mayor parte de los escenarios de análisis cotidiano.

Herramienta	Punto fuerte	Límite principal	Cuándo la usaría
Wireshark	Inspección visual muy rica, reconstrucción de sesiones y filtros avanzados	Consume más recursos y puede resultar excesivo en capturas enormes	Cuando necesito analizar protocolos, seguir flujos y explicar hallazgos a otra persona
tcpdump / TShark	Captura ligera, scripting, uso cómodo desde consola	Menos amigable para revisar manualmente grandes volúmenes de datos	Cuando quiero automatizar, registrar evidencia o capturar en sistemas con pocos recursos
TAP o SPAN	Fuente de tráfico controlada, más cercana a lo que realmente pasa en el enlace	Requiere diseño, permisos y, en el caso del TAP, presupuesto adicional	Cuando la captura debe ser fiable en producción o sobre enlaces críticos

Hay un detalle que yo no subestimo: Wireshark distingue entre filtro de captura y filtro de visualización. El primero reduce lo que grabas; el segundo solo cambia lo que ves después. Si el tráfico es voluminoso o sensible, esa diferencia evita discos llenos, capturas inmanejables y falsas sensaciones de control.

Elegida la herramienta, lo importante pasa a ser el contexto: para qué la vas a usar y qué esperas demostrar con ella.

Dónde aporta valor en hacking ético

En auditoría ética, el analizador de tráfico me resulta útil cuando necesito evidencia técnica, no opiniones. Es especialmente valioso para comprobar si una red, un servicio o una aplicación se comporta como promete. Lo uso para detectar errores de configuración, entender incidentes y verificar si una segmentación cumple su función real.

Los casos que más valor me dan suelen ser estos:

• Diagnóstico de conectividad: tiempos de respuesta, retransmisiones, resets, MTU problemática o fallos de negociación.
• Validación de protocolos: comprobar si un servicio aún expone tráfico en claro o si una transición a TLS está bien ejecutada.
• Revisión de segmentación: confirmar si una VLAN, una ACL o una política de firewall realmente limita lo que debería limitar.
• Investigación de incidentes: observar conexiones salientes inesperadas, patrones de beaconing o comportamientos repetitivos que encajan con un compromiso.

Yo insisto mucho en esto: capturar tráfico no es lo mismo que “espionar”. En un trabajo serio, la captura se hace con un alcance definido, sobre activos autorizados y con una hipótesis concreta. Cuando falta ese marco, la herramienta deja de ser útil y se convierte en un riesgo operativo y ético.

Y precisamente porque captura tanto, también tiene límites. Ahí es donde suelen aparecer los errores que arruinan una auditoría o una simple sesión de diagnóstico.

Límites, riesgos y errores que yo no pasaría por alto

El error más común es creer que ver paquetes equivale a verlo todo. No. En redes modernas, la topología manda. Si capturas en el punto equivocado, te faltará justo el tráfico que necesitabas. Si además trabajas con volúmenes altos, puedes perder paquetes sin darte cuenta y construir conclusiones sobre una muestra incompleta.

• Confundir modos de captura: modo promiscuo no sustituye a un punto de monitorización real en un switch.
• Usar el filtro equivocado: un filtro de visualización no reduce el tamaño de la captura ni el impacto en disco.
• Ignorar el cifrado: TLS, VPN y Wi-Fi protegida limitan lo que puedes leer; a veces solo verás metadatos.
• Capturar demasiado tiempo: sesiones largas sin criterio generan ruido, ocupan espacio y complican el análisis.
• No sincronizar relojes: sin una hora coherente, correlacionar eventos entre equipos distintos se vuelve incómodo y poco fiable.
• Tomar decisiones con muestras parciales: una captura incompleta puede hacer parecer “normal” algo que en realidad no lo es.

En enlaces de 1 Gbps ya puedes tener sorpresas si el equipo de captura es modesto; en 10 Gbps o más, la planificación deja de ser opcional. Yo prefiero capturas más cortas, mejor ubicadas y con un objetivo claro, antes que archivos enormes llenos de ruido. La precisión acaba valiendo más que el volumen.

Con estos límites asumidos, la captura empieza a parecerse menos a una curiosidad técnica y más a una disciplina de trabajo. Y ahí es donde conviene ordenar el proceso.

Lo que yo reviso antes de usarlo en una auditoría

Antes de abrir una captura, yo cierro cuatro decisiones: dónde se toma, qué alcance tiene, qué ruido acepto y qué evidencia necesito conservar. Si esas preguntas están bien resueltas, la herramienta trabaja a favor; si no, solo produce archivos difíciles de interpretar.

1. Defino el objetivo: troubleshooting, validación de seguridad, forense o verificación de un cambio concreto.
2. Elijo el punto de captura: endpoint, SPAN, TAP o un tramo intermedio con visibilidad suficiente.
3. Limito el volumen: filtro de captura si el enlace es ruidoso, ventanas cortas y, cuando hace falta, una muestra representativa.
4. Conservo contexto: hora exacta, host, interfaz, red, motivo de la captura y cualquier cambio previo que pueda influir.
5. Reviso la integridad: formato de guardado, pérdida de paquetes, coherencia temporal y posibilidad de repetir la prueba.

Si yo tuviera que resumirlo en una sola idea, sería esta: una captura buena no es la que ve más cosas, sino la que permite responder una pregunta concreta sin ruido innecesario. Cuando trabajas así, el analizador de paquetes deja de ser un accesorio y se convierte en una herramienta de diagnóstico reproducible, útil y realmente alineada con el hacking ético.