Rootless Podman oculta IPs en Poste.io: ¿cómo capturarlas para CrowdSec?
Un usuario de Poste.io ejecutado en un VPS con Podman rootless descubre que el firewall interno reemplaza las IP externas por la propia del contenedor, dificultando la detección de bots.
Problema de IPs en contenedores rootless
El usuario ejecuta Poste.io mediante Quadlet en un VPS. Los puertos SMTP, IMAP y POP3 están expuestos; el correo fluye sin problemas, pero los bots que escanean el puerto intentan inicios de sesión con credenciales falsas.
Para bloquearlos, pasó de Fail2Ban a CrowdSec. Para alimentar a CrowdSec necesita las IPs fallidas de Haraka, pero en un contenedor rootless el único IP visible es el del propio contenedor (10.89.4.50). El log de Haraka, ubicado en el contenedor, muestra una línea disconnect ip=10.89.4.50 por cada conexión, sin revelar la IP real.
Por qué ocurre
Podman rootless usa un rootlessport de usuariospace que reenvía el tráfico sin conservar la dirección de origen. Cada conexión externa aparece internamente como proveniente del puente mailnet, con la IP del gateway del contenedor. Así, CrowdSec no puede diferenciar un atacante externo de tráfico interno.
Intentos de solución
El autor probó HAProxy como proxy intermedio, pero el hecho de que los contenedores se creen dinámicamente impedía que HAProxy se vinculara a un puerto fijo.
Posibles enfoques
- Desactivar el port‑forwarder de rootless: usar el proxy de Docker o un servicio externo que mantenga los IPs reales.
- Ejecutar el contenedor con privilegios: habilitar
--net=hosto usarrootfulPodman para que el kernel maneje el reenvío. - Capturar IPs a nivel de red: emplear
iptables -t nat -I PREROUTINGpara registrar la dirección original antes de que llegue al contenedor. - Reconfigurar CrowdSec: crear un parser que ignore la IP interna y busque la cabecera
X-Forwarded-Forsi se usa un proxy.
Relevancia para infraestructuras
Esta situación muestra una limitación de los contenedores rootless cuando se exponen servicios de red. Los administradores deben valorar si la seguridad adicional que ofrece rootless compensa la pérdida de trazabilidad de clientes. En entornos donde la detección de ataques automatizados es crítica, puede ser necesario recurrir a soluciones que preserven la dirección de origen o cambiar a un modelo con acceso de root.
Próximos pasos
El autor está buscando una solución viable. Una alternativa podría ser desplegar un sidecar de logging que intercepte las conexiones antes de que lleguen al contenedor, o migrar a un stack que soporte IPs reales en rootless, como el nuevo podman-rootless-network.
Este caso subraya la importancia de comprender cómo el stack de contenedores afecta la información de la capa de aplicación, especialmente cuando se usan herramientas de defensa basadas en logs.
