Cómo usar TShark en servidores Linux para analizar HTTP, TCP/IP, DNS y SMTP

Publicado: 21 Octubre 2026 | Escrito por Javier Orovengua | Correo electrónico | Visto: 74

Aprende a capturar e interpretar el tráfico de red desde la terminal para diagnosticar páginas web, conexiones TCP, fallos DNS y problemas de correo

Wireshark es una herramienta excelente para analizar redes, pero su interfaz gráfica no suele estar disponible en servidores Linux. Para esos sistemas podemos utilizar TShark, la versión de Wireshark diseñada para funcionar desde la terminal.

TShark emplea el mismo motor de análisis y reconoce los mismos protocolos y filtros de visualización que Wireshark. Permite capturar tráfico en tiempo real, guardar los paquetes en archivos pcapng, reconstruir conexiones y extraer campos concretos para incorporarlos a informes o scripts.

En esta guía aprenderemos a examinar HTTP/HTTPS, TCP/IP, DNS y SMTP desde un servidor sin entorno gráfico.

Instalar TShark en Linux

En Debian y Ubuntu:

sudo apt update
sudo apt install tshark

En Fedora:

sudo dnf install wireshark-cli

En Rocky Linux, AlmaLinux y otras distribuciones compatibles con RHEL:

sudo dnf install wireshark-cli

En Arch Linux:

sudo pacman -S wireshark-cli

Podemos comprobar la instalación con:

tshark --version

Identificar la interfaz de red

Para mostrar las interfaces disponibles:

tshark -D

La salida puede ser similar a esta:

1. enp1s0
2. any
3. lo
4. docker0

También podemos consultar qué interfaz utiliza el servidor para salir a Internet:

ip route get 1.1.1.1

En Linux, la interfaz any permite escuchar simultáneamente en todas las interfaces. Resulta útil cuando desconocemos si una conexión llega por Ethernet, una red virtual, Docker o una VPN.

Realizar una captura básica

Para visualizar los paquetes en tiempo real:

sudo tshark -i any

Detenemos la captura pulsando Ctrl+C.

En un servidor con actividad aparecerán demasiados paquetes, por lo que normalmente será preferible guardar la captura y analizarla después:

sudo tshark -i any -a duration:60 -w /var/tmp/captura.pcapng

Este comando:

Captura desde todas las interfaces.
Mantiene la captura durante 60 segundos.
Guarda los paquetes en /var/tmp/captura.pcapng.
Se detiene automáticamente al finalizar el tiempo.

Para leer posteriormente el archivo:

tshark -r /var/tmp/captura.pcapng

Para mostrar todos los detalles de cada paquete:

tshark -r /var/tmp/captura.pcapng -V

Precauciones en servidores de producción

Una captura sin límites puede crecer rápidamente y llenar el disco. En producción conviene definir siempre una duración, un tamaño máximo o una cantidad limitada de archivos.

Por ejemplo, esta captura crea archivos de hasta 50 MB, conserva un máximo de cinco y termina después de cinco minutos:

sudo tshark -i any \
  -a duration:300 \
  -b filesize:50000 \
  -b files:5 \
  -w /var/tmp/diagnostico.pcapng

También podemos capturar únicamente los protocolos que nos interesan:

sudo tshark -i any \
  -f "port 53 or port 80 or port 443 or port 25 or port 465 or port 587" \
  -a duration:120 \
  -w /var/tmp/protocolos.pcapng

Una captura puede contener direcciones IP, consultas DNS, correos, cookies, cabeceras HTTP y, cuando no existe cifrado, credenciales o contenido privado. Debemos proteger el archivo:

sudo chmod 600 /var/tmp/protocolos.pcapng

Filtros de captura y visualización

TShark utiliza dos clases de filtros diferentes.

El filtro de captura se indica con -f y decide qué paquetes se guardan:

sudo tshark -i any -f "port 53"

El filtro de visualización se introduce mediante -Y y decide qué paquetes se muestran durante el análisis:

tshark -r captura.pcapng -Y "dns"

Para evitar perder información útil, suele ser aconsejable aplicar un filtro de captura relativamente amplio y usar posteriormente filtros de visualización más precisos.

