Si estas en el camino del sysadmin aprender a analizar la red es un paso importante por que el paso a paso de cada cosa y saber como funcionan es muy importante para conocer todo el proceso, los equipos que estan en juego y sobre todo aprender para asegurar la red. Más adelante si vemos que vale la pena para los que nos siguen hasta hoy, vamos a hacer el curso de Operador de Pc y Administrador de Sistemas básico para que puedas aprender sobre este oficio genial!

¿Qué es Wireshark?

Wireshark es un analizador de protocolos de red (sniffer) gratuito y de código abierto. Captura y muestra el contenido de los paquetes que circulan por una interfaz de red en tiempo real. Es ampliamente utilizado por administradores de red, analistas de seguridad y desarrolladores. Soporta cientos de protocolos: TCP, UDP, HTTP, DNS, TLS, ARP y muchos más…

Atenti que Wireshark solo captura tráfico visible desde tu interfaz de red o sea que si tenes una placa de red (lan o wifi) vas a usar eso y el alcance de ese dispositivo. No es una herramienta de ataque: captura lo que ya circula por tu red local.

Como veras en la siguiente imagen, tenes la red lan donde «actua wireshark», luego el router y por ultimo internet.

Descargar e Instalar Wireshark

La web es https://www.wireshark.org/ en donde tendrias que ir a descargas o download y ahi vas a encontrar para los distintos sistemas operativos.

Para windows podes bajar la version Windows x64 Installer (incluye npcap otro software necesario que al preguntarle tenes que poner que si!).

Luego de instalar te hará aceptar el resto de las herramientas y con siguiente siguiente concluirá. Al finalizar te recomiendo reiniciar windows por que viste como son estas cositas….

Para linux como siempre primero actualizamos el sistema, luego instalamos wireshark y luego agregamos el usuario de siempre al grupo wireshark para no tener que correrlo como root.

sudo apt update && sudo apt upgrade -y
sudo apt install wireshark
sudo usermod -a -G wireshark $USER

Nunca le doy bola a los usuarios de macOs la forma de instalar seria:

brew install --cask wireshark

Una vez que lo tenemos wireshark instalado y reiniciamos la compu, se verá asi:

Analizamos la red local con Wireshark

La pantalla en principio nos da la bienvenida mostrando las placas de redes que tenemos configuradas, y si… mi maquina es un lio, tengo diferentes dispositivos para diferentes cosas, un puente entre dos placas, las conexiones de docker, vpn, tailscale etc etc etc…cositas…. pero para el ejemplo actual voy a usar mi placa wifi para lo cual le tengo que dar doble clic y se verá algo asi:

Podemos dividir la pantalla en:

Barra de herramientas de Wireshark:

Filtro y Lista de paquetes:

Detalle del paquete:

Voy a tomar una linea del listado de paquetes para que lo puedan leer conmigo, leemos la de color rojo o morado resaltada:

 2034    202.940196300    192.168.0.17    34.149.66.154    TCP    54    61328 → 443 [RST, ACK] Seq=6941 Ack=4629 Win=0 Len=0

Número de paquete: 2034 — es el paquete número 2034 en tu captura.

Tiempo: 202.940196300 — segundos transcurridos desde el inicio de la captura.

Origen → Destino: 192.168.0.17 → 34.149.66.154 Mi notebook (IP local) le envía un paquete a un servidor remoto. La IP 34.149.66.154 pertenece a Google (Google Cloud / CDN). Esto lo puedo saber llendo a virus total y al poner la ip me dará información como:

Protocolo: TCP

Longitud: 54 bytes — paquete muy pequeño, solo cabecera TCP, sin datos.

Lo más importante — los flags y valores TCP:

• 61328 → 443 — La notebook uso un puerto efímero 61328 para hablar con el puerto 443 (HTTPS) del servidor.
• [RST, ACK] — esto es la clave. RST significa reset: tu PC está cerrando la conexión de forma abrupta, no con el proceso normal FIN/FIN-ACK. El ACK confirma el último paquete recibido antes de cortar.
• Seq=6941 — número de secuencia: cuántos bytes ya envió tu lado.
• Ack=4629 — tu PC acusa recibo hasta el byte 4629 del servidor.
• Win=0 — ventana de recepción en cero: no quiero recibir más datos.
• Len=0 — sin payload, es solo señalización.

y ahora, en castellano ¿que significa todo esto? jajajaaj y si es un lio pero basicamente en la practica es que mi notebook terminó una conexión HTTPS con un servidor de Google de forma forzada (RST). Esto puede pasar por varias razones: la aplicación cerró el socket sin esperar el cierre limpio, hubo un timeout, el sistema operativo mató la conexión, o el firewall intervino (que es lo que suele pasar en mi notebook). No me acuerdo si les conte en alguna otra entrada pero no uso el firewall comun de windows sino que uso simplewall por que me encanta saber que si y que no sale de mi compu y en todo caso que me lo avise de una manera sencilla.

Un problema de las redes que empiezan a crecer

Los administradores de redes juniors se suelen olvidar que los routers por defecto vienen con un rango de red /24 entonces (y esto me ha pasado en varias oportunidades) suman redes agregando un nuevo router en algun sector de la red lan. Esta acción, sobre todo si esta mal configurada «la termina cagando». ¿Porque? El problema: cuando hay dos servidores DHCP en la misma red, algunos clientes reciben IP del servidor legítimo y otros del que en la jerga le llamamos intruso (o «rogue DHCP») pero rogue es demasiado titulo para uno que pusieron sin querer jajajaj. Lo sierto es que esto puede causar conflictos de IP, gateway incorrecto, y muchisimo más grabe un ataque man-in-the-middle si el servidor falso da su propia IP como gateway.

