Zum Hauptinhalt springen
Im Januar 2026 veröffentlichten SentinelLABS sowie Censys eine Studie, in der sie ungefähr 175,000 im Internet erreichbare Ollama-Server in etwa 130 Ländern kartierten – SentinelOne stellt die Hauptquelle dar; diese Zahlen wurden zudem über The Hacker News und SecurityWeek verbreitet. Demnach bot rund die Hälfte der öffentlich zugänglichen Server Unterstützung für Tool-Aufrufe – also die Ausführung von Code, nicht bloß Chat-Funktionen. Dies stellt keineswegs eine Schwachstelle in Ollama dar; vielmehr handelt es sich um eine Standardeinstellung, die viele Nutzer niemals ändern.

​
Das typische Fehlerverhalten

Standardmäßig lauscht Ollama auf 127.0.0.1:11434 – ausschließlich auf dem Loopback-Interface, sodass externe Zugriffe unmöglich sind. Um den Server jedoch von anderen Geräten im Netzwerk aus zu erreichen (beispielsweise vom Smartphone, einem zweiten Computer oder einem extern laufenden Coding-Agenten), ist folgende Maßnahme üblich:
Diese eine Umgebungsvariable ändert die Bindeadresse von Loopback auf alle verfügbaren Netzwerkschnittstellen. In Kombination mit einer Port-Weiterleitung am Router, der öffentlichen IP-Adresse einer Cloud-VM oder einer temporär erstellten Firewall-Regel wird Port 11434 für das gesamte Internet zugänglich – nicht bloß für das lokale Netzwerk. Standardmäßig fehlt dabei jegliche Authentifizierung; somit kann jeder, der den Port findet, die API direkt nutzen: Modelle auflisten, Inferenzen ausführen sowie – bei Servern mit Tool-Aufruf-Unterstützung – Code ausführen lassen. Genau dieses Muster suchen Massen-Scanning-Tools wie Shodan und Censys. Dafür ist kein gezielter Angriff nötig – ein einfacher Port-Scan genügt.
Es handelt sich um ein Konfigurationsproblem, nicht um einen Fehler in Ollama. Dieses Fehlerverhalten – Bindung an alle Schnittstellen, offener oder weitergeleiteter Port sowie fehlende Authentifizierung – gilt für sämtliche lokalen Modell-Server, nicht nur für Ollama.

​
Warum eine bloße Authentifizierung nicht ausreicht

Die Einrichtung eines Reverse Proxys mit Basis-Authentifizierung vor 0.0.0.0:11434 hilft zwar, beseitigt jedoch nicht die zugrundeliegende Ursache: Der Port bleibt weiterhin aktiv, und Komponenten im Netzwerkpfad müssen weiterhin von außen erreichbar sein, damit der Proxy funktioniert. Jedes einzelne Komponente – Proxy, Firewall-Regel, Port-Weiterleitung sowie TLS-Zertifikat – muss dauerhaft korrekt konfiguriert bleiben. Eine einzige Fehlkonfiguration oder eine versehentliche Rücknahme während der Fehlerbehebung führt sofort wieder zu einem offenen Port.

​
Die Alternative: ganz auf einen eingehenden Port verzichten.

