Den eigenen Ollama-Server absichern: Authentifizierung, Reverse Proxy, exposition

#Warum es dringend nötig ist, Ollama abzusichern

Ollama verfügt über keine native Authentifizierung. Der Daemon lauscht und bedient Anfragen, Punkt: Er geht davon aus, dass nur ein vertrauenswürdiger Client auf dem lokalen Rechner mit ihm kommuniziert. Dieses Modell funktioniert, solange man bei http://localhost:11434 bleibt. Das Problem entsteht, sobald man eine Umgebungsvariable ändert, um den Dienst über das Netzwerk zugänglich zu machen – ein üblicher Schritt, um eine entfernte Benutzeroberfläche oder einen anderen Rechner anzubinden.

Wenn Sie OLLAMA_HOST auf 0.0.0.0 setzen, weisen Sie den Daemon an, auf allen Netzwerkschnittstellen zu lauschen. Wenn Port 11434 nicht durch eine Firewall gefiltert wird, ist die API für das gesamte lokale Netzwerk zugänglich, unter Umständen sogar für das gesamte Internet, falls die Maschine eine öffentliche IP-Adresse hat oder auf dem Router eine Portweiterleitung eingerichtet ist. Kein Passwort, kein Token: Jeder kann Anfragen senden, Ihre Modelle herunterladen oder löschen und Ihre GPU beanspruchen.

#Was die Ollama-API tatsächlich bereitstellt

Bevor Sie irgendetwas absichern, müssen Sie den Umfang der Angriffsoberfläche verstehen. Die Ollama-API ist nicht nur ein Chat-Endpunkt: Sie ist eine vollständige Verwaltungs-API ohne Unterscheidung zwischen Berechtigungsstufen. Ein anonymer Client hat genau dieselben Rechte wie Sie.

/api/generate et /api/chat

Textgenerierung. Beansprucht Ihre GPU nach Belieben und sieht sämtliche Prompts — also möglicherweise auch sensible Daten, die Ihre eigenen Anwendungen einspeisen.

/api/tags

Listet alle installierten Modelle auf. Ein Angreifer weiß sofort, was Sie hosten, einschließlich Ihrer möglichen internen Fine-Tunes.

/api/pull

Lädt beliebige Modelle aus einer Registry herunter. Ein Dritter kann Ihren Datenträger füllen oder ein manipuliertes Modell installieren.

/api/delete

Löscht Modelle. Daten können ohne jegliche Authentifizierung zerstört werden.

/api/create et /api/push

Erstellung von Modellen aus einem Modelfile und Übertragung an eine Registry. Vollständige Übernahme der Instanz.

/v1/*

OpenAI-kompatible Schicht auf demselben Port. Auch hier fehlt die Zugriffskontrolle; jeder standardmäßige OpenAI-Client kann darauf zugreifen.

#Prüfen, ob Ihr Ollama über das Netzwerk zugänglich ist

Beginnen Sie mit einer ehrlichen Bestandsaufnahme. Das Ziel: feststellen, auf welchen Netzwerkschnittstellen der Daemon lauscht und ob der Port von außen erreichbar ist. Drei Prüfungen, von der lokalsten bis zur externsten Perspektive.

Prüfen Sie zunächst, auf welchen Adressen der Prozess auf Verbindungen lauscht. Auf 127.0.0.1 zu lauschen ist unbedenklich; lauscht der Prozess auf 0.0.0.0 oder einer Netzwerk-IP-Adresse, bedeutet das, dass der Dienst Verbindungen von anderen Rechnern akzeptiert.

# Voir sur quelle interface Ollama écoute (Linux)
ss -tlnp | grep 11434

# Alternative si ss n'est pas disponible
sudo lsof -i :11434

# Vérifier la variable qui contrôle l'écoute
systemctl show ollama --property=Environment 2>/dev/null | grep -i host
echo $OLLAMA_HOST

Testen Sie anschließend von einem anderen Rechner im Netzwerk aus. Ersetzen Sie IP_DU_SERVEUR durch die lokale Adresse des Rechners, auf dem Ollama läuft. Wenn der Befehl die Modellliste zurückgibt, ist die Instanz über das Netzwerk erreichbar – das ist in einem vertrauenswürdigen LAN akzeptabel, bei Zugriffen aus dem Internet jedoch niemals ohne Filterung.

# Depuis un autre poste du réseau local
curl http://IP_DU_SERVEUR:11434/api/tags

# Réponse = liste JSON des modèles => l'instance répond aux tiers

Prüfen Sie abschließend die öffentliche Erreichbarkeit. Wenn Ihr Rechner eine öffentliche IP-Adresse oder eine aktive Portweiterleitung hat, suchen Sie ihn über eine Suchmaschine wie Shodan oder Censys, die öffentlich erreichbare Systeme erfasst. Eine einfache Suche nach Port 11434 und dem Ollama-Banner zeigt, ob Ihre Instanz bereits indexiert ist. Sie können auch Ihre öffentliche IP-Adresse direkt testen.

# Récupérer votre IP publique
curl -s https://api.ipify.org; echo

# Tester si le port 11434 répond depuis internet (depuis un réseau externe,
# ex. partage 4G du téléphone, pas depuis le LAN)
curl http://VOTRE_IP_PUBLIQUE:11434/api/tags

#Schritt 1 — Wieder nur auf localhost lauschen

Die erste und oft einzige notwendige Maßnahme besteht darin, Ollama wieder auf sein Standardverhalten zurückzustellen: nur auf der Loopback-Adresse zu lauschen. Es gibt keinen Grund, den Port direkt nach außen freizugeben, wenn Sie anschließend einen Reverse-Proxy vorschalten. Der Proxy kommuniziert lokal mit Ollama, und die Außenwelt kommuniziert ausschließlich mit dem Proxy.

Unter Linux läuft Ollama als systemd-Dienst. Die Variable OLLAMA_HOST wird über eine Override-Konfiguration für den Dienst festgelegt, die auch bei Paketaktualisierungen erhalten bleibt.

1. 01
   Das Override des Dienstes bearbeiten

   Öffnen Sie den systemd-Editor für Overrides des Dienstes ollama. Dadurch wird eine saubere Drop-in-Datei erstellt, ohne den ursprünglichen Dienst zu verändern.
2. 02
   Das Lauschen auf lokale Verbindungen beschränken

   Setzen Sie OLLAMA_HOST auf 127.0.0.1:11434. Der Daemon wird dann keine Verbindungen aus dem Netzwerk akzeptieren.
3. 03
   Neu laden und neu starten

   Laden Sie die systemd-Konfiguration neu und starten Sie den Dienst neu, um die Variable zu aktivieren.
4. 04
   Bestätigen

   Prüfen Sie erneut mit ss -tlnp | grep 11434: Die Adresse muss 127.0.0.1 sein und nicht 0.0.0.0.

# Ouvre un éditeur pour un drop-in override
sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama

# L'écoute doit revenir sur 127.0.0.1
ss -tlnp | grep 11434

#Schritt 2 — Authentifizierung über Reverse Proxy hinzufügen

Da Ollama selbst keine Authentifizierung durchführen kann, wird diese Aufgabe einem vorgeschalteten Reverse-Proxy übertragen. Der Proxy verlangt eine Benutzerkennung, prüft den Datenverkehr und leitet ihn anschließend lokal an Ollama weiter. Zwei bewährte Optionen: Caddy (minimale Konfiguration, automatisches TLS) und nginx (allgegenwärtig, sehr gut dokumentiert).

#Option A — Caddy (empfohlen aufgrund der Einfachheit)

Caddy verwaltet TLS automatisch über Let's Encrypt und bietet mit wenigen Zeilen HTTP-Basisauthentifizierung. Erzeugen Sie zunächst einen Hash des Passworts und referenzieren Sie diesen anschließend im Caddyfile. Speichern Sie das Passwort niemals im Klartext.

# Génère un hash bcrypt à coller dans le Caddyfile
caddy hash-password --plaintext 'VotreMotDePasseFort'

ollama.mondomaine.fr {
    # Authentification basique (utilisateur : admin)
    basic_auth {
        admin $2a$14$le_hash_genere_ci_dessus
    }

    # Relais vers Ollama en local
    reverse_proxy 127.0.0.1:11434
}

Wenn ein Domainname auf Ihre öffentliche IP-Adresse verweist und die Ports 80/443 geöffnet sind, beschafft und erneuert Caddy das TLS-Zertifikat automatisch. Der Client muss bei jeder Anfrage die Kennung über den Authorization-Header übermitteln.

# L'accès nécessite désormais des identifiants
curl -u admin:VotreMotDePasseFort https://ollama.mondomaine.fr/api/tags

#Option B — nginx

nginx benötigt eine separate Passwortdatei, die mit htpasswd erzeugt wird, und anschließend einen server-Block, der die Authentifizierung durchsetzt und Anfragen an Ollama weiterleitet. Das erfordert mehr Konfiguration, ist aber sehr verbreitet, insbesondere wenn nginx bereits andere Dienste bereitstellt.

# Paquet apache2-utils (Debian/Ubuntu) ou httpd-tools (Fedora)
sudo htpasswd -c /etc/nginx/.ollama_htpasswd admin

server {
    listen 443 ssl;
    server_name ollama.mondomaine.fr;

    ssl_certificate     /etc/letsencrypt/live/ollama.mondomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.mondomaine.fr/privkey.pem;

    location / {
        auth_basic           "Ollama";
        auth_basic_user_file /etc/nginx/.ollama_htpasswd;

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;

        # Le streaming des tokens ne doit pas être bufferisé
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

#Schritt 3 — Datenverkehr verschlüsseln (TLS)

Die Basic-Authentifizierung überträgt die Kennung Base64-kodiert: Ohne TLS wird sie praktisch im Klartext übertragen und lässt sich sehr leicht abfangen. Die Transportverschlüsselung ist daher zwingend erforderlich, sobald Sie localhost verlassen. Es gibt zwei Fälle, je nachdem, ob Sie einen öffentlichen Domainnamen haben oder nicht.

Öffentliche Domain + Ports 80/443

Let's Encrypt über Caddy (automatisch) oder certbot für nginx. Anerkanntes Zertifikat, keine Browserwarnung, automatische Erneuerung.

Internes Netzwerk ohne öffentliche Domain

Selbstsigniertes Zertifikat oder interne Zertifizierungsstelle (mkcert). Die Clients müssen dem Zertifikat vertrauen, aber der Datenverkehr im LAN bleibt verschlüsselt.

Hinter einem VPN

Der VPN-Tunnel verschlüsselt bereits alles. TLS bleibt als zusätzliche Schutzmaßnahme empfohlen, ist aber weniger kritisch, da kein externer Benutzer den Proxy erreicht.

# Obtenir et installer le certificat, avec renouvellement automatique
sudo certbot --nginx -d ollama.mondomaine.fr

# Tester le renouvellement à blanc
sudo certbot renew --dry-run

#Schritt 4 — Fernzugriff richtig einrichten: VPN und Tailscale

Die wichtigste Frage: Müssen Sie Ollama wirklich über das Internet öffentlich zugänglich machen? In der überwiegenden Mehrheit der Fälle lautet die Antwort nein. Sie möchten von Ihren eigenen Geräten darauf zugreifen, nicht aus dem offenen Web. Ein privates Netzwerk (VPN) erfüllt genau diesen Bedarf, ohne den Port jemals öffentlich zugänglich zu machen.

Tailscale ist die einfachste Option: Es erstellt ein verschlüsseltes Mesh-Netzwerk (WireGuard) zwischen Ihren Rechnern mit stabilen privaten IP-Adressen. Ollama lauscht dann ausschließlich auf der Tailscale-Schnittstelle, und nur Ihre in Ihrem Tailnet authentifizierten Geräte können es erreichen. Keine Portweiterleitung, keine öffentlich exponierte IP-Adresse.

1. 01
   Tailscale auf dem Server installieren

   Installieren Sie den Client und verbinden Sie das Gerät mit Ihrem Tailnet. Es erhält eine private IP-Adresse im Format 100.x.y.z, die ausschließlich von Ihren anderen authentifizierten Geräten erreichbar ist.
2. 02
   Ollama an die Tailscale-Schnittstelle binden

   Setzen Sie OLLAMA_HOST auf die Tailscale-IP-Adresse des Rechners (oder behalten Sie 127.0.0.1 bei und machen Sie den Dienst über Tailscale Serve erreichbar). Der Port ist nur innerhalb des Tailnets erreichbar.
3. 03
   Tailscale auf Ihren Clients installieren

   Ihre anderen Rechner treten demselben Tailnet bei und erreichen Ollama über dessen IP-Adresse 100.x.y.z, unabhängig davon, wo Sie sich befinden, ohne auch nur einen Port am Router zu öffnen.
4. 04
   Die Isolation prüfen

   Von einem externen Netzwerk außerhalb des Tailnets aus muss der Port vollständig unerreichbar sein. Das ist das erwartete Verhalten.

# Installation (Linux)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Récupérer l'IP Tailscale de la machine
tailscale ip -4

# Exposer Ollama proprement dans le tailnet (HTTPS + identité tailnet)
tailscale serve --bg 11434

Wenn Sie Wert auf ein klassisches VPN legen, bietet selbst gehostetes WireGuard dasselbe Ergebnis mit mehr Kontrolle: Sie richten den Tunnel ein, binden Ollama an die Schnittstelle wg0 und der Port bleibt vom Internet aus unsichtbar. Die Wahl zwischen Tailscale und reinem WireGuard hängt vor allem von der Abwägung zwischen Einfachheit und vollständiger Souveränität über die Infrastruktur ab.

#Zusätzliche Netzwerkhärtung

Zusätzlich zu Proxy und VPN begrenzen einige Maßnahmen für eine mehrschichtige Verteidigung die Schäden bei einer Fehlkonfiguration. Das Leitprinzip: sich niemals auf eine einzige Schicht verlassen.

Strikte Firewall-Regeln

Blockieren Sie eingehende Verbindungen auf Port 11434 auf allen Schnittstellen außer Loopback und VPN. Mit ufw: Port 11434 standardmäßig sperren und den Zugriff nur aus dem Tailscale-/WireGuard-Subnetz erlauben.

Keine Portumleitung

Erstellen Sie niemals Port Forwarding für 11434 auf dem Router. Wenn Sie eines „zum Testen“ haben, löschen Sie es: Das ist die Ursache Nr. 1 für exponierte Instanzen.

Begrenzung der Anfragerate

Richten Sie auf dem Reverse Proxy Rate Limiting ein, um möglichen Missbrauch auch nach der Authentifizierung abzufangen (nginx limit_req, Caddy rate_limit).

Starke Passwörter und Passwortrotation

Die Sicherheit der Basic-Authentifizierung hängt allein von der Stärke des Passworts ab. Verwenden Sie lange Passwörter und ändern Sie sie, wenn ein Client-Rechner kompromittiert ist.

Protokollierung

Aktivieren Sie die Zugriffsprotokolle des Proxys, um ungewöhnliche Zugriffsversuche zu erkennen. Eine ordnungsgemäß betriebene Instanz erhält nur Ihre Anfragen.

# Refuser l'accès direct au port depuis le réseau
sudo ufw deny 11434

# N'autoriser que le sous-réseau Tailscale (exemple)
sudo ufw allow from 100.64.0.0/10 to any port 11434

sudo ufw status verbose

#Fehlerbehebung

403 Forbidden hinter dem Proxy

Ollama weist den Host-Header zurück. Erzwingen Sie auf der Proxy-Seite den Wert localhost:11434 für Host, oder setzen Sie OLLAMA_ORIGINS, um Ihre Domain zuzulassen.

Das Streaming stockt oder die Ausgabe kommt auf einmal an

Der Proxy puffert die Antwort. Deaktivieren Sie das Buffering (proxy_buffering off bei nginx) und erhöhen Sie das Lese-Timeout für lange Generierungen.

curl fonctionne mais pas depuis une autre machine

Ollama lauscht weiterhin auf 127.0.0.1, obwohl der Proxy auf einem anderen Rechner läuft, oder die Firewall blockiert Port 443 des Proxys. Prüfen Sie ss -tlnp und die ufw-Regeln.

Ausstellung des Let's-Encrypt-Zertifikats schlägt fehl

Der Port 80 muss vom Internet aus erreichbar sein, um die HTTP-01-Validierung durchzuführen, und der Domainname muss auf die richtige IP zeigen. Prüfen Sie den DNS-Eintrag und die Öffnung des Ports 80.

Tailscale: Ollama im Tailnet nicht erreichbar

Ollama lauscht auf 127.0.0.1, ohne tailscale serve. Binden Sie Ollama über OLLAMA_HOST an die IP-Adresse 100.x oder machen Sie es über tailscale serve 11434 erreichbar.

Nach der Korrektur weiterhin auf Shodan sichtbar

Der Index benötigt Zeit zum Aktualisieren. Stellen Sie zunächst selbst über ein externes Netzwerk sicher, dass der Port geschlossen ist; danach wird die Indexierung aktualisiert.

#Weiterführende Informationen

Die Absicherung des Zugriffs ist nur ein Teil des Gesamtbilds. Diese Leitfäden ergänzen den vorliegenden Leitfaden um die Themen Bereitstellung und Compliance:

KI-Chatbot für das Team im Intranet deployen

Der typische Anwendungsfall für diese Absicherung: Ollama + Open WebUI für mehrere Nutzer hinter einem Reverse-Proxy mit Authentifizierung.

Ein LLM mit Docker Compose in einer Produktionsumgebung bereitstellen

Vollständiger Stack aus Ollama und Traefik, bei dem Reverse-Proxy und Netzwerkisolierung bereits bei der Konzeption berücksichtigt werden.

Lokale LLMs und DSGVO: Datenschutzkonformität im Unternehmen

Die regulatorische Seite: Eine unkontrollierte Exposition birgt auch ein zu dokumentierendes Risiko, dass personenbezogene Daten nach außen gelangen.