Hace poco, durante una investigación sobre Docker y seguridad de red en una Raspberry Pi, partí de una suposición bastante razonable: si UFW tenía sus reglas configuradas, esas reglas deberían proteger los servicios publicados por Docker.
Pero decidí no asumirlo.
Seguí el recorrido real del tráfico.
Y ahí apareció el problema.
El tráfico dirigido a un servicio publicado por Docker no estaba siguiendo el mismo camino que el tráfico destinado al propio sistema. Docker tenía sus propias reglas para los servicios publicados, y esas reglas estaban siendo evaluadas antes de los controles de UFW que yo estaba considerando.
Eso significaba que las reglas de UFW podían estar correctamente configuradas y funcionando, pero no necesariamente estar controlando el tráfico que yo creía que estaban protegiendo.
La pregunta dejó de ser:
"¿Qué regla debería agregar?"
Y pasó a ser:
"¿Qué está ocurriendo realmente con este tráfico?"
Ese cambio de pregunta hizo toda la diferencia.
A partir de ahí, la investigación se convirtió en una serie de pruebas: observar el estado real, seguir el recorrido del tráfico, modificar una sola variable, reiniciar servicios, comprobar qué sobrevivía y separar lo que estaba demostrado de lo que todavía era una hipótesis.
Una de las piezas que apareció en esa investigación fue DOCKER-USER, una cadena que Docker incorpora precisamente en ese recorrido y que terminó siendo mucho más relevante para el modelo de control que las reglas de UFW que inicialmente estaba observando.
Pero incluso ahí decidí no saltar directamente a una solución.
Todavía había preguntas que necesitaban evidencia: qué ocurre con esa cadena durante los diferentes eventos del ciclo de vida de Docker, qué sucede cuando UFW participa en su creación y qué garantías tenemos de que el mecanismo de control permanezca presente después de reinicios, recargas o cambios en los contenedores.
Y eso me recordó algo que considero cada vez más importante en tecnología:
una configuración no es evidencia de que un mecanismo funciona.
Que una regla exista no demuestra que el tráfico pase por ella.
Que un servicio esté activo no demuestra que esté protegido como creemos.
Que una solución haya funcionado en otro sistema no demuestra que funcione igual en el nuestro.
Y que una AI proponga una solución técnicamente plausible tampoco demuestra que debamos implementarla.
La solución puede ser correcta.
Pero primero hay que demostrar que responde al problema real.
Esta forma de trabajar está cambiando también la manera en que utilizo AI para investigar problemas técnicos.
En lugar de pedir directamente:
"¿Cómo soluciono esto?"
la pregunta empieza a ser:
"¿Qué necesitamos observar para saber qué está pasando?"
Después viene la hipótesis.
Después la prueba.
Después la evidencia.
Y solamente entonces la decisión.
No siempre el resultado es una configuración nueva.
A veces el resultado es descubrir que nuestra interpretación inicial era incorrecta.
Y, para mí, eso también es un resultado valioso.
Porque una hipótesis que no sobrevive a la evidencia puede evitar que implementemos una solución equivocada.
Tal vez una de las habilidades más importantes cuando trabajamos con AI no sea conseguir que nos dé respuestas más rápidas.
Tal vez sea aprender a no aceptar demasiado rápido una respuesta que todavía no hemos demostrado.
Primero vemos. Luego decidimos.
¿Quieres saber si tu infraestructura tiene el mismo tipo de exposición? Agenda una conversación técnica con Directsales PTY.