7.3 Auditoría de Puertos

tutorial.getReady

Entenderás cómo funciona un “Demonio en Escucha” (Sockets, IP, Puertos). - Sabrás utilizar ss para examinar todas las conexiones TCP y UDP de la máquina. - Dominarás el legendario lsof para descubrir qué proceso humano está usando el puerto 80.

1. La Anatomía de los Puertos

Imagina que tu servidor es un edificio corporativo enorme con la Dirección IP 192.168.1.10. Si un ordenador externo intenta enviar un paquete a ese edificio, el paquete llega a la puerta principal y choca contra un muro. ¿A quién iba dirigido el paquete? ¿Al servidor web? ¿Al servidor de correo? ¿Al chat?

Para solucionar esto existen Los Puertos (Numerados típicamente del 1 al 65535). Son como las “extensiones telefónicas” del edificio. Cuando un paquete llega a la IP del servidor, el sistema operativo examina el número de puerto en el encabezado del paquete y lo redirige al proceso que está “escuchando” en ese puerto.

Clasificación de puertos:

Rango	Descripción	Ejemplos
1-1023	Puertos privilegiados (solo procesos con privilegios de root pueden usar)	22 (SSH), 80 (HTTP), 443 (HTTPS)
1024-49151	Puertos registrados (asignados a servicios específicos)	3306 (MySQL), 5432 (PostgreSQL)
49152-65535	Puertos dinámicos/ephemeral (para conexiones salientes)	Usados por clientes, no por servidores

El proceso de “escucha” (Bind):

Cuando un demonio (servicio) se inicia, realiza una operación llamada bind (atar) en un puerto específico. Esto reserva ese puerto para el proceso, y el proceso queda en estado LISTEN (escucha), esperando que lleguen paquetes destinados a ese puerto.

# Ejemplo conceptual: Un servidor web se ata al puerto 80
# El sistema operativo asigna el puerto 80 al proceso nginx (PID 1055)
# Cualquier paquete que llegue al puerto 80 será entregado a nginx

¿Por qué es importante auditar los puertos?

Seguridad: Un puerto abierto innecesariamente es una superficie de ataque. Si no estás usando un servicio, deberías cerrar su puerto o limitar su acceso.
Resolución de conflictos: Dos servicios no pueden usar el mismo puerto al mismo tiempo. Si un servicio no arranca, puede ser porque otro está ocupando su puerto.
Cumplimiento normativo: Auditorías de seguridad (como PCI-DSS) requieren que solo los puertos necesarios estén abiertos.
Detección de intrusiones: Un puerto abierto inesperadamente podría indicar la presencia de malware o un backdoor.

2. El Radar Moderno (`ss`)

En la antigüedad se usaba el comando netstat. Hoy en día (y en tu examen LFCS), está obsoleto por lento y ha sido reemplazado por Socket Statistics (ss) del paquete de redes (iproute2).

ss a pelo te lanzaría un millón de líneas con cada conexión interna de red. Los Sysadmins usamos siempre la misma composición de letras inamovibles: -tulpn

sudo ss -tulpn

Desglose detallado de las opciones:

Opción	Descripción	Ejemplo de uso
-t	Muestra conexiones TCP (protocolo con confirmación, usado en web, SSH, bases de datos)	Ver servicios web o SSH
-u	Muestra conexiones UDP (protocolo sin confirmación, usado en DNS, streaming, gaming)	Ver servicios DNS o NTP
-l	LISTEN - Solo muestra puertos en modo escucha, oculta conexiones ya establecidas	Enfocarse en servicios activos, no en clientes
-p	PROGRAM - Muestra el PID y nombre del proceso dueño del puerto	Identificar qué programa está usando cada puerto
-n	NUMERIC - Muestra puertos como números, evita resolver nombres de servicio	Ver `:22` en lugar de `:ssh`, más rápido y claro

Interpretación de la salida de ss:

tcp   LISTEN  0  128  0.0.0.0:80  0.0.0.0:*  users:(("nginx",pid=1055,fd=6))

Campo	Significado	Ejemplo
Protocolo	TCP o UDP	`tcp`
Estado	LISTEN (escuchando), ESTABLISHED (establecida), etc.	`LISTEN`
Recv-Q	Bytes recibidos en cola sin procesar	`0` (sin datos pendientes)
Send-Q	Bytes enviados en cola sin confirmar	`128` (tamaño de la cola)
Dirección Local	IP y puerto donde el proceso está escuchando (0.0.0.0 = todas las interfaces)	`0.0.0.0:80`
Dirección Remota	IP y puerto del cliente (si hay conexión establecida)	`0.0.0.0:*` (cualquier cliente)
Proceso	Programa dueño del puerto, con su PID y descriptor de archivo	`(“nginx”,pid=1055,fd=6)`

Análisis de “Dirección Atada” (la clave de seguridad):

Dirección Atada	Significado	Nivel de Exposición
0.0.0.0:80	Escucha en todas las interfaces de red (públicas y privadas). Accesible desde Internet.	🔴 ALTO
127.0.0.1:80	Escucha solo en localhost (bucle interno). Solo accesible desde el mismo servidor.	🟢 BAJO
192.168.1.10:80	Escucha en una IP específica de la red interna. Accesible solo desde esa red.	🟡 MEDIO

Ejemplo de un servidor mal configurado:

# MySQL escuchando en todas las interfaces (PELIGROSO)
tcp   LISTEN  0  128  0.0.0.0:3306  0.0.0.0:*  users:(("mysqld",pid=1234,fd=10))

# MySQL bien configurado (solo localhost)
tcp   LISTEN  0  128  127.0.0.1:3306  0.0.0.0:*  users:(("mysqld",pid=1234,fd=10))

3. Investigador Privado (`lsof`)

Si ss es la visión general del país, List Open Files (lsof) es el láser milimétrico enfocado a una sola ciudad.

El principio fundamental de Unix:

Casos de uso comunes de lsof:

Resolver conflictos de puertos:

# ¿Quién está usando el puerto 80?
sudo lsof -i :80
# Salida:
# nginx   1055  root   6u  IPv4  12345  0t0  TCP *:http (LISTEN)

Ver qué procesos están usando un archivo específico:

# ¿Quién está usando el archivo de configuración de Apache?
sudo lsof /etc/apache2/apache2.conf

Listar todas las conexiones de red de un usuario específico:

# ¿Qué conexiones de red tiene abiertas el usuario <usuario>?
sudo lsof -u <usuario> -i

Ver qué archivos tiene abiertos un proceso específico:
ventana terminal
```
# ¿Qué archivos tiene abiertos nginx?
sudo lsof -p 1055
```

Combinar con grep para búsquedas específicas:

# Buscar procesos que escuchan en puertos altos (posibles backdoors)
sudo lsof -i | grep LISTEN | grep -E ':[0-9]{5}'

Estructura de la salida de lsof:

COMMAND   PID   USER   FD   TYPE   DEVICE  SIZE/OFF  NODE  NAME
nginx    1055   root    6u  IPv4    12345   0t0      TCP   *:http (LISTEN)
nginx    1056  www-data 7u  IPv4    12346   0t0      TCP   *:http (LISTEN)

Campo	Significado
COMMAND	Nombre del comando/proceso
PID	ID del proceso
USER	Propietario del proceso
FD	Descriptor de archivo (6u = archivo abierto en modo lectura-escritura)
TYPE	Tipo de archivo (IPv4, IPv6, REG = regular, DIR = directorio)
DEVICE	Número de dispositivo
SIZE/OFF	Tamaño del archivo o offset
NODE	Número de inodo
NAME	Nombre del archivo o dirección IP:puerto

Solución de problemas comunes con puertos:

# Escenario: Apache no arranca porque el puerto 80 está ocupado

# Paso 1: Verificar quién está usando el puerto 80
sudo lsof -i :80
# Salida:
# nginx   1055  root   6u  IPv4  12345  0t0  TCP *:http (LISTEN)

# Paso 2: Decidir si detener nginx o cambiar el puerto de Apache
sudo systemctl stop nginx

# Paso 3: Verificar que el puerto está libre
sudo ss -tulpn | grep :80
# No debe haber salida

# Paso 4: Iniciar Apache
sudo systemctl start apache2

# Opción alternativa: Matar el proceso directamente (con cuidado)
sudo kill -9 1055

4. Otros Comandos Útiles para Auditoría de Puertos

1. nmap (escaneo de puertos remoto):

# Escanear puertos comunes en un servidor remoto (desde otra máquina)
nmap -sS -p 22,80,443,3306 192.168.1.10

# Escaneo rápido de los 1000 puertos más comunes
nmap -T4 -F 192.168.1.10

2. netstat (obsoleto pero aún presente):

# Alternativa antigua a ss (no recomendada para el examen LFCS)
netstat -tulpn

3. fuser (identificar procesos por puerto o archivo):

# Identificar el proceso que usa el puerto 80
sudo fuser -v 80/tcp

# Matar el proceso que usa el puerto 80
sudo fuser -k 80/tcp

4. journalctl (logs de servicios):

# Ver logs relacionados con fallos de bind (puerto en uso)
sudo journalctl -u apache2 -f

5. Buenas Prácticas para la Auditoría de Puertos

Auditar regularmente los puertos abiertos:

# Script simple para revisar puertos abiertos diariamente
sudo ss -tulpn > /var/log/port_audit_$(date +%Y%m%d).log

Usar firewalls para limitar el acceso:

# Permitir solo SSH desde la red local
sudo ufw allow from 192.168.1.0/24 to any port 22

Configurar servicios para que escuchen solo en localhost cuando sea posible:
ventana terminal
```
# En /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 127.0.0.1
```

Monitorear cambios inesperados en los puertos:

# Comparar estado actual con una línea base
sudo ss -tulpn | diff - /var/log/port_audit_baseline.log

Documentar todos los puertos abiertos y su propósito:

Puerto	Servicio	Propósito	Responsable
22	SSH	Administración remota	Sysadmin
80	HTTP	Servidor web	Dev Team
443	HTTPS	Servidor web seguro	Dev Team
3306	MySQL	Base de datos (solo localhost)	DBA

Comprueba tus conocimientos (Versión Mejorada)

Contexto: Acabas de instalar un servidor de base de datos PostgreSQL en tu servidor de producción. Después de iniciar el servicio, ejecutas sudo ss -tulpn y ves la siguiente línea: tcp LISTEN 0 128 0.0.0.0:5432 0.0.0.0:* users:(("postgres",pid=456,fd=3)). Analizando la dirección de atado (0.0.0.0:5432), ¿cuál es tu evaluación de seguridad?
1. La base de datos está correctamente aislada, ya que 0.0.0.0 es la dirección de loopback interna, equivalente a 127.0.0.1. Solo procesos del mismo servidor pueden acceder.
2. Es una configuración peligrosa. 0.0.0.0 significa que PostgreSQL está escuchando en todas las interfaces de red, incluyendo la interfaz pública. Cualquier máquina con acceso a la red (incluyendo Internet, si está expuesta) podría intentar conectarse a la base de datos. Deberías cambiar la configuración a listen_addresses = '127.0.0.1' si solo debe ser accesible localmente.
3. Es seguro porque PostgreSQL usa el puerto 5432, que no es un puerto privilegiado (está por encima de 1024), por lo que solo puede ser usado por procesos no-root. Esto limita el riesgo de ataques.
Contexto: Un desarrollador te reporta que su aplicación Java no puede iniciarse porque el puerto 8080 ya está en uso. Necesitas identificar rápidamente qué proceso está ocupando ese puerto para detenerlo o reconfigurarlo. De los siguientes comandos, ¿cuál es el más efectivo para obtener información precisa (PID, nombre del proceso, usuario) de forma directa y sin ruido?
1. sudo lsof -i :8080 - Este comando muestra exactamente el proceso que está usando el puerto 8080, incluyendo su PID, usuario y el comando completo. Es la herramienta más directa y específica para este escenario.
2. sudo ss -tulpn | grep 8080 - Aunque también funciona, requiere filtrar la salida con grep y muestra todas las conexiones, no solo el proceso en escucha. Es menos directo que lsof para este caso específico.
3. sudo netstat -ano | grep 8080 - Es una opción válida pero netstat está obsoleto y es más lento que ss. Además, requiere opciones adicionales para mostrar el PID. lsof es más rápido y directo.
Contexto: Estás realizando una auditoría de seguridad en tu servidor y encuentras un servicio llamado redis-server escuchando en el puerto 6379 con la siguiente salida de ss -tulpn: tcp LISTEN 0 128 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=789,fd=6)). Además, notas que el archivo de configuración de Redis tiene bind 0.0.0.0 y protected-mode no. ¿Cuál es la mejor acción a tomar?
1. No es necesario hacer nada. ss muestra que Redis está escuchando en 127.0.0.1, lo que significa que solo es accesible localmente, a pesar de la configuración de bind 0.0.0.0.
2. La configuración actual es segura porque protected-mode no desactiva todas las restricciones de seguridad, lo cual es aceptable en entornos de desarrollo. En producción, deberías habilitar autenticación con requirepass.
3. Hay una inconsistencia grave. ss muestra que Redis está escuchando en 127.0.0.1 (solo localhost), pero la configuración indica bind 0.0.0.0 (todas las interfaces). Esto sugiere que Redis no está usando el archivo de configuración esperado, o que hay otra instancia de Redis ejecutándose. Debes revisar qué archivo de configuración está usando el proceso con sudo lsof -p 789 | grep redis.conf y corregir la configuración para que coincida con el comportamiento esperado. Además, protected-mode no es peligroso y debe ser yes en producción.