Auditar una red local con Nmap y Wireshark es una de las formas más efectivas de entender qué está pasando realmente en tu infraestructura, detectar servicios expuestos de más y comprobar qué información podría ver un atacante si se cuela en tu segmento de red. Son dos herramientas veteranas, muy usadas tanto por administradores como por pentesters. Bien combinadas, te permiten ir desde una simple foto de los puertos abiertos hasta el análisis al detalle de cada paquete que circula.
En este artículo vamos a juntar todo lo que necesitas para montar una auditoría completa de una red local: desde los conceptos de escaneo de puertos, flags TCP y tipos de escaneo en Nmap, hasta el filtrado avanzado con Wireshark para detectar esos escaneos y jugar al gato y al ratón con técnicas de evasión. Verás también ejemplos de entornos docentes con máquinas virtuales, ejercicios típicos de laboratorio (ping sweep, SYN scan, NULL scan, MITM con Bettercap) y varias herramientas adicionales que complementan a Nmap y Wireshark.
Qué es un escaneo de puertos y por qué importa en una auditoría
Un escaneo de puertos (port scan) es un proceso automatizado mediante el cual se envían paquetes a todos o a parte de los 65.535 puertos TCP/UDP de uno o varios equipos para ver cuáles responden y cómo lo hacen. A partir de esas respuestas podemos deducir qué servicios están activos, qué sistema operativo podría estar detrás e incluso si hay cortafuegos filtrando.
Para un atacante, un buen escaneo de puertos es la forma de localizar “puertas de entrada” y puntos débiles: servicios mal configurados, versiones antiguas con vulnerabilidades conocidas o protocolos en claro como Telnet, FTP o HTTP. Para un administrador o auditor, exactamente el mismo escaneo sirve para ver qué está expuesto, qué habría que cerrar y qué conviene proteger mejor.
Conviene tener claro que no es buena idea abrir más puertos de los necesarios. Muchos routers, servidores o aplicaciones pueden dejar puertos abiertos “porque sí” o porque alguien los abrió un día para pruebas y nadie los volvió a cerrar. Escanear tu propia red con Nmap te ayuda a sacar un inventario real de lo que está accesible desde dentro o desde fuera.
Además del inventario, es importante usar firewalls y sistemas de detección de intrusos que filtren accesos no deseados y registren intentos de conexión sospechosos. Y, por supuesto, mantener sistemas, router y servicios actualizados para reducir el impacto de cualquier puerto que, por negocio, tengas que mantener abierto sí o sí.
Qué es Nmap y qué puede hacer en una red local
Nmap (Network Mapper) es una utilidad de código abierto y gratuita diseñada para descubrir equipos en una red, analizar qué puertos tienen abiertos y qué servicios están escuchando detrás. Funciona por línea de comandos en Linux, Windows y macOS, y cuenta con una interfaz gráfica opcional llamada Zenmap.
Con Nmap puedes detectar hosts tanto en red local como a través de Internet: ordenadores, routers, switches, dispositivos IoT, servidores, etc. Además de listar qué puertos están abiertos o filtrados, es capaz de intentar identificar el sistema operativo, la versión de los servicios, y de lanzar scripts de seguridad (NSE) que automatizan pruebas de pentesting.
Entre sus características más relevantes está el soporte para diferentes tipos de escaneos: TCP (SYN, connect, FIN, NULL, Xmas…), UDP, ICMP y algunos métodos más avanzados que intentan pasar desapercibidos ante ciertos firewalls. También permite trabajar con IPv4 e IPv6, escanear un único host, rangos de IP o subredes completas.
Uno de los puntos fuertes de Nmap es que permite escanear grandes volúmenes de objetivos de forma bastante eficiente. Puede controlar el nivel de agresividad, la velocidad de envío de paquetes y el grado de paralelismo. Esto es útil tanto para auditorías planificadas en redes corporativas como para simulaciones en laboratorios docentes.
Estados de puertos y tipos de escaneo en Nmap
Cuando Nmap termina un escaneo, clasifica cada puerto en uno de varios estados que conviene dominar, porque su interpretación es básica para la auditoría:
- open: hay una aplicación aceptando conexiones en ese puerto (TCP o UDP). Es una superficie de ataque evidente.
- closed: el puerto responde pero no hay servicio escuchando. El host está vivo, pero ese puerto concreto no ofrece nada. Idealmente debería estar filtrado por firewall.
- filtered: un firewall o filtro impide que Nmap determine si está abierto o cerrado (no hay respuesta clara).
- open|filtered: no se puede saber si está abierto o filtrado, típico en ciertos escaneos UDP o TCP especiales (FIN, NULL, Xmas).
- closed|filtered: estado ambiguo usado en técnicas muy concretas como el IP idle scan.
En auditoría real solemos empezar con escaneos rápidos sobre los puertos más habituales para tener una primera foto:
nmap 192.168.1.2
Si queremos ir a por todas, es posible forzar el escaneo de los 65.535 puertos de un host:
nmap -p 1-65535 192.168.1.2
También es muy común limitar el rango a puertos concretos o bloques que nos interesen. Por ejemplo del 20 al 200:
nmap -p 20-200 192.168.1.2
Además del estado de puertos, Nmap permite hacer detección de sistema operativo y versiones de servicios con una sola orden, a costa de ser algo más ruidosa:
nmap -A -v 192.168.1.2
Esta detección de SO no es perfecta, pero suele acertar bien a grandes rasgos. Dentro del mundo Linux afinar modelo exacto y versión concreta ya es otro cantar.
Flags TCP, tipos de escaneo y cómo detectarlos
Nmap saca partido de las diferentes flags TCP (SYN, ACK, FIN, RST, PSH, URG…) para realizar escaneos más o menos sigilosos. En retos tipo CTF, por ejemplo, es habitual usar un SYN scan “stealth”. En entornos defensivos, interesa reconocer estas pautas en los logs o en Wireshark.
Para entender los escaneos hay que tener claro el handshake TCP clásico: SYN → SYN/ACK → ACK. A partir de ahí, se pueden jugar variaciones que envían o no ciertos flags y cortan la conexión con un RESET en lugar de terminar el ciclo de forma normal.
En muchas explicaciones se asignan valores numéricos a las flags TCP para poder sumar y filtrarlas. Por ejemplo:
| Cabecera | Valor |
|---|---|
| SYN | 1 |
| SYN/ACK | 2 |
| ACK | 4 |
| DATA | 8 |
| FIN | 16 |
| RESET | 32 |
Con esta forma de codificar es posible, por ejemplo, usar en Wireshark el campo tcp.completeness y filtrar por la suma de flags que aparecen en un flujo concreto para localizar patrones de escaneo.
Full TCP handshake (connect scan)
En un escaneo “completo” con Nmap (lo que se conoce como TCP connect scan, opción -sT), el cliente establece la conexión entera con el servidor: SYN → SYN/ACK → ACK y, después de intercambiar algo de tráfico, se cierra con un RESET o un FIN normal.
Si capturas esta secuencia en Wireshark y sumas los valores de flags según la tabla anterior (por ejemplo SYN + SYN/ACK + ACK + RESET), puedes filtrar con tcp.completeness = 39 para localizar conexiones que se han establecido y roto completamente.
Este tipo de escaneo es el más sencillo de detectar, ya que deja rastro en los logs de los servicios (web, FTP, Telnet, IMAP, etc.) y en los ficheros de log del sistema. En un laboratorio típico, si tienes rsyslog activo, verás mensajes en /var/log/syslog, /var/log/auth.log, /var/log/daemon.log y similares cuando Nmap complete el handshake hacia servicios como in.fingerd, inetd, telnetd, ftpd, dovecot o postfix/smtpd.
Escaneo SYN “stealth”
El SYN scan o escaneo “stealth” (opción -sS) es uno de los más utilizados porque es rápido y, en principio, menos visible. Aquí Nmap envía un SYN. Si el puerto está abierto, el servidor responde con SYN/ACK, y en lugar de contestar con ACK para completar la conexión, el escáner corta con un RESET.
Desde el punto de vista de Wireshark, la secuencia típica de un puerto abierto será SYN → SYN/ACK → RST, cuya suma de flags según el esquema anterior sería (1 + 2 + 32) = 35. Filtrando por ese valor de tcp.completeness es posible localizar conexiones que parecen escaneos SYN sin handshake completo.
A nivel de logs de aplicación, este método es más discreto porque la mayoría de servicios no llegan a registrar sesión. Sin embargo, si el sistema tiene reglas de firewall con log sobre paquetes SYN de inicio de conexión, sí aparecerán entradas de intento de conexión.
NULL scan y otros escaneos “raros”
Otra técnica clásica es el NULL scan (opción -sN), en la que Nmap envía paquetes TCP sin ninguna flag activa. Aunque suene extraño, algunos stacks TCP reaccionan de forma diferente ante puertos abiertos o cerrados, lo que permite a Nmap inferir el estado del puerto.
En un NULL scan, si el puerto está cerrado suele devolver un RST, mientras que si está abierto o filtrado puede no responder. Para detectarlo con Wireshark puedes emplear filtros sobre tcp.flags y dejar solo aquellos segmentos con todas las flags a cero.
En la misma línea tenemos escaneos como el Xmas scan (FIN + PSH + URG), el FIN scan o combinaciones similares, que tratan de explotar matices del estándar TCP o de implementaciones concretas para descubrir puertos sin seguir patrones típicos de handshake.
Controlando el Window Size como pista de Nmap
Otra característica que se puede usar para detectar escaneos es el Window Size TCP, el tamaño de ventana que un host anuncia como cantidad de datos que es capaz de recibir. Ciertas versiones de Nmap usan valores fijos para algunos tipos de escaneo.
Por ejemplo, es frecuente que en un SYN scan estándar de Nmap los paquetes SYN tengan un Window Size de 1024 bytes, mientras que en conexiones “normales” de un sistema concreto se usan valores distintos (como 64240 o 65535, según OS y configuración).
En Wireshark podrías aplicar un filtro tipo tcp.window_size == 1024 unido a determinadas flags para localizar patrones sospechosos. Como atacante o pentester, Nmap permite modificar este comportamiento con parámetros como --win para evitar dejar esa firma tan evidente.
Detectar y analizar escaneos con Wireshark y puertos “raros”
Wireshark es el analizador de protocolos por excelencia en el mundo de la seguridad de redes. Captura paquetes, los decodifica capa a capa (Ethernet, IP, TCP/UDP, HTTP, TLS, etc.) y permite aplicar filtros muy finos para quedarte solo con el tráfico que te interesa investigar.
Una forma muy práctica de detectar escaneos es filtrar por actividad en puertos poco habituales. Si tienes un servidor web legítimo, es normal ver tráfico a 80 o 443. Lo que ya no es tan normal es observar un montón de intentos hacia puertos aleatorios como 1234, 31337 o 4444.
En una red corporativa, puedes establecer una lista de puertos “sospechosos” asociados a frameworks maliciosos o herramientas de ataque frecuentes, y filtrar en Wireshark por esos puertos para ver si hay sondeos o conexiones inesperadas. Esto se puede apoyar en hojas de cálculo públicas que recopilan puertos asociados a malware y frameworks de explotación.
Desde el punto de vista defensivo, Wireshark permite además ver cómo se comportan diferentes tipos de escaneos de Nmap que tú mismo lances en tu laboratorio, para aprender a reconocerlos: número de paquetes por puerto, flags, tiempos entre paquetes, respuestas del sistema, etc.
Combinando filtros como tcp.completeness, tcp.flags, número de puertos distintos tocados en poco tiempo y tamaños de ventana, puedes construir reglas manuales o inspirarte para reglas de IDS/IPS.
Laboratorio típico: escaneo con Nmap y captura con Wireshark
En muchos entornos docentes se prepara un escenario de red virtualizado con VirtualBox para practicar escaneos y análisis de tráfico sin riesgo. Un ejemplo habitual incluye tres máquinas GNU/Linux en una red interna: interno1 (192.168.100.11), interno2 (192.168.100.22) y observador (192.168.100.33), cada una con una MAC fija.
Los servicios que se dejan arrancados por defecto en estas máquinas suelen ser abundantes: Apache 2, Telnet, SSH, FTP, Finger, MySQL, SMTP (Postfix), POP3 e IMAP (Dovecot), DNS (BIND)… ideal para que un escáner como Nmap tenga un buen puñado de puertos que encontrar.
El primer paso en ese laboratorio suele ser habilitar rsyslog en interno1 para que registre todo lo que ocurra: se activa con systemctl enable rsyslog y systemctl start rsyslog. Así, se empiezan a llenar ficheros de log en /var/log como syslog, auth.log, daemon.log o kernel.log.
Desde la máquina observadora, se lanza un ping sweep con Nmap para descubrir qué equipos están activos en la red 192.168.100.0/24:
nmap -sP 192.168.100.0/24
Una vez identificados los hosts activos (excluyendo la propia observador), se ejecutan escaneos de tipo TCP connect contra cada uno de ellos para ver qué puertos están abiertos y qué servicios corren:
nmap -sT -v -T4 192.168.100.11
nmap -sT -v -T4 192.168.100.22
Posteriormente se repite contra interno1 añadiendo detección de sistema operativo y versiones de los servicios:
nmap -sT -O -sV -T4 192.168.100.11
A continuación se consultan los logs de interno1, por ejemplo con tail -200 /var/log/syslog | less, para comprobar cómo han quedado registrados esos escaneos en los distintos demonios y servicios, y apreciar la huella que deja un TCP connect scan.
Comparando escaneos ruidosos y “sigilosos” con firewall y logs
Para ver la diferencia de rastro entre varias técnicas de Nmap, en ese mismo laboratorio se añade una regla de iptables en interno1 que anota cualquier intento de inicio de conexión TCP (paquetes SYN con estado NEW) con un prefijo fácilmente reconocible:
iptables -A INPUT -i enp0s3 -p tcp \
--tcp-flags SYN SYN -m state --state NEW \
-j LOG --log-prefix "INICIO CONEXION:"
Mientras se monitoriza el fichero /var/log/syslog con tail -f, desde observador se prueban tres escaneos distintos contra interno1:
- TCP connect scanning (
-sT). Genera entradas “INICIO CONEXION:” y, además, logs en los servicios que llegan a completar el handshake. - SYN scanning (
-sS). Produce entradas “INICIO CONEXION:”, pero la mayoría de servicios no anotan sesión porque no se completa la conexión. - NULL scanning (
-sN). No levanta la flag SYN, por lo que no coincide con la regla del firewall y no aparece el prefijo en los logs, resultando más sigiloso a ojos de esa política concreta.
Esta comparación sirve para entender que no todos los tipos de escaneo se detectan con las mismas reglas y que, como defensores, hay que ir más allá del “solo SYN” si queremos ver intentos más camuflados.
Del escaneo al MITM: Bettercap, Wireshark y servicios cifrados
En una segunda parte de la práctica, la máquina observador se usa para realizar ataques de envenenamiento ARP y MITM con Bettercap y luego analizar el tráfico capturado con Wireshark o con el propio módulo net.sniff de Bettercap. El objetivo es comparar la exposición de protocolos en claro (Telnet, HTTP) frente a alternativas cifradas (SSH, HTTPS).
Antes de esto, se habilita en interno2 el soporte SSL en Apache, generando un certificado autofirmado con make-ssl-cert hacia /etc/apache2/ssl/apache.pem, configurando default-ssl.conf para usar ese archivo como certificado y clave, activando el módulo SSL con a2enmod ssl y el sitio SSL por defecto con a2ensite default-ssl, y reiniciando Apache.
En un primer chequeo se ejecuta tshark en observador escuchando en la interfaz de la red interna y, mientras tanto, desde interno1 se abren sesiones Telnet y HTTP contra interno2. Al no haber MITM, el tráfico va directo entre interno1 e interno2 y tshark casi no ve nada de ese flujo. Esto demuestra que sin trucos extra, un tercer host en la misma red no siempre ve el tráfico ajeno.
Si se revisan las tablas ARP de interno1 e interno2 (arp -n), se observa cómo cada uno asocia la IP del otro a su MAC real, y a observador únicamente con su IP y su MAC, sin interferencias.
Envenenamiento ARP y captura del tráfico
El siguiente paso es arrancar Bettercap en observador, activar los módulos net.recon y net.probe para descubrir equipos de la red y verificar que aparecen 192.168.100.11, 192.168.100.22 y 192.168.100.33 con sus respectivas MAC. Opcionalmente puede activarse la interfaz web de Bettercap, aunque para la práctica no es imprescindible.
En paralelo, se lanza de nuevo tshark en observador para ver qué tramas ARP van apareciendo. Desde la consola de Bettercap se configuran los objetivos del módulo arp.spoof (interno1 e interno2) y se activa el ataque con:
set arp.spoof.internal true
set arp.spoof.targets 192.168.100.11,192.168.100.22
arp.spoof on
En ese momento Bettercap empieza a enviar respuestas ARP falsas asegurando a cada máquina que la IP del otro host (interno1 o interno2) corresponde a la MAC de observador. Teniendo en cuenta la Cuestión 1, los mensajes ARP emitidos son básicamente respuestas “gratuitas” (no solicitadas) que actualizan la caché ARP de las víctimas. El resultado es que en las tablas ARP de interno1 e interno2, las IP del otro equipo pasan a apuntar a la MAC 08:00:27:33:33:33 (la de observador), convirtiéndolo de facto en un hombre en medio.
Comparando Telnet, SSH, HTTP y HTTPS bajo MITM
Con el MITM activo, se utiliza el módulo net.sniff de Bettercap para volcar el tráfico entre interno1 e interno2 a ficheros .pcap distintos según el servicio a probar, excluyendo ARP con un filtro:
set net.sniff.filter "not arp"
set net.sniff.output /tmp/telnet.pcap
net.sniff on
Mientras tanto, desde interno1 se abre una sesión Telnet a interno2 con usuario “usuario” y contraseña “usuario”, se listan ficheros y se sale. El fichero /tmp/telnet.pcap se analiza luego con Wireshark, y es trivial ver las credenciales y comandos en texto claro siguiendo el flujo TCP correspondiente.
Se repite el experimento con SSH, guardando en /tmp/ssh.pcap, y esta vez, aunque se puede observar el establecimiento de la conexión SSH y el intercambio de claves, los datos de usuario y contraseña van cifrados. No es posible ver las credenciales en Wireshark, solo tramas cifradas.
Lo mismo ocurre con HTTP frente a HTTPS: con net.sniff volcando a /tmp/http.pcap, una navegación con Lynx o un navegador gráfico hacia http://interno2.ssi.net deja peticiones y respuestas HTTP completamente legibles (cabeceras, cookies, parámetros, etc.). En cambio, al repetirlo con https://interno2.ssi.net y analizando /tmp/https.pcap, se observa el handshake TLS (ClientHello, ServerHello, certificados, etc.) y después solo tráfico cifrado etiquetado como TLS 1.3.
Filtro en mano, se puede centrar la vista en tls dentro de Wireshark, seguir el flujo TCP correspondiente y comprobar que, aunque todo el tráfico pasa por el atacante, no tiene acceso al contenido en claro a menos que consiga romper o abusar del cifrado de alguna manera.
Personalización, Nmap NSE e integración con otras soluciones
Una de las razones por las que Nmap sigue siendo tan potente hoy en día es su alto grado de personalización y automatización. A nivel de línea de comandos, casi todo es configurable: puertos concretos, tiempos de espera, número de reintentos, grado de paralelismo, nivel de sigilo (perfiles T0 a T5), fragmentación de paquetes, IP y MAC de origen falsificadas, etc.
Además está el Nmap Scripting Engine (NSE), un ecosistema de scripts que permiten ir mucho más allá del simple “puerto abierto/cerrado”. Hay scripts para fuerza bruta de SSH o FTP, detección de configuraciones inseguras, comprobación de vulnerabilidades conocidas, obtención de banners detallados, pruebas contra servidores web, Samba, DNS, etc.
Por ejemplo, para intentar un ataque de fuerza bruta al puerto 22 de SSH de un host concreto a partir de dos diccionarios, puedes usar:
nmap -p 22 --script ssh-brute --script-args userdb=usuarios.txt,passdb=claves.txt,ssh-brute.timeout=4s 99.99.99.99
Del mismo modo, para comprobar si un servidor FTP permite acceso anónimo o probar credenciales por fuerza bruta, existen scripts como ftp-anon o ftp-brute. Estos se lanzan encadenados a un -sV -sC o de forma individual según convenga.
Otra ventaja es que Nmap se integra muy bien con otras herramientas. Los resultados pueden guardarse en múltiples formatos (texto normal, XML, apto para grep, combinado con -oA) y luego alimentar procesados posteriores, dashboards o incluso herramientas como Metasploit, sistemas de inventario o motores de correlación de eventos.
A nivel empresarial, implantar Nmap como pieza dentro de un programa de seguridad implica definir políticas de uso, planificación de escaneos, análisis de resultados y actualización continua. Escanear una vez y guardarlo en un cajón no sirve de mucho; hay que repetir, comparar y actuar sobre los hallazgos.
En conjunto, usar Nmap y Wireshark para auditar una red local, complementados con otras herramientas, proporciona una radiografía muy completa de cómo se comportan los servicios, qué se expone realmente y qué información podría ver o manipular un atacante, dejando claro por qué merece la pena apostar por el cifrado (SSH, HTTPS), el cierre de puertos innecesarios, una buena configuración de firewall y un seguimiento constante de los registros y del tráfico de red.