Levantar, destruir y reconstruir

1Por qué importa

Las dos mitades de esta lección parecen no tener nada que ver y son la misma idea vista desde dos ángulos: saber en qué estado está tu sistema. El reset garantiza que el laboratorio empieza donde crees que empieza. El firewall garantiza que la superficie de ataque de tu máquina es la que crees que es. En los dos casos el enemigo es el mismo, y no es un atacante: es la diferencia entre lo que configuraste y lo que hay.

El reset importa por una razón muy concreta que vas a sufrir si no lo interiorizas. Los ejercicios de este curso dependen de un estado inicial conocido. Cuando un ataque “ya no funciona” o funciona sin que hayas hecho nada, la causa casi nunca es interesante: es un volumen que sobrevivió, un contenedor huérfano de otro proyecto o una imagen que se reconstruyó a medias. Horas de depuración imaginaria.

Y el firewall importa porque cierra el círculo de la fase. Has aprendido a no publicar puertos y a usar redes internas. Falta la última capa, la que te protege de tus propios olvidos: si un día publicas algo sin dirección delante, un firewall bien puesto es lo que debería salvarte. La mala noticia —y el motivo de que esto sea una lección y no una nota al pie— es que con Docker en Linux, por defecto, no te salva.

2Conceptos

3Explicación profunda

Los seis estados que sobreviven

“Reiniciar el laboratorio” no significa nada hasta que enumeras qué puede quedar vivo. Son seis cosas, y cada comando borra un subconjunto distinto:

Los dos que más daño hacen son el tercero y el cuarto. El volumen ya lo viste: es la causa número uno de un ejercicio que no reproduce. El huérfano es más traicionero: aparece cuando cambias el compose y eliminas o renombras un servicio. El contenedor antiguo no se borra, sigue conectado a la red del proyecto y sigue respondiendo a su nombre. Depurar por qué un servicio devuelve contenido viejo cuando lo has reescrito entero es una experiencia que se tiene una vez.

La caché de construcción merece una nota aparte porque es el estado que produce el error más desconcertante. Si el laboratorio construye una imagen, Docker reutiliza capas mientras crea que nada cambió. Sus heurísticas son buenas pero no perfectas, y cuando fallan reconstruyes “desde cero” una imagen que trae dentro archivos de hace tres días.

De ahí sale el procedimiento completo, que no es un comando sino tres, y en este orden:

# 1) destruir del todo: contenedores, redes, volumenes y huerfanos
docker compose down -v --remove-orphans

# 2) comprobar que no queda nada del proyecto
docker compose ps -a
docker volume ls
docker network ls

# 3) reconstruir sin reutilizar nada dudoso
docker compose up -d --force-recreate --build

El paso 2 es el que casi todo el mundo salta y el que convierte el procedimiento en verificable. Un reset que no se comprueba es una intención, exactamente igual que en la lección de instantáneas: si no miras, no sabes.

Un aviso sobre la motosierra: docker system prune -a borra todo lo no utilizado de toda tu máquina, incluidas imágenes y volúmenes de proyectos que no tienen nada que ver con el curso. Funciona, sí, igual que funciona formatear. Para un laboratorio, la versión acotada al proyecto siempre es preferible.

Firewall: cuatro distinciones que casi nadie hace

“Tengo el firewall activado” es una frase tan poco informativa como “está cifrado”. Estas cuatro distinciones son las que convierten esa frase en algo que se puede verificar.

Con estado o sin estado. Un firewall sin estado mira cada paquete aislado: para permitir una navegación web tendrías que abrir la entrada de los puertos altos, porque la respuesta llega por ahí. Un firewall con estado mantiene una tabla de conexiones vivas y reconoce la respuesta a algo que tú iniciaste. Es lo que permite la configuración que quieres: salida abierta, entrada cerrada, sin que se rompa nada. Todos los firewalls de sistema modernos tienen estado, pero conviene saber por qué la regla “permitir establecidas y relacionadas” está siempre la primera.

Capa 3/4 o capa 7. El firewall del sistema filtra por dirección, puerto y protocolo. No sabe qué dominio pediste ni qué ruta HTTP. Filtrar por nombre de dominio requiere mirar el contenido, y eso vive en un proxy, no en el núcleo. Es una limitación real y explica por qué “bloquear un sitio web con el firewall” funciona mal: el nombre puede resolver a direcciones que cambian, y varios servicios comparten dirección.

Entrada o salida. Denegar por defecto en entrada es fácil y casi gratis: es la configuración por defecto de cualquier sistema de escritorio decente. Denegar por defecto en salida es lo que de verdad estorba a un atacante —corta la exfiltración y el canal de mando y control— y es lo que casi nadie hace, porque obliga a enumerar cada destino legítimo y rompe cosas cada semana. La honestidad obliga a decirlo: en una máquina de trabajo es un dolor sostenido; en un servidor con una función clara, es de las medidas con mejor relación entre coste y efecto que existen.

Dónde se evalúa. Un paquete dirigido a tu propia máquina y uno que la atraviesa hacia un contenedor no pasan por el mismo sitio. El primero se filtra en la cadena de entrada; el segundo, en la de reenvío. Es una distinción de fontanería que resultaría aburrida si no fuera exactamente la causa del problema siguiente.

El puerto que tu firewall no cierra

Este es el punto que justifica la lección. En Linux, cuando publicas un puerto, Docker programa la traducción de direcciones y las reglas de aceptación necesarias directamente en la cadena de reenvío, y lo hace en sus propias cadenas, que se evalúan antes que las reglas que tú añades con las herramientas habituales de administración de firewall.

