SSD Nodes Learn 🎉 VPS $5.50/aydan başlayan
Rehberler Matt ConnorYazan Matt Connor

Ollama API guvenlik acigi ve parola korumasi nasil yapilir

Ollama sunucusu varsayilan olarak kimlik dogrulama icermez. 11434 numarali port uzerinden herkes modellerinizi calistirabilir veya silebilir. Guvenligi saglamak icin uc adimli yontem.

Ollama API parola korumasına sahip değildir

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

Resmi dokümantasyon bunu açıkça belirtir: "Ollama API'sine http://localhost:11434 üzerinden yerel olarak erişilirken kimlik doğrulama gerekmez." Yerel ifadesi tüm güvenlik modelini kapsar. Ollama varsayılan olarak 127.0.0.1 adresine bağlanır; bu nedenle dizüstü bilgisayarlarda loopback arayüzü erişim kontrolü 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 kontrolü 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, ikinci bir makinenin modeli kullanabilmesi için dinleyiciyi dış dünyaya açma işlemi, tüm korumayı aynı anda kaldıran değişikliktir.

Açık bir 11434 numaralı port neleri açığa çıkarır

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

Operasyonel açıdan dört temel sorun ortaya çıkar:

  • CPU veya GPU'nuz başkası için çıkarım (inference) işlemleri yürütür. 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 zor hale gelir.
  • /api/pull diskinize yazma işlemi yapar. Modellerin her biri iki ila kırk gigabayt arasındadır. Sürekli model çekme (pull) döngüsü disk alanını doldurur ve disk dolduğunda sadece Ollama değil, sunucudaki diğer tüm servisler de ç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; bu nedenle istemin (prompt) metnini değil, uç noktayı, durumu, gecikme süresini ve istemci adresini görürsünüz. Bu yine de sunucunuzu kimin ve ne için kullandığının bir kaydıdır, günlüğünüzde tutulur ve bunu toplama tercihini siz yapmamışsınızdır.
  • /api/delete modelleri siler. Onları geri almak, 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ı giderir.

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

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

Bu anahtar dışarıya dönüktür. ollama signin, anahtarın açık kısmını ollama.com hesabınızla ilişkilendirir; bu, bir modeli kayıt defterine (registry) göndermeniz veya özel bir modeli çekmeniz için sizi yetkilendiren şeydir. Makinenizi ollama.com'a tanıtır. 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 bunu Authorization: Bearer $OLLAMA_API_KEY olarak gönderir. Bu, onların hizmeti için bir kimlik bilgisidir ve sizin tarafınızdan istemci olarak kullanılır. Kendi ollama serve servisiniz 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 adreslerini temsil eder. *:11434 ve [::]:11434 ifadeleri, IPv6 dahil aynı anlama gelir.

Şimdi dışarıdan doğrulama yapın. Bu komutu 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 erişilebilir 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. İlki, başka bir makinenin modele erişmesi gerektiği için yapılan bilinçli 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ın kaynağıdır. İkinci yol ise Docker'dır ve herhangi bir düzenleme yapmanızı gerektirmez. Bununla ilgili detaylar aşağıdaki bölümde yer almaktadır.

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

Bunu ilk seçenek olarak değerlendirin. 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 (public interface) var olmaz, bu nedenle tarama işlemleri onu bulamaz.

Varsayılan ayarlara 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, ikinci bir drop-in dosyası öncelik kazanıyor demektir. Birimi ve tüm drop-in dosyalarını yollarıyla 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 komutu dizüstü bilgisayarınızda 11434 numaralı portu açar ve oraya gelen her şeyi sunucu tarafından görüldüğü şekliyle 127.0.0.1:11434 adresine iletir. -N parametresi 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 kurulan bir tünel üzerinden boş yanıt alıyorsanız, SSH çalışıyor ancak Ollama sunucu tarafında dinleme yapmıyor demektir; 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 kurmaktan 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 gerektiren bir arayüzde var olur. Bu yöntem bir güvenlik duvarı hatasına karşı da 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 denetleyen 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 (header) sahip olmayan istekleri reddeder. Ollama yalnızca 127.0.0.1 üzerinden gelen bağlantıları kabul ettiğinden, proxy tek giriş yoludur.

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

openssl rand -base64 36

Bunu denetleyen bir nginx 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.

Bir location bloğu içindeki if kullanımı nginx'te genellikle kötü bir fikirdir, ancak tam olarak return gövdesi öngörülebilir şekilde davranan iki biçimden 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 bile değerlendirilmeden reddedilir. Geçerli bir token, disk alanınızı doldurma yetkisi değil, yalnızca çıkarım (inference) yapma 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ı (hostname) doğrudan iletmek, nginx yerine Ollama'dan gelen bir 403 Forbidden üretilmesine neden olabilir; bu da hata ayıklamayı zorlaştırır. OLLAMA_ORIGINS, belirli bir kaynağa (origin) izin verilmesi gereken tarayıcı istemcileri için kullanılan diğer araçtı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 istemcinizin 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 süren bir üretim bu süreyi kolayca aşar, istemci 504 Gateway Time-out hatası alır ve /var/log/nginx/error.log, upstream timed out (110: Connection timed out) while reading response header from upstream kaydını düşer. İstek aslında çalışmaya devam ediyordu ancak nginx isteği sonlandırdı.

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 yazdırmalıdır. Eğer ilki de model listesini döndürüyorsa, map bloğu yanlış kapsamdadır. Bu blok http seviyesine aittir, 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, dört satırda temel kimlik doğrulama (basic authentication) ile aynı işi yapar; bu, tarayıcı istemcileri için bearer token kullanımından daha uygundur:

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üklenmeyecek ve Caddy tanımadığı yönergeyi belirtecektir.

Hangi proxy'yi seçerseniz seçin, bu herkes için paylaşılan tek bir gizli anahtardır. Buna sahip her istemci aynı erişim yetkisine sahiptir; 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 konumda bir ağ geçidi (gateway) konumlandırılır; 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 kontrolünün yanı sıra anahtar bazlı bütçe yönetimi ve istek günlükleri tutma imkanı 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ü çağrı yapanlar ağ geçidini kolayca devre dışı bırakabilir.

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

Düzgün yapılandırılmış bir güvenlik duvarına sahip sunucularda bile dışarıya açık örneklerin bulunmasının nedeni budur.

UFW (uncomplicated firewall), kurallarını çekirdeğin INPUT zincirine, filter tablosuna yazar ve INPUT, doğrudan ana makineye yönlendirilen paketleri işler. Docker'ın -p bayrağı, hedef NAT (network address translation) kuralını nat tablosunun PREROUTING zincirine yazar; çekirdek, paketin nereye gideceğine karar vermeden önce bu kuralı değerlendirir. Yönlendirme kararı alındığında hedef zaten container adresine dönüştürülmüş durumdadır; bu nedenle paket yerel olarak teslim edilmek yerine iletilir ve INPUT yerine FORWARD üzerinden geçer. UFW'nin INPUT kurallarına hiçbir zaman başvurulmaz, bu yüzden paket güvenlik duvarının içinden değil, etrafından dolaşır.

İşte bu dizinin 11434 numaralı portu internete açık bırakmasının nedeni budur:

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 hala güvenlik duvarının varsayılan reddetme kuralıyla aktif olduğunu raporlar. Her iki okuma da aynı anda doğrudur; insanların yanlış olana güvenmesinin tam 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ısaltmadır. 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, adlandırılmış ollama volume içinde tutulur.

Her iki görünümün de aynı fikirde 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ışarıya açıksınız demektir. Mekanizmayı bir kez öğrenin; yayınladığınız her container için geçerli olacaktır: Docker yayınlanan portlarının neden UFW'yi atladığı konusu, DOCKER-USER zincirini ve Docker yeniden başlatıldığında hayatta kalan kuralları kapsar. Eğer hala ana makine politikasını oluşturuyorsanız, yeni bir VPS'in ihtiyaç duyduğu UFW kuralları konusu, bu yapının temelini oluşturan kuralları kapsar.

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, giriş yaptığınız kullanıcı kimliğiyle çalışır; eğer bu kullanıcı root ise, kimlik doğrulaması yapılmamış bir API dosyaları root yetkisiyle yazar. Hangi kullanıcının çalıştığını kontrol edin:

ps -o user= -C ollama

Alınan 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 geçerlidir ve servisleri en düşük yetkili kullanıcılarla çalıştırma rehberi bu konuyu detaylıca ele alır.

Ollama API uç noktasının güvenli olduğu nasıl doğrulanır

Hangi yöntemi seçerseniz seçin, durumu netleştiren tek bir test vardır ve bu testin başka bir makine üzerinden ç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 makine 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; bu günlük, port açıkken herhangi birinin portu keşfedip keşfetmediğini size söyleyecektir:

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ırda 127.0.0.1 görünmelidir; çünkü bağlantının gelebileceği tek adres budur. Bu sütunda genel bir IP adresi görünmesi, dışarıdan bir istek geldiği anlamına gelir ve zaman damgası size bunun ne zaman gerçekleştiğini gösterir. 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 bir API anahtarına veya parolaya sahip mi?

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 gerekmediğini belirtir. "Ollama API key" olarak adlandırılan iki kavram da farklı işlevlere sahiptir. /usr/share/ollama/.ollama/ içindeki Ed25519 çifti, model yükleyebilmeniz (push) ve özel modelleri çekebilmeniz (pull) 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 denetimi ağ katmanından veya ön tarafa yerleştirilen bir proxy üzerinden sağlanmalıdır.

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

Yalnızca o makinede 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 var 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. 127.0.0.1 adresine veya özel bir tünel adresine bağlama yapmak, 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örmek ve uzak makinedeki 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örmek ve uzak makinedeki curl isteğinin JSON döndürmesi, API'nin tamamen erişilebilir olduğu anlamına gelir. Asla sunucunun kendisinde curl ile test 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 belirtilmelidir. 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 porttan gelirse gelsin servisi tanımlar. Portu değiştirmek ayrıca tüm istemci varsayılanlarını bozar ve kendi kurulumunuzun mantığını daha sonra anlamanızı zorlaştırır. Bunun yerine loopback adresine bağlama yapın; bu, 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ın ve yeniden başlatın; böylece incelemeye başlamadan önce dış erişimi durdurmuş olursunuz. Ardından hangi dış adreslerin hangi uç noktalara ne zaman istek attığını 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 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 ne üretildiğine dair bir kayıt bulunmaz.

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