¿Qué puede descubrir otro ordenador sobre los servicios que tenemos abiertos en nuestra red?
Para comprobarlo utilicé dos equipos reales de mi laboratorio CIBERMURO: un Dell de 12 pulgadas con Kali Linux y un ordenador con Ubuntu Server. Ambos estaban conectados mediante un router GL.iNet.
Desde Kali analicé mi propio servidor utilizando dos herramientas: Nmap y LancaTcher Lite. Después comparé los resultados con los servicios que realmente estaban funcionando en Ubuntu.
No es una simulación ni una relación de comandos sin probar. Es una práctica ejecutada, con resultados obtenidos y varias comprobaciones para entender qué demuestra cada herramienta.
1. El laboratorio que utilicé
El entorno ya estaba instalado y tenía conectividad y acceso SSH configurados antes de comenzar esta prueba.
- Dell de 12 pulgadas: Kali Linux, utilizado para analizar la red.
- Ubuntu Server: equipo que quería comprobar, identificado como
ch1. - Router GL.iNet: conexión entre ambos equipos.
- IP del servidor:
192.168.8.241.
Dell — Kali Linux
|
| Router GL.iNet
|
Ubuntu Server — 192.168.8.241
La idea era sencilla: comprobar desde fuera del servidor qué puertos podían verse abiertos y contrastar esa información con la configuración real del sistema.
2. Primero comprobé el servidor desde dentro
Antes de escanear nada desde Kali, accedí a Ubuntu mediante SSH.
Ejecuté:
sudo ss -lntupEste comando permite comprobar qué servicios están escuchando conexiones en el sistema.
El resultado mostraba, entre otros datos:
0.0.0.0:22
sshdEsto indicaba que el servidor SSH estaba escuchando en el puerto TCP 22.
También aparecieron servicios locales relacionados con DNS y sincronización horaria, asociados a direcciones de loopback como 127.0.0.1 y 127.0.0.53.
Después comprobé el estado de UFW:
sudo ufw status verboseEl resultado fue:
Status: inactivePrimera conclusión: SSH estaba activo y UFW se encontraba desactivado. No modifiqué ninguna configuración.
3. Un problema real: perdí la conexión tras reiniciar el router
Durante la sesión reinicié el router GL.iNet y dejé de poder acceder al servidor mediante SSH.
El intento de conexión terminaba con:
Connection timed outEn lugar de cambiar SSH o tocar el firewall, comprobé la configuración de red de Kali utilizando:
ip addr
ip routeDescubrí que el Dell estaba conectado a otra red, con dirección 192.168.1.58, mientras que Ubuntu permanecía en la red 192.168.8.x del GL.iNet.
Volví a conectar Kali al GL.iNet y recuperé el entorno de trabajo.
Aprendizaje: si un servicio deja de responder después de un cambio de red, conviene comprobar primero la conectividad y las direcciones IP. No hay que asumir que el problema está en el servicio o en el firewall.
4. Escaneé Ubuntu desde Kali utilizando Nmap
Con ambos equipos de nuevo en la misma red, instalé Nmap en el Dell y realicé el primer escaneo:
nmap -p 1-1024 192.168.8.241Este comando comprueba los puertos TCP del 1 al 1024.
El resultado fue:
PORT STATE SERVICE
22/tcp open ssh
Not shown: 1023 closed tcp ports
En ese rango, Nmap encontró un único puerto TCP abierto: el 22.
Esto coincidía con lo observado anteriormente desde dentro del servidor.
5. Nmap identificó incluso la versión de OpenSSH
Después ejecuté un segundo escaneo:
nmap -sV -p 1-1024 192.168.8.241La opción -sV intenta descubrir qué servicio y versión responden en los puertos abiertos.
El resultado obtenido fue:
22/tcp open ssh OpenSSH 10.2p1 Ubuntu 2ubuntu3.8
Service Info: OS: Linux
Ahora no solo sabía que el puerto 22 estaba abierto.
Nmap había identificado la implementación OpenSSH y la versión que anunciaba el servidor.
Esta información puede ser útil para revisar posteriormente qué versión tenemos instalada, si necesita actualizaciones y si el servicio está correctamente configurado.
Importante: detectar una versión no demuestra por sí mismo que exista una vulnerabilidad.
6. Instalé y compilé LancaTcher Lite
Después pasé a la segunda herramienta.
LancaTcher es un proyecto publicado en GitHub, desarrollado en Go. Para la prueba elegí su versión Lite, que dispone de un menú sencillo.
En Kali comprobé que tenía instalados Go y Git.
Descargué el código:
git clone https://github.com/hackermexico/lancatcher.git
cd lancatcherComprobé los archivos:
lsEntre ellos estaban:
lancatcher.go
lancatcherlite.go
LICENSE
README.mdCompilé la versión Lite:
go build -o lancatcherlite lancatcherlite.goLa compilación finalizó correctamente y apareció el ejecutable.
Lo inicié con:
./lancatcherlite7. Repetí con LancaTcher el mismo escaneo
En el menú seleccioné la opción de escanear puertos específicos.
Introduje los mismos datos que había utilizado con Nmap:
IP: 192.168.8.241
Puertos: 1-1024El resultado fue:
Puerto 22 [ABIERTO]
Puerto 22 [ABIERTO] -> SSH
1 puertos abiertos encontradosLancaTcher había encontrado el mismo puerto que Nmap.
El puerto 22 aparece dos veces en la pantalla porque el programa primero informa del puerto encontrado y después lo muestra asociado al nombre del servicio. No son dos puertos diferentes.
También utilicé la opción de análisis de servicios. De nuevo, LancaTcher identificó únicamente el puerto 22 como SSH.
8. ¿Por qué Nmap ofrece más información?
Aunque ambas herramientas encontraron lo mismo, existe una diferencia importante.
En la versión Lite de LancaTcher, buena parte de la identificación se basa en relacionar números de puerto con nombres conocidos.
Por ejemplo, el puerto 22 suele utilizar SSH y el 80 suele utilizar HTTP.
Pero eso no significa que siempre exista ese servicio detrás.
Nmap, mediante -sV, realiza comprobaciones adicionales para intentar identificar qué programa está respondiendo realmente.
En nuestra prueba, LancaTcher identificó SSH mientras que Nmap obtuvo también la implementación y versión de OpenSSH.
9. Intenté identificar el sistema operativo con Nmap
Por último, desde Kali ejecuté:
sudo nmap -O -p 1-1024 192.168.8.241La opción -O intenta identificar el sistema operativo analizando determinadas características de su comportamiento en red.
El resultado incluyó:
22/tcp open ssh
No exact OS matches for hostEs decir, Nmap no encontró una coincidencia exacta mediante esta técnica.
Esto puede sorprender porque anteriormente, con -sV, había mostrado información compatible con Linux.
Pero se trata de dos métodos distintos.
Con -sV, Nmap pudo obtener información sobre el sistema a través del servicio SSH. En cambio, con -O no consiguió identificarlo de forma exacta mediante fingerprinting de red.
Una herramienta puede obtener información válida mediante un método y no llegar a una conclusión con otro.
10. Resultados reales de la comparación
| Comprobación | Resultado |
|---|---|
| Servidor Ubuntu | SSH escuchando en TCP 22 |
| Firewall UFW | Inactivo |
| Nmap — puertos 1-1024 | Solo TCP 22 abierto |
| Nmap — detección de versión | OpenSSH 10.2p1 Ubuntu 2ubuntu3.8 |
| LancaTcher Lite | Solo puerto 22 abierto, identificado como SSH |
| Nmap — detección de sistema operativo | Sin coincidencia exacta mediante -O |
11. ¿Qué he demostrado realmente?
He comprobado que, desde el Dell con Kali Linux, mi Ubuntu Server tenía accesible el puerto TCP 22 dentro del rango analizado.
El resultado coincide con lo que había observado directamente en Ubuntu.
También he comprobado que LancaTcher Lite detecta correctamente ese puerto en este escenario, aunque Nmap proporciona información más detallada sobre el servicio.
Lo que no he demostrado: que el servidor esté completamente protegido, que no tenga vulnerabilidades o que no existan otros servicios en puertos superiores al 1024. Tampoco realicé una auditoría completa de UDP.
Esta fue una comprobación concreta y reproducible de exposición de servicios TCP.
12. ¿Para qué puede servirte esta prueba?
Imagina que tienes un pequeño servidor, un NAS o un ordenador que utilizas para compartir archivos.
Quizá hayas instalado varios programas y no sepas qué servicios pueden verse desde otros equipos de tu red.
Con herramientas como Nmap puedes realizar una primera comprobación y detectar qué puertos responden.
Después debes investigar si esos servicios son necesarios, cómo están configurados y si deberían ser accesibles.
Eso no exige realizar un ataque: consiste en conocer mejor tu propio sistema.
Conclusión CIBERMURO
En esta práctica no me limité a ejecutar dos programas.
Utilicé dos ordenadores reales, comprobé los servicios desde dentro del servidor, solucioné un problema de conectividad, ejecuté escaneos desde Kali, compilé LancaTcher Lite y comparé lo que encontraron ambas herramientas.
El resultado fue claro: ambas detectaron el puerto SSH, pero Nmap ofreció información más completa.
La enseñanza principal es que un resultado técnico gana valor cuando podemos contrastarlo con otras evidencias y sabemos explicar sus límites.
CIBERMURO — Seguridad digital práctica
Comprueba · Entiende · Protege
Práctica: [LAB-BT-02]
Fecha: 21 de octubre de 2026
Entorno: Dell con Kali Linux, Ubuntu Server y router GL.iNet
Herramientas: Nmap 7.99, LancaTcher Lite, ss y UFW
Referencias:
LancaTcher — repositorio original
Nmap — manual oficial
Acerca del autor
