TCP/IP, puertos y qué escucha de verdad

1Por qué importa

La superficie de ataque de red de un sistema no es lo que dice el diagrama de arquitectura. Es la lista de sockets en estado de escucha, cruzada con quién puede llegar a cada uno. Esa lista se obtiene con un comando, cambia con cada despliegue y casi nunca coincide con lo que el equipo cree.

Los tres desajustes que más veces he visto son siempre los mismos. Un servicio de depuración que alguien levantó para una tarde y quedó escuchando en todas las interfaces. Una base de datos con el puerto publicado “para poder mirarla desde el portátil” que nadie retiró. Y un contenedor que expone un puerto sin que su servicio esté pensado para recibir tráfico de nadie. Ninguno de los tres aparece en un diagrama; los tres aparecen en la tabla de sockets.

Hay un motivo más profundo para empezar la fase aquí. Todo lo que viene después —DNS, HTTP, TLS, firewalls— son capas construidas encima de esto. Si no tienes claro qué es una conexión, qué la establece y qué la corta, las lecciones siguientes se convierten en recetas. Con el modelo claro, se convierten en consecuencias.

2Conceptos

3Explicación profunda

El modelo TCP/IP tiene cuatro capas y la utilidad de recordarlas no es académica: cada control de seguridad de red actúa en una capa concreta y es ciego a las demás. Un filtro que decide por dirección y puerto no sabe si dentro va HTTP o Postgres. Un proxy que entiende rutas HTTP no ve el encaminamiento. Cuando alguien dice “el firewall lo cubre”, la primera pregunta útil es en qué capa mira.

En la capa de transporte está la decisión que más consecuencias tiene. TCP establece una conexión con un intercambio de tres pasos: el cliente manda SYN, el servidor responde SYN-ACK y el cliente confirma con ACK. A partir de ahí hay una conversación con números de secuencia, acuse de recibo y retransmisión. UDP no tiene nada de eso: manda un datagrama y termina su trabajo.

Esa diferencia tiene tres consecuencias de seguridad que conviene tener memorizadas. La primera: en TCP, quien recibe sabe con quién habla, porque completar el intercambio de tres pasos exige recibir de vuelta el número de secuencia del servidor. En UDP no, y por eso la falsificación de origen es trivial y por eso los ataques de amplificación viven casi siempre ahí. La segunda: un filtro stateful puede seguir una conexión TCP y permitir sus respuestas sin abrir un rango entero; con UDP tiene que aproximar con tiempos de espera. La tercera: los escaneos se comportan distinto. Un puerto TCP cerrado contesta RST de inmediato, así que se distingue de uno filtrado, que no contesta nada. Un puerto UDP cerrado responde con un mensaje de control, y muchos sistemas limitan la tasa de esos mensajes, con lo que un escaneo UDP es lento y ambiguo.

El socket es el otro concepto que hay que tener sin nieblas. No es el puerto: es la tupla de cinco elementos. Un servidor con un solo socket en LISTEN sobre el puerto 443 mantiene simultáneamente miles de sockets establecidos, uno por cliente, todos con el mismo puerto local. Cuando miras una tabla de sockets tienes que separar mentalmente las dos poblaciones: las líneas LISTEN son tu superficie de ataque; las líneas ESTAB son tu tráfico.

Queda la parte que más confusión genera: la dirección de escucha. Un proceso puede escuchar en la dirección de loopback, en una interfaz concreta o en todas. Escuchar en loopback significa que solo los procesos de esa misma pila de red llegan; es la diferencia entre un servicio de administración razonable y un incidente. Escuchar en todas las interfaces significa todas las de esa pila de red, que en un contenedor no son las de tu máquina. Por eso publicar un puerto es un acto explícito y separado: sin ports en el compose, el proceso escucha y no lo alcanza nadie de fuera.

NAT y el encaminamiento completan el cuadro. Cuando publicas un puerto, Docker escribe una regla de traducción: lo que llega a una dirección y puerto del host se reescribe hacia la dirección y el puerto del contenedor. La consecuencia práctica es que abierto es una propiedad relativa al punto desde el que preguntas, y por eso el inventario tiene que hacerse desde los dos lados. Es también la razón de que NAT no sea una medida de seguridad: no filtra nada, solo cambia direcciones. Que durante veinte años haya funcionado como cortafuegos accidental no lo convierte en uno.

4Ejemplo sencillo

# Un edificio de oficinas

direccion IP     la calle y el numero del edificio
puerto           el numero de despacho dentro del edificio
socket           "despacho 443 del edificio X hablando con el despacho 51844 del edificio Y"

# Y los dos transportes

TCP   llamas al telefono: alguien descuelga, dice "si?", y sabes que
      te oye. Si se corta, los dos os enterais.
UDP   metes una carta por debajo de la puerta y te vas. Puede que
      llegue, puede que no, y puede que llegue despues de la siguiente.

# Tres estados que la gente confunde

ESCUCHA          hay alguien en el despacho esperando visitas
ALCANZABLE       ademas existe un pasillo desde donde tu estas
PUBLICADO        ademas hay un cartel en la puerta de la calle

5Ejemplo técnico

Así se lee una tabla de sockets de verdad. Esta salida es del contenedor app del laboratorio de esta lección, y cada columna dice algo que importa:

Dos líneas para un solo servicio, porque nginx abre un socket para cada familia de direcciones. La dirección local es la parte que decide la exposición: aquí es “todas las interfaces del contenedor”. Y la columna del proceso es la que convierte el hallazgo en una tarea asignable: sin ella tienes un puerto abierto y ningún responsable.

La tabla resume el método: ningún comando responde la pregunta completa. El inventario correcto se hace desde dentro del sistema y desde fuera, y las discrepancias entre las dos vistas son precisamente los hallazgos.

6Diagrama

flowchart LR
    A[aplicacion] --> PA[proxy: ruta y cookie]
    T[transporte] --> PT[firewall L4: puerto y estado]
    R[red] --> PR[segmentacion: hay ruta o no]
    E[enlace] --> PE[ARP: sin autenticacion]
    A --- T --- R --- E

7Código

Un inventario de exposición cabe en un script y en una tabla. Este recorre las dos vistas —desde dentro y desde fuera— y deja las discrepancias a la vista, que es lo único que hay que revisar a mano:

#!/bin/sh
# inventario-sockets.sh — que escucha, y desde donde se alcanza.
# Se ejecuta contra el laboratorio propio. Nada de esto apunta fuera.
set -eu

SERVICIOS="entrada app db cliente"

echo "== vista de dentro: sockets en escucha =="
for s in $SERVICIOS; do
  echo "--- $s"
  # -l solo LISTEN, -t TCP, -u UDP, -n sin resolver, -p con proceso
  docker compose exec -T "$s" ss -ltunp 2>/dev/null || echo "sin ss en la imagen"
done

echo
echo "== vista de fuera: lo que el host publica =="
docker compose ps --format "table {{.Service}}\t{{.Ports}}"

echo
echo "== alcanzabilidad real desde el puesto de trabajo =="
for destino in "app 80" "db 5432" "app 8080"; do
  set -- $destino
  if docker compose exec -T cliente nc -z -w 2 "$1" "$2" 2>/dev/null; then
    echo "ALCANZABLE  $1:$2"
  else
    echo "no          $1:$2"
  fi
done

Lo valioso del script no es ninguno de los tres bloques por separado: es el contraste. Un socket que aparece en la vista de dentro y no en la de fuera está correctamente contenido. Uno que aparece en las dos es superficie de ataque declarada. Y uno que resulta alcanzable desde un contenedor que no debería hablar con él es un hallazgo de segmentación, que es justo lo que la última lección de esta fase va a arreglar.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

# forma correcta: solo tu maquina
  db:
    ports:
      - "127.0.0.1:5432:5432"

# forma peligrosa: toda la red local (NO dejarlo asi)
  db:
    ports:
      - "5432:5432"

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos