SSD Nodes Learn 🎉 VPS od $5.50/mies.
Przewodniki Matt ConnorAutor: Matt Connor

Jak zabezpieczyć API Ollama przed nieautoryzowanym

Domyślna konfiguracja Ollama na porcie 11434 nie posiada uwierzytelniania. Dowiedz się, jak zabezpieczyć serwer przed zdalnym uruchamianiem modeli za pomocą trzech metod.

Interfejs API Ollama nie posiada hasła

Interfejs API Ollama nie posiada mechanizmów uwierzytelniania. W uruchomionym serwerze nie ma użytkowników, haseł, weryfikacji kluczy ani list dozwolonych adresów. Każdy podmiot, który może nawiązać połączenie TCP z portem 11434, może wyświetlić listę modeli, uruchamiać je, pobierać nowe oraz usuwać istniejące.

Oficjalna dokumentacja stwierdza to wprost: "Podczas lokalnego dostępu do API Ollama przez http://localhost:11434 nie jest wymagane uwierzytelnianie". Słowo lokalnie stanowi fundament całego modelu bezpieczeństwa. Domyślnie Ollama nasłuchuje na 127.0.0.1, więc w przypadku laptopa interfejs loopback pełni rolę kontroli dostępu. Przeniesienie nasłuchiwania na publiczny adres IP powoduje utratę tej kontroli, ponieważ nie wprowadzono żadnego mechanizmu zastępczego.

Dlatego kwestia ta jest istotna w przypadku serwerów VPS (virtual private server). Ustawienia domyślne są bezpieczne. Pierwsza zmiana, którą wprowadza większość użytkowników – otwarcie nasłuchiwania w celu udostępnienia modelu innej maszynie – jest jednocześnie działaniem, które całkowicie usuwa wszelkie zabezpieczenia.

Co ujawnia otwarty port 11434

Każdy punkt końcowy. Nie istnieje tryb tylko do odczytu ani oddzielny port administracyjny. Poniżej przedstawiono rzeczywiste żądania, skierowane na adres serwera zamiast na localhost:

# 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"}'

Z perspektywy operatora, cztery kwestie stanowią problem:

  • Procesor CPU lub GPU wykonuje wnioskowanie dla osób trzecich. W planach z limitem wykorzystania CPU, ciągłe obciążenie oznacza, że Twój limit jest wyczerpywany przez nieznajomego, a kontrola kosztów obciążeń AI na VPS staje się znacznie trudniejsza, gdy nie jesteś jedynym użytkownikiem.
  • /api/pull zapisuje dane na dysku. Modele zajmują od dwóch do czterdziestu gigabajtów każdy. Pętla pobierania zapełnia wolumen, a pełny dysk powoduje awarię wszystkich pozostałych usług na serwerze, nie tylko Ollama.
  • Żądania trafiają do procesu i są rejestrowane. Przy domyślnym poziomie logowania Ollama zapisuje tylko metadane, więc otrzymujesz punkt końcowy, status, opóźnienie i adres klienta, a nie treść promptu. Jest to jednak zapis tego, kto korzystał z serwera i w jakim celu, przechowywany w dzienniku, którego nie planowałeś gromadzić.
  • /api/delete usuwa modele. Ich odzyskanie oznacza ponowne pobranie przez Twoje łącze.

Nic z powyższych nie wymaga wykorzystania luki w zabezpieczeniach. Jest to udokumentowane API działające dokładnie zgodnie z projektem.

Klucz Ed25519 nie służy do kontroli dostępu

Wyszukanie frazy "Ollama API key" prowadzi do dwóch różnych zagadnień. Żadne z nich nie jest hasłem do serwera, a ich rozróżnienie eliminuje większość niejasności.

Pierwszym jest para kluczy tożsamości. Ollama generuje parę kluczy Ed25519 przy pierwszym uruchomieniu. W systemie Linux skrypt instalacyjny tworzy użytkownika systemowego o nazwie ollama z katalogiem domowym w /usr/share/ollama, więc para kluczy znajduje się tutaj:

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

Ten klucz jest skierowany na zewnątrz. ollama signin rejestruje część publiczną w koncie ollama.com i to ona autoryzuje wypychanie modelu do rejestru lub pobieranie modelu prywatnego. Potwierdza ona tożsamość maszyny wobec ollama.com. Nie wymaga ona niczego od klientów łączących się z maszyną. Usunięcie, rotacja lub brak utworzenia tego klucza nie zmienia zasad dostępu do API.

Drugim jest OLLAMA_API_KEY. Ta zmienna przechowuje klucz utworzony w https://ollama.com/settings/keys, który klient przesyła jako Authorization: Bearer $OLLAMA_API_KEY podczas wywoływania hostowanego API pod adresem https://ollama.com/api. Jest to poświadczenie dla ich usługi, używane przez użytkownika w roli klienta. Własna instancja ollama serve nigdy go nie odczytuje. Ustawienie OLLAMA_API_KEY na VPS nie nakłada hasła na VPS.

Nie istnieje zatem żadne ustawienie, które można włączyć. Poniższe trzy metody ochrony działają w ten sam sposób: należy utrzymać port w stanie niedostępnym z zewnątrz i umieścić przed nim komponent, który faktycznie weryfikuje dostęp.

Sprawdź, na jakich portach nasłuchuje serwer

sudo ss -tlnp | grep 11434

Bezpieczny wynik wskazuje na adres pętli zwrotnej (loopback):

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

Wynik wskazujący na wystawienie usługi wymienia wszystkie interfejsy:

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

0.0.0.0 oznacza wszystkie adresy IPv4 na maszynie, w tym adres publiczny. *:11434 oraz [::]:11434 oznaczają to samo z uwzględnieniem protokołu IPv6.

Teraz zweryfikuj dostępność z zewnątrz. Wykonaj poniższe polecenie na komputerze lokalnym, a nie na serwerze:

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

curl: (28) Connection timed out after 5001 milliseconds to pożądany wynik, podobnie jak curl: (7) Failed to connect ... Connection refused. Obiekt JSON zawierający pole version oznacza, że całe API jest dostępne dla każdego, kto wyśle zapytanie. Testowanie za pomocą curl bezpośrednio na serwerze nie jest miarodajne, ponieważ interfejs loopback odpowiada zawsze.

Wystawienie usługi na świat zazwyczaj wynika z jednej z dwóch przyczyn. Pierwszą jest celowa edycja konfiguracji, gdy zaistniała potrzeba uzyskania dostępu do modelu z innej maszyny:

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

Ta pojedyncza linia odpowiada za pełne wystawienie usługi. Drugą przyczyną jest Docker, który nie wymaga edycji żadnych plików konfiguracyjnych. Temat ten został omówiony w poniższej sekcji.

Obrona 1: utrzymanie na localhost i tunelowanie

Zastosuj to rozwiązanie jako pierwsze. Nie wymaga ono instalacji dodatkowego oprogramowania i nie tworzy poświadczeń, które mogłyby wyciec. Port nie istnieje na interfejsie publicznym, więc skanowanie go nie wykryje.

Ustaw adres powiązania jawnie, zamiast polegać na wartości domyślnej:

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

To zapisuje /etc/systemd/system/ollama.service.d/override.conf. Zastosuj zmiany i sprawdź:

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

ss powinno teraz wskazywać 127.0.0.1:11434. Jeśli nadal widnieje 0.0.0.0, oznacza to, że nadrzędny jest drugi plik typu drop-in. Uruchom systemctl cat ollama.service, aby wyświetlić jednostkę wraz ze wszystkimi plikami drop-in i ich ścieżkami, a następnie usuń nieaktualny plik.

Aby korzystać z modelu z laptopa, przekieruj port przez SSH:

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

-L 11434:127.0.0.1:11434 otwiera port 11434 na laptopie i przesyła cały ruch do 127.0.0.1:11434 z perspektywy serwera. -N instruuje SSH, aby nie wykonywało zdalnego polecenia, dzięki czemu proces utrzymuje tunel otwarty. Gdy tunel działa, poniższe polecenie na laptopie zadziała:

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

Napotkasz dwie typowe awarie. bind [127.0.0.1]:11434: Address already in use oznacza, że na laptopie działa własna instancja Ollama na tym porcie; wybierz inny port lokalny za pomocą -L 11500:127.0.0.1:11434 i skieruj klienta na 11500. Pusta odpowiedź przez poprawnie nawiązany tunel oznacza, że SSH działa, ale Ollama nie nasłuchuje po stronie serwera; sprawdź ss na serwerze przed modyfikacją polecenia SSH.

W przypadku wielu maszyn klienckich sieć prywatna jest lepsza niż osobny tunel dla każdego użytkownika. Umieść maszyny w sieci WireGuard lub Tailscale, a następnie powiąż Ollama z adresem w tej sieci zamiast z 0.0.0.0:

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

Port istnieje wtedy tylko na interfejsie, do którego dostęp wymaga klucza. Rozwiązanie to chroni również przed błędami w konfiguracji firewalla, ponieważ reguła, która przypadkowo otwiera dostęp dla całego świata, nadal nie ujawni usługi, która nie nasłuchuje na interfejsie publicznym.

Obrona 2: reverse proxy sprawdzający token bearer

Gdy usługa z publicznego internetu musi wywołać model, należy pozostawić Ollama na interfejsie loopback i umieścić przed nią proxy. Proxy dokonuje terminacji TLS (transport layer security) i odrzuca żądania bez poprawnego nagłówka. Ollama nadal akceptuje połączenia wyłącznie z 127.0.0.1, więc proxy stanowi jedyną drogę dostępu.

Najpierw należy wygenerować właściwy token. Nie należy tworzyć go ręcznie:

openssl rand -base64 36

Konfiguracja nginx sprawdzająca token:

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;
    }
}

Pięć linii wykonuje tu kluczową pracę, a każda z nich zapobiega awarii, która wystąpiłaby w przeciwnym razie.

Użycie if wewnątrz bloku location jest w nginx zazwyczaj niewskazane, jednak ciało o długości dokładnie return jest jedną z dwóch form zachowujących się przewidywalnie, więc to zastosowanie jest bezpieczne.

location = /api/pull to dopasowanie dokładne, a nginx stawia dopasowania dokładne wyżej niż prefiks location /, więc dostęp do tych trzech endpointów jest odmawiany, zanim token zostanie w ogóle sprawdzony. Poprawny token uprawnia do wnioskowania, a nie do zapełnienia dysku.

proxy_set_header Host 127.0.0.1:11434; jest istotne, ponieważ Ollama sprawdza przychodzące nagłówki Host oraz Origin. Przekazywanie publicznej nazwy hosta proxy bezpośrednio może skutkować otrzymaniem 403 Forbidden pochodzącego z Ollama, a nie z nginx, co utrudnia debugowanie. OLLAMA_ORIGINS to drugi mechanizm, przydatny dla klienta przeglądarkowego wymagającego zezwolenia na konkretne źródło (origin).

proxy_buffering off; jest istotne, ponieważ Ollama przesyła odpowiedź strumieniowo, token po tokenie. Przy włączonym buforowaniu nginx wstrzymuje strumień i dostarcza go w całości dopiero na końcu, przez co klient sprawia wrażenie zawieszonego przez cały czas generowania.

proxy_read_timeout 600s; jest istotne, ponieważ domyślny limit nginx wynosi 60 sekund. Długie generowanie na CPU łatwo przekracza ten czas, klient otrzymuje 504 Gateway Time-out, a /var/log/nginx/error.log odnotowuje upstream timed out (110: Connection timed out) while reading response header from upstream. Żądanie nadal było przetwarzane, ale nginx przerwał oczekiwanie.

Przeładuj i przetestuj obie ścieżki:

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

Pierwsza powinna zwrócić 401. Druga powinna wyświetlić listę modeli. Jeśli pierwsza również zwraca listę modeli, blok map znajduje się w niewłaściwym zakresie. Powinien znajdować się na poziomie http, więc należy umieścić go w pliku wewnątrz /etc/nginx/conf.d/ lub powyżej bloku server, nigdy wewnątrz server.

Caddy wykonuje to samo zadanie przy użyciu uwierzytelniania podstawowego (basic authentication) w czterech liniach, co w przypadku klienta przeglądarkowego sprawdza się lepiej niż token bearer:

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

Uruchom caddy hash-password, aby wygenerować oczekiwany skrót bcrypt. Pułapka nazewnictwa: dyrektywa nazywała się basicauth przed wersją Caddy v2.8, a obecnie nazywa się basic_auth, więc konfiguracja skopiowana ze starszego poradnika nie zostanie załadowana, a Caddy wskaże nierozpoznaną dyrektywę.

Niezależnie od wybranego proxy, jest to jeden wspólny sekret dla wszystkich. Każdy klient posiadający go ma identyczny dostęp, a jego unieważnienie wymaga edycji konfiguracji i jednoczesnej aktualizacji wszystkich klientów.

Obrona 3: bramka wydająca klucze dla każdego klienta

Gdy z modelu korzysta więcej niż jedna osoba lub aplikacja, współdzielony token przestaje wystarczać. Nie można określić, który klient generuje obciążenie, ani odciąć dostępu jednemu z nich bez blokowania pozostałych. Bramka (gateway) umieszczona w miejscu, w którym znajdowało się proxy, obsługuje to samo API zgodne z OpenAI, wydaje osobny klucz dla każdego klienta i rejestruje zużycie dla każdego z nich. Samodzielnie hostowana bramka LiteLLM jest standardowym rozwiązaniem, które oprócz kontroli dostępu dodaje budżety dla poszczególnych kluczy oraz logi żądań.

Zasada z obrony 1 pozostaje niezmienna. Ollama wiąże się z 127.0.0.1, bramka jest jedynym procesem, który się z nią komunikuje, i jedyną usługą nasłuchującą publicznie. Bramka na serwerze, na którym port 11434 pozostaje otwarty dla świata, jest jedynie dekoracją, ponieważ klienci mogą ją łatwo ominąć.

Pułapka firewalla: opublikowany port kontenera omija UFW

Oto przyczyna, dla której wystawione instancje istnieją na serwerach, których właściciele poprawnie skonfigurowali firewall.

UFW (uncomplicated firewall) zapisuje swoje reguły w łańcuchu INPUT tabeli filter jądra systemu, a INPUT obsługuje pakiety kierowane bezpośrednio do hosta. Flaga -p Dockera zapisuje regułę docelowego NAT (network address translation) w łańcuchu PREROUTING tabeli nat, którą jądro analizuje przed podjęciem decyzji o trasowaniu pakietu. W momencie podejmowania decyzji o trasowaniu, adres docelowy został już nadpisany na adres kontenera, więc pakiet jest przekazywany (forwarded), a nie dostarczany lokalnie, przez co przechodzi przez FORWARD zamiast INPUT. Reguły INPUT w UFW nigdy nie są sprawdzane, więc pakiet omija firewall zamiast przez niego przechodzić.

Dlatego poniższa sekwencja pozostawia port 11434 otwarty na świat:

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

a sudo ufw status nadal raportuje, że firewall jest aktywny z domyślną polityką odrzucania (deny). Oba odczyty są jednocześnie poprawne, co jest dokładnie powodem, dla którego użytkownicy ufają błędnemu z nich. Można sprawdzić regułę, która za to odpowiada:

sudo iptables -t nat -L DOCKER -n

Rozwiązaniem jest podanie adresu we flagach publikacji:

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 to skrót od -p 0.0.0.0:11434:11434. Wskazanie 127.0.0.1 wiąże stronę hosta mapowania z interfejsem loopback, dzięki czemu tunel SSH oraz reverse proxy nadal mają dostęp do usługi, a Internet nie. Odtworzenie kontenera jest w tym przypadku bezpieczne, ponieważ modele znajdują się w nazwanym wolumenie ollama, a nie wewnątrz kontenera.

Należy potwierdzić, że oba widoki są zgodne:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama powinno wyświetlić 11434/tcp -> 127.0.0.1:11434. Jeśli wyświetli 0.0.0.0:11434, usługa nadal jest wystawiona. Zrozumienie tego mechanizmu raz pozwala stosować go do każdego publikowanego kontenera: dlaczego opublikowane porty Dockera omijają UFW omawia łańcuch DOCKER-USER oraz reguły, które przetrwają restart usługi Docker. Jeśli dopiero budujesz politykę bezpieczeństwa hosta, reguły UFW wymagane dla nowego VPS opisują fundamenty, na których opiera się ta konfiguracja.

Z jakim użytkownikiem uruchomiony jest proces

Skrypt instalacyjny systemu Linux tworzy dedykowane konto i uruchamia usługę w jego kontekście:

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

Jednostka w /etc/systemd/system/ollama.service ustawia następnie User=ollama oraz Group=ollama. Nie należy zmieniać tych ustawień. Szybkie polecenie ollama serve uruchomione ręcznie w terminalu działa z uprawnieniami użytkownika, który jest zalogowany. Jeśli jest to root, nieautoryzowane API zapisuje pliki jako root. Należy sprawdzić, który użytkownik jest właścicielem procesu:

ps -o user= -C ollama

Wynikiem powinno być ollama. Każda inna wartość oznacza, że ręcznie uruchomiony proces działa równolegle lub zamiast jednostki systemowej. Ta sama zasada dotyczy każdego demona dodawanego w przyszłości, a uruchamianie usług z uprawnieniami najmniejszego przywileju szczegółowo wyjaśnia to zagadnienie.

Jak sprawdzić, czy punkt końcowy API Ollama jest zabezpieczony

Niezależnie od wybranej metody, jeden test rozstrzyga kwestię bezpieczeństwa i musi zostać wykonany z innej maszyny:

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

Oba polecenia powinny zwrócić błąd przekroczenia czasu lub odmowy połączenia. Jeśli skonfigurowano proxy, te same dwie ścieżki dla nazwy hosta proxy powinny zwracać 401 bez poświadczeń oraz poprawny kod JSON po ich podaniu.

Następnie należy jednorazowo przejrzeć dziennik dostępu, ponieważ informuje on, czy ktokolwiek wykrył port w czasie, gdy był on otwarty:

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

Ollama zapisuje jeden wiersz dla każdego żądania i uwzględnia adres klienta:

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

Każdy wiersz powinien wskazywać 127.0.0.1, gdy Ollama jest powiązana z interfejsem loopback, ponieważ jest to jedyny adres, z którego może nadejść połączenie. Publiczny adres w tej kolumnie oznacza żądanie z zewnątrz, a znacznik czasu wskazuje moment wystąpienia zdarzenia. Brak danych wyjściowych po wykonaniu tego polecenia jest pożądanym rezultatem. Jeśli kwestie związane z modelami są nowe, uruchamianie Ollama na VPS zawiera informacje o instalacji, doborze rozmiaru modelu oraz limitach pamięci, które decydują o tym, co faktycznie zostanie załadowane.

FAQ

Czy Ollama posiada klucz API lub hasło?

Nie. Uruchamiany serwer nie posiada żadnego mechanizmu uwierzytelniania, a oficjalna dokumentacja wskazuje, że dostęp do API nie wymaga autoryzacji. Oba elementy określane mianem "Ollama API key" służą do innych celów. Para kluczy Ed25519 w /usr/share/ollama/.ollama/ uwierzytelnia maszynę w serwisie ollama.com, co umożliwia wysyłanie modeli oraz pobieranie modeli prywatnych. OLLAMA_API_KEY to poświadczenie wysyłane przez klienta do hostowanego API pod adresem https://ollama.com/api. Własna instancja ollama serve nie odczytuje żadnego z nich, dlatego kontrola dostępu musi zostać zaimplementowana na poziomie sieci lub poprzez proxy umieszczone przed usługą.

Czy OLLAMA_HOST=0.0.0.0 jest bezpieczne, jeśli korzystam z firewalla?

Tylko dopóki żadne inne oprogramowanie nie modyfikuje reguł firewalla na danej maszynie. 0.0.0.0 oznacza, że proces nasłuchujący jest faktycznie dostępny na publicznym interfejsie, a bezpieczeństwo opiera się wyłącznie na założeniu, że firewall zablokuje niepożądany ruch. To założenie przestaje być prawdziwe w momencie, gdy Docker publikuje port, ponieważ reguła DNAT dodawana przez Dockera do tablicy nat jest przetwarzana przed dotarciem pakietu do łańcucha INPUT, w którym działa UFW. W rezultacie pakiet jest przekazywany, a UFW go nie widzi. Powiązanie usługi z adresem 127.0.0.1 lub prywatnym adresem tunelu usuwa proces nasłuchujący z publicznego interfejsu, dzięki czemu błąd w konfiguracji firewalla nie powoduje wystawienia usługi na zewnątrz.

Jak sprawdzić, czy port Ollama jest otwarty na świat?

Uruchom sudo ss -tlnp | grep 11434 na serwerze oraz curl -m 5 http://YOUR_SERVER_IP:11434/api/version z innej maszyny. Wynik ss wskazujący na 127.0.0.1:11434 przy jednoczesnym przekroczeniu czasu oczekiwania (timeout) zdalnego polecenia curl to pożądany stan. Wynik ss wskazujący na 0.0.0.0:11434 lub *:11434, podczas gdy zdalny curl zwraca JSON, oznacza, że pełne API jest dostępne. Nigdy nie testuj połączenia za pomocą curl bezpośrednio na serwerze, ponieważ interfejs loopback odpowiada niezależnie od tego, na jakim adresie nasłuchuje usługa.

Czy mogę zmienić port z 11434 na inny, losowy?

Nie, a powód jest istotny. Zmiana portu nie spowalnia niczego poza skanowaniem pojedynczego portu. Skanery sprawdzają cały zakres, a jedno żądanie do /api/tags identyfikuje usługę niezależnie od portu, na który trafiło. Zmiana portu powoduje również problemy z domyślnymi ustawieniami klientów i utrudnia późniejszą analizę konfiguracji. Zamiast przenosić usługę, należy powiązać ją z adresem loopback, co usuwa proces nasłuchujący z publicznej sieci.

Ktoś uzyskał dostęp do mojej otwartej instancji Ollama. Co powinienem sprawdzić?

W pierwszej kolejności powiąż usługę z adresem 127.0.0.1 i zrestartuj ją, aby przerwać ekspozycję przed rozpoczęciem analizy. Następnie uruchom journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1, aby sprawdzić, które zewnętrzne adresy wywoływały poszczególne endpointy i w jakim czasie. Porównaj ollama list z listą modeli, które powinny znajdować się na serwerze, ponieważ /api/pull nie wymaga uwierzytelnienia, a obecność nieautoryzowanego modelu oznacza zarówno zajętość miejsca na dysku, jak i dowód naruszenia. Sprawdź wolne miejsce za pomocą df -h. Ollama nie rejestruje treści zapytań przy domyślnym poziomie logowania, więc w dziennikach znajdziesz informację o tym, kto i o jaki model pytał, ale nie o tym, co zostało wygenerowane.

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