Auditoría de puertos abiertos y servicios en escucha

Objetivo:

Comprender y dominar las herramientas avanzadas de auditoría de red a nivel de host en Linux, aprendiendo a identificar puertos abiertos, servicios en escucha, procesos asociados y conexiones activas mediante ss, netstat y lsof.

Escenario:

  • Herramientas: Terminal Linux, comandos ss, netstat, lsof, y utilidades de filtrado de texto (grep).
  • Conceptos analizados: Puertos TCP y UDP, sockets en escucha (listening), conexiones establecidas, asociación de puertos con PID de procesos y direcciones IP de enlace (IPv4 e IPv6).
  • Proceso clave: Ejecución de una auditoría completa de los servicios expuestos en el servidor, identificación de demonios huérfanos o sospechosos y comprobación de interfaces de escucha.

Escenario Real: Detección de servicios no autorizados en un servidor

Se sospecha que un servidor corporativo expone a la red servicios no autorizados debido a una mala configuración tras una actualización de paquetes. Como administrador de sistemas, debes realizar una auditoría exhaustiva de los puertos activos en escucha, identificar con total precisión qué aplicación o proceso de usuario está acaparando cada puerto y comprobar si hay conexiones remotas activas no deseadas.

Por defecto, los sistemas operativos pueden iniciar servicios en segundo plano que escuchan en interfaces públicas sin que el administrador sea plenamente consciente. Dominar la inspección de sockets con herramientas modernas como ss es un requisito indispensable para garantizar la seguridad perimetral interna.

NOTA: Para realizar esta práctica de auditoría con total seguridad, utilizaremos comandos de consulta en modo de solo lectura, evitando alterar o detener los servicios en producción activos.

Instrucciones:

Fase 1: Auditoría rápida de puertos en escucha con el comando moderno ss:

  • Listar de forma detallada todos los sockets TCP y UDP que se encuentran actualmente a la escucha (listening) en el sistema utilizando la herramienta moderna y eficiente ss: sudo ss -tulpn
  • Analizar los parámetros clave empleados: -t (TCP), -u (UDP), -l (en escucha), -p (mostrar procesos asociados) y -n (mostrar puertos numéricos sin resolver nombres de servicio).
  • Comprobar si algún servicio está escuchando indebidamente en todas las interfaces de red (0.0.0.0 o [::]) en lugar de estar restringido de forma segura a la interfaz local (127.0.0.1).

Fase 2: Inspección de conexiones establecidas y sockets con netstat:

  • Consultar el estado de todas las conexiones de red activas, incluyendo sockets establecidos y tablas de enrutamiento mediante la utilidad clásica netstat: sudo netstat -antp
  • Filtrar la salida anterior para buscar exclusivamente conexiones asociadas a un puerto o servicio específico (por ejemplo, el puerto web 80 o SSH 22): sudo netstat -antp | grep ':22'
  • Comprender por qué la herramienta ss ha sustituido progresivamente a netstat en las distribuciones modernas de Linux debido a su rendimiento superior al consultar directamente las estructuras del kernel.

Fase 3: Asociación profunda de ficheros y puertos abiertos mediante lsof:

  • Listar todos los ficheros y sockets de red abiertos en el sistema filtrando específicamente por aquellos de tipo internet: sudo lsof -i
  • Consultar de forma precisa qué proceso exacto (con su PID y nombre de usuario) está utilizando un puerto determinado (por ejemplo, el puerto 80): sudo lsof -i :80
  • Verificar el PID asociado a un servicio para poder investigarlo, auditar sus binarios o detenerlo de forma controlada si se trata de una amenaza o aplicación no deseada.

Fase 4: Análisis de tráfico local y filtrado avanzado:

  • Combinar las herramientas de consulta con filtros de texto para extraer un informe resumido de los demonios de red activos en el sistema:
    sudo ss -tlp | grep -E 'LISTEN|State'
    
  • Verificar que los servicios críticos del servidor responden únicamente en los puertos esperados y bajo los permisos correctos de usuario del sistema.

