Wie ein Eintrag in der hosts-Datei die Sprachtranskription eines KI-Bots lahmlegte

Eine KI-Plattform für den Kundenservice verlor im Oktober nach einer routinemäßigen Servermigration zwei Tage lang die Fähigkeit, Sprachnachrichten, Fotos und Dokumente zu verarbeiten. Die Ursache war eine einzelne Zeile, die zur hosts-Datei des Systems hinzugefügt wurde und mit einem bestehenden Sicherheitsmechanismus kollidierte, der Server-Side Request Forgery verhindern soll.

Was geschah

Das Team hinter DOS AI, einem Assistenten, der Kundeninteraktionen über WhatsApp, Instagram und Telegram abwickelt, hat seine Infrastruktur kürzlich von einem Managed Cloud Provider auf einen selbst gehosteten Server migriert. Als Teil des Härtungsprozesses modifizierte ein Skript die Datei /etc/hosts, um die Domainnamen auf die Loopback-Adresse 127.0.0.1 zu fixieren. Das Ziel war es sicherzustellen, dass interne Aufrufe an Speicher- und Authentifizierungsdienste auch dann funktionsfähig bleiben, wenn die externe DNS-Auflösung fehlschlägt. Die Anwendung sollte ihre eigenen Domains lokal auflösen und sich auf einen Reverse Proxy verlassen, um den Traffic korrekt unter Verwendung von Server Name Indication (SNI) zu leiten.

Allerdings löste diese Änderung einen stillen Fehler in der Medienverarbeitungs-Pipeline der Anwendung aus. Wenn Kunden Sprachnachrichten oder Dateien sendeten, speicherte das WhatsApp-Gateway diese im Object Storage und generierte eine URL, die auf die eigene Domain des Unternehmens zeigte. Bevor Inhalte von einer benutzerdefinierten oder internen URL heruntergeladen wurden, führte die Anwendung einen Schutz gegen Server-Side Request Forgery (SSRF) durch. Diese Sicherheitsmaßnahme löst den Hostnamen auf und blockiert Anfragen an private, Loopback- oder Link-local-IP-Adressen, um zu verhindern, dass Angreifer auf interne Metadaten-Endpunkte zugreifen.

Da die hosts-Datei nun die Speicher-Domain des Unternehmens auf 127.0.0.1 auflöste, identifizierte der SSRF-Schutz die legitime interne Anfrage als potenzielle Sicherheitsbedrohung und blockierte sie. Das System stürzte nicht ab und protokollierte keine Fehlermeldungen mit hoher Schweregradstufe, da das Blockieren unsicherer URLs beabsichtigtes Verhalten ist. Infolgedessen antwortete der KI-Assistent auf jede Sprachnachricht mit einer Standard-Fehlermeldung, die die Nutzer aufforderte, ihre Anfrage stattdessen einzutippen. Im Laufe von zwei Tagen konnte das System 314 von 339 Sprachnachrichten, 241 von 248 Fotos und 92 von 94 Dokumenten in dreizehn verschiedenen Projekten nicht verarbeiten.

Wichtige Details

• Der Vorfall ereignete sich im Oktober 2026 nach einer Migration von Managed Cloud zu selbst gehoster Infrastruktur.
• Ein Härtungsskript fügte 127.0.0.1 sb.dosai.pro dosai.pro zur Datei /etc/hosts hinzu, um die Abhängigkeit von DNS zu reduzieren.
• Ein SSRF-Schutz blockierte Downloads von diesen Domains, da sie auf die Loopback-Adresse 127.0.0.1 aufgelöst wurden.
• Der Ausfall verlief lautlos; abgelehnte Downloads wurden als Warnungen, nicht als Fehler protokolliert, was die Erkennung verzögerte.
• Der Datenverlust umfasste 314 Sprachnachrichten, 241 Fotos und 92 Dokumente in 13 Projekten über zwei Tage hinweg.
• Die Lösung bestand darin, den SSRF-Schutz so anzupassen, dass er bestimmte öffentliche Hostnamen als sicher erkennt, bevor IP-Adressen überprüft werden.

Hintergrund

