SSD Nodes Learn Hosting plans →
Rehberler Matt ConnorYazan Matt Connor · Güncellendi 2026-08-27

Ollama API guvenlik acigi nasil kapatilir?

Ollama sunucusu varsayilan olarak 11434 portunda kimlik dogrulamasi olmadan calisir. Yetkisiz erisimi engellemek ve sunucunuzu korumak icin uygulayabileceginiz uc etkili yontem.

Ollama API parola korumasına sahip değildir

Ollama API kimlik doğrulama mekanizması içermez. Çalıştırdığınız sunucuda kullanıcı, parola, anahtar denetimi veya izin verilenler listesi bulunmaz. 11434 numaralı porta TCP bağlantısı kurabilen herhangi bir istemci, modellerinizi listeleyebilir, çalıştırabilir, yenilerini indirebilir ve mevcut olanları silebilir.

Resmi belgelerde bu durum açıkça belirtilmiştir: "Ollama API'sine http://localhost:11434 üzerinden yerel olarak erişilirken kimlik doğrulaması gerekmez." Yerel ifadesi, tüm güvenlik modelini tanımlar. Ollama varsayılan olarak 127.0.0.1 adresine bağlanır; bu nedenle bir dizüstü bilgisayarda loopback arayüzü erişim denetimi işlevi görür. Dinleyiciyi genel bir IP adresine taşıdığınızda, yerini alacak başka bir mekanizma bulunmadığı için erişim denetimi tamamen ortadan kalkar.

Bu durumun bir VPS (sanal özel sunucu) üzerinde kritik olmasının nedeni budur. Varsayılan yapılandırma güvenlidir. Çoğu kullanıcının yaptığı ilk değişiklik olan dinleyiciyi dış dünyaya açma işlemi, ikinci bir makinenin modeli kullanabilmesini sağlarken aynı zamanda tüm koruma katmanlarını da devre dışı bırakır.

Açık bir 11434 numaralı portun ifşa ettikleri

Her bir uç nokta. Salt okunur bir mod veya ayrı bir yönetici portu bulunmamaktadır. Bunlar, localhost yerine doğrudan sunucu adresine yönlendirilen gerçek isteklerdir:

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

Operatör açısından dört temel sorun ortaya çıkar:

  • CPU veya GPU'nuz başkası için çıkarım (inference) yapar. Adil kullanım CPU kotası olan bir planda, sürekli yük, kotanızın bir yabancı tarafından harcanması anlamına gelir ve bir VPS üzerinde yapay zeka iş yükü maliyetlerini kontrol altında tutmak, tek kullanıcı siz olmadığınızda çok daha zorlaşır.
  • /api/pull diskinize yazma işlemi yapar. Modellerin her biri iki ila kırk gigabayt arasındadır. Sürekli çekme (pull) döngüsü depolama alanını doldurur ve disk dolduğunda sadece Ollama değil, sunucudaki diğer tüm servisler çalışamaz hale gelir.
  • İstekler sürecinize ulaşır ve günlüğe kaydedilir. Varsayılan günlük seviyesinde Ollama yalnızca meta verileri kaydeder; yani istem metni değil, uç nokta, durum, gecikme süresi ve istemci adresi kaydedilir. Bu yine de sunucunuzu kimin, ne amaçla kullandığının bir kaydıdır ve sistem günlüğünüzde (journal) tutulur; üstelik bunu toplama tercihini siz yapmadınız.
  • /api/delete modelleri siler. Onları geri getirmek, kendi bant genişliğiniz üzerinden tekrar indirmek anlamına gelir.

Bunların hiçbiri bir istismar gerektirmez. Bu, belgelenmiş API'nin tasarlandığı gibi çalışmasından ibarettir.

Ed25519 anahtarı bir erişim denetimi değildir

"Ollama API key" araması yaptığınızda iki farklı sonuçla karşılaşırsınız. Bunların hiçbiri sunucunuz için bir parola değildir; aralarındaki farkı anlamak kafa karışıklığının büyük kısmını ortadan kaldırır.

Birincisi kimlik anahtar çiftidir. Ollama, ilk çalıştırıldığında bir Ed25519 anahtar çifti oluşturur. Linux üzerinde kurulum betiği, ev dizini /usr/share/ollama olan ollama adında bir sistem kullanıcısı oluşturur; dolayısıyla anahtar çifti burada bulunur:

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

Bu anahtar dışa dönüktür. ollama signin, anahtarın açık kısmını ollama.com hesabınızla ilişkilendirir; bu anahtar, kayıt defterine bir model yüklemenize veya özel bir modeli çekmenize olanak tanır. Makinenizi ollama.com nezdinde doğrular. Makinenize bağlanan istemcilerden herhangi bir şey talep etmez. Bu anahtarı silmek, değiştirmek veya hiç oluşturmamak, API'nizi kimin çağırabileceği konusunda hiçbir şeyi değiştirmez.

İkincisi OLLAMA_API_KEY değişkenidir. Bu değişken, https://ollama.com/settings/keys adresinde oluşturduğunuz bir anahtarı tutar ve istemciniz, https://ollama.com/api adresindeki barındırılan API'yi çağırırken bu anahtarı Authorization: Bearer $OLLAMA_API_KEY olarak gönderir. Bu, onların hizmeti için bir kimlik bilgisidir ve istemci olarak sizin tarafınızdan kullanılır. Kendi ollama serve sunucunuz bunu asla okumaz. VPS'nizde OLLAMA_API_KEY ayarını yapmak, VPS'nize bir parola koymaz.

Sonuç olarak, açılacak bir ayar bulunmamaktadır. Aşağıdaki üç savunma yöntemi de aynı şekilde çalışır: portu erişilemez tutun ve önüne denetim yapan bir katman yerleştirin.

Sunucunuzun şu anda hangi portları dinlediğini kontrol edin

sudo ss -tlnp | grep 11434

Güvenli sonuç, loopback adresini belirtir:

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

Açık sonuç, tüm arayüzleri listeler:

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

0.0.0.0 ifadesi, sunucudaki genel IP adresi dahil tüm IPv4 adresleri anlamına gelir. *:11434 ve [::]:11434 ifadeleri, IPv6 dahil aynı anlama gelir.

Şimdi dışarıdan doğrulama yapın. Bunu sunucuda değil, dizüstü bilgisayarınızda çalıştırın:

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

curl: (28) Connection timed out after 5001 milliseconds ve curl: (7) Failed to connect ... Connection refused, görmeniz gereken yanıtlardır. version alanını içeren bir JSON nesnesi, tüm API'nin talep eden herkese açık olduğu anlamına gelir. Sunucunun kendi üzerinde curl ile test yapmak hiçbir şeyi kanıtlamaz, çünkü loopback her zaman yanıt verir.

Erişime açıklık genellikle iki yolla gerçekleşir. Birincisi, başka bir makinenin modele erişmesi gerektiği için yapılan kasıtlı bir düzenlemedir:

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

Bu tek satır, tüm erişim açıklığını oluşturur. İkinci yol ise Docker'dır ve herhangi bir dosyayı düzenlemenizi gerektirmez. Bununla ilgili detaylar aşağıdaki bölümde yer almaktadır.

Savunma 1: localhost üzerinde tutun ve tünel ile erişin

İlk olarak bu yöntemi deneyin. Yeni bir yazılım gerektirmez ve sızdırılabilecek herhangi bir kimlik bilgisi oluşturmaz. Port hiçbir zaman genel bir arayüzde bulunmaz, bu nedenle tarama işlemleri onu tespit edemez.

Varsayılan değerlere güvenmek yerine bind adresini açıkça belirtin:

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

Bu işlem /etc/systemd/system/ollama.service.d/override.conf dosyasını yazar. Uygulayın ve kontrol edin:

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

ss artık 127.0.0.1:11434 değerini göstermelidir. Eğer hala 0.0.0.0 gösteriyorsa, başka bir drop-in dosyası öncelik kazanıyor demektir. Birimi ve tüm drop-in dosyalarını yollarıyla birlikte listelemek için systemctl cat ollama.service komutunu çalıştırın, ardından eski olanı silin.

Modeli dizüstü bilgisayarınızdan kullanmak için portu SSH üzerinden yönlendirin:

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

-L 11434:127.0.0.1:11434, dizüstü bilgisayarınızda 11434 numaralı portu açar ve buraya gelen her şeyi sunucu tarafından görüldüğü şekliyle 127.0.0.1:11434 adresine iletir. -N, SSH'e uzak bir komut çalıştırmamasını söyler, böylece süreç tüneli açık tutar. Bu süreç çalışırken dizüstü bilgisayarınızda şu komut işe yarar:

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

Karşılaşacağınız iki hata türü vardır. bind [127.0.0.1]:11434: Address already in use, dizüstü bilgisayarınızın o portta kendi Ollama örneğini çalıştırdığı anlamına gelir; bu durumda -L 11500:127.0.0.1:11434 ile farklı bir yerel port seçin ve istemcinizi 11500 portuna yönlendirin. Başarıyla bağlanan bir tünel üzerinden boş yanıt almanız, SSH'in çalıştığını ancak Ollama'nın sunucu tarafında dinleme yapmadığını gösterir; bu nedenle SSH komutuna dokunmadan önce sunucuda ss durumunu kontrol edin.

Birden fazla istemci makinesi için özel bir ağ, kişi başına bir tünel oluşturmaktan daha verimlidir. Makineleri WireGuard veya Tailscale ağına dahil edin, ardından Ollama'yı 0.0.0.0 yerine bu ağdaki kendi adresine bağlayın:

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

Bu durumda port, yalnızca katılmak için anahtar gereken bir arayüzde var olur. Bu yapı, bir güvenlik duvarı hatası durumunda bile koruma sağlar; çünkü yanlışlıkla tüm dünyaya izin veren bir kural bile, genel arayüzde bulunmayan bir dinleyiciyi dışarıya açamaz.

Savunma 2: bearer token kontrolü yapan bir reverse proxy

İnternet üzerinden bir servisin modele erişmesi gerektiğinde, Ollama'yı loopback üzerinde tutun ve önüne bir proxy yerleştirin. Proxy, TLS (transport layer security) sonlandırmasını yapar ve doğru başlığa sahip olmayan istekleri reddeder. Ollama bağlantıları yalnızca 127.0.0.1 üzerinden kabul ettiği için, tek giriş yolu proxy'dir.

Öncelikle gerçek bir token oluşturun. Elle oluşturmayın:

openssl rand -base64 36

Bunu kontrol eden bir nginx site yapılandırması:

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

Buradaki beş satır gerçek işi yapar ve her biri karşılaşabileceğiniz bir hatayı önler.

nginx içinde bir location bloğu içindeki if kullanımı genellikle kötü bir fikirdir, ancak tam olarak return gövdesi öngörülebilir şekilde davranan iki formdan biridir, bu yüzden bu kullanım güvenlidir.

location = /api/pull tam eşleşmedir ve nginx tam eşleşmeleri location / önekinden daha üstte tutar, bu nedenle bu üç uç nokta token kontrol edilmeden önce reddedilir. Geçerli bir token, diskinizi doldurma yetkisi değil, yalnızca çıkarım (inference) yetkisi sağlar.

proxy_set_header Host 127.0.0.1:11434; önemlidir çünkü Ollama gelen Host ve Origin başlıklarını inceler. Proxy'nin genel ana bilgisayar adını doğrudan iletmek, nginx yerine Ollama'dan gelen ve hata ayıklaması kafa karıştırıcı olan bir 403 Forbidden oluşturabilir. OLLAMA_ORIGINS, belirli bir kaynağa izin verilmesi gereken tarayıcı istemcileri için diğer kontrol mekanizmasıdır.

proxy_buffering off; önemlidir çünkü Ollama yanıtını token token yayınlar (stream). Tamponlama (buffering) açıkken, nginx akışı tutar ve sonunda tek parça halinde iletir, bu da istemcinin tüm üretim süreci boyunca donmuş gibi görünmesine neden olur.

proxy_read_timeout 600s; önemlidir çünkü nginx varsayılan olarak 60 saniye bekler. CPU üzerinde uzun bir üretim süreci bu süreyi kolayca aşar, istemci 504 Gateway Time-out alır ve /var/log/nginx/error.log, upstream timed out (110: Connection timed out) while reading response header from upstream kaydeder. İstek aslında hala çalışıyordur ancak nginx isteği sonlandırmıştır.

Yeniden yükleyin ve her iki yolu da test edin:

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

İlki 401 çıktısını vermelidir. İkincisi model listenizi listelemelidir. Eğer ilki de model listesini döndürüyorsa, map bloğu yanlış kapsamdadır. http seviyesinde olmalıdır, bu yüzden /etc/nginx/conf.d/ altındaki bir dosyaya veya server bloğunun üzerine yerleştirin, asla server içine koymayın.

Caddy, tarayıcı istemcileri için bearer token'dan daha uygun olan temel kimlik doğrulama (basic authentication) ile aynı işi dört satırda yapar:

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

Beklediği bcrypt hash değerini üretmek için caddy hash-password komutunu çalıştırın. Bir isimlendirme tuzağı: yönerge Caddy v2.8 öncesinde basicauth idi, şimdi ise basic_auth; bu nedenle eski bir kılavuzdan kopyalanan yapılandırma yüklenmeyi reddeder ve Caddy tanımadığı yönergeyi belirtir.

Hangi proxy'yi seçerseniz seçin, bu herkes için paylaşılan tek bir gizli anahtardır. Buna sahip olan her istemci aynı erişim haklarına sahiptir ve anahtarı iptal etmek, yapılandırmayı düzenlemek ve tüm istemcileri aynı anda güncellemek anlamına gelir.

Savunma 3: istemci başına anahtar düzenleyen bir ağ geçidi

Birden fazla kişi veya uygulama modele istek gönderdiğinde, paylaşımlı bir token yetersiz kalır. Hangi istemcinin yük oluşturduğunu tespit edemez ve birini engellemek istediğinizde hepsini engellemek zorunda kalırsınız. Proxy'nin bulunduğu noktaya bir ağ geçidi yerleştirilir; bu geçit, OpenAI uyumlu API ile aynı dili konuşur, her istemci için ayrı bir anahtar düzenler ve her anahtarın kullanımını kayıt altına alır. Self-hosted bir LiteLLM ağ geçidi bu durum için standart çözümdür; erişim denetimine ek olarak anahtar bazlı bütçe yönetimi ve istek günlükleri sağlar.

Savunma 1'deki kural değişmez. Ollama 127.0.0.1 adresine bağlanır, ağ geçidi onunla konuşan tek süreçtir ve ağ geçidi dış dünyaya açık olan tek servistir. 11434 numaralı portun dış dünyaya açık olduğu bir sunucuda ağ geçidi kullanmak sadece göstermeliktir; çünkü istemciler ağ geçidini kolayca devre dışı bırakıp doğrudan sunucuya erişebilir.

Güvenlik duvarı tuzağı: yayınlanan bir container portu UFW'yi atlar

Sunucu sahiplerinin güvenlik duvarını doğru yapılandırdıklarını düşündükleri halde dış dünyaya açık servislerle karşılaşmalarının nedeni budur.

UFW (uncomplicated firewall), kurallarını çekirdeğin INPUT zincirine, filter tablosuna yazar ve INPUT doğrudan ana makineye gelen paketleri işler. Docker'ın -p bayrağı, nat tablosunun PREROUTING zincirine bir hedef NAT (ağ adresi çevirisi) kuralı ekler; çekirdek, paketin nereye gideceğine karar vermeden önce bu kuralı değerlendirir. Yönlendirme kararı verildiğinde hedef çoktan container adresine dönüştürülmüş olur; bu nedenle paket yerel olarak teslim edilmek yerine iletilir ve INPUT yerine FORWARD üzerinden geçer. UFW'nin INPUT kuralları hiçbir zaman kontrol edilmez, dolayısıyla paket güvenlik duvarının içinden değil, etrafından dolaşır.

Bu nedenle aşağıdaki dizi, 11434 numaralı portu internete açık bırakır:

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

ve sudo ufw status, güvenlik duvarının varsayılan olarak reddetme (deny) kuralıyla aktif olduğunu bildirmeye devam eder. Her iki okuma da aynı anda doğrudur; insanların yanlış olana güvenmesinin temel nedeni de budur. Buna neden olan kuralı şu şekilde görebilirsiniz:

sudo iptables -t nat -L DOCKER -n

Çözüm, publish bayrağında tek bir adres belirtmektir:

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, -p 0.0.0.0:11434:11434 için kısa bir yazım şeklidir. 127.0.0.1 belirtmek, eşlemenin ana makine tarafını loopback arayüzüne bağlar; böylece SSH tüneliniz ve reverse proxy'niz servise erişebilir ancak internet erişemez. Container'ı yeniden oluşturmak burada güvenlidir çünkü modeller container içinde değil, isimlendirilmiş ollama volume içinde tutulur.

Her iki görünümün de uyumlu olduğunu doğrulayın:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama, 11434/tcp -> 127.0.0.1:11434 çıktısını vermelidir. Eğer 0.0.0.0:11434 çıktısını veriyorsa hala dış dünyaya açıksınız demektir. Mekanizmayı bir kez öğrenin; bu bilgi yayınladığınız her container için geçerlidir: Docker yayınlanan portlarının UFW'yi neden atladığı konusu, DOCKER-USER zincirini ve Docker yeniden başlatıldığında geçerliliğini koruyan kuralları açıklar. Eğer hala ana makine politikasını oluşturuyorsanız, yeni bir VPS'in ihtiyaç duyduğu UFW kuralları bu yapının temelini kapsar. Rocky veya AlmaLinux üzerinde yapılandırılacak bir UFW bulunmadığından, başlangıç için firewalld ile yazılmış aynı temel politika rehberine bakılmalıdır.

Süreç hangi kullanıcı ile çalışıyor

Linux kurulum betiği, özel bir hesap oluşturur ve servisi bu hesap altında çalıştırır:

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

/etc/systemd/system/ollama.service konumundaki birim dosyası, User=ollama ve Group=ollama değerlerini ayarlar. Bu ayarları değiştirmeyin. Terminalde elle başlatılan hızlı bir ollama serve, o an oturum açmış olan kullanıcı kimliğiyle çalışır; eğer bu kullanıcı root ise, kimlik doğrulaması yapılmamış bir API dosyaları root yetkisiyle yazar. Hangisinin çalıştığını kontrol edin:

ps -o user= -C ollama

Alınacak yanıt ollama olmalıdır. Bunun dışındaki herhangi bir sonuç, elle başlatılan bir sürecin birim dosyasıyla birlikte veya onun yerine çalıştığı anlamına gelir. Aynı mantık daha sonra ekleyeceğiniz tüm daemon süreçleri için de geçerlidir ve servisleri en düşük yetkili kullanıcılarla çalıştırma konusu bu süreci ayrıntılı olarak ele alır.

Ollama API uç noktasının güvenli olup olmadığı nasıl kontrol edilir

Hangi yöntemi seçerseniz seçin, tek bir test durumu netleştirir ve bu testin başka bir makineden çalıştırılması gerekir:

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

Her iki komut da zaman aşımına uğramalı veya bağlantıyı reddetmelidir. Eğer bir proxy kurduysanız, proxy ana bilgisayar adındaki aynı iki yol, kimlik bilgileri olmadan 401 döndürmeli, kimlik bilgileriyle ise gerçek JSON çıktısını vermelidir.

Ardından erişim günlüğünü bir kez inceleyin; çünkü bu günlük, port açıkken herhangi birinin portu keşfedip keşfetmediğini size bildirir:

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

Ollama her istek için bir satır yazar ve istemci adresini içerir:

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

Ollama loopback adresine bağlandığında her satır 127.0.0.1 değerini göstermelidir; çünkü bağlantının gelebileceği tek adres budur. Bu sütundaki genel bir IP adresi, dışarıdan gelen bir isteği temsil eder ve zaman damgası size isteğin ne zaman yapıldığını söyler. Bu komuttan hiçbir çıktı alınmaması, hedeflenen sonuçtur. Eğer model tarafı sizin için yeniyse, VPS üzerinde Ollama çalıştırma rehberi; kurulumu, model boyutlandırmayı ve nelerin yükleneceğini belirleyen bellek sınırlarını kapsamaktadır.

FAQ

Ollama'nın bir API anahtarı veya parolası var mı?

Hayır. Çalıştırdığınız sunucuda herhangi bir kimlik doğrulama mekanizması bulunmamaktadır ve resmi belgeler, API'ye erişmek için kimlik doğrulamanın gerekli olmadığını belirtir. "Ollama API anahtarı" olarak adlandırılan iki kavram da farklı bir amaca hizmet eder. /usr/share/ollama/.ollama/ içindeki Ed25519 anahtar çifti, model yükleyebilmeniz ve özel modelleri çekebilmeniz için makinenizi ollama.com üzerinde doğrular. OLLAMA_API_KEY ise istemcinizin https://ollama.com/api adresindeki barındırılan API'ye gönderdiği bir kimlik bilgisidir. Kendi ollama serve kurulumunuz bu anahtarların hiçbirini okumaz; bu nedenle erişim kontrolünün ağ seviyesinde veya ön taraftaki bir proxy üzerinden sağlanması gerekir.

Güvenlik duvarım varsa OLLAMA_HOST=0.0.0.0 güvenli midir?

Yalnızca o sunucuda başka hiçbir uygulama güvenlik duvarı kurallarını değiştirmediği sürece güvenlidir. 0.0.0.0, dinleyicinin gerçekten genel ağ arayüzünde mevcut olduğu anlamına gelir ve erişilemez kalması için yalnızca güvenlik duvarına güveniyorsunuz demektir. Docker bir portu dışarıya açtığı anda bu güven sarsılır; çünkü Docker'ın nat tablosuna eklediği DNAT kuralı, paket UFW'nin bulunduğu INPUT zincirine ulaşmadan önce değerlendirilir. Bu durumda paket iletilir ve UFW paketi asla görmez. Dinleyiciyi 127.0.0.1 adresine veya özel bir tünel adresine bağlamak, dinleyiciyi genel ağ arayüzünden kaldırır; böylece bir güvenlik duvarı hatası durumunda dışarıya açık bir nokta kalmaz.

Ollama portumun internete açık olup olmadığını nasıl kontrol ederim?

Sunucuda sudo ss -tlnp | grep 11434 komutunu, farklı bir makinede ise curl -m 5 http://YOUR_SERVER_IP:11434/api/version komutunu çalıştırın. ss çıktısında 127.0.0.1:11434 değerini görmeniz ve uzak makineden yapılan curl isteğinin zaman aşımına uğraması, beklenen sonuçtur. ss çıktısında 0.0.0.0:11434 veya *:11434 değerlerini görmeniz ve uzak makinedeki curl isteğinin JSON döndürmesi, API'nin tamamen erişilebilir olduğu anlamına gelir. Testi asla sunucunun kendisinde curl ile yapmayın; çünkü loopback adresi, bind adresinin ne olduğuna bakılmaksızın her isteğe yanıt verir.

Portu 11434 yerine rastgele bir portla değiştirebilir miyim?

Hayır, bunun nedeni oldukça nettir. Farklı bir port, tek bir portun taranması dışında hiçbir şeyi yavaşlatmaz. Tarayıcılar tüm port aralığını kontrol eder ve /api/tags adresine yapılacak tek bir istek, hangi portta gelirse gelsin servisi tanımlar. Portu değiştirmek ayrıca tüm istemci varsayılanlarını bozar ve kurulumunuzun ileride yönetilmesini zorlaştırır. Bunun yerine dinleyiciyi loopback adresine bağlayın; bu işlem dinleyiciyi başka bir yere taşımak yerine tamamen kaldırır.

Birisi açık olan Ollama sunucuma erişti. Neleri kontrol etmeliyim?

Öncelikle servisi 127.0.0.1 adresine bağlayıp yeniden başlatın; böylece incelemeye başlamadan önce dış erişimi kesin. Ardından hangi dış adreslerin, hangi uç noktalara ve ne zaman istek gönderdiğini görmek için journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 komutunu çalıştırın. ollama list listesini, sahip olmanız gereken modellerle karşılaştırın; çünkü /api/pull kimlik doğrulaması gerektirmez ve sizin çekmediğiniz bir model hem disk alanı kullanımı hem de bir kanıttır. df -h ile boş disk alanını kontrol edin. Ollama, varsayılan günlük seviyesinde istem metinlerini (prompt) kaydetmez; bu nedenle elinizde kimin hangi modeli sorguladığına dair bir kayıt bulunur, ancak üretilen içeriğe dair bir kayıt bulunmaz.

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