SSD Nodes Learn 🎉 VPS ab $5.50/Monat
Anleitungen Matt ConnorVon Matt Connor

Ollama API absichern: Kein Passwort auf Port 11434

Die Ollama API hat keine Authentifizierung: Wer Port 11434 erreicht, kann Modelle auflisten, ausführen, herunterladen und löschen. Drei Schutzmaßnahmen in Reihenfolge.

Die Ollama API hat kein Passwort

Die Ollama API bietet keine Authentifizierung. Auf dem Server, den Sie betreiben, gibt es weder einen Benutzer noch ein Passwort, eine Schlüsselprüfung oder eine Allowlist. Alles, was eine TCP-Verbindung zu Port 11434 öffnen kann, kann Ihre Modelle auflisten, sie ausführen, neue Modelle herunterladen und vorhandene Modelle löschen.

Die offizielle Dokumentation formuliert es eindeutig: „Für den lokalen Zugriff auf die Ollama API über http://localhost:11434 ist keine Authentifizierung erforderlich.“ Das Wort lokal beschreibt das gesamte Sicherheitsmodell. Ollama bindet standardmäßig an 127.0.0.1. Auf einem Laptop übernimmt daher die Loopback-Schnittstelle die Zugriffskontrolle. Verschieben Sie den Listener auf eine öffentliche Adresse, entfällt diese Zugriffskontrolle, weil nichts sie ersetzt.

Deshalb ist das auf einem VPS (virtuellen privaten Server) relevant. Die Standardeinstellung ist sicher. Die erste Änderung, die viele vornehmen, ist das Öffnen des Listeners, damit ein zweiter Rechner das Modell verwenden kann. Genau diese Änderung entfernt den gesamten Schutz auf einmal.

Was ein offener Port 11434 preisgibt

Jeden Endpunkt. Es gibt keinen Nur-Lese-Modus und keinen separaten Admin-Port. Dies sind die tatsächlichen Anfragen, die an eine Serveradresse statt an localhost gerichtet sind:

# List every model on the box
curl http://SERVER_IP:11434/api/tags

# See what is loaded into memory right now
curl http://SERVER_IP:11434/api/ps

# Run a prompt on your hardware
curl http://SERVER_IP:11434/api/generate -d '{"model":"llama3.2","prompt":"Why is the sky blue?"}'

# Write several gigabytes to your disk
curl http://SERVER_IP:11434/api/pull -d '{"model":"llama3.2"}'

# Remove a model
curl -X DELETE http://SERVER_IP:11434/api/delete -d '{"model":"llama3.2"}'

Aus Betreibersicht gehen vier Dinge schief:

  • Ihre CPU oder GPU führt Inferenz für jemand anderen aus. Bei einem Tarif mit einem Fair-Use-Kontingent für CPU-Leistung wird eine anhaltende Auslastung von einem Fremden auf Ihr Kontingent angerechnet. Die Kosten für KI-Workloads auf einem VPS unter Kontrolle zu halten wird deutlich schwieriger, sobald nicht mehr nur Sie Anfragen senden.
  • /api/pull schreibt auf Ihre Festplatte. Modelle benötigen jeweils zwischen zwei und vierzig Gigabyte. Eine Schleife aus Pulls füllt das Volume, und ein volles Dateisystem legt jeden anderen Dienst auf dem Server lahm, nicht nur Ollama.
  • Anfragen erreichen Ihren Prozess und werden protokolliert. Mit der standardmäßigen Protokollierungsstufe erfasst Ollama nur Metadaten. Sie erhalten also den Endpunkt, den Status, die Latenz und die Clientadresse, nicht den Prompttext. Das ist trotzdem ein Protokoll darüber, wer Ihren Server wofür verwendet hat. Es liegt in Ihrem Journal, obwohl Sie sich nicht dafür entschieden haben, diese Daten zu erfassen.
  • /api/delete entfernt Modelle. Um sie wiederherzustellen, müssen Sie sie erneut über Ihre eigene Bandbreite herunterladen.

Dafür ist kein Exploit erforderlich. Die dokumentierte API verhält sich genau wie vorgesehen.

Der Ed25519-Schlüssel ist keine Zugriffskontrolle

Wenn Sie nach „Ollama API key“ suchen, stoßen Sie auf zwei verschiedene Dinge. Keines davon ist ein Passwort für Ihren Server. Wenn Sie beide unterscheiden, verschwinden die meisten Unklarheiten.

Das erste ist das Identitätsschlüsselpaar. Ollama erzeugt beim ersten Start ein Ed25519-Schlüsselpaar. Unter Linux erstellt das Installationsskript einen Systembenutzer namens ollama mit dem Home-Verzeichnis /usr/share/ollama. Das Schlüsselpaar befindet sich daher hier:

/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pub

Dieser Schlüssel wird für ausgehende Verbindungen verwendet. ollama signin registriert die öffentliche Hälfte bei Ihrem ollama.com-Konto. Der Schlüssel autorisiert Sie außerdem, ein Modell in die Registry zu übertragen oder ein privates Modell abzurufen. Er weist Ihre Maschine gegenüber ollama.com aus. Für Clients, die eine Verbindung zu Ihrer Maschine herstellen, bewirkt er nichts. Wenn Sie ihn löschen, rotieren oder nie erstellen, ändert sich nichts daran, wer Ihre API aufrufen darf.

Das zweite ist OLLAMA_API_KEY. Diese Variable enthält einen Schlüssel, den Sie unter https://ollama.com/settings/keys erstellen. Ihr Client sendet ihn als Authorization: Bearer $OLLAMA_API_KEY, wenn er die gehostete API unter https://ollama.com/api aufruft. Es handelt sich um eine Zugangsinformation für den Dienst des Anbieters, die Sie als Client verwenden. Ihr eigenes ollama serve liest sie niemals aus. Wenn Sie OLLAMA_API_KEY auf Ihrer VPS setzen, wird dadurch kein Passwort für Ihre VPS eingerichtet.

Sie müssen daher keine Einstellung aktivieren. Die drei folgenden Schutzmaßnahmen funktionieren alle nach demselben Prinzip: Halten Sie den Port unerreichbar und schalten Sie einen Dienst davor, der die Zugriffe tatsächlich prüft.

Prüfen, worauf Ihr Server derzeit lauscht

sudo ss -tlnp | grep 11434

Das sichere Ergebnis nennt die Loopback-Adresse:

LISTEN 0  4096  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

Das exponierte Ergebnis nennt jedes Interface:

LISTEN 0  4096  0.0.0.0:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

0.0.0.0 bedeutet alle IPv4-Adressen auf dem Server, einschließlich der öffentlichen Adresse. *:11434 und [::]:11434 bedeuten dasselbe einschließlich IPv6.

Prüfen Sie dies nun von außerhalb. Führen Sie den folgenden Befehl auf Ihrem Laptop aus, nicht auf dem Server:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version

curl: (28) Connection timed out after 5001 milliseconds ist das gewünschte Ergebnis, ebenso curl: (7) Failed to connect ... Connection refused. Ein JSON-Objekt mit einem Feld version bedeutet, dass die gesamte API für jeden erreichbar ist. Ein Test mit curl auf dem Server selbst beweist nichts, weil die Loopback-Adresse immer antwortet.

Eine Freigabe erfolgt meist auf eine von zwei Arten. Die erste ist eine absichtliche Änderung, weil ein anderes Gerät auf das Modell zugreifen musste:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Diese eine Zeile stellt die vollständige Freigabe dar. Die zweite Möglichkeit ist Docker. Dafür müssen Sie überhaupt nichts bearbeiten. Dafür gibt es weiter unten einen eigenen Abschnitt.

Abwehr 1: Dienst auf localhost beschränken und per Tunnel zugreifen

Verwenden Sie diese Möglichkeit zuerst. Sie benötigt keine neue Software und erzeugt keine Zugangsdaten, die offengelegt werden können. Der Port ist auf keiner öffentlichen Schnittstelle vorhanden und kann daher durch Scans nicht gefunden werden.

Legen Sie die Bind-Adresse explizit fest, statt sich auf den Standardwert zu verlassen:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

Damit wird /etc/systemd/system/ollama.service.d/override.conf geschrieben. Wenden Sie die Änderung an und prüfen Sie sie:

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434

ss sollte jetzt 127.0.0.1:11434 anzeigen. Wenn weiterhin 0.0.0.0 angezeigt wird, hat eine zweite Drop-in-Datei Vorrang. Führen Sie systemctl cat ollama.service aus, um die Unit und alle Drop-in-Dateien einschließlich ihrer Pfade aufzulisten, und löschen Sie die veraltete Datei.

Um das Modell von Ihrem Laptop aus zu verwenden, leiten Sie den Port über SSH weiter:

ssh -N -L 11434:127.0.0.1:11434 you@your-server

-L 11434:127.0.0.1:11434 öffnet Port 11434 auf Ihrem Laptop und sendet alle dort eingehenden Daten an 127.0.0.1:11434, aus Sicht des Servers. -N weist SSH an, keinen Remote-Befehl auszuführen. Der Prozess hält dadurch lediglich den Tunnel offen. Solange der Tunnel läuft, funktioniert dies auf Ihrem Laptop:

curl -s http://localhost:11434/api/tags

Dabei treten zwei Fehler häufig auf. bind [127.0.0.1]:11434: Address already in use bedeutet, dass auf Ihrem Laptop bereits ein eigenes Ollama auf diesem Port läuft. Wählen Sie mit -L 11500:127.0.0.1:11434 einen anderen lokalen Port und richten Sie Ihren Client auf 11500. Eine leere Antwort über einen erfolgreich aufgebauten Tunnel bedeutet, dass SSH funktioniert, Ollama jedoch auf der Serverseite nicht lauscht. Prüfen Sie dort zunächst ss, bevor Sie den SSH-Befehl ändern.

Für mehrere Clientcomputer ist ein privates Netzwerk besser geeignet als ein Tunnel pro Benutzer. Binden Sie die Computer in WireGuard oder Tailscale ein. Binden Sie Ollama anschließend an seine Adresse in diesem Netzwerk und nicht an 0.0.0.0:

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

Der Port ist dann nur auf einer Schnittstelle vorhanden, für deren Nutzung ein kryptografischer Schlüssel erforderlich ist. Diese Konfiguration schützt auch vor einem fehlerhaften Firewall-Eintrag. Selbst wenn eine Regel versehentlich den gesamten Datenverkehr zulässt, kann sie keinen Listener auf einer öffentlichen Schnittstelle erreichbar machen, auf der dieser nicht gebunden ist.

Defence 2: ein Reverse Proxy, der ein Bearer-Token prüft

Wenn etwas aus dem öffentlichen Internet das Modell aufrufen muss, lassen Sie Ollama auf dem Loopback-Interface laufen und schalten Sie einen Proxy davor. Der Proxy übernimmt die TLS-Terminierung (Transport Layer Security) und weist Anfragen ohne den richtigen Header zurück. Ollama akzeptiert weiterhin nur Verbindungen von 127.0.0.1. Der Proxy ist damit der einzige Zugangsweg.

Erzeugen Sie zuerst ein echtes Token. Erfinden Sie keines von Hand:

openssl rand -base64 36

Eine nginx-Site, die das Token prüft:

map $http_authorization $ollama_ok {
    default                                   0;
    "Bearer PASTE_YOUR_GENERATED_TOKEN_HERE"  1;
}

server {
    listen 443 ssl;
    server_name llm.example.com;

    ssl_certificate     /etc/letsencrypt/live/llm.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/llm.example.com/privkey.pem;

    location = /api/pull   { return 403; }
    location = /api/delete { return 403; }
    location = /api/push   { return 403; }

    location / {
        if ($ollama_ok = 0) { return 401; }

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host 127.0.0.1:11434;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

Die fünf Zeilen darin erledigen wichtige Aufgaben. Jede davon verhindert einen Fehler, der sonst auftreten würde.

if innerhalb eines location-Blocks ist in nginx normalerweise keine gute Idee. Ein Body mit genau return ist jedoch eine von zwei Formen, die sich vorhersehbar verhalten. Diese Verwendung ist daher sicher.

location = /api/pull ist eine exakte Übereinstimmung. nginx bewertet exakte Übereinstimmungen höher als das location /-Präfix. Daher werden diese drei Endpunkte abgelehnt, bevor das Token überhaupt geprüft wird. Ein gültiges Token ermöglicht anschließend Inference, nicht jedoch, die Festplatte zu füllen.

proxy_set_header Host 127.0.0.1:11434; ist wichtig, weil Ollama die eingehenden Header Host und Origin auswertet. Wenn der öffentliche Hostname des Proxy unverändert weitergereicht wird, kann ein 403 Forbidden entstehen, das von Ollama statt von nginx stammt. Das erschwert die Fehlersuche. OLLAMA_ORIGINS ist der andere wichtige Parameter. Er wird für Browser-Clients benötigt, die einen bestimmten zulässigen Ursprung voraussetzen.

proxy_buffering off; ist wichtig, weil Ollama seine Antwort Token für Token streamt. Bei aktiviertem Buffering hält nginx den Stream zurück und liefert ihn erst am Ende vollständig aus. Ihr Client wirkt dann während der gesamten Generierung eingefroren.

proxy_read_timeout 600s; ist wichtig, weil nginx standardmäßig 60 Sekunden verwendet. Eine lange Generierung auf der CPU überschreitet diesen Wert leicht. Der Client erhält 504 Gateway Time-out, und /var/log/nginx/error.log protokolliert upstream timed out (110: Connection timed out) while reading response header from upstream. Die Anfrage wurde weiterhin verarbeitet. nginx hat sie lediglich abgebrochen.

Laden Sie die Konfiguration neu und testen Sie beide Pfade:

sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
curl -s -H "Authorization: Bearer YOUR_TOKEN" https://llm.example.com/api/tags

Der erste Befehl sollte 401 ausgeben. Der zweite sollte Ihre Modellliste ausgeben. Wenn der erste Befehl ebenfalls die Modellliste zurückgibt, befindet sich der map-Block im falschen Gültigkeitsbereich. Er gehört auf die Ebene http. Platzieren Sie ihn daher in einer Datei unter /etc/nginx/conf.d/ oder oberhalb des server-Blocks, niemals innerhalb von server.

Caddy erledigt dieselbe Aufgabe mit einer auf vier Zeilen verteilten Basisauthentifizierung. Das eignet sich für einen Browser-Client besser als ein Bearer-Token:

llm.example.com {
	basic_auth {
		apiuser PASTE_BCRYPT_HASH_HERE
	}
	reverse_proxy 127.0.0.1:11434
}

Führen Sie caddy hash-password aus, um den erwarteten bcrypt-Hash zu erzeugen. Beachten Sie eine wichtige Umbenennung: Die Direktive hieß vor Caddy v2.8 basicauth und heißt jetzt basic_auth. Eine aus einer älteren Anleitung kopierte Konfiguration wird daher nicht geladen, und Caddy nennt die nicht erkannte Direktive.

Unabhängig vom gewählten Proxy handelt es sich um ein gemeinsames Geheimnis für alle. Jeder Client, der es besitzt, hat identischen Zugriff. Zum Widerrufen müssen Sie die Konfiguration ändern und gleichzeitig jeden Aufrufer aktualisieren.

Verteidigung 3: ein Gateway, das Schlüssel pro Client ausstellt

Sobald mehr als eine Person oder Anwendung das Modell aufruft, reicht ein gemeinsames Token nicht mehr aus. Sie können nicht feststellen, welcher Client die Last verursacht hat, und Sie können nicht nur einen Client sperren, ohne alle anderen ebenfalls zu sperren. Ein Gateway übernimmt den Platz des Proxy und verwendet dieselbe OpenAI-kompatible API. Es stellt pro Client einen eigenen Schlüssel aus und protokolliert, welche Nutzung auf den jeweiligen Schlüssel entfällt. Ein selbst gehostetes LiteLLM-Gateway ist dafür die übliche Lösung. Zusätzlich zur Zugriffskontrolle bietet es Budgets pro Schlüssel und Anforderungsprotokolle.

Die Regel aus Verteidigung 1 bleibt unverändert. Ollama bindet an 127.0.0.1. Nur das Gateway kommuniziert mit Ollama, und nur das Gateway ist ein Dienst mit einem öffentlich erreichbaren Listener. Ein Gateway auf einem System, auf dem Port 11434 weiterhin für das gesamte Internet offen ist, ist wirkungslos, weil Clients es einfach umgehen können.

Die Firewall-Falle: Ein veröffentlichter Container-Port umgeht UFW

Deshalb sind auf Servern erreichbare Instanzen vorhanden, obwohl ihre Betreiber die Firewall korrekt konfiguriert haben.

UFW (uncomplicated firewall) schreibt seine Regeln in die INPUT-Kette der filter-Tabelle des Kernels. INPUT verarbeitet Pakete, die an den Host selbst adressiert sind. Das -p-Flag von Docker schreibt eine Destination-NAT-Regel (network address translation) in die PREROUTING-Kette der nat-Tabelle. Der Kernel wertet diese Regel aus, bevor er entscheidet, wohin das Paket geleitet wird. Wenn die Routing-Entscheidung erfolgt, wurde das Ziel bereits in die Adresse des Containers umgeschrieben. Das Paket wird daher weitergeleitet, statt lokal zugestellt zu werden, und durchläuft FORWARD statt INPUT. Die INPUT-Regeln von UFW werden nie geprüft. Das Paket umgeht die Firewall daher, statt sie zu durchlaufen.

Deshalb lässt diese Abfolge Port 11434 aus dem Internet erreichbar:

sudo ufw default deny incoming
sudo ufw enable
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

und sudo ufw status meldet weiterhin eine aktive Firewall mit standardmäßiger Ablehnung. Beide Ausgaben sind gleichzeitig korrekt. Genau deshalb verlassen sich viele auf die falsche Ausgabe. Die dafür verantwortliche Regel sehen Sie mit:

sudo iptables -t nat -L DOCKER -n

Die Korrektur besteht aus einer Adresse im Publish-Flag:

docker rm -f ollama
docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama

-p 11434:11434 ist eine Kurzform für -p 0.0.0.0:11434:11434. Durch die Angabe von 127.0.0.1 wird die Host-Seite der Zuordnung an das Loopback-Interface gebunden. Dadurch erreichen Ihr SSH-Tunnel und Ihr Reverse Proxy den Dienst weiterhin, während er aus dem Internet nicht erreichbar ist. Das erneute Erstellen des Containers ist hier sicher, weil die Modelle im benannten ollama-Volume und nicht im Container gespeichert sind.

Bestätigen Sie, dass beide Ansichten übereinstimmen:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama sollte 11434/tcp -> 127.0.0.1:11434 ausgeben. Wenn 0.0.0.0:11434 ausgegeben wird, ist der Dienst weiterhin aus dem Internet erreichbar. Wenn Sie den Mechanismus einmal verstanden haben, gilt er für jeden Container, den Sie veröffentlichen: warum veröffentlichte Docker-Ports UFW umgehen erklärt die DOCKER-USER-Kette und die Regeln, die einen Docker-Neustart überstehen. Wenn Sie die Host-Richtlinien noch erstellen, beschreibt die UFW-Regeln, die ein neuer VPS benötigt die Grundlage dafür.

Als welcher Benutzer läuft der Prozess

Das Linux-Installationsskript erstellt ein dediziertes Konto und führt den Dienst unter diesem Konto aus:

useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama

Die Unit unter /etc/systemd/system/ollama.service setzt anschließend User=ollama und Group=ollama. Ändern Sie diese Einstellungen nicht. Ein per ollama serve manuell in einem Terminal gestarteter Prozess läuft unter dem Benutzer, mit dem Sie sich angemeldet haben. Ist das root, schreibt eine nicht authentifizierte API Dateien als root. Prüfen Sie, welcher Fall vorliegt:

ps -o user= -C ollama

Die Ausgabe sollte ollama lauten. Jede andere Ausgabe bedeutet, dass neben der Unit oder an ihrer Stelle ein manuell gestarteter Prozess läuft. Dasselbe gilt für jeden später hinzugefügten Daemon. Dienste mit Benutzern mit den geringsten erforderlichen Rechten ausführen setzt dieses Prinzip korrekt um.

So prüfen Sie, ob der Ollama-API-Endpunkt sicher ist

Unabhängig von Ihrer Konfiguration gibt es einen eindeutigen Test. Er muss von einem anderen Rechner ausgeführt werden:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tags

Beide Anfragen sollten mit einem Timeout abbrechen oder abgewiesen werden. Wenn Sie einen Proxy eingerichtet haben, sollten dieselben beiden Pfade über den Proxy-Hostnamen ohne Zugangsdaten 401 und mit Zugangsdaten gültiges JSON zurückgeben.

Lesen Sie anschließend einmal das Access-Log. Daraus geht hervor, ob jemand den Port gefunden hat, während er offen war:

journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1

Ollama schreibt eine Zeile pro Anfrage und enthält darin die Client-Adresse:

[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"

Jede Zeile sollte einmal 127.0.0.1 anzeigen, sobald Ollama an loopback gebunden ist. Das ist dann die einzige Adresse, von der eine Verbindung kommen kann. Eine öffentliche Adresse in dieser Spalte weist auf eine Anfrage von außerhalb hin. Der Zeitstempel zeigt, wann sie eingegangen ist. Die gewünschte Ausgabe dieses Befehls ist überhaupt keine Ausgabe. Wenn dieses Thema für Sie neu ist, beschreibt Ollama auf einem VPS ausführen die Installation, die Auswahl der Modellgröße und die Speichergrenzen, die bestimmen, welches Modell tatsächlich geladen werden kann.

FAQ

Verfügt Ollama über einen API-Schlüssel oder ein Passwort?

Nein. Der von Ihnen ausgeführte Server hat keinerlei Authentifizierung. In der offiziellen Dokumentation steht, dass für den Zugriff auf die API keine Authentifizierung erforderlich ist. Die beiden Dinge, die als „Ollama API key“ bezeichnet werden, dienen anderen Zwecken. Das Ed25519-Schlüsselpaar in /usr/share/ollama/.ollama/ weist Ihren Rechner gegenüber ollama.com aus, damit Sie Modelle bereitstellen und private Modelle abrufen können. OLLAMA_API_KEY ist ein Zugangstoken, das Ihr Client an die gehostete API unter https://ollama.com/api sendet. Ihr eigenes ollama serve liest keines von beiden. Die Zugriffskontrolle muss daher über das Netzwerk oder einen vorgeschalteten Proxy erfolgen.

Ist OLLAMA_HOST=0.0.0.0 sicher, wenn ich eine Firewall habe?

Nur solange nichts anderes auf diesem Rechner Firewall-Regeln schreibt. 0.0.0.0 bedeutet, dass der Listener tatsächlich auf der öffentlichen Schnittstelle vorhanden ist und Sie ausschließlich darauf vertrauen, dass die Firewall ihn unerreichbar hält. Dieses Vertrauen endet, sobald Docker einen Port veröffentlicht. Die von Docker zur Tabelle nat hinzugefügte DNAT-Regel wird ausgewertet, bevor das Paket die Kette INPUT erreicht, in der UFW arbeitet. Das Paket wird daher weitergeleitet, und UFW sieht es nie. Durch das Binden an 127.0.0.1 oder an eine private Tunneladresse wird der Listener von der öffentlichen Schnittstelle entfernt. Ein Fehler in der Firewall kann dann nichts mehr nach außen freigeben.

Wie prüfe ich, ob mein Ollama-Port aus dem Internet erreichbar ist?

Führen Sie auf dem Server sudo ss -tlnp | grep 11434 und auf einem anderen Rechner curl -m 5 http://YOUR_SERVER_IP:11434/api/version aus. Wenn ss 127.0.0.1:11434 anzeigt und der entfernte curl-Aufruf mit einem Timeout endet, ist das die gewünschte Kombination. Wenn ss 0.0.0.0:11434 oder *:11434 anzeigt und der entfernte curl-Aufruf JSON zurückgibt, ist die gesamte API erreichbar. Testen Sie niemals mit curl direkt auf dem Server. Loopback antwortet unabhängig davon, an welche Adresse der Dienst gebunden ist.

Kann ich den Port einfach von 11434 auf einen zufälligen Port ändern?

Nein. Der Grund ist wichtig. Ein anderer Port verlangsamt nur den Scan dieses einzelnen Ports. Scanner prüfen den gesamten Portbereich. Eine Anfrage an /api/tags identifiziert den Dienst unabhängig davon, an welchem Port sie eingegangen ist. Das Ändern des Ports bricht außerdem die Standardkonfiguration aller Clients und erschwert später die Fehlersuche in Ihrer eigenen Umgebung. Binden Sie den Dienst stattdessen an Loopback. Dadurch wird der Listener entfernt und nicht nur an einen anderen Port verschoben.

Jemand hat meine offene Ollama-Instanz erreicht. Was sollte ich prüfen?

Binden Sie sie zuerst an 127.0.0.1 und starten Sie den Dienst neu. Dadurch wird die externe Erreichbarkeit beendet, bevor Sie mit der Untersuchung beginnen. Führen Sie anschließend journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 aus, um zu sehen, welche externen Adressen welche Endpunkte zu welcher Zeit aufgerufen haben. Vergleichen Sie ollama list mit den Modellen, die vorhanden sein sollten. /api/pull ist nicht authentifiziert. Ein Modell, das Sie nicht abgerufen haben, belegt daher Speicherplatz und ist zugleich ein Hinweis auf den Vorfall. Prüfen Sie den freien Speicherplatz mit df -h. Ollama protokolliert auf der Standardprotokollstufe keinen Prompt-Text. Sie sehen daher, wer welches Modell angefragt hat, aber nicht, was generiert wurde.

#ollama#security#api#firewall#reverse-proxy