Antes de ir a wireshark clararmente tenemos que saber como funciona DHCP sino ¿que sentido tiene? saber de protocolos es importante sino es como mirar algo en ingles por mirarlo….no entenderiamos nada.

Una maquina sin configuración dice HOLA en la red, o sea DHCP DISCOVER (busca un servidor dhcp). El router que obviamente tiene dice HOLA AQUI TE VA UNA IP, o sea un DHCP OFFER, a la pc le va entonces dice «Bueno dale dame esa ip» (DHCP Request) y el router termina asignandosela con un DHCP ACK.

Que se ve aca??? lo traigo a la practica por que lo más probable que te pueda pasar. Primero a entender cada cosa:

25286    1403.344925900    192.168.0.1    255.255.255.255    DHCP    321    DHCP Discover - Transaction ID 0x415f

Esta línea es muy interesante porque es lo opuesto a lo normal.

Número: 25286 — paquete número 25286 en la captura.

Tiempo: 1403.34 segundos — unos 23 minutos después de iniciada la captura.

Origen: 192.168.0.1 — esta es la IP de tu router/gateway.

Destino: 255.255.255.255 — broadcast total, se envía a todos los dispositivos de la red.

Protocolo: DHCP — protocolo de asignación de IPs.

Longitud: 321 bytes

Lo llamativo — el mensaje: DHCP Discover

Aquí está la rareza. Un DHCP Discover significa «necesito una IP, ¿hay algún servidor DHCP en la red?». Pero lo está enviando 192.168.0.1, que normalmente es el router, y el router normalmente es el servidor DHCP, no un cliente que busca uno. Y como vemos en la captura no solo es una vez sino que son muchas muchas muchas veces, entonces….. ¿que puede estar pasando?

Lo primero y más común es que el router tiene la función DHCP deshabilitada y él mismo está buscando una IP desde un servidor upstream, por ejemplo si está configurado en modo bridge o repetidor en lugar de router.

Lo segundo es que sea un dispositivo diferente que tiene configurada manualmente la IP 192.168.0.1 y está buscando confirmación o renovación.

La tercera, más preocupante, es que sea un ataque de DHCP starvation o un dispositivo intentando suplantar al router — aunque para eso normalmente verías muchos Discover seguidos con Transaction IDs distintos, no uno solo (Que es lo que vimos en pantalla Capturada).

La cuarta opción es simplemente un problema de configuración: el router reinició y temporalmente está en modo cliente mientras levanta sus servicios.

Yo ya se lo que pasa, y si sos sysadmin viejo tambien… pero para el que recien ve estas cosas te puede asustar o estas como loco queriendo saber que pasa. Vamos realiar un nuevo filtro para ver si alguno de esos Discover recibió respuesta (fijate en tu caso que numero corresponderian, esto que estoy poniendo son numeros que se aprecian en la captura de pantalla utilizada en el ejemplo).

bootp.id == 0x36ec || bootp.id == 0x5acb || bootp.id == 0x343f

Como podemos observar, solo aparecen los Discover y ningún DHCP Offer ni DHCP ACK en respuesta, el router está gritando al vacío — nadie le contesta. Esto se debe a que el router esta buscando por la wan una ip publica pero como esta mal configurado lo larga por el brodcast y lo terminamos escuchando en la red. Un router sabe de rutas peroooo si esta mal configurado hace muchas macanas! Tambien pudimos observar que el SOURCE siempre era el mismo 192.168.0.1 por que si ubiera sido otro nos hubieramos con el famoso DHCP ROGUE:

Otra prueba que me encanta que vean sobre todo los nuevos es por que es tan pero tan importante el uso de certificados de seguridad en las web, o sea SSL. Para esta prueba voy a hacer lo siguiente:

Tengo un XAMPP intalado:

Este funciona como servidor web y como servidor de bases de datos mysql. Tengo un proyectito en construcción llamado ZetaBox que Claramente no tiene ssl por que esta en mi maquina 192.168.0.17 y no me intereza por ahora, solo es para una prueba. Se ve asi:

CUal es la prueba que vamos a hacer? Vamos a ingresar desde mi celular a la http://192.168.0.17/zetabox/public/login.php para que luego pueda poner un usuario y contraseña, darle clic en ingresar y ver que pasa con los famosos SSL. La ip de mi celular es la 192.168.0.223 asi que voy a filtrar por que la navegación sea http y que la ip sea 192.168.0.223

http && ip.addr == 192.168.0.223

Vemos muchos GET (que seria como traer) que son el login.php, un icono alguna imagencita….. perooooo hay un POST! El metodo post que sale del celular, o sea con origen 192.168.0.223 hacia 192.168.0.17 es un «dato» que viajo hacia el servidor y generalmente los campos de formularios como los son los de un login se envian por metodo post.

Vamos a hacer un clic sobre el post y ver que pasa:

Abajo a la izquierda nos indica dos cosas geniales:

Hypertex Transfer Protocol y Html Fore URL Enconde. En el primero son los HEADERS o cabeceras capturadas y en el segundo:

Guauuuu viajaron el usuario y la clave sin ningun tipo de encriptado y uno que andaba espiando por la red lo pudo ver!!

Es importante conocer los protocolos, como trabajan cada uno de ellos, que tipo de conexiones hay y sobre que ips estamos trabajando. No es lo mismo analizar una red local que conectarnos a una red entre routers o a alguna red mucho más grande que nos permita ver otros traficos.

Espero que te haya gustado entrar a jugar con wireshark y te espero nuevamente por el blog con lecturas ideas y hasta el infinito y más allá!!