Ollama İnternete Açık mı? Yerel LLM Sunucusu Denetimi

Yerel LLM sunucusu neden internete açık kalır?

Yerel model sunucuları çoğunlukla tek kişilik geliştirme aracı olarak başlar. Ekip kullanımına geçerken başka makinelerden erişim gerekir ve en kısa yol seçilir. Açıklık çoğu zaman kötü niyetten değil, kolaylıktan doğar.

Sık görülen nedenler şunlardır:

• OLLAMA_HOST değişkenini 0.0.0.0 yaparak tüm arayüzlerde dinlemek
• Docker'da -p 11434:11434 gibi adres belirtmeyen port yayını
• Bulut sanal makinesinde 11434 için geniş bir giriş kuralı bırakmak
• Ofis ya da ev yönlendiricisine port yönlendirmesi eklemek
• Test için açılan geçici tüneli kapatmayı unutmak

Docker ayrıntısı özellikle önemlidir. Docker belgelerine göre portu adres belirtmeden yayınladığınızda Docker bunu ana makinenin tüm adreslerinde açar. Linux'ta ufw kullanıyorsanız, yayınlanan port trafiği ufw kurallarına ulaşmadan yönlendirilir. Yani güvenlik duvarında kapalı sandığınız port dışarıdan erişilebilir olabilir.

Kurumsal ölçekte açık ağırlıklı modelleri barındırmanın mimari seçenekleri Llama ve DeepSeek ile kurumsal self-host yazısında ele alınır.

Ollama internete açık mı, nasıl anlaşılır?

Denetim üç katmanda yapılır: sunucunun kendisi, aynı ağdaki başka bir makine ve ağ dışı. Her katmanın sonucu ayrı yazılır. Sonuçlar farklıysa sorun katmanlar arasındaki kuraldadır. Denetimi yalnız sahibi olduğunuz sistemlerde yapın.

Sunucu tarafında dinleme adresine bakın. Linux'ta ilk komutu, macOS'ta ikinci komutu kullanın:

ss -ltnp | grep 11434
lsof -nP -iTCP:11434 -sTCP:LISTEN

Çıktıda 127.0.0.1:11434 görüyorsanız sunucu yalnız yerelde dinliyordur. 0.0.0.0:11434, *:11434 ya da [::]:11434 tüm arayüzlerde dinlediğini gösterir. Ardından aynı ağdaki başka bir makineden sürüm ucunu çağırın:

curl -s http://192.0.2.10:11434/api/version

Yanıt geliyorsa sunucu iç ağa açıktır. Son adımda dış adresinizi, kurumun yetkili dış tarama aracından ya da dış ağdaki bir test makinesinden kontrol edin. Bulut sanal makinelerinde ayrıca sağlayıcının güvenlik grubu ya da ağ kuralı listesinde 11434 için açılmış bir giriş olup olmadığına bakın. Sunucu yerelde dinlese bile aynı makinede çalışan bir tünel ya da vekil portu dışarı taşıyor olabilir. Bu yüzden çalışan süreçleri ve tünel araçlarını da listeleyin. Her katmanın sonucunu tarih ve denetleyen kişiyle birlikte kayda geçirin. Sonraki denetim bu kayıtla karşılaştırılır ve bir değişikliğin ne zaman girdiği anlaşılır.

Açık bir Ollama API'si neyi riske atar?

Ollama belgeleri, localhost:11434 üzerindeki yerel API için kimlik doğrulama gerekmediğini belirtir. Sunucu ağa açıldığında bu, API'nin tamamının ağa açılması demektir. Model çalıştırma uçları işlem gücünüzü tüketir. Model listeleme ucu hangi modelleri kullandığınızı gösterir. İndirme, oluşturma ve silme uçları ise sunucunun içeriğini değiştirmeye izin verir.

Ölçek küçük değildir. Cisco Talos'un Eylül 2025'te yayımladığı Shodan çalışması, kimlik doğrulamasız erişilebilen 1.139 Ollama sunucusu tespit etti. Bunların 214'ü canlı model sunuyordu. Geri kalanlar model yüklü olmasa da yetkisiz model yükleme ve yapılandırma değişikliğine açıktı.

Sunucu yazılımının kendi açıkları da risk taşır. CVE-2024-37032 kaydına göre Ollama'nın 0.1.34 öncesi sürümleri, model yolunu oluştururken özet değerinin biçimini doğrulamıyordu ve ../ içeren değerleri yanlış işliyordu. Açık bir API, bu tür bir hatanın internetten tetiklenmesine yol açar. Sürüm takibini ihmal etmeyin.

Sunucu belge arama, dosya okuma ya da dış servis çağıran araçlara bağlıysa etki büyür. Sistem istemine anahtar ya da iç adres yazmak, açık bir sunucuda anında ifşaya dönüşür.

Port değiştirmek yeterli bir önlem mi?

Değildir. Cisco Talos önerileri arasında varsayılan portu değiştirmek ve tanıtıcı başlıkları gizlemek de yer alır, ama bu öneriler parmak izini azaltmaya yöneliktir. Aynı çalışma asıl önlem olarak kimlik doğrulama, ağ yalıtımı ve hız sınırlamayı sayar. Kimlik doğrulaması olmayan bir sunucu farklı bir portta da bulunur.

Doğru sıralama şudur:

1. Model sunucusunu yalnız yerel arayüze ya da özel ağa bağlayın.
2. Dış erişim gerekiyorsa VPN ya da kimlik doğrulamalı bir vekil kullanın.
3. Yönetim uçlarını dış kullanıcılara kapatın.
4. İstek boyutu, süre ve hacim için sınır koyun.
5. Her isteği kimlik, zaman ve boyut bilgisiyle kaydedin.

Docker kullanıyorsanız portu yalnız yerel adrese bağlayın. Vekil aynı makinede çalışıyorsa bu yeterlidir:

services:
  ollama:
    image: ollama/ollama
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama:/root/.ollama
volumes:
  ollama:

Kimlik doğrulamalı ters vekil nasıl kurulur?

Ollama belgeleri, sunucunun Nginx gibi bir vekil sunucuyla dışarı açılabileceğini belirtir. Vekil, model sunucusunun yapmadığı işleri üstlenir: kimlik doğrulama, şifreli bağlantı, adres kısıtı, istek sınırı ve kayıt. Aşağıdaki örnek, iç ağ ve VPN aralığına izin verir, yönetim uçlarını kapatır ve temel kimlik doğrulama ister:

server {
    listen 443 ssl;
    server_name llm.example.com;
    ssl_certificate     /etc/nginx/tls/llm.example.com.crt;
    ssl_certificate_key /etc/nginx/tls/llm.example.com.key;

    allow 192.0.2.0/24;
    deny  all;

    location ~ ^/api/(pull|push|create|copy|delete) {
        return 403;
    }

    location / {
        auth_basic           "LLM";
        auth_basic_user_file /etc/nginx/llm.htpasswd;
        client_max_body_size 1m;
        proxy_pass           http://127.0.0.1:11434;
        proxy_set_header     Host localhost:11434;
        proxy_read_timeout   120s;
    }
}

Temel kimlik doğrulama bir başlangıçtır. Kurumsal kullanımda vekili kurumun kimlik sağlayıcısına bağlamak, kullanıcı bazlı kayıt ve kota sağlar. Girdi ve çıktıyı içerik düzeyinde denetleyen, kota ve kayıt işlerini tek noktada toplayan yaklaşım için LLM gateway yazısına bakın.

Güvenlik duvarı kuralları nasıl yazılır?

Temel ilke, giriş trafiğini varsayılan olarak reddetmek ve yalnız bilinen kaynaklara izin vermektir. Model portuna yalnız vekilin adresinden erişilmelidir. Yönetim arayüzleri yalnız yönetim ağından açılmalıdır.

• Giriş trafiğinde varsayılan eylem engelleme olsun.
• 11434 portuna yalnız vekil adresinden izin verilsin.
• Docker'lı Linux sunucularda ufw kuralına güvenmeyin. Portu yerel adrese bağlayın ya da kuralı Docker'ın kendi zincirinde yazın.
• Çıkış trafiğini sınırlayın. Sunucu yalnız model kaynağına ve gerekli iç servislere bağlansın.
• Kural değişiklikleri kayda geçsin ve dönemsel olarak gözden geçirilsin.

Kubernetes üzerinde aynı işi ağ politikaları yapar. Ayrıntılar Kubernetes üzerinde LLM servisi sertleştirme yazısındadır.

Maruziyet bulunursa ne yapılır?

Önce erişimi kapatın, sonra neyin ifşa olduğunu araştırın. Kapatmak için dinleme adresini daraltın, Docker port yayınını yerel adrese çekin ya da bulut kuralını kaldırın.

1. Dış erişimi kesin ve kesme saatini yazın.
2. Sunucu ve ağ kayıtlarını koruyun, silmeyin.
3. Yüklü model listesini beklenen listeyle karşılaştırın. Tanımadığınız model varsa silmeden önce kayda alın.
4. Sunucudan erişilebilen anahtarları, belgeleri ve bağlı servisleri listeleyin, gerekiyorsa anahtarları yenileyin.
5. Ollama sürümünü kontrol edin ve güncelleyin.
6. Bağlı araçlar üzerinden kişisel veriye erişilmiş olabilirse KVKK kapsamındaki 72 saatlik bildirim değerlendirmesini başlatın.
7. Kök nedeni ve düzeltmeyi olay kaydına yazın.

Kurumunuz bir sektörel SOME'ye bağlıysa siber olay bildirimini sektörel SOME ve USOM kanalıyla yapın. Başka birinin açık sunucusunu fark ederseniz kurcalamayın, sahibine ya da USOM'a bildirin.

Sürekli izleme ve sorumluluk nasıl kurulur?

Tek seferlik denetim, ertesi hafta yapılan bir yapılandırma değişikliğiyle geçersiz kalır. Maruziyet denetimi tekrarlanan bir kontrole dönüşmelidir.

1. Sahip olduğunuz dış adresleri ve alan adlarını bir envanterde tutun.
2. Her adres için beklenen açık portları yazın.
3. Kendi adres aralığınızı yetkili ve düzenli taramayla kontrol edin, 11434 gibi beklenmeyen portları uyarıya bağlayın.
4. Yeni model sunucusu kurulumunu onaya bağlayın.
5. Her sunucu için bir sahip, bir amaç ve bir bitiş tarihi tanımlayın.

Çalışanların onaysız kurduğu model sunucuları, gölge yapay zekânın teknik yüzüdür. Bunları ağ kayıtlarından ve envanterden bulma yöntemi Shadow AI yönetişimi yazısında anlatılır. Dış bir ekipten denetim alacaksanız kapsamı, izinli adresleri ve zaman aralığını sözleşmede açık yazın.

Sık Sorulan Sorular

Ollama varsayılan olarak internete açık mıdır?

Hayır. Ollama belgelerine göre sunucu varsayılan olarak 127.0.0.1 adresinde ve 11434 numaralı bağlantı noktasında dinler, yani yalnız aynı makineden erişilebilir. Risk, OLLAMA_HOST değişkeniyle dinleme adresini tüm arayüzlere açtığınızda, Docker'da portu adres belirtmeden yayınladığınızda ya da yönlendiriciye port yönlendirmesi eklediğinizde başlar.

Ollama API'sinde kimlik doğrulama var mı?

Yerel API kimlik doğrulaması istemez. Ollama belgeleri, localhost:11434 üzerindeki API için kimlik doğrulama gerekmediğini, API anahtarının yalnız ollama.com bulut uçları için kullanıldığını belirtir. Bu nedenle ağa açılan bir Ollama sunucusunda kimlik doğrulama, hız sınırı ve kayıt gibi işleri önüne koyacağınız bir ters vekil ya da ağ geçidi üstlenmelidir.

Kendi ağım dışındaki sunucuları tarayabilir miyim?

Hayır. Yalnız sahibi olduğunuz ya da yazılı izin aldığınız sistemleri denetleyin. Başkasına ait bir bilişim sistemine izinsiz girmek Türk Ceza Kanunu'nun 243. maddesindeki bilişim sistemine girme suçunu oluşturabilir. Dış denetim yaptıracaksanız kapsamı, izinli adres aralığını ve zaman penceresini sözleşmede yazılı olarak belirleyin. Şüphede hukuk biriminize danışın.

Port numarasını değiştirmek güvenlik sağlar mı?

Tek başına sağlamaz. Cisco Talos, varsayılan portu değiştirmenin ve tanıtıcı başlıkları gizlemenin taramalarda parmak izini azaltabileceğini belirtir. Ancak bu önlem erişim kontrolünün yerini tutmaz. Kimlik doğrulaması olmayan bir sunucu, farklı bir portta da bulunur. Asıl önlem, sunucuyu yerel arayüzde tutmak ve dış erişimi yalnız kimlik doğrulamalı bir ara katmandan vermektir.

Kaynaklar

• Ollama Docs: FAQ (bind adresi, OLLAMA_HOST, Nginx vekil)
• Ollama Docs: Authentication
• Docker Docs: Port publishing and mapping
• Docker Docs: Packet filtering and firewalls
• Cisco Talos: Detecting Exposed LLM Servers, A Shodan Case Study on Ollama
• CVE Program: CVE-2024-37032

İlgili Yazılar

• Llama ve DeepSeek Kurumsal Self-Host Güvenliği Açık Ağırlıklı Modellerin Kurum İçi Mimarisi
• Kubernetes LLM Güvenliği: Model Servisini Sertleştirme
• Shadow AI Tespiti: DNS ve Proxy Loglarından Gölge Yapay Zekâ Envanteri Tanım değil, uygulanabilir tespit mühendisliği
• LLM Gateway Nedir? LLM Firewall ve Runtime Protection ile Farkı