Comment une entrée dans le fichier hosts a cassé la transcription vocale d'un bot IA

Une plateforme de service client basée sur l'IA a perdu la capacité de traiter les notes vocales, les photos et les documents pendant deux jours en octobre après une migration de serveur de routine. La cause profonde était une seule ligne ajoutée au fichier hosts du système, qui entrait en conflit avec un mécanisme de sécurité existant conçu pour prévenir la falsification des requêtes côté serveur (SSRF).

Ce qui s'est passé

L'équipe derrière DOS AI, un assistant qui gère les interactions clients sur WhatsApp, Instagram et Telegram, a récemment déplacé son infrastructure d'un fournisseur cloud managé vers un serveur auto-hébergé. Dans le cadre du processus de durcissement, un script a modifié le fichier /etc/hosts pour épingler leurs noms de domaine à l'adresse de bouclage 127.0.0.1. L'objectif était de garantir que les appels internes aux services de stockage et d'authentification restent fonctionnels même si la résolution DNS externe échoue. L'application résoudrait ses propres domaines localement et dépendrait d'un proxy inverse pour router correctement le trafic en utilisant l'Indication du Nom du Serveur (SNI).

Cependant, ce changement a déclenché une défaillance silencieuse dans le pipeline de traitement des médias de l'application. Lorsque les clients envoyaient des notes vocales ou des fichiers, la passerelle WhatsApp les stockait dans un stockage objet et générait une URL pointant vers le propre domaine de l'entreprise. Avant de télécharger tout contenu depuis une URL fournie par l'utilisateur ou interne, l'application exécute un garde contre la Falsification des Requêtes Côté Serveur (SSRF). Cette mesure de sécurité résout le nom d'hôte et bloque les requêtes vers les adresses IP privées, de bouclage ou locales afin d'empêcher les attaquants d'accéder aux points de terminaison de métadonnées internes.

Parce que le fichier hosts résolvait désormais le domaine de stockage de l'entreprise vers 127.0.0.1, le garde SSRF a identifié la légitime requête interne comme une menace potentielle pour la sécurité et l'a bloquée. Le système ne s'est pas planté et n'a pas enregistré d'erreurs à un niveau de sévérité élevé, car le blocage des URLs non sûres est un comportement attendu. Par conséquent, l'assistant IA répondait à chaque message vocal par une erreur par défaut demandant aux utilisateurs de taper leur requête à la place. Au cours des deux jours, le système n'a pas réussi à traiter 314 des 339 notes vocales, 241 des 248 photos et 92 des 94 documents répartis sur treize projets différents.

Détails clés

• L'incident s'est produit en octobre 2026 suite à une migration du cloud managé vers une infrastructure auto-hébergée.
• Un script de durcissement a ajouté 127.0.0.1 sb.dosai.pro dosai.pro au fichier /etc/hosts pour réduire la dépendance au DNS.
• Un garde SSRF a bloqué les téléchargements provenant de ces domaines car ils résolvaient vers l'adresse de bouclage 127.0.0.1.
• La défaillance était silencieuse ; les téléchargements refusés étaient journalisés comme des avertissements, et non des erreurs, retardant la détection.
• Les pertes de données comprenaient 314 notes vocales, 241 photos et 92 documents sur 13 projets en deux jours.
• La correction consistait à mettre à jour le garde SSRF pour reconnaître des noms d'hôtes publics spécifiques comme sûrs avant de vérifier les adresses IP.

Contexte

La Falsification des Requêtes Côté Serveur (SSRF) est une vulnérabilité où un attaquant trompe un serveur pour qu'il effectue des requêtes vers des ressources internes non accessibles publiquement. Pour atténuer cela, les applications implémentent souvent des gardes qui inspectent les URLs avant de les récupérer. Ces gardes résolvent généralement le nom d'hôte en adresse IP et rejettent toute requête ciblant des plages privées (comme 127.0.0.1 ou 192.168.x.x). Cela empêche un attaquant d'utiliser le serveur pour sonder son propre réseau interne ou accéder aux services de métadonnées locaux.

Dans les environnements auto-hébergés, il est courant de mapper les noms de domaine publics vers localhost dans le fichier hosts. Cela garantit que les services internes peuvent communiquer entre eux en utilisant leurs noms publics sans dépendre des serveurs DNS externes. Cependant, cela crée un conflit avec les protections SSRF standard. Le garde de sécurité voit une requête vers un domaine public qui résout vers une IP privée et suppose qu'il s'agit d'une attaque, bien que ce soit un appel interne légitime. Résoudre ce problème nécessite que la logique de sécurité distingue les attaques de rebinding malveillantes du routage local intentionnel.

Pourquoi c'est important

Pour les équipes exécutant leur propre logiciel, cet incident met en évidence la complexité cachée de la combinaison des meilleures pratiques de sécurité avec les optimisations d'infrastructure. La modification du fichier hosts et le garde SSRF étaient corrects pris isolément. L'entrée hosts a amélioré la fiabilité en supprimant les dépendances DNS, et le garde protégeait contre une classe sérieuse de vulnérabilités. La défaillance n'a émergé que de leur interaction, démontrant que les contrôles de sécurité doivent être conscients de la topologie réseau spécifique et des conventions de nommage de l'environnement qu'ils protègent.

Le silence du mode de défaillance est une autre leçon critique. Les outils de sécurité sont souvent configurés pour échouer en mode fermé (fail-closed), ce qui signifie qu'ils bloquent l'activité suspecte plutôt que de la laisser passer. Bien que cela soit sécurisé, cela peut entraîner une perte de données si l'activité bloquée est en fait un trafic commercial légitime. Sans alertes spécifiques pour les requêtes internes bloquées ou la surveillance des métriques au niveau métier (telles que les transcriptions réussies), les équipes peuvent rester inconscientes du problème jusqu'à ce que les clients se plaignent. Dans ce cas, le fondateur n'a remarqué le problème qu'en observant une baisse des prospects publicitaires, et non grâce aux alarmes du système.

Ce que vous pouvez faire

• Auditez vos gardes SSRF pour vous assurer qu'ils peuvent distinguer vos propres domaines publics des menaces externes.
• Implémentez des listes blanches de correspondance exacte de noms d'hôtes dans les vérifications de sécurité plutôt que de compter uniquement sur la validation des adresses IP.
• Configurez des alertes pour les avertissements de sécurité, et pas seulement les erreurs, afin de détecter quand le trafic légitime est bloqué.
• Surveillez les métriques au niveau métier, telles que les téléversements de fichiers ou les transcriptions réussis, pour repérer tôt les régressions fonctionnelles.
• Testez les corrections de sécurité en simulant la résolution DNS pour retourner des adresses de bouclage pour les hôtes possédés et étrangers.
• Documentez les changements d'infrastructure tels que les modifications du fichier hosts et examinez leur impact sur les politiques de sécurité existantes.