1. Analizar HTTP y HTTPS

Para localizar tráfico HTTP sin cifrar:

tshark -r captura.pcapng -Y "http"

Para mostrar solamente las peticiones:

tshark -r captura.pcapng -Y "http.request"

Podemos extraer el método, servidor y recurso solicitado:

tshark -r captura.pcapng \
  -Y "http.request" \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e http.request.method \
  -e http.host \
  -e http.request.uri

Una posible salida sería:

Oct 20, 2026 10:15:21  192.168.1.20  GET  ejemplo.com  /index.html

Esto nos indica que el equipo 192.168.1.20 solicitó mediante GET el recurso /index.html del servidor ejemplo.com.

Para extraer los códigos de respuesta:

tshark -r captura.pcapng \
  -Y "http.response" \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e http.response.code \
  -e http.response.phrase \
  -e http.time

Los códigos más frecuentes son:

200: petición atendida correctamente.
301 o 302: redirección hacia otra dirección.
403: acceso prohibido.
404: recurso no encontrado.
500: error interno de la aplicación o del servidor.
502: un proxy recibió una respuesta incorrecta del servidor posterior.
503: servicio temporalmente no disponible.

Si http.time presenta valores elevados, el servidor o la aplicación pueden estar tardando demasiado en generar la respuesta.

Analizar conexiones HTTPS

Para mostrar tráfico TLS:

tshark -r captura.pcapng -Y "tls"

Para revisar la negociación inicial:

tshark -r captura.pcapng -Y "tls.handshake"

Podemos intentar extraer el nombre del servidor solicitado mediante SNI:

tshark -r captura.pcapng \
  -Y "tls.handshake.extensions_server_name" \
  -T fields \
  -e ip.src \
  -e ip.dst \
  -e tls.handshake.extensions_server_name

Una salida posible sería:

192.168.1.20  203.0.113.10  www.ejemplo.com

Esto demuestra que el cliente inició una conexión TLS con ese nombre de servidor. No significa que podamos ver el contenido de la página.

En HTTPS veremos la negociación, los certificados, las direcciones, los tiempos, las alertas y el volumen de datos, pero el contenido de la comunicación aparecerá cifrado:

TLSv1.3 Application Data

La presencia de Application Data sin texto legible es normal. Además, tecnologías como ECH pueden ocultar también el nombre solicitado.

Para detectar alertas TLS:

tshark -r captura.pcapng -Y "tls.alert_message"

Estas alertas pueden ayudar a encontrar certificados rechazados, incompatibilidades criptográficas o cierres inesperados.

2. Analizar TCP/IP

Para mostrar todo el tráfico TCP:

tshark -r captura.pcapng -Y "tcp"

Para examinar una dirección concreta:

tshark -r captura.pcapng -Y "ip.addr == 192.168.1.50"

Para estudiar un puerto:

tshark -r captura.pcapng -Y "tcp.port == 443"

Comprobar el establecimiento de una conexión

Una conexión TCP normal comienza con:

Cliente → Servidor: SYN
Servidor → Cliente: SYN, ACK
Cliente → Servidor: ACK

Podemos localizar los intentos iniciales de conexión con:

tshark -r captura.pcapng \
  -Y "tcp.flags.syn == 1 && tcp.flags.ack == 0"

Para buscar las respuestas del servidor:

tshark -r captura.pcapng \
  -Y "tcp.flags.syn == 1 && tcp.flags.ack == 1"

Si aparecen varios SYN dirigidos a un servidor, pero ningún SYN, ACK, las posibles causas son:

El servidor no está accesible.
El servicio no está respondiendo.
Un cortafuegos está descartando paquetes.
Existe un problema de ruta.
La dirección o el puerto son incorrectos.

Si recibimos RST, ACK, el equipo remoto es accesible, pero generalmente no existe un servicio escuchando en ese puerto o la conexión ha sido rechazada.

Para localizar reinicios de conexión:

tshark -r captura.pcapng -Y "tcp.flags.reset == 1"

Detectar retransmisiones

Para encontrar segmentos retransmitidos:

tshark -r captura.pcapng -Y "tcp.analysis.retransmission"

