Ver puertos abiertos en Linux: ss, netstat, lsof y nmap

Ver los puertos abiertos con ss, el estándar moderno

Cada puerto abierto en un sistema Linux existe porque un proceso pidió al kernel escuchar en él. La herramienta que hoy muestra esos sockets es ss (socket statistics), parte del conjunto iproute2 instalado en toda distribución moderna. Un solo comando cubre la mayoría de los casos:

sudo ss -tulpn

Cada opción cumple una función:

• -t: incluye los sockets TCP
• -u: incluye los sockets UDP
• -l: muestra solo los sockets en escucha (omítela para ver también las conexiones establecidas)
• -p: muestra el proceso propietario de cada socket; por eso conviene usar sudo, ya que sin él solo ves tus propios procesos
• -n (salida numérica): imprime :22 en lugar de :ssh y omite las resoluciones DNS inversas, lo que además acelera el comando

Una línea de salida típica tiene este aspecto:

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=712,fd=3))

La columna Local Address es la que importa para la seguridad. 0.0.0.0:22 significa que el socket acepta conexiones en todas las interfaces IPv4, [::]:22 es su equivalente IPv6, y 127.0.0.1:5432 indica que el servicio solo responde en loopback y no es accesible desde la red.

Algunas variantes que vale la pena memorizar:

ss -tlnp                      # TCP listeners only
ss -ulnp                      # UDP listeners only
sudo ss -tlnp 'sport = :22'   # who is listening on port 22
ss -tn state established      # active TCP connections right now

netstat sigue funcionando, pero es heredado

Millones de tutoriales siguen indicando netstat -tulpn, y sus opciones se corresponden una a una con el comando ss anterior, así que la memoria muscular sirve en ambos sentidos. La diferencia está en el interior: netstat pertenece al paquete net-tools, en modo de mantenimiento, y lee archivos de /proc, mientras que ss consulta el kernel directamente por netlink, algo bastante más rápido en máquinas con miles de sockets.

La mayoría de las distribuciones actuales ya no incluyen net-tools por defecto. Si aún así lo necesitas:

sudo netstat -tulpn

# if the command is missing:
sudo apt install net-tools    # Debian / Ubuntu
sudo dnf install net-tools    # RHEL / Fedora

No hay motivo para instalarlo en un servidor nuevo. Considera netstat un recurso de compatibilidad para sistemas antiguos que heredes, y usa ss en todo lo demás.

lsof: los puertos vistos desde los procesos

En Linux todo es un archivo, incluidos los sockets de red, así que lsof (list open files) también sirve de inspector de puertos. Brilla cuando ya piensas en términos de procesos y no de puertos:

sudo lsof -i -P -n                  # every process with a network socket
sudo lsof -iTCP -sTCP:LISTEN -P -n  # TCP listeners only
sudo lsof -i :443                   # everything touching port 443

-P y -n desactivan la resolución de nombres de puerto y de host, la misma idea que la -n de ss -tulpn. La tercera forma es la del día a día: la apuntas a un puerto y obtienes el nombre del comando, el PID, el usuario y el descriptor de archivo en una tabla legible. A diferencia de ss, lsof también lista las conexiones establecidas de cada proceso junto a sus sockets en escucha, lo que ayuda cuando quieres saber quién está hablando con un servicio y no solo que el servicio existe.

nmap: estar en escucha no es lo mismo que ser accesible

Todo lo anterior responde a una pregunta: qué escucha en esta máquina. Para la seguridad importa más otra: a qué se puede llegar realmente desde fuera. Las dos listas casi nunca coinciden, porque los cortafuegos del host, el filtrado del proveedor y los enlaces solo a loopback abren huecos entre ellas. Por eso escanearte a ti mismo desde ti mismo demuestra poco: nmap localhost pasa por la interfaz de loopback, esquiva por completo tus reglas de cortafuegos externas y anuncia sin problema servicios a los que ningún atacante podría llegar.

Lanza el escaneo desde otra máquina, apuntando a la IP pública del servidor:

