Container (Docker) Forensics Temelleri: Geçici Ortamlarda Kalıcı Deliller

Container teknolojileri (özellikle Docker), uygulamaları hafif, hızlı ve geçici biçimde çalıştırmayı hedefler. Ancak “geçici” olmaları, iz bırakmadıkları anlamına gelmez. Container forensics; image katmanları, container yaşam döngüsü, volume’ler, network namespace’leri ve orchestrator etkileşimleri üzerinden olayları yeniden inşa etmeyi amaçlar. Bu makalede Docker odaklı container forensics’in temellerini, pratik analiz adımlarını ve sahada işe yarayan ipuçlarını ele alıyoruz.

Container Forensics Nedir?

Container forensics; container tabanlı ortamlarda (Docker/Kubernetes) adli artefact’lerin tespiti, korunması ve analizidir. Klasik OS forensics’ten farklı olarak:

- Host + container birlikte değerlendirilir
- Dosya sistemi katmanlıdır (layered FS)
- Ağ ve süreçler namespace’ler içindedir

Neden Zor?

- Ephemeral container’lar (silinip yeniden oluşur)
- Log’ların stdout/stderr’a akması
- Immutable image’lar ama mutable runtime
- OverlayFS katmanları
- Otomasyon (CI/CD) ile hızlı değişim

Docker Mimarisi: Nerelerde İz Var?
Başlıca Artefact Alanları

- Image katmanları (read-only)
- Container writable layer
- Volume’ler / bind mount’lar
- Container log’ları
- Network namespace & iptables
- Host Docker daemon log’ları

Analize Nereden Başlanmalı?
1. Container Envanteri ve Yaşam Döngüsü

Önce ne vardı, ne çalıştı, ne silindi sorularını yanıtla.

1docker ps -a

Bu çıktı:

- Çalışan/duran container’lar
- Oluşturulma zamanları
- Exit code’lar

hakkında ilk resmi verir.

2. Image İncelemesi (Supply Chain)

Image’ın kaynağı ve katmanları kritik önemdedir.

1docker images

1docker history suspicious_image:tag

Şüpheli göstergeler:

- Beklenmeyen base image
- “curl | sh” gibi riskli RUN komutları
- Gizli paket kurulumları

3. Container Dosya Sistemi (Writable Layer)

Container silinse bile katman kalıntıları host’ta bulunabilir.

1docker inspect container_id

Ardından ilgili overlay dizinleri salt-okunur incelenir.

Log Analizi
Container Log’ları

Varsayılan olarak stdout/stderr:

1docker logs container_id

Şunlara bak:

- Hata/exception
- Komut çıktıları
- Beklenmeyen servis başlatmaları

Host (Daemon) Log’ları

Container olaylarının üst tanığıdır.

Volume ve Bind Mount Analizi

Volume’ler container’dan bağımsız yaşar.

1docker volume ls

1docker volume inspect vol_name

Riskli durumlar:

- Host path bind mount (/etc, /var/run/docker.sock)
- Hassas dizinlere yazım

Network ve Süreç İzleri
Ağ

- Container IP’leri
- Port publish’leri
- iptables/NAT kuralları

Süreçler

- Container PID’leri host PID’lerine map edilir
- Kısa süreli süreçler bile kayıtta olabilir

Adli Senaryo Örneği

Olay:
Bir container, “kısa süre çalıştı ve kapandı” deniyor.

Analiz:

docker ps -a → 9 dakika çalışmış
docker history → image’a son anda eklenen script
docker logs → dış IP’ye veri gönderimi
Volume → kalıcı çıktı dosyaları

Sonuç:

- Kısa ömürlü ama etkili veri sızıntısı
- Runtime katmanda kanıtlandı

Anti-Forensics Taktikleri (ve Karşı Hamleler)
Yaygın Taktikler

- Container’ı hızlı silme
- Log driver değiştirme
- --rm ile çalıştırma
- Volume’leri temizleme

Karşı Hamleler

- Daemon log korelasyonu
- Image cache analizi
- Host FS artefact’leri
- Orchestrator kayıtları (varsa)

Adli Analistler İçin Pratik İpuçları
Host’u Merkez Al

- Container tek başına düşünülmez

Image ve Runtime’ı Ayır

- “Temiz image” savunmasına aldanma

Volume’leri Önceliklendir

- Kalıcı veri genelde oradadır

Otomasyon İzlerini Ara

- CI/CD, cron, webhook tetikleri

Hukuki ve Adli Değer

Mahkemelerde:

- Host + container korelasyonu
- Read-only analiz
- Zaman çizelgesi tutarlılığı

özellikle vurgulanmalıdır.

#AdliBilişim #kaynak