Para ver distintos avisos del analizador TCP:

tshark -r captura.pcapng -Y "tcp.analysis.flags"

Podemos encontrar mensajes como:

TCP Retransmission: un segmento se ha enviado nuevamente.
TCP Dup ACK: el receptor repite una confirmación porque falta información.
TCP Out-Of-Order: los segmentos llegaron desordenados.
TCP ZeroWindow: el receptor no puede aceptar temporalmente más datos.
Previous segment not captured: falta un paquete anterior en la captura.

Una retransmisión ocasional no demuestra por sí sola que exista un problema grave. Muchas retransmisiones consecutivas pueden indicar pérdida de paquetes, saturación, mala conectividad o una interfaz sobrecargada.

Mostrar todas las conversaciones TCP

TShark puede generar una tabla con los equipos, puertos, paquetes y bytes intercambiados:

tshark -r captura.pcapng -q -z conv,tcp

Esta información resulta especialmente útil para descubrir qué conexiones consumen más tráfico.

3. Analizar consultas DNS

Para visualizar todas las consultas y respuestas DNS:

tshark -r captura.pcapng -Y "dns"

Para mostrar únicamente las consultas:

tshark -r captura.pcapng -Y "dns.flags.response == 0"

Para ver solo las respuestas:

tshark -r captura.pcapng -Y "dns.flags.response == 1"

Podemos extraer nombres, direcciones y códigos de respuesta:

tshark -r captura.pcapng \
  -Y "dns" \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e dns.qry.name \
  -e dns.flags.rcode \
  -e dns.a \
  -e dns.aaaa

Una respuesta normal puede mostrar:

cliente → DNS       linuxparty.es
DNS → cliente       linuxparty.es  NOERROR  203.0.113.25

Los códigos principales son:

NOERROR: la consulta fue procesada correctamente.
NXDOMAIN: el nombre consultado no existe.
SERVFAIL: el servidor DNS no consiguió resolverlo.
REFUSED: el servidor rechazó la consulta.

Para buscar un dominio determinado:

tshark -r captura.pcapng \
  -Y 'dns.qry.name == "linuxparty.es"'

Para mostrar respuestas que tardaron más de un segundo:

tshark -r captura.pcapng -Y "dns.time > 1"

Si vemos consultas repetidas sin respuesta, debemos revisar el servidor DNS configurado, el cortafuegos y la conectividad UDP y TCP del puerto 53.

Los navegadores pueden utilizar DNS sobre HTTPS o DNS sobre TLS. En esos casos, las consultas estarán cifradas y no aparecerán directamente bajo el filtro dns.

4. Analizar el correo SMTP

Para localizar tráfico SMTP:

tshark -r captura.pcapng -Y "smtp"

También podemos revisar sus puertos habituales:

tshark -r captura.pcapng \
  -Y "tcp.port == 25 || tcp.port == 465 || tcp.port == 587"

Para mostrar las órdenes SMTP reconocidas por TShark:

tshark -r captura.pcapng \
  -Y "smtp" \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e smtp.command_line \
  -e smtp.response

En una conexión sin cifrar podríamos encontrar:

220 mail.ejemplo.net ESMTP
EHLO servidor.local
250 mail.ejemplo.net
MAIL FROM:<Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.>
RCPT TO:<Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.>
DATA
250 Message accepted
QUIT

Los códigos SMTP más importantes son:

220: servidor preparado.
250: orden aceptada.
354: el servidor espera el contenido del mensaje.
421: servicio temporalmente no disponible.
450 o 451: error temporal; normalmente se intentará de nuevo.
535: autenticación incorrecta.
550: destinatario o envío rechazado.
552: mensaje demasiado grande o cuota agotada.
554: transacción rechazada, frecuentemente por una política antispam.

Las respuestas 4xx suelen representar errores temporales. Los códigos 5xx indican generalmente un rechazo permanente que requiere corregir la dirección, la autenticación o la configuración del servidor.

Si SMTP emplea STARTTLS podremos observar el inicio de la sesión y la orden STARTTLS, pero la comunicación posterior estará cifrada. En el puerto 465 el cifrado comienza desde el establecimiento de la conexión.

