Introducción
En el ámbito de la administración de sistemas e infraestructura Linux, la inspección minuciosa de sockets de red constituye una habilidad crítica para diagnosticar incidentes y auditar la seguridad. Durante años, netstat fue el estándar indiscutible; sin embargo, ha quedado obsoleto frente a ss (Socket Statistics), la herramienta nativa y ultrarrápida provista por el kernel moderno. A lo largo de esta guía práctica, exploraremos cómo auditar puertos en escucha, rastrear conexiones activas e identificar con precisión qué procesos están asociados a cada flujo de comunicación.
1. Verificación del entorno y métricas globales de sockets con ss
Para aprovechar al máximo el comando ss en Ubuntu, el primer paso consiste en garantizar que la suite de utilidades de red iproute2 se encuentre debidamente instalada y actualizada en el sistema operativo.
A diferencia de herramientas heredadas que leen laboriosamente pseudo-archivos en /proc, ss extrae la información directamente del espacio del kernel a través del subsistema Netlink, brindando un rendimiento sobresaliente. Si combinamos la instrucción con el parámetro -s, el sistema genera un resumen estadístico completo con el cómputo total de sockets abiertos en tiempo real.
⚙️ [Parámetros fundamentales de filtrado]
-s : Muestra un informe numérico consolidado de todos los sockets del sistema (TCP, UDP, RAW, etc.).-t : Restringe el análisis exclusivamente al tráfico y sockets bajo el protocolo TCP.-u : Enfoca la visualización únicamente en sockets vinculados al protocolo UDP.-l : Filtra los sockets que están a la espera de peticiones entrantes (estado LISTEN).-a : Despliega la totalidad de sockets presentes, combinando tanto los que están a la escucha como los establecidos.-n : Desactiva la resolución de nombres de dominio y servicios, mostrando direcciones IP y puertos en formato numérico explícito.-p : Revela el nombre del ejecutable y el identificador de proceso (PID) vinculado a cada socket analizado.
2. Puesta en marcha de un servicio web y auditoría de puertos TCP en escucha
Con el fin de comprobar el comportamiento práctico de la herramienta, desplegaremos un servidor web Nginx e iniciaremos su demonio para generar un punto de escucha activo en el sistema.
Al invocar ss -tl, la consola lista de inmediato aquellos sockets TCP configurados en modo de espera pasiva (LISTEN), resolviendo los números de puerto a sus correspondientes nombres de servicio estandarizados (tales como http, ssh o domain).
La salida confirma de forma evidente que el demonio Nginx recién iniciado permanece activo esperando tráfico en el puerto estándar http (80).
Si añadimos el modificador -n estructurando la consulta como ss -tln, suprimimos la traducción por nombres conocidos y forzamos la representación numérica exacta de los puertos.
Esta variación técnica resulta esencial en entornos de producción, ya que permite distinguir con total claridad puertos como el 80 (en lugar de http) o el 22 (en lugar de ssh) sin ambigüedad alguna.
3. Identificación precisa del proceso: PIDs y binarios asociados
Al ejecutar ss -tlp, enriquecemos la salida con metadatos de los procesos que mantienen abiertos los sockets TCP en escucha.
La columna Process desglosa con exactitud el emparejamiento entre cada puerto y el binario responsable, mostrando con total transparencia el demonio web Nginx junto a servicios esenciales del sistema gestionados por systemd.
Por su parte, la combinación ss -tulpn conforma una de las directivas más empleadas por administradores de sistemas en auditorías rápidas: consolida la inspección de sockets TCP y UDP en estado LISTEN, suprime la resolución de nombres y reporta los PIDs involucrados.
Gracias a esta sintaxis, es posible correlacionar instantáneamente los puertos 80 (Nginx), 22 (SSH) o 53 (systemd-resolved) con sus respectivos identificadores de proceso en una sola pasada.
4. Rastreo de conexiones activas y aplicación de filtros avanzados
Para evaluar cómo refleja ss los cambios dinámicos de tráfico, instalaremos la herramienta curl y enviaremos una petición HTTP hacia nuestro propio host local.
Al consultar la red mediante ss -ta, se extrae el panorama íntegro de la pila TCP: no solo visualizamos los sockets receptores (LISTEN), sino también aquellos que transicionan hacia su cierre definitivo, como el estado TIME-WAIT.
En el reporte se observa claramente el socket residual originado por la interacción anterior hacia 127.0.0.1:http, el cual permanece momentáneamente en TIME-WAIT antes de liberarse.
Si deseamos limitar la búsqueda a sesiones concurrentes activas donde el intercambio de datos se encuentra plenamente abierto, podemos ejecutar ss -t state established.
Puesto que la consulta local ejecutada previamente concluyó y cerró el canal de inmediato, el comando no reporta conexiones persistentes en curso en este instante.
Finalmente, ss incorpora una potente sintaxis de expresiones lógicas para aislar flujos específicos. Mediante la instrucción ss -tln 'sport = :80', aplicamos un filtro directo sobre el puerto de origen (source port), aislando únicamente los sockets en escucha asignados al puerto 80 local.
Esta capacidad de segmentación ahorra tiempo valioso al depurar servidores con cientos de puertos abiertos, permitiendo verificar el estado del servidor web Nginx de forma selectiva e instantánea.
A lo largo de este tutorial hemos examinado cómo ss se erige como el sustituto definitivo y altamente eficiente de netstat para monitorizar la red en distribuciones Ubuntu.
Integre estos modificadores y filtros en sus rutinas habituales de mantenimiento para optimizar el diagnóstico de conectividad y la seguridad de sus servidores Linux.