Server-Side Request Forgery (SSRF) ist eine Schwachstelle, bei der ein Angreifer einen Server dazu bringt, Anfragen an interne Ressourcen zu stellen, die öffentlich nicht zugänglich sind. Um dies zu mildern, implementieren Anwendungen oft Schutzmechanismen, die URLs vor dem Abruf inspizieren. Diese Schutzvorrichtungen lösen typischerweise den Hostnamen in eine IP-Adresse auf und lehnen jede Anfrage ab, die auf private Bereiche zielt (wie 127.0.0.1 oder 192.168.x.x). Dies verhindert, dass ein Angreifer den Server nutzt, um sein eigenes internes Netzwerk zu sondieren oder auf lokale Metadaten-Dienste zuzugreifen.

In selbst gehosteten Umgebungen ist es üblich, öffentliche Domainnamen in der hosts-Datei auf localhost zu mappen. Dies stellt sicher, dass interne Dienste über ihre öffentlichen Namen miteinander kommunizieren können, ohne sich auf externe DNS-Server verlassen zu müssen. Allerdings erzeugt dies einen Konflikt mit standardmäßigen SSRF-Schutzmaßnahmen. Der Sicherheitsschutz sieht eine Anfrage an eine öffentliche Domain, die zu einer privaten IP aufgelöst wird, und geht davon aus, dass es sich um einen Angriff handelt, obwohl es sich um einen legitimen internen Aufruf handelt. Die Lösung dieses Problems erfordert, dass die Sicherheitslogik zwischen böswilligen Rebinding-Angriffen und absichtlicher lokaler Routing-Konfiguration unterscheidet.

Warum es wichtig ist

Für Teams, die ihre eigene Software betreiben, verdeutlicht dieser Vorfall die versteckte Komplexität bei der Kombination von Best Practices für Sicherheit mit Infrastruktur-Optimierungen. Sowohl die Modifikation der hosts-Datei als auch der SSRF-Schutz waren isoliert betrachtet korrekt. Der hosts-Eintrag verbesserte die Zuverlässigkeit durch die Beseitigung von DNS-Abhängigkeiten, und der Schutz bewahrte vor einer schweren Klasse von Schwachstellen. Der Fehler entstand erst durch ihr Zusammenspiel und zeigt, dass Sicherheitskontrollen die spezifische Netzwerktopologie und Namenskonventionen der Umgebung kennen müssen, die sie schützen.

Die Lautlosigkeit des Fehlermodus ist eine weitere kritische Lektion. Sicherheitstools sind oft so konfiguriert, dass sie „fail closed“ agieren, d.h., sie blockieren verdächtige Aktivitäten, anstatt sie durchzulassen. Während dies sicher ist, kann es zu Datenverlust führen, wenn die blockierte Aktivität tatsächlich legitimer Geschäfts-Traffic ist. Ohne spezifische Alarme für blockierte interne Anfragen oder das Monitoring von Business-Level-Metriken (wie erfolgreiche Transkriptionen) bleiben Teams möglicherweise unwissentlich über das Problem, bis Kunden sich beschweren. In diesem Fall bemerkte der Gründer das Problem nur durch einen Rückgang der Werbe-Leads, nicht durch Systemalarme.

Was Sie tun können

• Prüfen Sie Ihre SSRF-Schutzmechanismen daraufhin, ob sie zwischen Ihren eigenen öffentlichen Domains und externen Bedrohungen unterscheiden können.
• Implementieren Sie exakte Hostname-Allowlists in Sicherheitsprüfungen, anstatt sich ausschließlich auf die Validierung von IP-Adressen zu verlassen.
• Konfigurieren Sie Alarme für Sicherheitswarnungen, nicht nur für Fehler, um zu erkennen, wenn legitimer Traffic blockiert wird.
• Überwachen Sie Business-Level-Metriken, wie erfolgreiche Datei-Uploads oder Transkriptionen, um funktionale Regressionen frühzeitig zu erfassen.
• Testen Sie Sicherheitskorrekturen, indem Sie die DNS-Auflösung so simulieren, dass sie Loopback-Adressen für sowohl eigene als auch fremde Hosts zurückgibt.
• Dokumentieren Sie Infrastrukturänderungen wie Modifikationen der hosts-Datei und prüfen Sie deren Auswirkung auf bestehende Sicherheitsrichtlinien.