Reconstruir una conversación desde la terminal

La función gráfica «Seguir flujo TCP» también tiene equivalente en TShark.

Primero podemos obtener los identificadores de las conversaciones:

tshark -r captura.pcapng \
  -T fields \
  -e tcp.stream |
sort -n -u

Para reconstruir el flujo número cero en texto ASCII:

tshark -r captura.pcapng \
  -q \
  -z "follow,tcp,ascii,0"

Para mostrarlo en hexadecimal:

tshark -r captura.pcapng \
  -q \
  -z "follow,tcp,hex,0"

También podemos seguir directamente una conversación HTTP:

tshark -r captura.pcapng \
  -q \
  -z "follow,http,ascii,0"

Esta opción es útil para reconstruir peticiones HTTP, sesiones SMTP sin cifrar y otros protocolos basados en TCP. Si la comunicación está protegida mediante TLS, veremos datos cifrados.

Ejemplo completo: una página web no responde

Podemos realizar una captura limitada mientras reproducimos el error:

sudo tshark -i any \
  -f "port 53 or port 80 or port 443" \
  -a duration:60 \
  -w /var/tmp/error-web.pcapng

Después seguimos este orden.

Primero comprobamos DNS:

tshark -r /var/tmp/error-web.pcapng -Y "dns"

Si devuelve NXDOMAIN, el nombre no existe. Si observamos consultas sin respuesta, puede fallar el servidor DNS o la conectividad.

A continuación buscamos intentos de conexión:

tshark -r /var/tmp/error-web.pcapng \
  -Y "tcp.flags.syn == 1"

Si solamente aparecen paquetes SYN sin SYN, ACK, el servidor, el puerto, la ruta o un cortafuegos pueden estar bloqueando la conexión.

Después revisamos TLS:

tshark -r /var/tmp/error-web.pcapng \
  -Y "tls.handshake || tls.alert_message"

Si TCP conecta, pero aparece una alerta TLS, debemos comprobar el certificado y la configuración criptográfica.

Finalmente, si se utiliza HTTP sin cifrar, buscamos errores:

tshark -r /var/tmp/error-web.pcapng \
  -Y "http.response.code >= 400"

De esta manera podemos determinar en qué fase falla la comunicación:

DNS → Conexión TCP → Negociación TLS → Respuesta HTTP

Extraer un informe resumido

TShark puede generar una tabla sencilla para adjuntarla a un informe:

tshark -r captura.pcapng \
  -T fields \
  -E header=y \
  -E separator=';' \
  -E quote=d \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e _ws.col.Protocol \
  -e _ws.col.Info \
  > informe.csv

El archivo informe.csv puede abrirse posteriormente con LibreOffice Calc.

No debemos compartir una captura completa sin revisarla previamente, ya que puede incluir datos confidenciales. Un informe limitado a los campos necesarios reduce ese riesgo.

TShark frente a Wireshark

TShark no muestra ventanas ni gráficos interactivos, pero ofrece prácticamente el mismo sistema de análisis de protocolos.

Sus principales ventajas en servidores son:

Funciona sin escritorio.
Consume menos recursos que la interfaz gráfica.
Puede conectarse mediante SSH.
Permite automatizar capturas y análisis.
Exporta campos a CSV.
Genera estadísticas sobre conversaciones.
Guarda capturas compatibles con Wireshark.
Puede reconstruir flujos TCP, HTTP, TLS y otros protocolos.

Para una investigación compleja podemos capturar con TShark en el servidor y abrir después el archivo pcapng con Wireshark en nuestro equipo de administración.

Conclusión

TShark convierte la terminal de un servidor Linux en un potente analizador de protocolos. Con una captura breve y unos cuantos filtros podemos comprobar si un dominio se resuelve, si TCP consigue establecer la conexión, si TLS negocia correctamente, qué código devuelve un servidor web o por qué un servidor de correo rechaza un mensaje.

La secuencia más eficaz consiste en capturar únicamente durante el tiempo necesario, guardar los paquetes, analizarlos por capas y eliminar de forma segura el archivo cuando ya no sea necesario.

Fuentes

Escribir un comentario

JComments

Categoría: Seguridad

LinuxParty