Ollama absichern

Was dieser Artikel über Ollama-Sicherheit behandelt

• Warum Ollama im Standard unsicher im Netzwerk ist.
• Wie man den Zugriff auf das lokale Netzwerk beschränkt.
• Wie ein Reverse Proxy mit Authentifizierung eingesetzt wird.
• Wie Tailscale oder ein VPN den Fernzugriff sicher macht.
• Wichtige Firewall- und Systemregeln.

Einleitung: Ollama absichern

Ollama lauscht standardmäßig auf 127.0.0.1:11434 und bietet keine eigene Authentifizierung. Sobald man den Dienst im Netzwerk erreichbar macht, kann jeder im gleichen Netzwerk auf das Modell zugreifen, Prompts senden und gegebenenfalls Daten aus der Laufzeitumgebung abfragen. Eine saubere Absicherung ist daher Pflicht, sobald Ollama auf mehr als einem Gerät genutzt werden soll.

Dieser Artikel zeigt, wie man Ollama mit Netzwerkisolation, Firewall, Reverse Proxy und VPN sicher betreibt.

Wichtige Begriffe

• Bind: Netzwerkschnittstelle, auf der Ollama lauscht.
• Firewall: Regelbasierte Netzwerkabsicherung.
• Reverse Proxy: Vermittler zwischen Client und Ollama.
• Authentifizierung: Prüfung, wer zugreifen darf.
• Tailscale: Mesh-VPN für sicheren Fernzugriff.
• mTLS: Gegenseitige TLS-Authentifizierung.
• API-Key: Geheimer Schlüssel für den Zugriff.

Standardverhalten von Ollama

Ohne Konfiguration ist Ollama nur auf localhost erreichbar. Das ist sicher, solange alles auf einem Rechner läuft. Möchte man einen anderen Host im Netzwerk anbinden, muss man Ollama an eine externe Schnittstelle binden. Damit wird der Dienst aber potenziell für jeden im Netzwerk erreichbar.

Netzwerkbindung einschränken

Für den Zugriff aus dem lokalen Netzwerk:

export OLLAMA_HOST=0.0.0.0:11434

Besser ist eine bestimmte Schnittstelle:

export OLLAMA_HOST=192.168.1.50:11434

Damit lauscht Ollama nur auf der internen Adresse, nicht auf allen Interfaces.

Firewall regeln

Auf einem Proxmox-Host oder Linux-Server sollte der Ollama-Port nicht offen ins Internet zeigen. Beispiel mit iptables:

iptables -A INPUT -p tcp --dport 11434 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 11434 -j DROP

Auf Proxmox kann die integrierte Firewall im Datacenter und auf dem LXC/VM-Level entsprechende Regeln enthalten.

Reverse Proxy mit Authentifizierung

Ein Reverse Proxy wie Nginx oder Traefik kann den Ollama-Port veröffentlichen und gleichzeitig Authentifizierung erzwingen. Beispiel mit Nginx:

server {
    listen 443 ssl;
    server_name ollama.home.local;

    auth_basic "Ollama";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

So ist Ollama nur mit Benutzername und Passwort erreichbar.

Tailscale für Fernzugriff

Anstatt Ollama öffentlich erreichbar zu machen, kann man Tailscale nutzen:

• Ollama bleibt auf 127.0.0.1 gebunden.
• Der Client verbindet sich über Tailscale mit dem Host.
• Die Kommunikation ist verschlüsselt.
• Keine öffentlichen Ports nötig.

Ollama hinter Open WebUI

Open WebUI kann als zentrale Schaltstelle dienen. Ollama selbst bleibt unerreichbar aus dem Netzwerk, Open WebUI spricht es lokal an. Benutzer melden sich in Open WebUI an. Das vereinfacht die Sicherheit erheblich.

-e OLLAMA_BASE_URL=http://localhost:11434
-p 8080:8080

Open WebUI bekommt dann Port 8080, Ollama bleibt lokal.

API-Keys über einen Proxy

Ollama kennt keine API-Keys. Wer dennoch Key-basierte Authentifizierung braucht, kann einen Proxy wie oauth2-proxy, Traefik oder Caddy mit Forward-Auth einsetzen. Alternativ gibt es Middlewares, die API-Keys prüfen, bevor Anfragen an Ollama weitergeleitet werden.

mTLS

Für höchste Sicherheit kann man mTLS zwischen Client und Reverse Proxy verwenden. Beide Seiten prüfen sich gegenseitig mit Zertifikaten. Das eignet sich für automatisierte Agenten und interne Dienste.

Docker- und Container-Sicherheit

Wenn Ollama in Docker läuft:

• Port 11434 nur an 127.0.0.1 binden: -p 127.0.0.1:11434:11434.
• Nicht als root ausführen.
• --read-only und --security-opt no-new-privileges prüfen.
• Capabilities minimieren.

Logs und Monitoring

Zugriffslogs helfen, ungewöhnliche Aktivitäten zu erkennen. Beim Reverse Proxy werden HTTP-Logs geschrieben. Ollama selbst protokolliert wenig, daher ist der Proxy oder ein vorangestelltes Gateway wichtig.

Typische Stolpersteine

• Ollama an 0.0.0.0 gebunden: Dann ist der Port überall erreichbar.
• Keine Authentifizierung: Jeder im Netzwerk kann Modelle nutzen.
• Offener Port im Internet: Kann schnell ausgenutzt werden.
• Open WebUI ohne Absicherung: Auch hier sollte Authentifizierung aktiv sein.
• Firewall-Regeln vergessen: Netzwerk trennen, wo möglich.

Weiterführende Links und Infos

• BotServ.de Tailscale Grundlagen
• BotServ.de Proxmox LXC vs. VM
• BotServ.de Proxmox Storage
• BotServ.de Open WebUI Administration

FAQ: Ollama absichern

Brauche ich Authentifizierung für Ollama? Ja, sobald mehr als ein Gerät zugreift.

Kann Ollama selbst API-Keys? Nein, das muss ein Reverse Proxy oder ein anderes Tool übernehmen.

Ist Tailscale sicher genug? Ja, für den Zugriff aus der Ferne ist Tailscale eine sehr gute Lösung.

Sollte ich Ollama im Internet erreichbar machen? Nein. Falls unbedingt nötig, nur mit Reverse Proxy, Authentifizierung, TLS und Rate-Limiting.

Was ist der sicherste Weg, Ollama im Netzwerk anzubieten? Ollama auf 127.0.0.1 lassen und über Open WebUI oder einen geschützten Reverse Proxy zugänglich machen.

Quellen und weiterführende Literatur

• Ollama Docs: https://github.com/ollama/ollama/blob/main/docs/
• Nginx Reverse Proxy: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• Tailscale: https://tailscale.com/

Zusammenfassung: Ollama absichern

Ollama ist ohne zusätzliche Massnahmen nicht für den Netzwerkzugriff ausgelegt. Wer Ollama im lokalen Netzwerk oder aus der Ferne nutzen will, sollte die Bind-Adresse einschränken, Firewall-Regeln setzen, Authentifizierung über einen Reverse Proxy einrichten und Fernzugriffe über Tailscale absichern. Open WebUI kann als geschützte Schaltstelle dienen, während Ollama selbst nur lokal erreichbar bleibt. Wer diese Schichten kombiniert, bekommt sicheren Zugriff auf lokale KI-Modelle.