TurkTeam | Türk Siber Güvenlik Topluluğu - Sanallaştırma ve Konteyner

Docker İmajını Digest ile Sabitlemek: latest Tuzağından Kurtulmak

Thu, 22 Oct 2026 11:31:28 +0300

Selamlar,

LiteLLM olayında yalnızca PyPI wheel'leri değil, Docker Hub ve GHCR'daki latest, main-latest ve main-stable etiketleri de zararlı imaja işaret etti. Etiket hareketli bir işaretçidir; digest ise içeriğin parmak izidir. Bu yazıda Docker'ın resmi pull belgelerine göre imajı digest ile sabitlemenin nasıl yapıldığını anlatıyorum.

Konuda anlatılacaklar

Etiket ile digest farkı
Digest nasıl öğrenilir, nasıl çekilir?
Dockerfile'da FROM ...@sha256:...
Üretim politikası önerileri

Etiket ile digest
docker pull debian dediğinizde Engine varsayılan olarak :latest etiketini kullanır. Aynı imaj daha sonra güvenlik güncellemesiyle yeniden yayınlandığında aynı etiket yeni bir içeriğe bakabilir - bu bazen istediğiniz şeydir (yama almak), bazen istemediğiniz (saldırganın latest'i zehirlemesi).

Digest, imaj yapılandırması ve katmanlarını kapsayan bir SHA256 özetidir. Docker belgelerinin dediği gibi: digest ile çekmek, o imajın tam olarak o sürümünü "pin"ler ve her zaman aynı içeriği garantiler.

Lab: digest öğrenip sabitlemek

Kod:
# Once etiketi cekin; Docker pull bitince digest'i yazar
docker pull debian:bookworm
# Yerel imajin RepoDigests degerini okuyun
docker image inspect debian:bookworm --format '{{json .RepoDigests}}'
# Digest ile cekme ornegi (asagidaki hash ornektir; kendi ciktinizi kullanin)
# docker pull debian@sha256:

Dockerfile'da:

Kod:
# ORNEK - hash'i kendi dogrulanmis degerinizle degistirin
FROM debian@sha256:3f1d6c17773a45c97bd8f158d665c9709d7b29ed7917ac934086ad96f92e4510

Belgelerin uyarısı: Digest ile sabitlemek, imajın güvenlik güncellemelerini otomatik almamanız anlamına gelir. Yamalı bir sürüme geçmek için digest'i bilinçli olarak değiştirirsiniz. Bu bir özelliktir: değişiklik denetimli olur.

LiteLLM bağlamı
LiteLLM, etkilenen Docker imaj index'ini açıkça yayınladı: sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Çalışan konteynerlerinizin gerçekte hangi digest'i koşturduğunu bilmiyorsanız, "biz latest kullanmıyoruz, v1.107.0 kullanıyoruz" demek yetmeyebilir; çünkü o etiket o aralıkta zehirli index'e bakıyordu.

Kod:
# Calisan konteynerin gercek digest'i
docker inspect --format '{{index .RepoDigests 0}}' 
# veya
docker image inspect  --format '{{join .RepoDigests "\n"}}'

Üretim politikası

CI'da imajı etiket + digest ile kaydedin; deploy yalnızca digest kullansın.
latest / main-stable gibi hareketli etiketleri üretim namespace'inde yasaklayın.
İmzalı imajlar (cosign / Docker Content Trust) ile digest doğrulamasını birleştirin.
Bağımlılık güncellemelerini (renovate/dependabot) digest değişikliği olarak PR'layın; insan gözü görsün.

Sizin Kubernetes manifest'lerinizde digest var mı, yoksa hâlâ tag mi?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

14-b04-docker-digest.png (Dosya Boyutu: 117.62 KB / İndirme Sayısı: 9)

Docker İmajını Digest ile Sabitlemek: latest Tuzağından Kurtulmak

Thu, 22 Oct 2026 11:30:21 +0300

Etiket ile digest farkı
Digest nasıl öğrenilir, nasıl çekilir?
Dockerfile'da FROM ...@sha256:...
Üretim politikası önerileri

Kod:
# Once etiketi cekin; Docker pull bitince digest'i yazar
docker pull debian:bookworm
# Yerel imajin RepoDigests degerini okuyun
docker image inspect debian:bookworm --format '{{json .RepoDigests}}'
# Digest ile cekme ornegi (asagidaki hash ornektir; kendi ciktinizi kullanin)
# docker pull debian@sha256:

Dockerfile'da:

Kod:
# ORNEK - hash'i kendi dogrulanmis degerinizle degistirin
FROM debian@sha256:3f1d6c17773a45c97bd8f158d665c9709d7b29ed7917ac934086ad96f92e4510

Kod:
# Calisan konteynerin gercek digest'i
docker inspect --format '{{index .RepoDigests 0}}' 
# veya
docker image inspect  --format '{{join .RepoDigests "\n"}}'

Üretim politikası

CI'da imajı etiket + digest ile kaydedin; deploy yalnızca digest kullansın.
latest / main-stable gibi hareketli etiketleri üretim namespace'inde yasaklayın.
İmzalı imajlar (cosign / Docker Content Trust) ile digest doğrulamasını birleştirin.
Bağımlılık güncellemelerini (renovate/dependabot) digest değişikliği olarak PR'layın; insan gözü görsün.

14-b04-docker-digest.png (Dosya Boyutu: 117.62 KB / İndirme Sayısı: 8)

Docker Rootless ve Kullanıcı Namespace: Ne Kazanırız, Ne Kaybederiz

Wed, 21 Oct 2026 09:33:19 +0300

Merhaba,

Docker varsayılanında konteyner süreçleri host'ta root benzeri geniş yetkilerle ilişkilendirilebilir. Rootless mod ve user namespace, kaçışın etkisini azaltmak için önemli bir sıkılaştırmadır. Bu yazıda ne kazandığımızı ve hangi sınırlarla karşılaştığımızı yazıyorum.

Rootless ne demek?
Dockerd ve konteynerlerin root olmayan bir kullanıcı altında çalışması. User namespace ile konteyner içindeki uid 0, host'ta ayrı bir uid'ye eşlenir. Konteynerden çıkılsa bile host root'u doğrudan alınmaz (teorik yüzey daralır; çekirdek zafiyetleri ayrı konu).

Kurulum (özet)
Resmi Docker docs'taki rootless kurulum adımlarını izleyin. Tipik gereksinimler: uid map, dbus / systemd --user, gerekli kernel özellikleri.

Kod:
dockerd-rootless-setuptool.sh install
systemctl --user enable --now docker
docker info | grep -i rootless

Ne kazanırız?

Daemon root değil
Çoğu kaçış senaryosunda etki azalır
Geliştirici laptop'larında daha az "sudo docker"

Ne kaybeder / zorlaşır?

Bazı düşük portlar (<1024) doğrudan bind zorlaşır
Overlay / dosya sistemi performans nüansları
Eski konteyner ağ özellikleri
Kurumsal güvenlik ürünlerinin desteği

Tamamlayıcı kontroller

--read-only, drop capabilities, no-new-privileges
seccomp / AppArmor / SELinux profilleri
İmaj tarama (Trivy) + imzasız imaj yasağı
K8s'te Pod Security Standards

Kaynaklar

Docker Docs: Rootless mode
rootlesskit projesi
CIS Docker Benchmark

Rootless'e geçerken kırılan ilk aracınız ne oldu? CI runner deneyimleri özellikle değerli.

Rootless + compose
docker compose rootless altında çoğu senaryoda çalışır; volume path izinlerine dikkat (uid map). IDE entegrasyonları bazen /var/run/docker.sock bekler; rootless socket yolunu ($XDG_RUNTIME_DIR/docker.sock) gösterin.

Güvenlik tiyatrosu olmasın
Rootless açıp konteynere --privileged vermek kazanımı sıfırlar. Capability drop ve read-only rootfs ile birlikte düşünün.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

100-n34-404191.png (Dosya Boyutu: 63.4 KB / İndirme Sayısı: 5)

n34-inner.png (Dosya Boyutu: 16.82 KB / İndirme Sayısı: 6)

Docker Guvenligi 2026: Rootless Mod, Trivy ile Imaj Tarama ve Sertlestirme

Sat, 17 Oct 2026 11:25:12 +0300

Merhaba,

Konteyner "guvenli gelir" diye dusunulur ama varsayilan ayarlarla calisan bir Docker ortami ciddi riskler tasir. Bu konuda 2026 icin guncel, pratik bir Docker sertlestirme listesi paylasiyorum: rootless mod, imaj tarama ve calisma zamani kisitlamalari.

Konuda Anlatilacaklar

Neden varsayilan Docker riskli?
Rootless mod
Trivy ile imaj zafiyet taramasi
Calisma zamani sertlestirme
CI'ya entegre etme

1) Varsayilan Risk
Klasik kurulumda Docker daemon root olarak calisir ve docker grubundaki kullanici pratikte root'a esdegerdir. Ayrica cogu imaj gereksiz paketlerle ve root kullaniciyla gelir. Bu iki nokta bile ciddi saldiri yuzeyidir.

2) Rootless Mod
Rootless mod, daemon ve konteynerleri host root'u olmadan calistirir; bir kacis durumunda etki alani daralir.

Kod:
curl -fsSL https://get.docker.com/rootless | sh
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock
systemctl --user enable --now docker

Subordinate UID/GID eslemelerinin tanimli oldugundan emin olun (/etc/subuid, /etc/subgid). Her senaryo rootless'i desteklemez ama cogu web uygulamasi icin uygundur.

3) Trivy ile Tarama
Trivy, imajlardaki bilinen zafiyetleri hizlica tarar. CI'da HIGH/CRITICAL bulgularda derlemeyi kirmak iyi bir politikadir.

Kod:
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest
# SBOM uretme
trivy image --format cyclonedx -o sbom.json myapp:latest

Veritabanini guncel tutun ve yalnizca bir kez degil, kayit defterindeki imajlari duzenli tarayin.

4) Calisma Zamani Sertlestirme
Birkac bayrak saldiri yuzeyini ciddi dusurur:

Kod:
docker run --rm \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --user 10001:10001 \
  myapp:latest

Ozetle: root olmayan kullanici, salt-okunur dosya sistemi, tum yeteneklerin dusurulup yalnizca gerekenin eklenmesi, no-new-privileges ve asla host docker.sock'unu konteynere baglamamak.

5) Imaj Hijyeni
Minimal temel imaj (distroless, alpine) kullanin, etiket yerine digest sabitleyin, gereksiz paket koymayin. Kucuk imaj hem daha hizli hem daha guvenlidir.

Kaynaklar

Alıntı:Yasal not: Tarama ve sertlestirmeyi yalnizca kendi imaj ve sunucularinizda uygulayin.

bilgekagan-b04.png (Dosya Boyutu: 94.32 KB / İndirme Sayısı: 6)

DVWA ve Juice Shop: Docker Compose ile Yerel Web Zafiyet Labı

Fri, 16 Oct 2026 11:17:06 +0300

Selam,

VirtualBox ile VM kurmak güzel ama her hedef için ayrı disk ve RAM ayırmak ağır geliyor. Web zafiyetleri çalışmak için Docker çok daha hafif. Bu konuda DVWA ve OWASP Juice Shop'u 2026 itibarıyla nasıl ayağa kaldıracağınızı, kendi lab notlarımdan derledim.

Konuda Anlatılacaklar

Neden Docker lab?
DVWA: resmi compose ile localhost:4280
OWASP Juice Shop v20.3.0
Güvenlik: portları sadece 127.0.0.1'e bağlamak
Lab hijyeni: silme, volume, güncelleme

1) Neden Docker?
Bir konteyner saniyeler içinde kalkar, host'unuzun çekirdeğini paylaşır ama süreçleri izole eder. Web uygulaması zafiyetleri için DVWA, Juice Shop, WebGoat gibi hedefler Docker Hub / GHCR üzerinden hazır geliyor. VM'lere göre disk ve RAM tasarrufu ciddi.

2) DVWA (Damn Vulnerable Web Application)
Resmi depo: github.com/digininja/DVWA. Her master commit'te GHCR'ye imaj basılıyor. compose.yml örneği:

Kod:
git clone https://github.com/digininja/DVWA.git
cd DVWA
docker compose up -d
# Uygulama: http://127.0.0.1:4280

compose.yml içinde port satırı 127.0.0.1:4280:80 olarak tanımlı; yani sadece sizin makinenizden erişilir. İnternete açmayın. İlk girişten sonra Setup sayfasından veritabanını oluşturun, security level'ı Low ile başlayıp kademeli yükseltin.

3) OWASP Juice Shop
2026-10-11'de v20.3.0 yayınlandı. Tek satırlık çalıştırma:

Kod:
docker pull bkimminich/juice-shop:v20.3.0
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop:v20.3.0
# Tarayıcı: http://127.0.0.1:3000

Juice Shop, OWASP Top 10 ve modern API/JWT zafiyetlerini CTF tadında sunuyor. Score Board'dan ilerlemeyi takip edebilirsiniz. "latest" etiketi yerine sürüm sabitlemek (v20.3.0) lab notlarınızın tekrarlanabilirliğini artırır.

4) Port Bağlama Disiplini

Kod:
# YANLIŞ: 0.0.0.0'a bağlar, LAN'daki herkes erişir
docker run -p 3000:3000 ...

# DOĞRU: sadece localhost
docker run -p 127.0.0.1:3000:3000 ...

Ev Wi-Fi'nizde bile yaralanabilir uygulamaları açmak istemezsiniz. VPN veya ortak ağdaysanız özellikle dikkat.

5) Lab Hijyeni

Kod:
docker compose down -v   # DVWA: konteyner + volume sil
docker rm -f         # Juice Shop tek konteyner
docker image prune       # kullanılmayan imajları temizle

Haftada bir güncelleme çekmek iyi alışkanlık. DVWA için docker compose pull && docker compose up -d.

Bonus: WebGoat da aktif; Docker Hub'da webgoat/webgoat imajının 2026.5 etiketi Ekim 2026'da güncellendi. Öğrenme yolunuzda DVWA (klasik) -> Juice Shop (modern) -> WebGoat (eğitici) sırası işe yarıyor.

Kaynaklar

Alıntı:Yasal not: Bu uygulamalar bilerek zafiyetlidir. Yalnızca kendi bilgisayarınızda, localhost'a bağlı çalıştırın. İnternete veya izinsiz ağlara açmak hem tehlikeli hem yasadışıdır (TCK 243-245).

Kapak: özgün TurkTeam görseli.

bilgekagan-04.png (Dosya Boyutu: 91.45 KB / İndirme Sayısı: 9)