Cómo una entrada en el archivo hosts rompió la transcripción de voz de un bot de IA

Una plataforma de atención al cliente con IA perdió la capacidad de procesar notas de voz, fotos y documentos durante dos días en octubre tras una migración rutinaria de servidores. La causa raíz fue una sola línea añadida al archivo hosts del sistema, que entró en conflicto con una medida de seguridad existente diseñada para prevenir la falsificación de solicitudes del lado del servidor (SSRF).

Qué ocurrió

El equipo detrás de DOS AI, un asistente que gestiona interacciones con clientes en WhatsApp, Instagram y Telegram, trasladó recientemente su infraestructura de un proveedor de nube gestionado a un servidor autoalojado. Como parte del proceso de endurecimiento de seguridad, un script modificó el archivo /etc/hosts para fijar sus nombres de dominio a la dirección de bucle invertido 127.0.0.1. El objetivo era garantizar que las llamadas internas a los servicios de almacenamiento y autenticación siguieran funcionando incluso si fallaba la resolución DNS externa. La aplicación resolvería sus propios dominios localmente y dependería de un proxy inverso para enrutar el tráfico correctamente utilizando Indicaciones de Nombre de Servidor (SNI).

Sin embargo, este cambio provocó un fallo silencioso en la canalización de procesamiento de medios de la aplicación. Cuando los clientes enviaban notas de voz o archivos, la pasarela de WhatsApp los almacenaba en el almacenamiento de objetos y generaba una URL apuntando al dominio propio de la empresa. Antes de descargar cualquier contenido de una URL proporcionada por el usuario o interna, la aplicación ejecuta una protección contra Falsificación de Solicitudes del Lado del Servidor (SSRF). Esta medida de seguridad resuelve el nombre de host y bloquea las solicitudes a direcciones IP privadas, de bucle invertido o de enlace local para evitar que los atacantes accedan a endpoints de metadatos internos.

Dado que el archivo hosts ahora resolvía el dominio de almacenamiento de la empresa a 127.0.0.1, la protección SSRF identificó la solicitud interna legítima como una posible amenaza de seguridad y la bloqueó. El sistema no se estrelló ni registró errores de alta severidad, ya que bloquear URLs inseguras es el comportamiento esperado. En consecuencia, el asistente de IA respondía a cada mensaje de voz con un error predeterminado pidiendo a los usuarios que escribieran su solicitud en lugar de hablarlo. Durante esos dos días, el sistema no logró procesar 314 de 339 notas de voz, 241 de 248 fotos y 92 de 94 documentos en trece proyectos diferentes.

Detalles clave

• El incidente ocurrió en octubre de 2026 tras una migración de nube gestionada a infraestructura autoalojada.
• Un script de endurecimiento añadió 127.0.0.1 sb.dosai.pro dosai.pro al archivo /etc/hosts para reducir la dependencia de DNS.
• Una protección SSRF bloqueó las descargas desde estos dominios porque resolvían a la dirección de bucle invertido 127.0.0.1.
• El fallo fue silencioso; las descargas rechazadas se registraron como advertencias, no como errores, lo que retrasó la detección.
• La pérdida de datos incluyó 314 notas de voz, 241 fotos y 92 documentos en 13 proyectos durante dos días.
• La solución consistió en actualizar la protección SSRF para reconocer ciertos nombres de host públicos como seguros antes de verificar las direcciones IP.

Contexto

La Falsificación de Solicitudes del Lado del Servidor (SSRF) es una vulnerabilidad en la que un atacante engaña a un servidor para que realice solicitudes a recursos internos no accesibles públicamente. Para mitigar esto, las aplicaciones suelen implementar protecciones que inspeccionan las URLs antes de obtenerlas. Estas protecciones típicamente resuelven el nombre de host a una dirección IP y rechazan cualquier solicitud dirigida a rangos privados (como 127.0.0.1 o 192.168.x.x). Esto evita que un atacante use el servidor para sondear su propia red interna o acceder a servicios locales de metadatos.

En entornos autoalojados, es común mapear nombres de dominio públicos a localhost en el archivo hosts. Esto asegura que los servicios internos puedan comunicarse entre sí usando sus nombres públicos sin depender de servidores DNS externos. Sin embargo, esto crea un conflicto con las protecciones SSRF estándar. La protección de seguridad ve una solicitud a un dominio público que resuelve a una IP privada y asume que es un ataque, aunque sea una llamada interna legítima. Resolver esto requiere que la lógica de seguridad distinga entre ataques de rebind maliciosos y enrutamiento local intencional.

Por qué importa

Para los equipos que ejecutan su propio software, este incidente destaca la complejidad oculta de combinar buenas prácticas de seguridad con optimizaciones de infraestructura. Tanto la modificación del archivo hosts como la protección SSRF eran correctas por separado. La entrada en hosts mejoró la fiabilidad eliminando dependencias de DNS, y la protección salvaguardaba contra una clase seria de vulnerabilidades. El fallo surgió solo de su interacción, demostrando que los controles de seguridad deben ser conscientes de la topología de red específica y las convenciones de nomenclatura del entorno que protegen.

El silencio del modo de fallo es otra lección crítica. Las herramientas de seguridad suelen configurarse para fallar cerradas, lo que significa que bloquean actividad sospechosa en lugar de permitir su paso. Aunque esto es seguro, puede llevar a pérdida de datos si la actividad bloqueada es realmente tráfico comercial legítimo. Sin alertas específicas para solicitudes internas bloqueadas o monitoreo de métricas de negocio (como transcripciones exitosas), los equipos pueden permanecer ignorantes del problema hasta que los clientes se quejen. En este caso, el fundador notó el problema solo al observar una caída en los leads publicitarios, no mediante alarmas del sistema.

Qué puedes hacer

• Audita tus protecciones SSRF para asegurar que puedan distinguir entre tus propios dominios públicos y amenazas externas.
• Implementa listas blancas de nombres de host con coincidencia exacta en las verificaciones de seguridad en lugar de depender únicamente de la validación de direcciones IP.
• Configura alertas para advertencias de seguridad, no solo errores, para detectar cuando se está bloqueando tráfico legítimo.
• Monitorea métricas de nivel de negocio, como cargas de archivos exitosas o transcripciones, para detectar regresiones funcionales tempranamente.
• Prueba las correcciones de seguridad simulando resoluciones DNS que devuelvan direcciones de bucle invertido tanto para hosts propios como extranjeros.
• Documenta cambios de infraestructura como modificaciones en el archivo hosts y revisa su impacto en las políticas de seguridad existentes.