Von Ollama API ohne Passwort: Port 11434 absichern
Ollama bietet standardmäßig keine Authentifizierung. Wer Port 11434 erreicht, kann Modelle auflisten, ausführen, herunterladen und löschen. Drei Schutzmaßnahmen erklärt.
Die Ollama API hat kein Passwort
Die Ollama API verfügt über keine Authentifizierung. Auf dem von Ihnen betriebenen Server gibt es weder einen Benutzer noch ein Passwort, keine Schlüsselprüfung und keine Allowlist. Alles, was eine TCP-Verbindung zu Port 11434 herstellen kann, kann Ihre Modelle auflisten, sie ausführen, neue Modelle herunterladen und vorhandene Modelle löschen.
Die offizielle Dokumentation sagt es eindeutig: „Für den lokalen Zugriff auf die Ollama API über http://localhost:11434 ist keine Authentifizierung erforderlich.“ Das Wort lokal definiert 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 (Virtual Private Server) wichtig. Die Standardeinstellung ist sicher. Die erste Änderung, die viele vornehmen, besteht darin, den Listener zu öffnen, 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 Read-only-Modus und keinen separaten Admin-Port. Dies sind die tatsächlichen Requests, die an eine Serveradresse statt an localhost gesendet werden:
# 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 Fair-Use-Limit für CPU-Leistung wird die anhaltende Last von einem Fremden auf Ihr Kontingent angerechnet. Die Kosten für AI-Workloads auf einem VPS unter Kontrolle zu halten wird deutlich schwieriger, sobald Sie nicht mehr der einzige Aufrufer sind.
/api/pullschreibt auf Ihre Festplatte. Modelle sind jeweils zwei bis vierzig Gigabyte groß. Eine Folge von Pulls füllt das Volume. Ein volles Laufwerk legt alle anderen Dienste auf dem System lahm, nicht nur Ollama.- Requests erreichen Ihren Prozess und werden protokolliert. Bei der Standard-Logstufe protokolliert Ollama nur Metadaten. Sie erhalten also den Endpunkt, den Status, die Latenz und die Clientadresse, nicht den Prompt-Text. Das ist trotzdem ein Protokoll darüber, wer Ihr System verwendet und wofür. Es liegt in Ihrem Journal, obwohl Sie sich nicht dafür entschieden haben, diese Daten zu erfassen.
/api/deleteentfernt 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 dient nicht der Zugriffskontrolle
Wenn Sie nach „Ollama API key“ suchen, stoßen Sie auf zwei unterschiedliche Dinge. Keines davon ist ein Passwort für Ihren Server. Wenn Sie beide auseinanderhalten, 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 liegt daher hier:
/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pubDieser Schlüssel wird für ausgehende Verbindungen verwendet. ollama signin registriert den öffentlichen Teil bei Ihrem ollama.com-Konto. Der Schlüssel autorisiert Sie außerdem dazu, 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, ist er nicht relevant. 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. Der Schlüssel ist eine Zugangsdaten für deren Dienst und wird von Ihnen als Client verwendet. Ihr eigenes ollama serve liest ihn nie. Wenn Sie OLLAMA_API_KEY auf Ihrem VPS setzen, wird dadurch kein Passwort für Ihren VPS eingerichtet.
Sie müssen daher keine Einstellung aktivieren. Die drei folgenden Schutzmaßnahmen funktionieren alle nach demselben Prinzip: Der Port bleibt nicht erreichbar, und davor wird eine Komponente platziert, die den Zugriff prüft.
Prüfen, worauf Ihr Server aktuell lauscht
sudo ss -tlnp | grep 11434Das 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 steht für alle IPv4-Adressen auf dem System, 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 Befehl auf Ihrem Laptop aus, nicht auf dem Server:
curl -m 5 http://YOUR_SERVER_IP:11434/api/versioncurl: (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 version-Feld bedeutet, dass die gesamte API für jeden erreichbar ist, der eine Anfrage stellt. Ein Test mit curl direkt auf dem Server beweist nichts, weil die Loopback-Schnittstelle immer antwortet.
Die Exponierung erfolgt normalerweise auf eine von zwei Arten. Die erste ist eine absichtliche Änderung, weil ein zweiter Rechner auf das Modell zugreifen musste:
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"Diese einzelne Zeile verursacht die gesamte Exponierung. Die zweite Möglichkeit ist Docker. Dafür müssen Sie überhaupt keine Datei bearbeiten. Diese Möglichkeit hat unten einen eigenen Abschnitt.
Abwehr 1: Deny it on localhost and tunnel it hinein
Verwenden Sie diese Methode zuerst. Sie benötigt keine neue Software und erstellt keine Zugangsdaten, die nach außen gelangen könnten. 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 11434ss 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 alles, was dort eintrifft, an 127.0.0.1:11434, gesehen vom Server aus. -N weist SSH an, keinen entfernten Befehl auszuführen. Der Prozess hält dadurch lediglich den Tunnel offen. Solange der Tunnel läuft, funktioniert auf Ihrem Laptop Folgendes:
curl -s http://localhost:11434/api/tagsZwei Fehler werden Ihnen begegnen. 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 daher mit -L 11500:127.0.0.1:11434 einen anderen lokalen Port und richten Sie Ihren Client auf 11500. Eine leere Antwort über einen Tunnel, der problemlos hergestellt wurde, bedeutet, dass SSH funktioniert, Ollama aber 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 als ein Tunnel pro Person. Verbinden Sie die Computer über WireGuard oder Tailscale und binden Sie Ollama dann an die Adresse dieses Netzwerks statt 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. Das schützt auch vor einem Fehler in der Firewall-Konfiguration, weil selbst eine Regel, die versehentlich den gesamten Internetverkehr zulässt, keinen Listener auf einer öffentlichen Schnittstelle freigeben kann, auf der dieser nicht vorhanden ist.
Abwehr 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 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, daher ist der Proxy der einzige Zugangsweg.
Erzeugen Sie zuerst ein echtes Token. Erfinden Sie keines von Hand:
openssl rand -base64 36Eine 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;
}
}Fünf Zeilen darin übernehmen die entscheidende Funktion. 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 exakt return ist jedoch eine von zwei Formen, die sich vorhersehbar verhalten. Diese Verwendung ist daher sicher.
location = /api/pull ist ein exakter Abgleich. nginx bewertet exakte Abgleiche höher als das location /-Präfix. Daher werden diese drei Endpunkte abgewiesen, bevor das Token überhaupt geprüft wird. Ein gültiges Token ermöglicht anschließend Inferenz, aber nicht das vollständige Belegen Ihrer Festplatte.
proxy_set_header Host 127.0.0.1:11434; ist wichtig, weil Ollama die eingehenden Host- und Origin-Header auswertet. Wenn der öffentliche Hostname des Proxy unverändert weitergegeben wird, kann ein 403 Forbidden entstehen, das von Ollama statt von nginx stammt. Das erschwert die Fehlersuche. OLLAMA_ORIGINS ist der andere relevante Parameter. Er wird von einem Browser-Client benötigt, der eine bestimmte erlaubte Origin voraussetzt.
proxy_buffering off; ist wichtig, weil Ollama seine Antwort Token für Token streamt. Bei aktivierter Pufferung 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 problemlos. 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 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/tagsDer erste Befehl sollte 401 ausgeben. Der zweite sollte Ihre Modellliste ausgeben. Wenn der erste ebenfalls die Modellliste zurückgibt, befindet sich der map-Block im falschen Gültigkeitsbereich. Er gehört auf der http-Ebene abgelegt. 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 einfachen Authentifizierung in vier Zeilen. Für einen Browser-Client ist das meist geeigneter 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 Benennungsfalle: 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. Caddy nennt dabei die Direktive, die es nicht erkannt hat.
Unabhängig davon, für welchen Proxy Sie sich entscheiden, handelt es sich um ein gemeinsames Geheimnis für alle. Jeder Client, der es besitzt, hat identischen Zugriff. Das Widerrufen erfordert Änderungen an der Konfiguration und gleichzeitig eine Aktualisierung jedes aufrufenden Clients.
Abwehr 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 keinen einzelnen Client sperren, ohne alle anderen ebenfalls zu sperren. Ein Gateway übernimmt die Position des Proxys, verwendet dieselbe OpenAI-kompatible API, 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 Abwehr 1 bleibt unverändert. Ollama bindet an 127.0.0.1, nur das Gateway kommuniziert mit Ollama, und nur das Gateway stellt einen öffentlich erreichbaren Listener bereit. Ein Gateway auf einem System, auf dem Port 11434 weiterhin weltweit offen ist, ist wirkungslos, weil Clients es einfach umgehen können.
Die Firewall-Falle: Ein veröffentlichter Container-Port umgeht UFW
Deshalb gibt es exponierte Instanzen auf Servern, deren Betreiber die Firewall korrekt konfiguriert haben.
UFW (uncomplicated firewall) schreibt seine Regeln in die INPUT-Chain der filter-Tabelle des Kernels. INPUT verarbeitet Pakete, die an den Host selbst adressiert sind. Das Docker-Flag -p schreibt eine Destination-NAT-Regel (Network Address Translation) in die PREROUTING-Chain der nat-Tabelle. Der Kernel wertet diese Regel aus, bevor er entscheidet, wohin das Paket weitergeleitet wird. Wenn die Routing-Entscheidung erfolgt, wurde das Ziel bereits auf 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 ausgewertet. 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/ollamaAußerdem meldet sudo ufw status die Firewall weiterhin als aktiv und mit einer Standardregel zum Verwerfen. Beide Anzeigen sind gleichzeitig korrekt. Genau deshalb verlassen sich viele auf die falsche Anzeige. Die dafür verantwortliche Regel lässt sich so anzeigen:
sudo iptables -t nat -L DOCKER -nDie 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. Mit 127.0.0.1 wird die Host-Seite der Zuordnung an Loopback gebunden. Dadurch erreichen Ihr SSH-Tunnel und Ihr Reverse Proxy den Dienst weiterhin, das Internet jedoch nicht. Das erneute Erstellen des Containers ist hier sicher, weil die Modelle im benannten ollama-Volume und nicht im Container gespeichert sind.
Prüfen Sie, ob beide Ansichten übereinstimmen:
docker port ollama
sudo ss -tlnp | grep 11434docker port ollama sollte 11434/tcp -> 127.0.0.1:11434 ausgeben. Wenn 0.0.0.0:11434 ausgegeben wird, ist der Dienst weiterhin exponiert. Wenn Sie den Mechanismus einmal verstanden haben, können Sie ihn auf jeden Container anwenden, den Sie veröffentlichen: warum veröffentlichte Docker-Ports UFW umgehen erklärt die DOCKER-USER-Chain und die Regeln, die einen Docker-Neustart überstehen. Wenn Sie die Host-Richtlinie selbst noch erstellen, beschreibt die UFW-Regeln für einen neuen VPS die Grundlage, auf der diese Konfiguration aufbaut. Auf Rocky oder AlmaLinux gibt es kein UFW, das Sie konfigurieren könnten. Beginnen Sie dort stattdessen mit dieser Grundlage mit firewalld.
Unter welchem Benutzerkonto läuft der Prozess?
Das Linux-Installationsskript erstellt ein eigenes Benutzerkonto und führt den Dienst darunter aus:
useradd -r -s /bin/false -U -m -d /usr/share/ollama ollamaDie Unit unter /etc/systemd/system/ollama.service setzt anschließend User=ollama und Group=ollama. Ändern Sie diese Konfiguration nicht. Ein manuell in einem Terminal gestartetes ollama serve läuft unter dem Benutzerkonto, mit dem Sie angemeldet sind. Ist das root, schreibt eine nicht authentifizierte API Dateien als root. Prüfen Sie das Benutzerkonto:
ps -o user= -C ollamaDas Ergebnis sollte ollama sein. Jedes andere Ergebnis bedeutet, dass neben der Unit oder an ihrer Stelle ein manuell gestarteter Prozess läuft. Dasselbe gilt für jeden weiteren Daemon, den Sie später hinzufügen. Dienste mit Benutzerkonten und den geringsten erforderlichen Berechtigungen 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/tagsBeide Anfragen sollten mit einem Timeout abbrechen oder abgewiesen werden. Wenn Sie einen Proxy eingerichtet haben, sollten dieselben beiden Pfade über den Hostnamen des Proxys ohne Anmeldedaten 401 zurückgeben und mit Anmeldedaten gültiges JSON liefern.
Lesen Sie anschließend einmal das Access-Log. Daraus geht hervor, ob jemand den Port gefunden hat, während er geöffnet war:
journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1Ollama schreibt eine Zeile pro Anfrage und nimmt die Client-Adresse auf:
[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"Nach der Bindung von Ollama an das Loopback-Interface sollte jede Zeile genau einmal 127.0.0.1 anzeigen, weil eine Verbindung dann nur von dieser Adresse kommen kann. Eine öffentliche Adresse in dieser Spalte bedeutet, dass die Anfrage von außerhalb kam. Der Zeitstempel zeigt, wann dies geschah. Wenn der Befehl überhaupt keine Ausgabe liefert, ist das das gewünschte Ergebnis. Wenn dieser Teil für Sie neu ist, behandelt 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. Die offizielle Dokumentation erklärt außerdem, dass für den Zugriff auf die API keine Authentifizierung erforderlich ist. Beide Dinge, die als „Ollama API key“ bezeichnet werden, dienen einem anderen Zweck. Das Ed25519-Schlüsselpaar in /usr/share/ollama/.ollama/ weist Ihren Rechner gegenüber ollama.com aus, damit Sie Modelle hochladen und private Modelle herunterladen können. OLLAMA_API_KEY ist ein Anmeldedatensatz, den 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 verwende?
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 sich allein darauf verlassen, dass die Firewall ihn unerreichbar hält. Dieses Vertrauen ist nicht mehr gerechtfertigt, 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. Wenn Sie an 127.0.0.1 oder an eine private Tunneladresse binden, wird der Listener von der öffentlichen Schnittstelle entfernt. Ein Fehler in der Firewall kann den Dienst dann nicht mehr offenlegen.
Wie prüfe ich, ob mein Ollama-Port aus dem Internet erreichbar ist?
Führen Sie sudo ss -tlnp | grep 11434 auf dem Server und curl -m 5 http://YOUR_SERVER_IP:11434/api/version von einem anderen Rechner aus. ss mit der Anzeige 127.0.0.1:11434 und einem Timeout bei curl vom entfernten Rechner liefern zusammen das gewünschte Ergebnis. Wenn ss 0.0.0.0:11434 oder *:11434 anzeigt und curl vom entfernten Rechner JSON zurückgibt, ist die vollständige 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 beliebigen anderen Port verschieben?
Nein. Der Grund dafür ist wichtig. Ein anderer Port verlangsamt nur einen Scan dieses einzelnen Ports. Scanner prüfen den gesamten Portbereich. Eine Anfrage an /api/tags identifiziert den Dienst unabhängig davon, über welchen Port sie eingegangen ist. Das Verschieben des Ports bricht außerdem die Standardwerte aller Clients und erschwert es später, die eigene Konfiguration nachzuvollziehen. Binden Sie den Dienst stattdessen an Loopback. Dadurch entfernen Sie den Listener, anstatt ihn nur zu verschieben.
Jemand hat meinen offenen Ollama-Dienst erreicht. Was sollte ich prüfen?
Binden Sie ihn zunächst an 127.0.0.1 und starten Sie den Dienst neu. So beenden Sie die Offenlegung, 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 welchen Zeitpunkten aufgerufen haben. Vergleichen Sie ollama list mit den Modellen, die vorhanden sein sollten. /api/pull ist nicht authentifiziert, und ein Modell, das Sie nicht heruntergeladen haben, belegt Speicherplatz und ist zugleich ein Hinweis auf den Vorfall. Prüfen Sie den freien Speicherplatz mit df -h. Ollama protokolliert auf der standardmäßigen Protokollebene keinen Prompt-Text. Sie haben daher einen Nachweis darüber, wer welches Modell angefordert hat, nicht darüber, was erzeugt wurde.