nmap 203.0.113.10                            # top 1000 TCP ports
nmap -p- 203.0.113.10                        # all 65535 TCP ports
sudo nmap -sU --top-ports 100 203.0.113.10   # common UDP ports (slow)

nmap informa de tres estados que conviene entender: open significa que un servicio respondió, closed que el paquete llegó pero nada escucha ahí, y filtered que el paquete se descartó en silencio, casi siempre por un cortafuegos. Un puerto que ss muestra como LISTEN y un nmap remoto informa como filtered es exactamente el aspecto de un cortafuegos que funciona. Una regla se aplica sin excepción: escanea solo hosts que te pertenezcan o para los que tengas autorización explícita.

Averiguar exactamente qué proceso ocupa un puerto

Supongamos que algo está ocupando el puerto 8080 y tu aplicación no puede enlazarse. Tres caminos llevan al PID:

sudo ss -tlnp 'sport = :8080'
sudo lsof -i :8080
sudo fuser -v 8080/tcp

fuser es el más compacto: imprime el PID, y -v añade el usuario y el nombre del comando. Incluso puede matar al culpable directamente con fuser -k 8080/tcp, pero eso envía una señal sin ninguna limpieza a nivel de servicio, así que resérvalo como último recurso. Una vez tengas un PID, ps -fp PID muestra la línea de comandos completa y systemctl status PID indica qué unidad de systemd lo lanzó.

Cuando no tienes ninguna herramienta (por ejemplo, en una imagen de contenedor minimalista), la tabla del propio kernel siempre está ahí: cat /proc/net/tcp. Los puertos aparecen en hexadecimal (0016 es el 22) y el estado 0A significa LISTEN. Esa tabla en bruto son precisamente los datos que las demás herramientas analizan y formatean para ti.

Todo lo que enlaza un socket aparece en estos listados del mismo modo, sea una base de datos o una pila de proxy: un inbound de V2Ray, por ejemplo, no es más que otro proceso en escucha en el puerto que hayas configurado, como se explica en nuestra guía del protocolo V2Ray.

Cerrar un puerto abierto: kill frente a cortafuegos

Un puerto está abierto porque un proceso escucha en él, lo que te deja dos palancas distintas: eliminar ese proceso en escucha o bloquear su accesibilidad. No son intercambiables y, en cualquier cosa importante, conviene accionar las dos.

La solución limpia es detener y deshabilitar el servicio propietario del socket. Matar el PID parece más rápido, pero rara vez perdura: systemd reinicia automáticamente los servicios supervisados y el puerto vuelve antes de que repitas ss. Reserva kill para los procesos que hayas lanzado a mano. Para ver qué se está ejecutando y apagar lo que no necesitas, nuestra guía para listar servicios con systemctl cubre ese flujo de principio a fin.

sudo systemctl stop cups
sudo systemctl disable cups

El cortafuegos se encarga de la segunda palanca. En Ubuntu, permite SSH antes de activar ufw o te quedarás fuera de la máquina:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

En los sistemas de la familia RHEL, la zona por defecto de firewalld ya descarta el tráfico no solicitado; retira lo que hubieras abierto antes con firewall-cmd --permanent --remove-port=8080/tcp seguido de firewall-cmd --reload. Algo que no es una solución: mover un servicio a un puerto no estándar. Te oculta de los escaneos más perezosos y limpia tus registros, pero nmap -p- encuentra el puerto nuevo en cuestión de minutos. La oscuridad no es seguridad: cierra el puerto o filtra con el cortafuegos.

Una auditoría de puertos de cinco minutos para un servidor nuevo

En el primer inicio de sesión de una máquina recién aprovisionada, haz el inventario con sudo ss -tulpn. Una instalación mínima y limpia debería mostrar muy poco: sshd en el 22 y, en las distribuciones que usan systemd-resolved, un stub DNS en 127.0.0.53:53. Cualquier otra cosa merece una explicación. Después recorre esta lista de comprobación:

1. Identifica cada proceso en escucha por nombre y PID; deshabilita todo servicio que no hayas pedido.
2. Cuestiona cada enlace a 0.0.0.0 o [::]: las bases de datos y los paneles de administración deben vivir en 127.0.0.1 salvo que realmente tengan que servir a la red.
3. Reconoce a simple vista los puertos habituales: 22 SSH, 80/443 web, 3306 MySQL, 5432 PostgreSQL, 6379 Redis. El puerto 3389 es escritorio remoto: en Linux significa que xrdp está en marcha, y las reglas de exposición y endurecimiento de ese puerto son el tema de nuestra guía del puerto RDP 3389.
4. Escanea la IP pública desde tu propia máquina con nmap -p- y compara el resultado con la lista de ss; cada diferencia es o un cortafuegos haciendo su trabajo o un enlace a loopback.
5. Termina con un cortafuegos de denegación por defecto que solo permita los puertos que hayas decidido exponer de forma consciente.

Aquí tienes toda la caja de herramientas, una línea por comando:

Los comandos solo se vuelven reflejos en una máquina donde tengas root de verdad y nada importante pueda romperse. Un VPS Linux de rdp.monster te da exactamente ese entorno de pruebas: acceso de administrador completo, CPU y RAM dedicadas, ancho de banda ilimitado (uso razonable), sin KYC, y el servidor está en línea unos 10 segundos después de la confirmación del pago, lo bastante rápido para lanzar tu primer ss -tulpn antes de que se enfríe el café.

Preguntas frecuentes

¿Necesito root para ver los puertos abiertos en Linux?

No para listar los puertos, sí para ver qué proceso los ocupa.

Cualquier usuario puede ejecutar ss -tuln o leer /proc/net/tcp, así que la lista de puertos en escucha nunca está oculta. El límite está en la opción -p: sin root, ss, lsof y fuser solo revelan los procesos de tu propio usuario, y el resto de sockets aparece con la columna de proceso vacía. Con nmap, el escaneo SYN por defecto (-sS) requiere root; la alternativa sin privilegios es el escaneo de conexión (-sT), que funciona bien pero es algo más ruidoso.

¿Cómo compruebo si un puerto concreto está abierto en un servidor remoto?

Usa netcat: nc -zv host puerto da una respuesta inmediata.

nc -zv example.com 443 intenta una conexión TCP e informa del éxito o del fallo sin enviar datos. Si no tienes netcat, Bash puro basta: timeout 3 bash -c '</dev/tcp/example.com/443' && echo open. Ambos solo demuestran que algo aceptó la conexión; no dicen nada sobre qué servicio respondió ni si está sano. Para UDP no existe una prueba rápida fiable, porque un puerto silencioso puede estar abierto o filtrado; ahí usa nmap -sU.

¿Por qué ss muestra un puerto en escucha pero no puedo conectarme desde fuera?

El socket está enlazado a loopback o un cortafuegos descarta el tráfico.

Mira primero la columna Local Address: 127.0.0.1:PORT o [::1]:PORT significa que el servicio solo acepta conexiones locales, algo deliberado y habitual en las bases de datos. Si está enlazado a 0.0.0.0, los paquetes se están filtrando en algún punto del camino: un cortafuegos del host como ufw, firewalld o nftables puro, o el filtrado de borde de tu proveedor. Un escaneo nmap externo que informe del puerto como filtered confirma un cortafuegos; closed significa que el tráfico llega pero nada escucha en esa interfaz.

¿Qué puertos deberían estar abiertos en un servidor Linux nuevo?

Uno: SSH. Cualquier otra cosa en una instalación limpia merece una explicación.

Una instalación mínima de Debian, Ubuntu o Rocky solo debería exponer sshd en el puerto 22 a la red. Un resolutor DNS stub en 127.0.0.53:53 (systemd-resolved) es normal e inaccesible desde fuera. Las imágenes de nube a veces añaden un agente o un demonio de monitorización: identifica cada proceso en escucha con ss -tulpn y deshabilita todo lo que no hayas pedido. Cada servicio que instales después debería enlazarse a loopback por defecto salvo que realmente necesite servir a la red, con el cortafuegos permitiendo solo lo que sea público.