Verificación:

  • Comprobar mediante el comando sudo ss -tulpn que los puertos de administración (SSH) y de aplicaciones web muestran los procesos y números de PID correctos asociados en la columna de usuarios y procesos.
  • Verificar que no existen sockets en escucha inesperados vinculados a direcciones IP públicas abiertas sin control perimetral.

Posibles errores y resolución de problemas:

Si al ejecutar los comandos de auditoría de red observas que las columnas correspondientes al nombre de los procesos y al PID (como en ss -p o netstat -p) aparecen vacías o muestran el mensaje users:(("??",pid=0,fd=0)), se debe a una restricción de privilegios.

  • Solución: Para consultar los identificadores de procesos y los sockets abiertos pertenecientes a demonios ejecutados por otros usuarios del sistema o por el propio root, es estrictamente obligatorio ejecutar los comandos precedidos de privilegios de superusuario (sudo).

Alternativa directa: Consulta de puertos con lsof para TCP

Si necesitas averiguar de forma instantánea qué aplicación concreta está acaparando un puerto TCP específico sin volcar listados masivos por pantalla, puedes ejecutar una consulta directa y optimizada con la herramienta lsof:

sudo lsof -i TCP -sTCP:LISTEN

Preguntas de reflexión:

  1. ¿Qué ventajas de rendimiento y precisión presenta el comando moderno ss frente al comando clásico netstat a la hora de consultar los sockets del kernel en Linux?
  2. ¿Por qué es un riesgo de seguridad crítico que un servicio de base de datos o aplicación interna escuche en la dirección IP comodín 0.0.0.0 en lugar de en la interfaz de bucle local 127.0.0.1?
  3. ¿Qué relación técnica existe en Linux entre un socket de red y un descriptor de fichero, justificando por qué la herramienta lsof (List Open Files) es capaz de auditar puertos de red?
  4. ¿Qué diferencia operativa existe entre un socket en estado LISTEN frente a una conexión en estado ESTABLISHED al auditar la actividad de un servidor?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué ventajas de rendimiento y precisión presenta el comando moderno ss frente al comando clásico netstat a la hora de consultar los sockets del kernel en Linux?

El comando ss obtiene la información de los sockets directamente de las estructuras especializadas del kernel mediante la interfaz de sockets netlink, evitando parsear ficheros de texto planos en /proc como hacía netstat. Esto le otorga una velocidad de respuesta drásticamente superior y una precisión absoluta en sistemas con miles de conexiones concurrentes activas.


2. ¿Por qué es un riesgo de seguridad crítico que un servicio de base de datos o aplicación interna escuche en la dirección IP comodín 0.0.0.0 en lugar de en la interfaz de bucle local 127.0.0.1?

Porque la dirección IP 0.0.0.0 indica que el servicio acepta conexiones entrantes a través de todas las interfaces de red disponibles en la máquina, incluyendo las tarjetas expuestas directamente a Internet o a redes locales no confiables, dejando el servicio accesible desde el exterior si el cortafuegos no lo bloquea explícitamente.


3. ¿Qué relación técnica existe en Linux entre un socket de red y un descriptor de fichero, justificando por qué la herramienta lsof (List Open Files) es capaz de auditar puertos de red?

En la filosofía de diseño de los sistemas operativos tipo Unix, "todo es un fichero". Los sockets de red abiertos por los procesos son tratados internamente por el kernel como descriptores de ficheros especiales asociados a flujos de comunicación, lo que permite a utilidades como lsof inspeccionarlos, listarlos y asociarlos directamente al proceso responsable de su apertura.


4. ¿Qué diferencia operativa existe entre un socket en estado LISTEN frente a una conexión en estado ESTABLISHED al auditar la actividad de un servidor?

Un socket en estado LISTEN indica que un servicio se encuentra a la espera y preparado en un puerto determinado para aceptar nuevas peticiones entrantes de clientes. Por el contrario, un socket en estado ESTABLISHED representa una sesión de comunicación bidireccional activa y ya establecida entre el servidor y un cliente remoto específico.