Tokios verfolgt einen anderen Ansatz: Der tokios-connector, den Sie neben Ihrem Modell ausführen, lauscht niemals auf eingehenden Datenverkehr. Stattdessen öffnet er eine einzige ausgehende wss://-Verbindung zu https://api.tokios.com – in derselben Richtung, in der Ihr Browser üblicherweise Webseiten lädt – und Tokios leitet Anfragen über diese Verbindung zurück. Es gibt keinen Port, den man weiterleiten müsste, keine Firewall-Regel, die man freigeben müsste, und nichts, das an 0.0.0.0 gebunden ist. Jede Anfrage, die schließlich Ihr Modell erreicht, muss einen auf das jeweilige Deployment beschränkten sk-tok-…-API-Schlüssel enthalten; dieser wird überprüft, bevor Tokios die Anfrage durch den Tunnel an Ihren Connector weiterleitet. Die Schlüssel lassen sich auf bestimmte Deployments mit Modellnamenmustern beschränken, rotieren, deaktivieren oder löschen – ein widerrufener Schlüssel verliert sofort seine Gültigkeit. Um genau zu sein: Ein rein ausgehender Connector besitzt von vornherein keine Schnittstelle für eingehenden Datenverkehr. Das ist ein struktureller Unterschied im Verbindungsmodell, kein Sicherheitsgarantie. Tokios behauptet nicht, jede mögliche Fehlverwendung eines Modells verhindern zu können, das über den Connector genutzt wird – ein kompromittierter API-Schlüssel stellt nach wie vor ein Risiko dar, genauso wie ein verlorenes Passwort. Es geht vielmehr um einen rein mechanischen Aspekt: Es existiert kein lauschender Port, den ein Scanner finden könnte, weil es ihn schlicht nicht gibt.
Falls Sie derzeit Ollama mit OLLAMA_HOST=0.0.0.0 für den Fernzugriff nutzen, entspricht das genau dem Prinzip hinter der 175,000-Host-Nummer. Setzen Sie Ihr Modell wieder auf 127.0.0.1 und greifen Sie darauf via einem rein ausgehenden Connector zu – nähere Informationen zur Umstellung finden Sie unter Ollama Fernzugriff.

​
Wie das in der Praxis aussieht.

1

Starten Sie Ollama auf der Loopback-Adresse, wie es standardmäßig geschieht.

Es ist weder ein OLLAMA_HOST-Überschreiben noch ein Flag zum Binden an alle Schnittstellen erforderlich.
2

Verknüpfen Sie anschließend den Connector.

tokios-connector stellt eine Verbindung zu https://api.tokios.com her und wartet darauf, dass Sie sie in der Konsole autorisieren. Dieser Schritt erzeugt keinesfalls einen Port auf Ihrem Rechner oder Router.
3

Rufen Sie Ihr Modell von überall aus auf.

Die Anfrage muss einen gültigen, auf das Deployment beschränkten sk-tok-…-Schlüssel enthalten; andernfalls gelangt sie niemals an Ihren Connector.
Dies gilt ebenfalls für alle Nutzer hinter carrier-grade NAT (CGNAT), bei denen Port-Weiterleitungen nicht nur unerwünscht sind – sie sind strukturell unmöglich, da der Router keine öffentliche IP-Adresse besitzt, an die man Daten weiterleiten könnte. Lesen Sie Serve a local LLM from behind CGNAT, um zu verstehen, warum das so ist sowie wie die rein ausgehende Verbindung dieses Problem umgeht.

​
Die wichtigsten Erkenntnisse

Die in 175,000 dargestellte Grafik ist ein Scan-Ergebnis und keine Vorhersage für irgendeinen konkreten Server. Dennoch ist das dahinterliegende Prinzip einfach und sollte man sich merken – unabhängig von der genauen Zahl: Eingehende Erreichbarkeit ohne Authentifizierung ist das Kernproblem. Entfällt die eingehende Kommunikation, verschwindet auch eine ganze Kategorie von Sicherheitsvorfällen, da es dann nichts mehr gibt, das auf Verbindungsanfragen reagiert.

Schnellstart

Verknüpfen Sie einen Connector, registrieren Sie ein Modell und senden Sie Ihre erste Anfrage.

Fernzugriff auf Ollama

Verschieben Sie eine bereits öffentlich zugängliche Ollama-Installation zurück auf den Loopback-Modus und greifen Sie stattdessen über Tokios darauf zu.

Wie Tokios Anfragen weiterleitet

Betrachten Sie die gesamte Architektur mit rein ausgehender Kommunikation im Detail.