El servidor abierto
Contexto
Un equipo pequeño operaba un servidor con varios servicios productivos en un mismo VPS: una aplicación web principal, una base de datos relacional con información de clientes, una base de datos en memoria que servía como caché y cola de mensajes, y un servicio de cálculo geográfico para una funcionalidad de mapas. El servidor estaba en producción hacía más de un año y, en apariencia, funcionando sin incidentes. El equipo decidió sumar una capa de borde (DNS gestionado, certificados automáticos, filtrado de tráfico y caché) para mejorar la experiencia del usuario final.
Qué intentaban hacer
Antes de tocar la configuración pública, el Tech Lead pidió al Coding Agent que indicara los comandos para mapear el estado real del servidor: qué procesos estaban escuchando, en qué puertos, con qué dirección de bind, y bajo qué usuario del sistema operativo corrían. La idea era construir un inventario completo antes de hacer cambios que pudieran romper algo.
Hallazgo
Al revisar la salida del comando con la IA línea por línea, descubrieron tres servicios escuchando en "0.0.0.0" — la dirección que significa "atender peticiones desde cualquier interfaz, incluida la pública". La base de datos relacional, la caché en memoria y el servicio de cálculo geográfico estaban literalmente expuestos a internet, no solo a las aplicaciones locales que los necesitaban. Había contraseña en las dos primeras, pero el principio era el mismo: cada puerto abierto a internet es una superficie de ataque permanente. Cualquier botnet escaneando rangos de IPs podía intentar fuerza bruta sobre esos servicios cuando quisiera, durante meses, sin que nadie del equipo lo notara. El Coding Agent explicó qué implicaba cada bind, qué tipo de ataques eran realistas (RCE conocido en la caché en memoria sin auth fuerte, fingerprinting del servicio de mapas), y qué se vería en los logs si alguien hubiera entrado. No había rastros de explotación — pero el riesgo había sido latente durante meses.
Corrección aplicada
El cambio fue quirúrgico y se hizo en quince minutos. Modificaron la configuración del orquestador de contenedores para que cada servicio escuchara solo en la dirección de loopback (127.0.0.1), accesible únicamente desde la propia máquina. Las aplicaciones locales seguían conectándose por dentro sin notar diferencia. Como mejora derivada, agregaron reglas explícitas al firewall del sistema operativo para denegar por defecto cualquier conexión entrante a puertos no esenciales. Y como práctica nueva del equipo: cada servicio que se sume al servidor pasa por un checklist de bind correcto antes de quedar productivo.
Lección
El objetivo declarado era sumar una capa de borde. El hallazgo crítico apareció al inventariar antes de actuar — al detenerse a leer la salida de un comando que, en teoría, todos del equipo sabían leer. Lo importante no fue el comando: fue que el Tech Lead conversara la salida con la IA, pregunta a pregunta, hasta entender qué significaba cada línea. Cualquier servicio que se haya quedado funcionando 'porque sí' durante meses merece la misma auditoría conversada. La deuda silenciosa no aparece sola.
El loop fantasma
Contexto
El mismo equipo terminó de aplicar la nueva capa de borde y los servicios habían quedado correctamente protegidos. Como parte de la verificación rutinaria del despliegue, abrieron los registros de acceso del servidor web — el archivo donde queda registrada cada petición HTTP que llega al sistema — y empezaron a leer las últimas seis horas para confirmar que no hubiera anomalías obvias.
Qué intentaban hacer
Pidieron al Coding Agent que les explicara los patrones que estaban viendo: qué peticiones eran normales para una aplicación web típica (gente cargando páginas, llamadas a API de usuarios autenticados, recursos estáticos servidos), qué patrones podían indicar problemas (intentos de fuerza bruta, escaneos automatizados, peticiones malformadas) y qué requería atención inmediata. El agente les fue clasificando líneas y los ayudó a separar el ruido habitual de internet de lo que merecía mirar dos veces.
Hallazgo
En medio del análisis apareció algo extraño. Una IP fija — la del propio servidor — estaba haciendo entre veinte y veinticinco peticiones por minuto a un endpoint que no existía en ninguna de las aplicaciones desplegadas. Todas devolvían error 404. Mismo path, mismo método HTTP, mismo user-agent, llovía y llovía. Al pedirle a la IA que rastreara el origen del tráfico hacia adentro del servidor (qué proceso del sistema operativo estaba abriendo conexiones a esa IP), encontraron una pequeña aplicación interna que llevaba meses haciendo reintentos en bucle contra una URL que en algún momento existió pero ya no. Era una telemetría implementada para un experimento que nunca llegó a producción; el experimento se canceló, la URL receptora se eliminó, pero la aplicación que enviaba los datos siguió corriendo silenciosamente, fallando, reintentando, fallando otra vez, durante meses.
Corrección aplicada
Identificaron el proceso responsable revisando los servicios del sistema y el listado de procesos activos. Lo apagaron y lo desinstalaron del sistema de arranque para que no volviera a levantar tras un reinicio. El impacto inmediato fue tangible: el ancho de banda saliente del servidor bajó notoriamente (porque cada petición fallida igual consumía bytes), los registros de acceso se volvieron mucho más legibles para detectar problemas reales, y desaparecieron las alertas falsas que algunos sistemas de monitoreo estaban generando por el patrón. Como cambio de práctica, el equipo adoptó la costumbre de revisar trimestralmente qué procesos están corriendo en cada servidor productivo, conversando la lista con el Coding Agent — porque un proceso desconocido suele esconder una historia.
Lección
Un sistema en producción acumula deuda silenciosa con el paso del tiempo. Bibliotecas que ya no se usan, experimentos olvidados, procesos zombi, configuraciones que sobrevivieron a las personas que las pusieron. Estos elementos no aparecen en ninguna lista de tareas pendientes porque nadie sabe que existen. La IA no descubrió este bug — el Tech Lead lo descubrió porque la IA le ayudó a leer mejor lo que ya estaba a la vista. La habilidad clave fue tener tiempo y disposición para mirar registros que parecían rutina.
El default silencioso
Contexto
Tras meses de trabajo, el equipo desplegó un sitio web nuevo en el mismo servidor donde ya vivían otros productos. Configuraron el dominio en el proveedor de DNS apuntando al servidor, levantaron el código de la nueva aplicación, ajustaron los certificados de TLS y todo parecía en orden. Como último paso, abrieron el navegador y entraron a la URL del nuevo sitio para hacer una primera verificación visual antes de comunicarlo al cliente.
Qué intentaban hacer
Lo que apareció en la pantalla no fue el sitio nuevo. Apareció la pantalla de login de un sistema completamente distinto — un panel administrativo de otro producto que también vivía en el mismo servidor. El Tech Lead, primero confundido, pensó que había un problema de caché del navegador o de propagación de DNS. Probó en modo incógnito. Mismo resultado. Probó desde el teléfono con datos móviles, asegurándose de que no era cache local. Mismo resultado.
Hallazgo
Conversando con la IA sobre qué podía estar pasando, entendieron que el problema vivía en el reverse proxy del servidor — el componente que recibe todas las peticiones HTTP y decide a qué aplicación interna pasárselas según el dominio solicitado. El reverse proxy estaba configurado para varios dominios conocidos (cada uno con su propio bloque de reglas que sabía a qué backend ir), pero el dominio nuevo no tenía aún su bloque correspondiente. Cuando el reverse proxy recibía una petición con un dominio que no reconocía, su comportamiento por defecto era servir el primer bloque que encontraba en su archivo de configuración — y ese primer bloque era el del panel administrativo de otro producto. El comportamiento llevaba años así, oculto: cualquier dominio mal apuntado al servidor (un error tipográfico, una migración a medias, un atacante que registrara un subdominio similar y lo apuntara a la misma IP) habría visto exactamente lo mismo. Era un riesgo de seguridad y un sangrado de información, todo al mismo tiempo.
Corrección aplicada
Lo primero fue agregar el bloque correcto para el dominio nuevo: una regla específica que dijera 'cuando recibas peticiones para este dominio, pásalas a este backend, con este certificado, con estas cabeceras'. Eso resolvió el síntoma. Pero el Tech Lead hizo la pregunta más importante: ¿qué quería que pasara cuando llegara una petición con un dominio que el servidor no reconoce? La respuesta — discutida con la IA — fue agregar un bloque por defecto explícito que rechaza activamente cualquier dominio no listado: devuelve un error 444 (cerrar conexión sin respuesta) en lugar de servir lo que encontrara primero. Como cambio de práctica, todo despliegue nuevo en ese servidor ahora exige verificar que el dominio esté en la configuración explícita antes de salir a producción.
Lección
Los comportamientos por defecto son riesgos cuando no se los conoce. Casi todo software importante tiene defaults — qué hace cuando recibe algo inesperado, cómo responde si una pieza falla, qué muestra cuando una configuración falta. La mayoría de esos defaults fueron decididos por alguien que no eres tú, en un momento que no fue ahora, para un contexto que probablemente cambió. La pregunta correcta no es '¿funciona?'. Es '¿qué hace mi sistema cuando recibe algo que no espera?'. La IA ayudó a formular esa pregunta y a explorar su respuesta sin necesidad de incidentes en producción.
Los redirects rotos
Contexto
Después de sumar la capa de borde con TLS gestionado a una aplicación interna del equipo — un panel administrativo que llevaba años funcionando estable — los usuarios comenzaron a reportar algo raro al loguearse: el navegador 'rebotaba' un instante antes de cargar la pantalla principal, como si pasara por una página intermedia invisible. No era un bug bloqueante (todo terminaba funcionando), pero rompía la sensación de fluidez y, en redes lentas, hacía que el login se sintiera lento.
Qué intentaban hacer
El Tech Lead le pidió a la IA que le explicara qué estaba viendo en las solicitudes del navegador. Abrieron juntos el inspector de red, miraron la cadena exacta de redirects, y la IA fue describiendo el flujo paso a paso: el cliente hacía la petición inicial por el protocolo seguro (HTTPS), la capa de borde la pasaba al servidor de origen, el servidor de origen recibía esa petición ya descifrada (porque la capa de borde había terminado el TLS antes), procesaba el login, y al responder con un redirect, lo armaba con protocolo plano (HTTP) porque desde el punto de vista del servidor interno la conexión que tenía con la capa de borde era plana. El navegador del cliente recibía ese redirect a HTTP, la capa de borde — que tenía configurada la opción de forzar HTTPS — lo interceptaba y lo volvía a redirigir a HTTPS. Resultado: dos redirects en cadena, uno bajando de protocolo y otro subiéndolo de nuevo. Rebote innecesario.
Hallazgo
El sitio funcionaba, pero había un riesgo concreto detrás del síntoma cosmético. Si alguna ruta interna de la aplicación devolvía URLs absolutas con protocolo plano (en correos transaccionales, en respuestas de API consumidas por integraciones externas, en cabeceras 'Location' generadas por código antiguo), los consumidores de esas URLs podían quedarse navegando temporalmente fuera del cifrado durante la transición. Una integración externa que confiara en la URL del email para hacer fetch automático no necesariamente seguiría el redirect — y vería respuestas en claro durante segundos críticos. Era una vulnerabilidad de bajo riesgo pero capaz de escalar en escenarios sensibles (callbacks de pagos, webhooks de terceros, flujos de OAuth).
Corrección aplicada
La solución requirió dos ajustes complementarios. En el reverse proxy del servidor, se agregó una directiva para pasar a la aplicación interna una cabecera específica que comunicara cuál había sido el protocolo original solicitado por el cliente — algo así como 'esta petición llegó por HTTPS, aunque te llegue a ti por HTTP'. En la aplicación interna, se habilitó la configuración correspondiente para confiar en esa cabecera al generar redirects y URLs absolutas. Dos líneas de configuración resolvieron años de comportamiento sutilmente roto que nadie había documentado como bug porque, técnicamente, todo funcionaba. Como cambio de práctica, cualquier aplicación detrás de la capa de borde debe pasar por la misma revisión: ¿está consciente del protocolo original o lo asume mal?
Lección
Sumar una capa nueva a un sistema en producción no rompe nada visible, pero casi siempre introduce sutilezas que solo se ven cuando uno conversa con el sistema. Lo que parecía una redirección molesta era el síntoma de una falta de configuración que, en escenarios más sensibles, sí rompería. La IA no diagnosticó el problema — el Tech Lead lo diagnosticó porque la IA le ayudó a leer el flujo de red paso a paso, sin asumir que 'funcionar' es lo mismo que 'estar bien'. Cuando agregues una capa entre el cliente y tu aplicación, asume que algo se va a portar distinto y dedícale tiempo a encontrar qué.