Consecuencia práctica: puedes tener el firewall configurado para denegar todo lo entrante, ver que dice que el puerto 8080 está cerrado, y que un contenedor publicado en 8080:80 siga siendo perfectamente alcanzable desde otra máquina de tu red. No es un fallo de tu configuración ni del firewall: es que tu regla está mirando un camino por el que el paquete no pasa.

# El paquete que va a TU maquina
  red --> [ cadena de ENTRADA ] --> proceso local
              ^ aqui SI estan tus reglas

# El paquete que va a un CONTENEDOR publicado
  red --> [ traduccion de direcciones ] --> [ cadena de REENVIO ] --> contenedor
                                                ^ aqui escribe Docker,
                                                  y sus cadenas van primero

Hay tres respuestas correctas y conviene tenerlas ordenadas por preferencia. La primera y la que este curso convierte en obligatoria: publica siempre en 127.0.0.1. Si el puerto solo escucha en la interfaz local, la discusión sobre cadenas desaparece, porque no hay tráfico externo que reenviar. La segunda: si de verdad necesitas publicar hacia fuera, escribe las reglas en la cadena específica que Docker deja reservada para el administrador, que sí se consulta antes de aceptar. La tercera, para casos concretos: desactivar la manipulación automática de reglas por parte del motor, con la advertencia de que entonces la conectividad de los contenedores pasa a ser tu problema entero.

En macOS y en Windows el mecanismo es distinto —el motor corre dentro de una máquina virtual ligera y quien publica el puerto en tu sistema es un proceso del propio Docker—, pero la conclusión operativa no cambia ni un milímetro: el firewall de tu sistema no es lo que decide si tu laboratorio está expuesto. Lo decide la dirección que escribes en ports.

Comprobar en vez de creer

La comprobación que cierra la fase no es leer configuración: es preguntarle al sistema qué está escuchando. Los sockets en estado de escucha son la verdad; todo lo demás es lo que alguien quiso que pasara.

# que escucha, en que direccion, y quien lo abrio
ss -tulpn | grep LISTEN

# lo que importa es la columna de direccion local:
#   127.0.0.1:8080   solo esta maquina                  -> bien
#   0.0.0.0:8080     todas las interfaces               -> revisar YA
#   [::]:8080        todas las interfaces, otra familia -> revisar YA

# y la version corta para Docker
docker ps --format "{{.Names}}\t{{.Ports}}"

Esa segunda familia de direcciones es un detalle que muerde de verdad. Es habitual proteger cuidadosamente una familia de direcciones y dejar la otra abierta de par en par, porque la configuración se escribió pensando solo en una. Cuando audites, mira siempre las dos.

4Ejemplo sencillo

# Reset: la diferencia entre parecido e identico

restart              apaga y enciende            estado: intacto
down                 quita contenedores y redes  estado: volumenes vivos
down -v              anade los volumenes         estado: huerfanos vivos
down -v --remove-orphans   ya no queda nada del proyecto

# Firewall: dos puertas y una sola cerradura

puerta 1  trafico hacia TU maquina    -> tu firewall la vigila
puerta 2  trafico hacia un CONTENEDOR -> Docker abrio esta, y va primero

# Por eso la cerradura buena no esta en el firewall:
# esta en escribir 127.0.0.1: delante del puerto.

5Ejemplo técnico

El experimento que demuestra el problema del firewall, hecho entero dentro de tu máquina y sin tocar la red de nadie. Copia el laboratorio, cambia una línea y observa:

Nueve caracteres de diferencia y dos posturas de seguridad opuestas. Fíjate en que el servicio funciona exactamente igual en los dos casos: no hay ningún error, ninguna advertencia y ninguna señal de que algo haya cambiado. Los fallos de exposición son silenciosos por naturaleza, y por eso la comprobación tiene que ser un hábito y no una reacción.

Sobre el firewall en sí: si estás en Linux y quieres comprobar el efecto, añade una regla que deniegue el 8080 con tu herramienta habitual y repite el escaneo desde otra máquina de tu propia red. El puerto seguirá abierto. Esa demostración vale más que cualquier párrafo, y es la razón de que la protección de este curso viva en el compose.

6Diagrama

flowchart LR
    P[paquete] --> IN[cadena de entrada]
    P --> FW[cadena de reenvio]
    IN --> L[proceso local]
    FW --> C[contenedor publicado]

7Código

El reset y la comprobación de exposición se escriben una vez y se ejecutan siempre. Un script así vive junto al laboratorio y su valor está en que falla cuando algo no está como debe:

#!/usr/bin/env sh
# reset.sh — devuelve el laboratorio a su estado inicial y lo verifica
set -eu

# 1) destruir del todo
docker compose down -v --remove-orphans

# 2) verificar que no queda estado del proyecto
if [ -n "$(docker compose ps -aq)" ]; then
  echo "quedan contenedores del proyecto" >&2; exit 1
fi

# 3) reconstruir sin reutilizar nada dudoso
docker compose up -d --force-recreate --build

# 4) puerta de salida: ningun puerto publicado fuera de la interfaz local
expuestos=$(docker compose ps --format '{{.Ports}}' \
  | tr ',' '\n' | grep '->' | grep -v '^127\.0\.0\.1:' || true)

if [ -n "$expuestos" ]; then
  echo "PUERTOS EXPUESTOS FUERA DE LA INTERFAZ LOCAL:" >&2
  echo "$expuestos" >&2
  docker compose down
  exit 1
fi

echo "laboratorio listo · sin exposicion fuera de la interfaz local"

Lo interesante del paso 4 no es la comprobación en sí, es qué hace cuando falla: tira el laboratorio abajo. Un aviso que se puede ignorar se ignora. Un laboratorio que se niega a quedarse arriba mal configurado enseña la lección la primera vez y no hace falta repetirla.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos