Einen selbst gehosteten LLM absichern: eine Checkliste

Das Ausführen eines Modells lokal mittels Ollama, llama.cpp, vLLM oder LM Studio ist einfach. Doch die Konfiguration so, dass Kollegen, Agenten oder andere Geräte darauf zugreifen können – ohne dabei eine Sicherheitslücke zu schaffen – bereitet häufig Probleme. Diese Checkliste führt die wichtigsten Punkte in der Reihenfolge auf, in der sie meist zum Problem werden, und erläutert, welche davon nach Einsatz eines rein ausgehenden Connectors wie Tokios keine Gefahr mehr darstellen. Dies ist lediglich eine Checkliste, keine Garantie. Ihre Beachtung mindert das Risiko, doch sie beseitigt es nicht; zudem ist keiner der Punkte als Versprechen zu verstehen, dass irgendeine Konfiguration – auch Tokios – absolut sicher ist.

​

1. Adressbindung: verwenden Sie ausschließlich die Loopback-Adresse

Jede Laufzeitumgebung in diesem Bereich setzt standardmäßig auf 127.0.0.1 (nur Loopback) – aus gutem Grund: dies ist die einzige Einstellung, die verhindert, dass die API von außerhalb des eigenen Rechners erreichbar ist.

• Ollama hört standardmäßig auf 127.0.0.1:11434. Durch Festlegen von OLLAMA_HOST=0.0.0.0 wird es auf allen Netzwerkschnittstellen aktiv – somit erreichbar für das lokale Netzwerk und, falls der Port weitergeleitet wird, auch für das offene Internet.
• llama.cpp server, vLLM sowie LM Studio verhalten sich ähnlich: Sie nutzen standardmäßig Loopback und bieten eine Option zur Bindung an 0.0.0.0 oder eine spezifische LAN-Schnittstelle.

Checklistenpunkt: Falls kein konkreter Grund vorliegt, die Bindung über Loopback hinaus zu erweitern, sollte man dies unterlassen. Sollte LAN- oder Fernzugriff dennoch erforderlich sein, dienen die übrigen Punkte dieser Checkliste – oder ein rein ausgehender Connector – dazu, dies zu realisieren.

​

2. Authentifizierung: die meisten Laufzeitumgebungen bieten keine oder nur optionale Authentifizierung

Eine Bindung über Loopback hinaus ohne Authentifizierung bedeutet, dass jeder, der den Port erreichen kann, die API nutzen darf – ohne jegliche Zugangsdaten. Das umfasst das Auflisten von Modellen, das Ausführen von Inferenzen sowie das Herunterladen weiterer Modelle. Checkliste: Falls mehrere Personen oder Dienste Ihren Endpunkt aufrufen, kann ein einziger gemeinsam genutzter statischer Schlüssel (oder gar kein Schlüssel) die Anrufer nicht unterscheiden und lässt sich auch nicht nur für einen bestimmten Nutzer widerrufen. Weitere Details zu den Vor- und Nachteilen finden Sie unter Hinzufügen von API-Schlüsseln zu einem lokalen Modell ohne Schlüssel.

​

3. Firewall und eingehende Ports

Sollten Sie die Bindung über den Loopback-Adressbereich hinaus erweitern, ist die nächste Kontrollinstanz die Firewall:

• Beschränken Sie den eingehenden Port (11434 für Ollama, 8080 für llama.cpp, 8000 für vLLM, 1234 für LM Studio) nach Möglichkeit auf bekannte Quell-IP-Adressen, anstatt ihn für alle Adressen zugänglich zu machen.
• Beachten Sie, dass das Weiterleiten eines Ports über Ihren Router nur funktioniert, wenn Sie eine stabile öffentliche IP-Adresse besitzen. Viele Heim- und Mobilfunkverbindungen befinden sich hinter CGNAT; dort existiert zunächst gar keine öffentliche IP, die weitergeleitet werden könnte – siehe dazu Zugriff auf ein Modell hinter CGNAT.
• Internetweite Scanner wie Shodan oder Censys erfassen neu geöffnete Dienste innerhalb weniger Stunden bis Tage. Ein offener, ungeschützter Port bleibt nicht lange unbemerkt.

Checkliste: Auch ein „vorübergehend weitergeleiteter Port“ bleibt entdeckbar. Ist ein Port geöffnet, ist davon auszugehen, dass er gefunden wird.

​

4. Fallstricke bei Reverse-Proxy-Lösungen

Die Verwendung von nginx oder Caddy als Frontend für ein Modell ohne Authentifizierung ist die gängigste Eigenlösung für das oben beschriebene Problem; dabei müssen jedoch zahlreiche Aspekte korrekt konfiguriert werden:

• TLS-Beendigung. Das Proxy benötigt ein gültiges Zertifikat; ein selbst signiertes Zertifikat würde die standardmäßigen Vertrauensprüfungen der meisten HTTP-Clients durchbrechen.
• Streaming-Antworten. LLM-APIs senden Token über Server-Sent Events (SSE). Ein Reverse-Proxy bzw. eine Upstream-CDN, die Antworten puffert statt sie unmittelbar weiterzuleiten, kann dazu führen, dass ein Chat, der eigentlich tokenweise gestreamt werden sollte, erst nach vollständiger Antwort fortfährt oder vorzeitig abbricht.
• Authentifizierungslogik befindet sich in der Proxy-Konfiguration, nicht auf dem Modellserver. Sie tragen nun die Verantwortung dafür, dass die Authentifizierungsregeln des Proxys korrekt, synchronisiert und getestet sind; der eigentliche Laufzeitprozess kennt keine Benutzer-spezifischen API-Schlüssel.
• Zeitüberschreitungen. Lange Generierungsvorgänge können die Standard-Anfragezeitüberschreitungen des Proxys bzw. des Edge-Netzwerks überschreiten, wodurch die Antwort während des Streamings abgeschnitten wird.

Checklistenpunkt: Falls Sie ein Reverse-Proxy einrichten, testen Sie ausführlich eine langsame, streamingbasierte Antwort – nicht bloß eine schnelle, kurze – bevor Sie das System in der Produktionsumgebung einsetzen.

​

5. Stellen Sie sicher, dass der Laufzeitprozess stets aktuell gepatcht ist.

Lokale Inferenzserver unterliegen dem üblichen Lebenszyklus von Sicherheitslücken; veröffentlichte CVE-Identifikatoren werden in der Praxis tatsächlich ausgenutzt. Ollama etwa weist in seiner Versionshistorie Sicherheitshinweise auf – prüfen Sie daher vor der Nutzung einer bestimmten CVE-Nummer oder Version die offiziellen GitHub-Sicherheitshinweise bzw. die Datenbank des NVD. Checklistenpunkt: Abonnieren Sie die Versionshinweise sowie Sicherheitsmitteilungen Ihres Laufzeitprozesses; setzen Sie keine Version dauerhaft ein, nur weil sie funktioniert. Dies gilt unabhängig davon, ob der Server lokal läuft oder öffentlich zugänglich ist – ein kompromittierter Host stellt ein Risiko dar, selbst wenn sonst alles in Ihrem Netzwerk in Ordnung ist.

​

Was „Outbound-only“ aus dieser Liste komplett entfernt.

Alle oben genannten Punkte existieren, weil ein Prozess auf eingehende Verbindungen warten muss, damit das Modell erreichbar bleibt. Ein „Outbound-only“-Connector – etwa der Tokios-Connector – verhält sich anders: Er läuft neben dem Modell und stellt eine Verbindung zu https://api.tokios.com her; somit hört weder Ihr Rechner noch das Netzwerk auf irgendeinen Port auf das Modellverkehr. Dadurch entfallen einige Checklistenpunkte vollständig, während andere unverändert bleiben.

• Kein einzubindender oder weiterzuleitender Eingangsport. Das Modell bleibt auf 127.0.0.1; der Connector initiiert die Verbindung, weshalb kein 0.0.0.0 gebunden werden muss, keine Port-Forwarding-Regeln erforderlich sind und auch keine CGNAT-Probleme bei der Erreichbarkeit auftreten.
• Es existiert keine Firewall-Regel für den Modell-Port. Folglich gibt es nichts, was eine Firewall für das Modell erlauben oder blockieren müsste.
• Für TLS oder Routing ist kein Reverse-Proxy erforderlich. Die Verbindung zu https://api.tokios.com erfolgt bereits verschlüsselt; Sie müssen weder nginx noch Caddy installieren oder verwalten.
• Verwenden Sie gezielt zugewiesene API-Schlüssel statt eines einzigen statischen Schlüssels. Jede Anfrage nutzt dabei einen Tokios-sk-tok-…-Schlüssel, der auf bestimmte Deployment-Instanzen beschränkt werden kann (z. B. durch Kommas getrennte Platzhalter wie gemma*, gpt-4*) und einzeln widerrufbar ist. So lässt sich der Zugriff einzelner Nutzer oder Dienste entziehen, ohne dass alle anderen ebenfalls neue Schlüssel erhalten müssen. Weitere Infos finden Sie unter API-Schlüssel für lokale Modelle hinzufügen.
• Was sich nicht ändert: das Patchen. Tokios fungiert lediglich als Vermittler zwischen Ihrer Umgebung und dem Modell; es führt keine Patches durch. Sie bleiben selbst verantwortlich dafür, Ollama, llama.cpp, vLLM oder LM Studio stets auf dem neuesten Stand zu halten – unabhängig davon, ob ein Connector genutzt wird oder nicht.

Treten bei Anfragen dennoch Fehler auf, prüfen Sie zunächst unter Fehlerbehebung mögliche Ursachen, bevor Sie von einem Sicherheitsproblem ausgehen. Meist handelt es sich um Konfigurationsprobleme und nicht um Sicherheitsverletzungen.

​

Wechseln Sie zu einer Einrichtung, die nur ausgehende Verbindungen zulässt.