TürkTeam Portal

Siber güvenlik topluluğunun nabzı

Duyurular, öne çıkan konular ve topluluktan son haberler burada.

Forumlar Yeni Mesajlar Kurallar

Duyurular

OpenVAS / Greenbone ile İlk İzinli Tarama: Kurulum ve Rapor Okuma

KulTigin 10-18-2026, 09:44 PM · Araç Tanıtım ve Eğitimleri

0 42

Selamlar,

Açık kaynak zafiyet tarayıcı denince akla hâlâ OpenVAS geliyor; proje bugün Greenbone Community Edition / GVM çatısı altında. Bu yazıda ev labımda GVM'i ayağa kaldırıp ilk izinli taramayı çalıştırma ve raporu okuma notlarımı paylaşıyorum. Hedef yalnızca kendi VM'lerim.

Mimariyi kısaca tanıyın

gvmd: yönetici daemon
ospd-openvas: tarayıcı sarmalayıcı
openvas-scanner: asıl motor
gsad: web arayüzü (Greenbone Security Assistant)
Feed'ler: NVT, SCAP, CERT — kalite bunların güncelliğine bağlı

Kurulum (Docker ile pratik yol)
Resmi Greenbone community container dokümantasyonunu takip etmek, kaynak derlemekten çok daha az acılı. Labımda docker compose ile ayağa kaldırdım; ilk feed senkronu uzun sürer (saat düzeyinde olabilir). Sabır şart.

Kod:
# Örnek: feed durumunu kontrol (kuruluma göre komut değişir)
docker compose ps
# Web arayüzü genelde https://localhost:9392

İlk girişten sonra varsayılan parolayı değiştirin; arayüzü internete açmayın.

İlk hedef ve görev

Configuration > Targets: lab IP veya CIDR (ör. 10.10.10.0/28)
Credentials (opsiyonel): SSH/SMB kimliği verirseniz authenticated scan derinleşir
Tasks > New Task: tarama profili seçin

Profil seçimi:

Full and fast: günlük lab için dengeli
Discovery: yalnızca keşif
Full and very deep: uzun ve gürültülü; bilinçli kullanın

Raporu okumak
Sonuçlarda CVSS skoru, QOD (Quality of Detection) ve CVE listesi gelir. Pratik filtrelerim:

Önce QOD'u yüksek + CVSS kritik/high olanlar
Sonra "False Positive" işaretleme disiplini (yoksa bir sonraki taramada aynı gürültü)
CVE'yi NVD ve üretici bülteniyle doğrula; tarayıcı yanlış pozitif üretebilir
Authenticated bulgular (eksik yama, zayıf cipher) genelde daha aksiyoneldir

CLI ile hızlı bakış
Ortamınıza göre gvm-cli / omp benzeri araçlarla görev başlatılabilir. Önemli olan otomasyonda kimlik bilgilerini düz metin dosyada bırakmamaktır.

Sınırlar: tarayıcı pentest değildir
GVM bilinen imzaları arar. İş mantığı açıkları, zincirleme exploit, fiziksel güvenlik bu aracın işi değildir. Raporu "otomatik bulgu listesi" olarak görün; pentest metodolojisinin keşif/zafiyet analizi aşamasına girdi sağlar.

Performans ipuçları

Feed güncellemesini geceye bırakın
Eşzamanlı hedef sayısını lab kaynaklarına göre sınırlayın
Firewall'da tarayıcı IP'sini allowlist'e almak (izinli pentestte) yanlış pozitif düşürür

Kaynaklar

Greenbone Community Documentation
OpenVAS / GVM GitHub org
NIST NVD (CVE doğrulama)

Siz feed senkronunda en çok hangi adımda takıldınız? Container log'unda gördüğünüz tipik hataları da yazabilirsiniz.

Authenticated scan değeri
Kimliksiz tarama çoğunlukla sürüm ve port bulur. SSH/WinRM/SMB hesabı verdiğinizde eksik yama, yerel kullanıcı politikası, zayıf servis yapılandırması çıkar. Labda ayrı bir "scanner" hesabı açın; domain admin vermeyin. Başarıyla giriş yapılamazsa rapor "auth failed" diye yalan yanlış critical üretmesin diye görev logunu kontrol edin.

Raporu iş biletleme
CSV/XML dışa aktarıp her kritik CVE için: varlık sahibi, yama penceresi, geçici mitigeasyon (WAF imzası, port kapatma). Tarayıcı skoru tek başına öncelik değildir; internete açık + exploit public ise yukarı çekin.

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.

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.

Ek DosyalarEkran Görüntüleri

Pasif ve Aktif Keşif Farkı: Ne Zaman Hangisi, Hangi Araçlar

KulTigin 10-18-2026, 09:26 PM · Sızma Testi (Pentest)

0 48

Merhaba,

Pentest raporlarının keşif bölümü bazen ya çok zayıf oluyor ya da müşteriye "neden bu kadar gürültü yaptınız?" sorusunu doğuruyor. Sorunun kökü çoğu zaman pasif / aktif keşif ayrımının bulanık olmasından. Bu yazıda ikisini netleştirip hangi aşamada hangi araçlara baktığımı anlatacağım.

Pasif keşif nedir?
Hedefe doğrudan paket göndermeden, kamuya açık kaynaklardan bilgi toplamaktır. DNS kayıtları, sertifika şeffaflık logları, arama motorları, GitHub, iş ilanları, BGP/WHOIS... Hedef sizin trafiğinizi "tarama" olarak görmez (yine de ToS ve yasaları unutmayın).

Örnek pasif akış:

WHOIS / RDAP ile sahip ve netblok
Certificate Transparency (crt.sh) ile alt alan adları
DNS: MX, TXT, SPF, DMARC
Arama motoru dork'ları (kendi varlıklarınız / izinli kapsam)
Şirket kariyer sayfası: teknoloji yığını ipuçları

Kod:
dig +short example.com ANY
dig +short _dmarc.example.com TXT
curl -s "https://crt.sh/?q=%25.example.com&output=json" | head

Aktif keşif nedir?
Hedefe paket gönderdiğiniz her şey: ping, port tarama, servis parmak izi, web spider, SMB null session denemeleri... IDS bunu görür, log üretir. Kapsam belgesi ve yazılı izin olmadan yapmayın.

Kod:
nmap -sS -sV -T3 -p- 10.10.10.50
whatweb https://hedef.lab

Ne zaman hangisi?

Sözleşme öncesi / dışarıdan görünürlük: ağırlıkla pasif. Müşteriye "dışarıdan şöyle görünüyorsunuz" demek için yeter.
İç ağ pentesti: aktif kaçınılmaz; yine de önce pasifle domain listesini çıkarın.
Bug bounty: program kuralları pasifi serbest, aktifi sınırlı tutabilir; her programı okuyun.
Kırmızı/mavi tatbikat: mavi takımın tespit edeceği aktif teknikleri bilinçli seçin.

Araç eşlemesi (kısa)
Pasif: dig/drill, whois, crt.sh, SecurityTrails (hesaplı), Wayback, theHarvester (kaynaklarına dikkat), GitHub code search.
Aktif: nmap, masscan (çok agresif; izin ve rate şart), httpx, ffuf, gobuster, netexec, respond/erv (lab).

Gürültü yönetimi
Aktif keşifte kalite = kapsam × hız × gürültü dengesi. Pratik kurallarım:

Önce top port, sonra tam port; kör -p- her zaman ilk adım olmasın.
--max-rate ve zaman penceresi anlaşması.
Aynı IP'ye paralel 10 araç yağdırmayın; sonuçları birleştirin.
Bulguyu "nasıl bulundu" diye raporlayın: pasif CT logu mu, aktif nmap mi?

Raporlama dili
Müşteriye "port taradık" demek yetmez. Pasifte bulunan alt alan adının aktif doğrulaması ayrı satır olsun. Yanlış pozitifleri (CDN arkasındaki paylaşılan IP gibi) açıkça yazın.

Etik sınır
Üçüncü taraf servislere (çalışan kişisel GitHub'ı, alt yüklenici) taşmak kapsam dışıdır. OSINT'te bile KVKK ve ilgili gizlilik kuralları geçerlidir; kişisel veri toplamayın, yaymayın.

Kaynaklar

OWASP Testing Guide - Information Gathering
PTES Technical Guidelines
nmap.org dokümantasyonu

Siz pasiften aktife geçişte hangi kontrol listesini kullanıyorsunuz? Varsa şablonunuzu (hassas bilgi olmadan) paylaşın.

Örnek zaman çizelgesi (dış pentest)
Gün 0: sözleşme + kapsam IP/domain listesi. Gün 1: pasif (CT, DNS, iş ilanı, GitHub org). Gün 2: nazik aktif (top ports, httpx). Gün 3+: derinleşme yalnızca açık bulunan servislerde. Bu sıra hem gürültüyü hem de "neden baştan -p-?" sorusunu azaltır.

Bug bounty farkı
Programlar bazen automated scanning'i yasaklar veya rate limit koyar. Pasif keşif çoğu zaman serbesttir; yine de ToS okuyun. Wildscope'ta müşteri olmayan alt alan adlarına kaymak en sık ban nedenidir.

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.

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.

Ek DosyalarEkran Görüntüleri

Disk İmajı Alma: dd, dc3dd, Hash Doğrulama ve Zincir of Custody Notları

KulTigin 10-18-2026, 09:23 PM · Adli Bilişim (Forensics)

0 38

Selam,

Adli bilişimde her şey imajla başlar. Yanlış alınan bir imaj, üzerine kurduğunuz tüm analizi zayıflatır. Bu yazıda Linux'ta dd ve dc3dd ile disk imajı alma, hash doğrulama ve basit zincir of custody (delil zinciri) notlarını paylaşıyorum. Senaryo: kendi lab diskim /dev/sdb (USB bellek).

Neden ham imaj?
Canlı diskte gezinmek delili değiştirir (atime vb.). Salt okunur bağlama ve bit-bit kopya (forensic image) standarttır. Hedef: kaynak ile imajın hash'inin aynı olması.

Hazırlık

Mümkünse donanım yazma engelleyici (write blocker) kullanın.
Yoksa kerneli salt okunur bağlayın:

Kod:
sudo hdparm -r1 /dev/sdb
# veya bind mount / blok cihazı RO
sudo blockdev --setro /dev/sdb

Cihaz adını doğrulayın; yanlış disk üzerine yazmak felakettir:

Kod:
lsblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINT

Klasik dd

Kod:
sudo dd if=/dev/sdb of=/mnt/evidence/case01.dd bs=4M status=progress conv=sync,noerror

bs=4M: blok boyutu; çok küçük yavaşlatır.
conv=noerror: okuma hatalarında durma, devam et (kötü sektörler).
status=progress: ilerleme (GNU dd).

Bitince:

Kod:
sync
sha256sum /dev/sdb /mnt/evidence/case01.dd | tee /mnt/evidence/case01.sha256

dc3dd: adli bilişim için geliştirilmiş dd
dc3dd hash'i işin içine gömer, log üretir:

Kod:
sudo dc3dd if=/dev/sdb of=/mnt/evidence/case01.dc3dd hash=sha256 log=/mnt/evidence/case01.log

Logda başlangıç/bitiş zamanı, hash ve hata sayıları yer alır. Mahkeme veya kurum içi incelemede bu log hayat kurtarır.

Alternatif modern araç: dcfldd veya ewf-tools (E01 formatı). Kurumsal tarafta çoğu laboratuvar E01/AFF tercih eder; ham dd eğitim ve hızlı lab için yeterlidir.

Hash disiplini

Kaynak ve imaj hash'i birebir aynı olmalı.
Hash algoritması: en az SHA-256 (MD5 tek başına artık yeterli sayılmaz).
Hash dosyasını imajla birlikte, ayrı bir kanıt notuna yazın.
Sonradan imajı kopyalarsanız yeni kopyanın hash'ini de alın; orijinal hash değişmez.

Kod:
sha256sum -c case01.sha256

Zincir of custody (basit şablon)
Her teslimatta kim, ne zaman, neden aldı yazılmalı. Minimal alanlar:

Dava / olay no
Cihaz seri no, model
İmaj dosya adı, boyutu, SHA-256
Alım tarihi (Europe/Istanbul), alan kişi
Saklama yeri (şifreli disk, erişim listesi)

Örnek satır:

Kod:
2026-10-17 14:05 TRT | Ahmet Y. | /dev/sdb -> case01.dc3dd | SHA256=abc... | Lab-Kasa-2

İmajı bağlamak (analiz için)

Kod:
sudo losetup -fP --show /mnt/evidence/case01.dd
sudo mkdir -p /mnt/img
sudo mount -o ro,noexec,noload /dev/loop0p1 /mnt/img

Her zaman ro. Analiz bitince:

Kod:
sudo umount /mnt/img
sudo losetup -d /dev/loop0

Sık hatalar

if/of karıştırmak (hedef diski siler)
Hash almadan kopyayı dağıtmak
İmajı RW bağlamak
Canlı sistemde "temizlik" yapıp sonra imaj almak (çok geç)

Kaynaklar

NIST SP 800-86 (Guide to Integrating Forensic Techniques)
dc3dd / dd man sayfaları
SANS Forensics white paper'ları

Siz E01 mi yoksa ham dd mi tercih ediyorsunuz? Küçük lablar için deneyimlerinizi merak ediyorum.

Canlı sistemden toplama sırası
Disk imajı almadan önce (politika izin veriyorsa) uçucu kanıt: bellek (dumpit/winpmem/lime), ağ bağlantıları, oturum listesi. Klasik sıra: bellek -> ağ durumu -> disk. Tersi yapılırsa bellek içeriği değişir. Linux'ta LiME ile bellek, ardından disk dd. Her adımın hash ve zamanını deftere yazın.

Bulut diskleri
AWS EBS snapshot / Azure disk snapshot adli süreçte sık kullanılır. Snapshot'tan yeni volume yaratıp salt okunur bağlamak, çalışan instance'ı kapatmadan kanıt almayı sağlar. Snapshot ID, bölge ve IAM yetkisini zincir of custody'ye ekleyin.

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.

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.

Ek DosyalarEkran Görüntüleri

Windows'ta Sysinternals: TCPView, Autoruns ve Process Explorer Pratikleri

KulTigin 10-18-2026, 09:21 PM · Windows ve Güvenlik

0 30

Merhaba,

Windows olay müdahalesinde ilk açtığım üç araç neredeyse hep aynı: Process Explorer, Autoruns ve TCPView. Hepsi Microsoft Sysinternals ailesinden, ücretsiz ve taşınabilir. Bu yazıda bunları sahada nasıl kullandığımı, nelere baktığımı ve sık gördüğüm tuzakları anlatacağım. Ortam: kendi Windows 11 lab VM'im.

Araçları güvenli edinmek
Resmi kaynak: Microsoft Sysinternals sayfası (learn.microsoft.com altında Sysinternals). ZIP'i indirip doğrulayın; "sysinternals gibi görünen" sahte siteler var. Taşınabilir kullanım için araçları imzalı USB'de tutuyorum; şüpheli makinede internetten indirmiyorum.

Process Explorer: süreç ağacı ve şüpheli çocuklar
Görev Yöneticisi'nden farkı: süreç ağacını, DLL'leri, handle'ları ve doğrulanmış imza bilgisini bir arada gösterir.

Options > Verify Image Signatures: imzasız binary'leri hemen görün.
View > Lower Pane View > DLLs: sürecin yüklediği DLL'ler (sideloading ipucu).
Şüpheli süreçte sağ tık > Properties > Strings / TCP/IP / Image.

Labda bilerek çalıştırdığım bir test process'inde parent'ın explorer.exe değil de bilinen bir LOLBin (ör. rundll32) olması kırmızı bayraktır. Parent-child ilişkisi SOC'ta 4688 ile de takip edilir; Process Explorer bunu canlı gösterir.

Autoruns: kalıcılık avcısı
Saldırganın en sevdiği şey yeniden başlatınca geri gelmektir. Autoruns; Run anahtarları, Scheduled Tasks, Services, WMI, Winlogon, AppInit_DLLs ve daha onlarcasını tek ekranda listeler.

Kod:
# Komut satırı sürümü (otomatik rapor için)
autorunsc64.exe -a * -c -h -s > C:\Temp\autoruns.csv

Pratik alışkanlıklarım:

Options > Hide Microsoft Entries (dikkat: saldırgan Microsoft gibi görünen isimler kullanabilir; tam tarama da yapın).
Verify Code Signatures açık olsun.
Bilinmeyen publisher + User klasörü altında path = inceleyin.
Scheduled Tasks'ta "powershell -enc" veya temp yolları = yüksek öncelik.

Temiz bir baseline'ı altın imajdan alıp şüpheli makineyle karşılaştırmak çok hızlandırır.

TCPView: kim dışarı bağlanıyor?
netstat güzeldir ama TCPView süreç adıyla birlikte canlı bağlantıyı gösterir. Şüpheli bir EXE'nin bilinmeyen bir IP:port'a ESTABLISHED olması, EDR yokken bile hızlı sinyaldir.

Options > Resolve Addresses: bazen kapatın (hız + DNS gürültüsü olmasın).
Şüpheli satırda sağ tık > Process Properties / Whois (dikkat: whois dışarı sorgu gönderir; hassas olayda önce IP'yi not alıp izole ortamda soruşturun).

PowerShell ile benzer bilgi:

Kod:
Get-NetTCPConnection -State Established |
  Select LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess |
  Format-Table -AutoSize

TCPView'in avantajı hız ve görsellik; betiğin avantajı otomatikleştirme.

USB müdahale çantamda neler var?

procexp64, autoruns64, tcpview64, handle64, listdlls64, sigcheck64, strings64
Küçük bir hash betiği (Get-FileHash) ve not defteri şablonu
Salt okunur çalıştırma alışkanlığı: mümkünse araçları USB'den çalıştır, çıktıyı ayrı kanıta yaz

sigcheck ile tek dosya imza kontrolü:

Kod:
sigcheck64.exe -accepteula -h C:\Users\Public\suspicious.exe

Sık tuzaklar

Aynı isimli meşru süreç: svchost.exe yolu C:\Windows\System32 dışında olmamalı.
DLL sideloading: meşru EXE + yanındaki şüpheli DLL; Process Explorer lower pane burada kurtarır.
Yalnızca GUI'ye güvenmek: çıktıyı CSV/log olarak alın, olay kaydına ekleyin.
Canlı sistemde "temizlik" yaparken kanıtı bozmak: önce topla, sonra müdahale et.

Mavi takım ile köprü
Bu üç araç L1/L2 analistin "elle doğrulama" katmanıdır. EDR varsa yine de kullanırım: EDR bazen aggregate gösterir, siz o anki süreci görürsünüz. Tespit kurallarınızı (4688, Sysmon 1/3/11, Prefetch) bu araçlarla çaprazlayın.

Kaynaklar

Microsoft Sysinternals resmi belgeleri
Windows Internals (süreç/handle modeli için)
SANS FOR500/FOR508 notları (canlı yanıt pratiği)

Sizin çantanızda olmazsa olmaz dördüncü araç hangisi? Ben ara sıra Process Monitor'ü de ekliyorum ama gürültüsü yüksek; filtre disiplini şart.

Process Monitor ne zaman devreye girer?
Procmon çok gürültülüdür; filtre olmadan açmayın. Senaryo: "Bu EXE hangi registry anahtarına yazıyor?" Operation is Registry + Process Name filtresi. Çıktıyı PML olarak kaydedip temiz makinede analiz edin. Canlı IR'de önce Process Explorer + Autoruns + TCPView; derinleşme gerekirse Procmon.

Imza ve hash'i ticket'a yazmak
sigcheck -h çıktısındaki SHA256'yı ticket'a ve MISP/IOC listesine ekleyin. "suspicious.exe" adı yetmez; ertesi gün dosya adı değişmiş olur. VirusTotal yüklemesi kurum politikasına bağlıdır; hassas örnekleri herkese açık VT'ye yüklemeyin, private instance veya iç sandbox kullanı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.

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.

Ek DosyalarEkran Görüntüleri

tcpdump ile Sahada En Çok Kullandığım Filtreler: BPF Mantığı ve Örnekler

KulTigin 10-18-2026, 07:16 PM · Ağ Güvenliği

0 42

Merhaba,

Wireshark güzel ama sahada çoğu zaman elinizde grafik arayüzü olmayan bir sunucu, bir SSH oturumu ve kısıtlı süre olur. O anlarda en hızlı dostum tcpdump. Yıllar içinde biriken not defterimdeki filtreleri, neden öyle yazıldıklarıyla birlikte paylaşmak istedim. Ezber listesinden çok "nasıl düşünülür" kısmına odaklandım.

Önce temel bayraklar
Her komutta neredeyse refleks olarak kullandığım seçenekler:

Kod:
sudo tcpdump -nn -i eth0 -c 50

-n: isim çözümlemesi yapma (DNS sorgusu üretmesin, çıktı hızlı gelsin)
-nn: hem host hem port isimlerini çözme
-i: arayüz seçimi; emin değilseniz -i any veya ip link ile bakın
-c: paket sayısı sınırı; unutunca terminali kilitleyen klasik hata
-w dosya.pcap: diske yaz; sonra Wireshark ile açarsınız
-r dosya.pcap: kayıtlı dosyayı oku
-A / -X: ASCII / hex+ASCII; HTTP gibi protokoller için

Yetki notu: ham paket yakalamak genelde CAP_NET_RAW ister. sudo veya setcap kullanın; üretimde setcap'i bilinçli verin.

BPF mantığı: filtre nasıl kurulur?
tcpdump'ın kalbi Berkeley Packet Filter ifadesidir. Mantık şudur: önce hangi trafiği istiyorsunuz (host, port, protokol), sonra bayrak ve içerik kısıtları. Operatörler: and, or, not. Parantez kullanın; öncelik karışıklığı klasik hata.

Host ve port:

Kod:
sudo tcpdump -nn -i eth0 host 10.0.0.5
sudo tcpdump -nn -i eth0 src host 10.0.0.5
sudo tcpdump -nn -i eth0 dst port 443
sudo tcpdump -nn -i eth0 'host 10.0.0.5 and port 22'

Sahada en çok işime yarayan filtreler

1) SYN taraması / yeni bağlantı avı

Kod:
sudo tcpdump -nn -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'

Sadece SYN (ACK yok) paketlerini gösterir. Ani SYN yağmuru port taraması veya flood belirtisi olabilir. Daha kısa yazım:

Kod:
sudo tcpdump -nn -i eth0 'tcp[13] & 2 != 0 and tcp[13] & 16 == 0'

13. bayt TCP bayrak alanı; 2=SYN, 16=ACK.

Labda örnek çıktı:

2) DNS sorguları

Kod:
sudo tcpdump -nn -i eth0 port 53

Olay müdahalesinde C2 alan adlarını yakalamak için ilk bakacağım yerlerden biri. UDP 53 dışında DoH (443) varsa bu filtre yetmez; o zaman DNS loguna geçersiniz.

3) Belirli bir HTTP host başlığı (şifresiz trafik)

Kod:
sudo tcpdump -nn -i eth0 -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

Karmaşık görünüyor ama anlamı "HTTP payload taşıyan paketler". Daha pratik alternatif: -A ile port 80'i yakalayıp greplemek veya hemen -w yazıp Wireshark'ta http.host filtresi kullanmak.

4) ARP ve yerel ağ gariplikleri

Kod:
sudo tcpdump -nn -i eth0 arp
sudo tcpdump -nn -i eth0 'arp and arp[6:2] == 2'

İkinci satır ARP reply'leri gösterir. Aynı IP için farklı MAC'ler görürseniz spoofing şüphesi.

5) Belirli bir konuşmayı (conversation) yakalamak

Kod:
sudo tcpdump -nn -i eth0 -w oturum.pcap 'host 10.0.0.5 and host 10.0.0.9'

İki uç arasındaki tüm trafiği kaydedip sonra Wireshark'ta Follow TCP Stream yaparsınız.

6) ICMP (ping, unreachable)

Kod:
sudo tcpdump -nn -i eth0 icmp

Path sorunlarında ve bazı tarama türlerinde işe yarar.

7) IPv6

Kod:
sudo tcpdump -nn -i eth0 ip6
sudo tcpdump -nn -i eth0 'ip6 and tcp port 22'

Birçok ortamda IPv6 unutuluyor; saldırganlar bunu seviyor.

Ring buffer ile uzun süre dinlemek
Disk doldurmadan saatlerce dinlemek için:

Kod:
sudo tcpdump -nn -i eth0 -W 10 -C 100 -w /var/tmp/capture.pcap 'not port 22'

-C 100: her dosya ~100 MB, -W 10: 10 dosyalık döngü. SSH oturumunuzu kendi yakalamanızdan boğmamak için not port 22 sık kurtarıcı olur.

Sorun giderme alışkanlıklarım

Önce arayüz doğru mu? ip -br a
Filtre çok mu dar? Geçici olarak filtreyi kaldırıp paket geliyor mu bakın.
Offload / checksum gariplikleri: Wireshark'ta "incorrect checksum" görürseniz çoğu zaman NIC offload kaynaklıdır; panik yapmayın.
Kapsüller (VLAN, GRE, VXLAN): basit host filtresi yetmeyebilir; vlan, proto gre gibi ekler gerekir.
Üretimde -w ile yazın, canlı ekranı izlemeyin; paket kaybı azalır.

tcpdump mu, tshark mı, Wireshark mı?
Hızlı doğrulama ve sunucu üstü yakalama: tcpdump. Aynı BPF'yi dosyada çalıştırıp alan çıkarmak: tshark. Derin protokol analizi ve Follow Stream: Wireshark. Üçü de aynı BPF dilini konuşur; öğrendiğiniz filtreler boşa gitmez.

Kaynaklar

tcpdump man sayfası ve pcap-filter (man 7 pcap-filter)
Wireshark Display Filter Reference (display filter BPF'den farklıdır; karıştırmayın)
Julia Evans'ın tcpdump cheatsheet notları (öğrenme için faydalı)

Sizin "olmazsa olmaz" filtreniz hangisi? Özellikle VLAN veya cloud mirror senaryolarında takılan varsa yazın, birlikte bakalım.

VLAN ve tünel paketlerinde BPF
Saha ağında mirror port VLAN tag taşıyorsa basit host filtresi yetmeyebilir:

Kod:
sudo tcpdump -nn -i eth0 'vlan and host 10.0.0.5'
sudo tcpdump -nn -e -i eth0 'vlan 120'

-e Ethernet başlığını gösterir; hangi VLAN'dan geldiğini anında görürsünüz. GRE/VXLAN için önce dış başlığı, sonra içeriği düşünün. Şüphede önce -w ile ham yakalayıp Wireshark'ta decode edin; canlı karmaşık BPF yazmak vakit kaybı olabilir.

Paket kaybı ve buffer
Yoğun trafikte tcpdump "dropped by kernel" uyarısı verebilir. -B ile buffer büyütün veya daha dar filtre uygulayın. Üretim olayında "her şeyi yakala" refleksi çoğu zaman boş dosya veya dolu disk ile biter; önce hipotez, sonra filtre.

Sık sorulanlar
tcpdump çıktısını sürekli diske yazarken rotasyon unutulursa disk dolar ve üretim servisi düşer. -C/-W kullanın. Konteyner içinde tcpdump için NET_RAW capability gerekir. Host ağındaki pod trafiğini görmek ayrı hikâye; CNI bridge üzerinde dinlemeniz gerekebilir. Şüpheli C2 avında önce DNS ve outbound 443 netflow'a bakın; kör tam paket yakalama son çaredir.

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.

Ek DosyalarEkran Görüntüleri

Linux'ta Dosya Bütünlüğü İzleme: AIDE Kurulumu, İlk Veritabanı ve Günlük Kontrol

KulTigin 10-18-2026, 07:14 PM · Linux Genel

0 42

Selam arkadaşlar,

Geçen ay bir test sunucusunda /usr/bin altındaki bir dosyanın tarihi dikkatimi çekti. Sonradan paket güncellemesi olduğu ortaya çıktı ama o an "bu dosya gerçekten değişti mi, ne zaman değişti?" sorusuna elimde net bir cevap yoktu. O günden beri kurduğum her Linux makinede ilk işlerden biri AIDE oluyor. Bu konuda AIDE'yi (Advanced Intrusion Detection Environment) sıfırdan kurmayı, ilk veritabanını oluşturmayı, gürültüyü azaltmayı ve kontrolü otomatiğe bağlamayı anlatacağım. Örnekler Debian 12 / Ubuntu 24.04 üzerinde; RHEL tarafındaki farkları da not düştüm.

AIDE tam olarak ne yapar?
AIDE bir dosya bütünlüğü izleme (FIM) aracıdır. Mantığı basit: sistem temizken seçtiğiniz dizinlerdeki dosyaların özniteliklerini (izinler, sahip, boyut, inode, değişiklik zamanı) ve hash değerlerini (SHA-256, SHA-512 vb.) bir veritabanına yazar. Sonraki her kontrolde mevcut durumu bu veritabanıyla karşılaştırır ve eklenen, silinen, değişen dosyaları raporlar.

Önemli nokta: AIDE gerçek zamanlı değildir. Bir saldırganın değiştirdiği dosyayı anında yakalamaz, bir sonraki taramada yakalar. Gerçek zamanlı izleme istiyorsanız auditd veya Wazuh'un syscheck modülü gibi araçlara bakmak gerekir. AIDE'nin gücü sadeliği ve bağımsız çalışabilmesidir.

Kurulum
Debian/Ubuntu:

Kod:
sudo apt update
sudo apt install aide aide-common
aide --version

RHEL / Rocky / Alma:

Kod:
sudo dnf install aide

Debian paketinde yapılandırma /etc/aide/aide.conf ve /etc/aide/aide.conf.d/ altında parçalı tutulur. RHEL tarafında tek dosya olarak /etc/aide.conf vardır. Bu fark, internetteki örnekleri birebir kopyalarken en sık takıldığım yer oldu.

İlk veritabanını oluşturmak
Debian ailesinde paketle gelen yardımcı betik işi kolaylaştırır:

Kod:
sudo aideinit

Bu komut veritabanını /var/lib/aide/aide.db.new dosyasına yazar ve ardından aide.db olarak kopyalar. RHEL tarafında elle yapılır:

Kod:
sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

İlk tarama disk boyutuna göre birkaç dakikadan yarım saate kadar sürebilir. Benim 40 GB'lık test VM'imde yaklaşık 6 dakika sürdü.

Çok kritik bir uyarı: veritabanını mutlaka temiz olduğundan emin olduğunuz bir anda oluşturun. Zaten ele geçirilmiş bir sistemde oluşturulan veritabanı, saldırganın değişikliklerini "normal" kabul eder.

Kontrol çalıştırmak ve çıktıyı okumak

Kod:
sudo aide --check --config /etc/aide/aide.conf

Ben test için bilerek /etc/passwd dosyasına bir test kullanıcısı ekledim. Çıktının özeti şuna benziyordu:

Çıktıdaki satır başındaki harf dosya tipini (f: dosya, d: dizin), ardından gelen sütunlar hangi özniteliğin değiştiğini gösterir. Örneğin boyut, mtime, ctime ve hash değişmişse ilgili sütunlarda işaret görürsünüz. Raporun alt kısmında "Detailed information about changes" bölümü eski ve yeni hash değerlerini tek tek listeler.

Çıkış kodu da önemlidir: AIDE değişiklik bulduğunda sıfırdan farklı bir kodla çıkar. Betiklerde bunu kullanarak alarm üretebilirsiniz.

Gürültüyü azaltmak: kural yazımı
Varsayılan yapılandırma ilk günlerde çok fazla satır üretir: log dosyaları, önbellekler, /var/lib altında sürekli değişen veriler... Bunları izlemenin anlamı yok. Kendi kurallarımı Debian'da /etc/aide/aide.conf.d/ altına ayrı bir dosya olarak koyuyorum:

Kod:
# /etc/aide/aide.conf.d/99_yerel
!/var/log
!/var/cache
!/var/lib/apt/lists
!/home/.*/\.cache
/etc        CONTENT_EX
/usr/bin    CONTENT_EX
/usr/sbin   CONTENT_EX
/boot       CONTENT_EX

Ünlem işareti (!) hariç tutma anlamına gelir. CONTENT_EX gibi grup adları ana yapılandırmada tanımlıdır; kendi grubunuzu da tanımlayabilirsiniz:

Kod:
BENIM = p+u+g+s+m+c+sha256
/opt/uygulama BENIM

Buradaki harfler: p izinler, u kullanıcı, g grup, s boyut, m mtime, c ctime. Tam liste için man 5 aide.conf kılavuzuna bakın.

Yapılandırmayı değiştirdikten sonra sözdizimini test etmek için:

Kod:
sudo aide --config-check --config /etc/aide/aide.conf

Meşru değişikliklerden sonra veritabanını güncellemek
Paket güncellemesi yaptığınızda yüzlerce dosya değişir. Bu durumda önce raporu gözden geçirip değişikliklerin beklenen olduğundan emin olun, sonra veritabanını yenileyin:

Kod:
sudo aide --update --config /etc/aide/aide.conf
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Benim alışkanlığım: her "apt upgrade" sonrası bir kontrol, rapor temizse güncelleme. Kontrol etmeden körlemesine güncelleme yapmak AIDE'yi anlamsız kılar.

Günlük otomatik kontrol
Debian paketi zaten /etc/cron.daily/aide betiğiyle günlük kontrol kurar ve sonuçları e-posta ile gönderir (MAILTO ayarı /etc/default/aide içinde). Systemd kullanan dağıtımlarda dailyaidecheck.timer da gelebilir:

Kod:
systemctl list-timers | grep -i aide

Kendi betiğinizi yazmak isterseniz basit bir örnek:

Kod:
#!/bin/bash
LOG=/var/log/aide/aide-$(date +%F).log
mkdir -p /var/log/aide
/usr/bin/aide --check --config /etc/aide/aide.conf > "$LOG" 2>&1
if [ $? -ne 0 ]; then
  logger -t aide "AIDE değişiklik tespit etti: $LOG"
fi

logger ile syslog'a yazınca SIEM'iniz bu satırı yakalayıp alarm üretebilir.

Veritabanını korumak
AIDE'nin en zayıf noktası şudur: root yetkisi alan bir saldırgan veritabanını da güncelleyebilir. Bu yüzden temiz veritabanının bir kopyasını salt okunur bir ortama alın, kontrol öncesi hash doğrulayın ve mümkünse AIDE binary'sinin kendisini de güvenilir bir kopyadan çalıştırın.

Kod:
sha256sum /var/lib/aide/aide.db > /root/aide.db.sha256

AIDE ne değildir?
AIDE size "ne değişti" der, "neden değişti" demez. Bir değişikliğin saldırı mı yoksa yönetici işlemi mi olduğunu anlamak için auditd kayıtları, paket yöneticisi geçmişi ve oturum loglarıyla birlikte değerlendirmek gerekir. Rootkit tespiti için de tek başına yeterli değildir.

Kaynaklar

AIDE resmi proje sayfası: aide.github.io
man aide, man 5 aide.conf
Red Hat Enterprise Linux Security Hardening belgesi, "Checking integrity with AIDE" bölümü

Siz FIM için hangi aracı kullanıyorsunuz? Wazuh syscheck ile AIDE'yi karşılaştıran olduysa deneyimini merak ediyorum.

Paket güncellemesi sonrası kontrol rutini
Üretimde unattended-upgrades veya Ansible ile yama dağıtıyorsanız AIDE veritabanını körlemesine güncellemek yerine şu sırayı kullanın: yama penceresi bitince aide --check, değişen dosyaların paket listesiyle kesişimini doğrula (dpkg -S /path veya rpm -qf), ardından --update. Kesişmeyen dosyalar (ör. /etc altında elle değiştirilmiş config) ayrı ticket ister.

Wazuh syscheck ile fark
Wazuh syscheck gerçek zamanlıa daha yakın (inotify) çalışabilir ve merkezi yöneticiden politika iter. AIDE ise ajan gerektirmeyen, tek makinelik, denetim izine kolay eklenen bir araçtır. Küçük lab veya internete kapalı sunucuda AIDE yeter; filo yönetiminde Wazuh/OSSEC ailesi daha ölçeklenir. İkisini birlikte kullananlar: AIDE'yi "altın imaj doğrulama", Wazuh'u "sürekli izleme" diye ayırır.

Sık sorulanlar
AIDE veritabanını NFS'e koymayın; saldırgan orayı da yazabilir. cron mail çalışmıyorsa logger + SIEM yolunu kullanın. İlk kurulumda /var ve /home'u olduğu gibi izlemek gürültü tsunami'sidir; önce /etc /bin /sbin /usr/bin /boot ile başlayın, sonra genişletin. Sunucu immutable infrastructure ise her deploy'da yeni baseline alın; AIDE'yi golden image pipeline'ının son adımı yapın.

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.

Ek DosyalarEkran Görüntüleri

Yapay Zeka Model Dosyası Güvenliği: pickle Tehlikesi, safetensors ve Güvenli Yükleme

Tonyukuk 10-18-2026, 07:12 PM · Yapay Zeka Güvenliği

0 49

Merhaba arkadaşlar,

Hugging Face gibi hub'lardan bir model indirip torch.load ile yüklediğinizde aslında ne çalıştırdığınızı biliyor musunuz? Yapay zeka tedarik zincirinin en gözden kaçan riski, model dosyalarının kendisidir. Python'ın pickle formatı, bir dosya yüklenirken rastgele kod çalıştırabilir; yani güvenilmeyen bir model dosyası, basit bir "yükleme" sırasında bilgisayarınızı ele geçirebilir. Bu rehberde model dosyası güvenliğini resmi PyTorch ve Hugging Face belgelerine dayanarak ele alıyor; pickle tehlikesini, safetensors çözümünü ve güvenli yükleme pratiklerini anlatıyorum. Bu, OWASP LLM03 (Tedarik Zinciri) ve LLM04 (Veri/Model Zehirleme) risklerinin somut tarafıdır.

Konuda Anlatılacaklar

Model dosyası neden bir güvenlik riski?
pickle nasıl kod çalıştırır?
PyTorch 2.6 ve weights_only varsayılanı
safetensors: güvenli format
Hugging Face tarafında güvenlik
Güvenli yükleme kontrol listesi
Tedarik zinciri sertleştirme

Model Dosyası Neden Bir Güvenlik Riski?

Bir model dosyası sadece sayılardan (ağırlıklardan) ibaret sanılır. Oysa yaygın formatların çoğu (.pt, .bin, .ckpt, .pkl) Python'ın pickle serileştirmesini kullanır. pickle, veriyi geri yüklerken nesneleri yeniden oluşturmak için kod çalıştırabilir. Kötü niyetli biri, modelin içine yüklendiği anda tetiklenen bir yük yerleştirebilir. Sonuç: "zararsız" görünen bir model dosyası, indirip yüklediğinizde arka kapı kurabilir, veri çalabilir veya komut çalıştırabilir.

pickle Nasıl Kod Çalıştırır?

pickle, bir nesnenin nasıl yeniden oluşturulacağını tarif eden talimatlar içerir ve __reduce__ gibi mekanizmalarla yükleme sırasında fonksiyon çağırabilir. Kavramı göstermek için zararsız bir örnek (yalnızca kendi makinenizde, eğitim amaçlı):

Kod:
import pickle, os

class Zararsiz:
    def __reduce__(self):
        # gercek saldiride burada tehlikeli bir komut olurdu
        return (os.system, ("echo 'model yuklenirken calisti'",))

veri = pickle.dumps(Zararsiz())
pickle.loads(veri)   # yukleme aninda echo calisir

Buradaki ders: pickle.loads (ve onu kullanan torch.load) güvenilmeyen veride asla körlemesine çağrılmamalıdır. Python'ın resmi pickle belgesi de en başında bu uyarıyı yapar: pickle güvenli değildir, yalnızca güvendiğiniz veriyi açın.

PyTorch 2.6 ve weights_only Varsayılanı

İyi haber: PyTorch bu riske karşı önemli bir değişiklik yaptı. PyTorch 2.6 sürüm notlarına ve resmi belgeye göre torch.load artık varsayılan olarak weights_only=True ile çalışır. Bu mod, açmayı yalnızca tensörler, temel tipler, sözlükler ve açıkça izin verilen (allowlist) güvenli global'lerle sınırlar; keyfi kod çalıştırmayı engeller.

Kod:
import torch
# Guvenli (varsayilan): yalnizca agirliklar ve guvenli tipler
state = torch.load("model.pt")           # weights_only=True (varsayilan)

Güvenilmeyen bir dosyada asla weights_only=False kullanmayın. Güvendiğiniz eski bir dosyada özel bir sınıf gerekiyorsa, onu açıkça izin listesine ekleyin:

Kod:
torch.serialization.add_safe_globals([MyConfigClass])
state = torch.load("eski-model.pt", weights_only=True)

safetensors: Güvenli Format

En sağlam çözüm, pickle kullanmayan bir formattır. Hugging Face'in safetensors formatı tam da bunun için tasarlandı: yalnızca tensör verisini saklar, kod çalıştırma mekanizması içermez; ayrıca daha hızlı yüklenir. safetensors dosyaları .safetensors uzantılıdır ve kendi yükleyicisiyle açılır:

Kod:
from safetensors.torch import load_file
state = load_file("model.safetensors")   # pickle yok, kod calismaz

Mümkün olan her yerde .bin/.pt yerine .safetensors tercih edin. Bir modelin hem .bin hem .safetensors sürümü varsa, safetensors olanı seçin.

Hugging Face Tarafında Güvenlik

Hugging Face Transformers belgelerine göre, kütüphane mümkün olduğunda otomatik olarak safetensors'ı tercih eder; eski .bin yüklemesinde ise torch.load'u weights_only=True ile çağırır. Ek olarak Hugging Face Hub, yüklenen model dosyalarını pickle içeriğine karşı tarar ve tehlikeli içe aktarmalar bulunursa uyarı gösterir. Yine de bu taramalar mutlak güvence değildir; sorumluluk indiren taraftadır. Güvenilir yayıncılardan, sürümü sabitlenmiş (pinned revision) modeller indirin:

Kod:
from transformers import AutoModel
model = AutoModel.from_pretrained(
    "kurulus/model-adi",
    revision="<commit-hash>",   # surumu sabitle
)

Güvenli Yükleme Kontrol Listesi

Format: safetensors varsa onu kullan.
weights_only: torch.load'da varsayılanı (True) koru; güvenilmeyen dosyada False kullanma.
Kaynak: Yalnızca güvenilir yayıncı ve sabitlenmiş sürüm.
İzolasyon: Yeni/şüpheli modelleri önce internet erişimi olmayan bir sanal makinede veya konteynerde dene.
Tarama: İndirdiğin dosyaları pickle tarayıcılarıyla (ör. Hub'ın uyarıları, picklescan gibi araçlar) kontrol et.

İleri Seviye: Tedarik Zinciri Sertleştirme

Model dosyası, YZ tedarik zincirinin tek halkası değil. OWASP LLM03 kapsamında bütünsel bir yaklaşım:

Bağımlılıklar: transformers, torch gibi kütüphaneleri güncel tutun ve bilinen zafiyetlere karşı tarayın (pip-audit).
Bütünlük doğrulama: İndirdiğiniz model dosyalarının karma (hash) değerini yayıncının beyanıyla karşılaştırın.
Veri zehirleme (LLM04): İnce ayar (fine-tuning) verinizin kaynağını doğrulayın; zehirlenmiş eğitim verisi arka kapı davranışı yerleştirebilir.
SBOM: Kullandığınız model ve veri setlerinin bir envanterini (yazılım malzeme listesi mantığıyla) tutun.

Basit bir bütünlük kontrolü:

Kod:
sha256sum model.safetensors
# yayincinin belirttigi hash ile karsilastirin

Sonuç

Bir model dosyası yüklemek, güvenilmeyen kaynaktan geliyorsa kod çalıştırmak kadar risklidir. Korunmak basit: safetensors kullanın, torch.load'un weights_only=True varsayılanını bozmayın, güvenilir ve sürümü sabitlenmiş kaynaklardan indirin ve şüpheli modelleri izole ortamda deneyin. Böylece YZ tedarik zincirinizin en zayıf halkasını kapatmış olursunuz. Siz model indirirken hangi kontrolleri yapıyorsunuz? Yorumlarda paylaşın.

Kaynakça

PyTorch, torch.load belgesi: https://docs.pytorch.org/docs/stable/gen....load.html
PyTorch 2.6 sürüm notu (weights_only varsayılanı): https://pytorch.org/blog/pytorch2-6/
Hugging Face, safetensors: https://huggingface.co/docs/safetensors/index
Hugging Face, Loading models (safetensors tercihi): https://huggingface.co/docs/transformers/en/models
Python, pickle güvenlik uyarısı: https://docs.python.org/3/library/pickle.html
Hugging Face, Pickle Scanning: https://huggingface.co/docs/hub/security-pickle
OWASP LLM Top 10 2025 (LLM03/LLM04): https://genai.owasp.org/llm-top-10/

Yasal Uyarı

Bu rehberdeki örnek kodlar yalnızca kendi bilgisayarınızda, eğitim ve savunma amacıyla çalıştırılmalıdır. Zararlı pickle yüklerini başkalarına ait sistemlerde denemek veya dağıtmak 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek DosyalarEkran Görüntüleri

Linux Kullanıcı ve İzin Yönetimi: chmod, chown, umask ve ACL Rehberi

KulTigin 10-18-2026, 06:34 PM · Linux Genel

0 39

Selam TurkTeam,

Linux'ta güvenliğin temeli izinlerdir. "Bu dosyayı kim okuyabilir, kim çalıştırabilir, kim değiştirebilir?" sorusunun cevabı; bir sunucunun ne kadar sağlam ya da ne kadar savunmasız olduğunu doğrudan belirler. Bu rehberde Linux izin modelini sıfırdan ele alıyor; chmod, chown, umask, özel izin bitleri (SUID/SGID/sticky) ve klasik modelin yetmediği yerde devreye giren ACL'yi uygulamalı olarak anlatıyoruz.

Konuda Anlatılacaklar

Linux izin modeli: kullanıcı/grup/diğer ve rwx
chmod: sembolik ve sayısal (oktal) kullanım
chown ve chgrp: sahiplik yönetimi
umask: varsayılan izinlerin belirlenmesi
Özel bitler: SUID, SGID, sticky bit
ACL: getfacl / setfacl ile ince ayar
Sonuç, kaynakça ve yasal uyarı

1. İzin Modeli: Üç Sınıf, Üç Yetki
Her dosya ve dizinin bir sahibi (user), bir grubu (group) ve bir de diğerleri (others) sınıfı vardır. Her sınıf için üç yetki tanımlanır: okuma ®, yazma (w) ve çalıştırma (x). İzinleri görmek için:

Kod:
ls -l dosya.txt

Çıktı şuna benzer:

Kod:
-rw-r--r-- 1 ahmet ekip 1024 Oct 17 14:00 dosya.txt

Baştaki 10 karakteri çözelim: ilk karakter tür (- dosya, d dizin, l sembolik bağ), sonraki üçlü sahip (rw-), ortadaki üçlü grup (r--), son üçlü diğerleri (r--) izinleridir. Yani sahibi okuyup yazabilir, grup ve diğerleri yalnızca okuyabilir.

Dizinlerde x yetkisinin anlamı özeldir: bir dizine "girip" içindeki yollara erişebilmek için x gerekir; r ise yalnızca listeleme yetkisidir.

2. chmod: İzin Değiştirme
chmod'u iki biçimde kullanırsınız: sembolik ve sayısal (oktal).

Sembolik kullanım (u=user, g=group, o=other, a=all; +ekle, -kaldır, =eşitle):

Kod:
chmod u+x script.sh          # sahibe çalıştırma ekle
chmod go-w dosya.txt         # grup ve diğerlerinden yazmayı kaldır
chmod a=r dosya.txt          # herkese yalnızca okuma

Sayısal (oktal) kullanım: r=4, w=2, x=1 değerlerinin toplamı her sınıf için bir rakam verir:

Kod:
chmod 644 dosya.txt    # rw-r--r--
chmod 755 script.sh    # rwxr-xr-x
chmod 600 gizli.key    # rw------- (yalnızca sahibi)

Dizinleri özyinelemeli değiştirmek için -R kullanın, ancak dikkatli olun:

Kod:
chmod -R 750 /opt/uygulama

3. chown ve chgrp: Sahiplik
Bir dosyanın sahibini ve/veya grubunu değiştirmek için chown kullanılır (genelde root yetkisi gerekir):

Kod:
sudo chown ahmet dosya.txt           # sahibi değiştir
sudo chown ahmet:ekip dosya.txt      # sahip ve grup
sudo chgrp ekip dosya.txt            # yalnızca grup
sudo chown -R ahmet:ekip /srv/proje  # özyinelemeli

Sahiplik, izinlerle birlikte düşünülmelidir: 600 izinli bir anahtar dosyası, yanlış kullanıcıya ait olursa koruması anlamını yitirir.

4. umask: Varsayılan İzinler
Yeni oluşturulan dosya ve dizinler, umask değerine göre izin alır. umask, verilmeyecek bitleri maskeler. Tipik varsayılan 022'dir:

Kod:
umask          # mevcut değeri göster
umask 027      # yeni dosyalara daha sıkı varsayılan

Hesaplama mantığı: dosyalarda taban 666, dizinlerde 777'dir ve umask bundan çıkarılır. 022 umask ile yeni dosya 644, yeni dizin 755 olur. 027 ile dosya 640, dizin 750 olur; yani "diğerleri" hiçbir erişim almaz. Kalıcı yapmak için ~/.bashrc veya /etc/profile içine umask satırı eklenir.

5. Özel Bitler: SUID, SGID, Sticky
Klasik rwx'in üstünde üç özel bit vardır ve güvenlik açısından kritiktir.

SUID (4): Çalıştırılabilir dosya, sahibinin yetkisiyle çalışır. Örnek: passwd komutu root SUID'lidir, böylece sıradan kullanıcı parolasını değiştirebilir.
SGID (2): Dosyada grup yetkisiyle çalıştırma; dizinde ise içinde oluşturulan dosyaların dizin grubunu devralmasını sağlar (ortak çalışma dizinleri için idealdir).
Sticky bit (1): Dizinde, bir kullanıcının yalnızca kendi dosyasını silebilmesini sağlar. /tmp dizini buna klasik örnektir.

Ayarlama:

Kod:
chmod u+s program       # SUID
chmod g+s paylasim/      # SGID dizin
chmod +t /ortak/alan     # sticky bit

Sistemdeki SUID dosyaları denetim için önemlidir; yanlış yapılandırılmış bir SUID, yetki yükseltmeye yol açabilir:

Kod:
find / -perm -4000 -type f 2>/dev/null

Bu komut root SUID'li ikilileri listeler; beklenmedik bir giriş varsa incelenmelidir.

6. ACL: getfacl ve setfacl
Klasik model yalnızca tek sahip, tek grup ve diğerlerini tanımlar. "Bu dosyaya Ayşe de yazsın ama başka kimse değil" gibi ince ihtiyaçlarda ACL (Access Control List) devreye girer.
Mevcut ACL'yi görme:

Kod:
getfacl dosya.txt

Belirli bir kullanıcıya izin verme:

Kod:
setfacl -m u:ayse:rw dosya.txt

Bir gruba izin ve varsayılan (yeni dosyalara miras) ACL:

Kod:
setfacl -m g:ekip:rx klasor/
setfacl -d -m g:ekip:rx klasor/

ACL kaldırma:

Kod:
setfacl -x u:ayse dosya.txt   # tek kayıt
setfacl -b dosya.txt          # tüm ACL

ls -l çıktısında izinlerin sonundaki "+" işareti, o dosyada ek ACL kayıtları olduğunu gösterir. ACL güçlüdür ancak karmaşıklığı artırır; yalnızca klasik modelin yetmediği yerde kullanın.

7. İleri Seviye ve İyi Uygulamalar

En az ayrıcalık: Her zaman gereken en dar izni verin; 777'den kaçının, bu neredeyse her zaman hatalı bir çözümdür.
Anahtar ve sır dosyaları: SSH özel anahtarları 600 olmalı, aksi halde istemci bağlanmayı reddeder.
Düzenli denetim: Dünyaya yazılabilir dosyaları bulun:
Kod:
find / -perm -0002 -type f 2>/dev/null
Değişmezlik: Kritik dosyaları kazara değişikliğe karşı chattr +i ile değişmez yapabilirsiniz (ext4):
Kod:
sudo chattr +i /etc/onemli.conf

Sonuç
Linux izin yönetimi, karmaşık görünse de birkaç sağlam kavrama dayanır: üç sınıf, üç yetki, özel bitler ve gerektiğinde ACL. chmod/chown/umask üçlüsünü ve SUID/SGID/sticky mantığını iyi oturtmak, hem sistemlerinizi sertleştirmenizi hem de bir denetimde zayıf noktaları hızla görmenizi sağlar. "En az ayrıcalık" ilkesini her kararın merkezine koyun.

Kaynakça

GNU Coreutils El Kitabı (chmod, chown) - https://www.gnu.org/software/coreutils/manual/
chmod(1), chown(1), umask(1p) man sayfaları
setfacl(1) / getfacl(1) man sayfaları - https://man7.org/linux/man-pages/man1/setfacl.1.html
Arch Wiki: File permissions and attributes - https://wiki.archlinux.org/title/File_pe...attributes
Debian Yönetici El Kitabı - https://www.debian.org/doc/

Yasal Uyarı

Alıntı:İzin ve sahiplik değişiklikleri yalnızca kendi sistemlerinizde veya yönetim yetkiniz olan sistemlerde yapılmalıdır. Başkasının sistemine izinsiz müdahale Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek DosyalarEkran Görüntüleri

tmux ile Terminal Verimliliği: Pentest İçin Oturum ve Panel Yönetimi

KulTigin 10-18-2026, 06:32 PM · Linux Genel

0 40

Merhaba TurkTeam,

Uzun süren taramalar, SSH üzerinden yönetilen hedefler ve aynı anda koşan onlarca komut... Bir pentest ya da sistem yönetimi oturumunda en büyük düşmanınız, bağlantı koptuğunda çalışan işlerinizin de ölmesidir. İşte tmux (terminal multiplexer) tam burada devreye girer: tek bir terminalde birden çok oturum, pencere ve paneli yönetmenizi, bağlantı kopsa bile işlerin arka planda sürmesini sağlar. Bu rehberde tmux'u sıfırdan, pentest akışına odaklanarak ele alıyoruz.

Konuda Anlatılacaklar

tmux nedir, neden kullanılır (session/window/pane kavramları)
Kurulum ve ilk çalıştırma
Prefix tuşu ve temel kısayol referansı
Uygulamalı: kopan bağlantıya dayanıklı tarama oturumu
Panel bölme, pencere yönetimi ve kopyalama modu
İleri seviye: ~/.tmux.conf ile özelleştirme
Sonuç, kaynakça ve yasal uyarı

1. tmux Nedir, Neden Kullanılır?
tmux, tek bir terminal penceresini birden çok sanal terminale bölen bir "terminal çoğullayıcı"dır. Üç temel kavramı vardır:

Session (oturum): İçinde pencere ve panellerin barındığı en üst kapsayıcı. Oturumdan "detach" olup (ayrılıp) daha sonra "attach" ile geri dönebilirsiniz.
Window (pencere): Oturum içindeki bir sekme gibidir; her biri tam ekrandır.
Pane (panel): Bir pencerenin yatay/dikey bölünmüş parçası; aynı ekranda birden çok kabuk.

Pentest'te en kritik faydası kalıcılıktır: SSH ile bir sunucuya bağlanıp uzun bir Nmap/Gobuster taraması başlattığınızda, bağlantı koparsa klasik kabukta iş ölür. tmux oturumunda ise iş sürmeye devam eder; yeniden bağlanıp attach olduğunuzda kaldığınız yerden devam edersiniz.

2. Kurulum ve İlk Çalıştırma

Kod:
sudo apt update
sudo apt install tmux
tmux -V

İsimli bir oturum başlatmak, sonradan bulmayı kolaylaştırır:

Kod:
tmux new -s denetim

3. Prefix Tuşu ve Kısayol Referansı
tmux komutlarının çoğu bir prefix tuşundan sonra verilir. Varsayılan prefix Ctrl+b'dir (aşağıda "C-b" olarak gösterilir). Önce prefix'e, sonra ilgili tuşa basarsınız.

Oturumdan ayrılma (detach): İş sürerken terminale geri dönmek için.

Kod:
C-b d

Dikey panel bölme:

Kod:
C-b %

Yatay panel bölme:

Kod:
C-b "

Paneller arası geçiş:

Kod:
C-b ok-tuşları

Yeni pencere / pencereler arası geçiş:

Kod:
C-b c      (yeni pencere)
C-b n      (sonraki)
C-b p      (önceki)
C-b 0..9   (numaraya git)

Paneli kapatma:

Kod:
C-b x

Komut satırından oturum yönetimi (prefix'siz):

Kod:
tmux ls                 # oturumları listele
tmux attach -t denetim  # oturuma geri dön
tmux kill-session -t denetim

4. Uygulamalı: Kopmaya Dayanıklı Tarama Oturumu
Adım 1 - Oturum aç ve uzun bir iş başlat:

Kod:
tmux new -s tarama
nmap -sV -p- 192.168.56.101 -oN tam_tarama.txt

Adım 2 - Oturumdan ayrıl (iş arkada sürer):

Kod:
C-b d

Terminalde "[detached (from session tarama)]" mesajını görürsünüz. Artık SSH bağlantınız kopsa bile Nmap çalışmaya devam eder.

Adım 3 - Daha sonra geri dön:

Kod:
tmux attach -t tarama

Tarama devam ediyorsa onu görürsünüz; bittiyse çıktıyı tam_tarama.txt dosyasında bulursunuz:

Kod:
tail -n 20 tam_tarama.txt

5. Panel ve Pencere ile Çoklu İş
Pentest'te sık senaryo: bir panelde tarama, diğerinde notlar, üçüncüsünde hedefe açık bir SSH. Bir pencereyi ikiye bölüp ikisinde ayrı iş yürütün:

Kod:
C-b %        # dikey böl
C-b "        # alt paneli yatay böl

Panel boyutunu ayarlamak için prefix'i basılı tutup ok tuşlarıyla yeniden boyutlandırabilir (C-b sonrası alt+ok veya :resize-pane komutu) veya bir paneli tam ekran yapıp geri küçültebilirsiniz:

Kod:
C-b z        # aktif paneli büyüt/küçült (zoom)

Kopyalama modu: Uzun çıktıda yukarı kaydırmak ve metin kopyalamak için kopyalama moduna girin:

Kod:
C-b [        # kopyalama moduna gir, ok/PageUp ile gez, q ile çık

Bu mod, kaydırma çubuğu olmayan uzak oturumlarda çıktı incelemeyi çok kolaylaştırır.

6. İleri Seviye: ~/.tmux.conf ile Özelleştirme
Varsayılan prefix (C-b) bazılarına rahatsız gelir; birçok kullanıcı onu C-a yapar. Ayrıca fare desteği ve daha büyük geçmiş tamponu verimliliği artırır. Örnek bir yapılandırma:

Kod:
# ~/.tmux.conf
set -g prefix C-a
unbind C-b
bind C-a send-prefix
set -g mouse on
set -g history-limit 100000
setw -g mode-keys vi

Değişiklikleri çalışan oturuma uygulamak için:

Kod:
tmux source-file ~/.tmux.conf

mouse on ile paneller fareyle seçilip boyutlandırılabilir; history-limit uzun tarama çıktılarının kaybolmamasını sağlar. vi kip tuşları kopyalama modunda vi alışkanlıklarını getirir.

Bir diğer güçlü alışkanlık, iş bazlı isimli oturumlardır: her müşteri/hedef için ayrı bir oturum (tmux new -s musteri1) açmak, işleri birbirine karıştırmadan paralel yürütmeyi sağlar. Günün sonunda tmux ls ile tüm aktif işlerinizi tek bakışta görürsünüz.

6.1. tmux, screen ve Pratik Alışkanlıklar
tmux'un en yakın alternatifi GNU screen'dir. screen daha eski ve yaygın olarak çoğu sunucuda hazır bulunur; tmux ise daha modern yapılandırma, daha güçlü panel yönetimi ve daha okunur bir durum çubuğu sunar. Yeni bir alışkanlık ediniyorsanız tmux'a yatırım yapmanızı öneririm, ancak bir sunucuda yalnızca screen varsa benzer mantıkla (Ctrl+a tabanlı kısayollar) iş görebileceğinizi bilin. İkisinin de ortak amacı aynıdır: oturumu kabuktan ayırıp işi yaşatmak.

Pentest sırasında tmux'u asıl değerli kılan, bir hedefe uzun süren bir işlem başlatıp bağlantıyı güvenle bırakabilmenizdir. Örneğin saatler sürebilecek bir tam port taraması, bir dizin keşfi ya da bir parola denetimi başlattığınızda, dizüstünüzü uyku moduna alıp eve gidebilir, ertesi gün attach olup kaldığınız yerden devam edebilirsiniz. Bu, özellikle sınırlı zaman penceresi olan kurumsal testlerde zaman kazandırır ve kesintiye bağlı veri kaybını önler.

Verimliliği artıran birkaç alışkanlık: her göreve anlamlı bir oturum adı verin, böylece tmux ls çıktısı okunur kalsın; sık kullandığınız panel düzenini bir kabuk fonksiyonu veya tmux betiğiyle otomatikleştirin; uzun çıktıları dosyaya da yazdırın (-oN, tee gibi) ki tmux geçmiş tamponuna bel bağlamayın. Son olarak, durum çubuğunu özelleştirerek saat, oturum adı ve aktif pencereyi görünür kılmak, aynı anda birçok iş yürütürken kafa karışıklığını ciddi biçimde azaltır.

Bir uyarı: tmux oturumu makine yeniden başlatıldığında kaybolur; kalıcılık yalnızca aynı oturum açıkken geçerlidir. Gerçekten kritik, günlerce sürecek işler için işleri bir servis veya nohup ile arka plana almayı da değerlendirin. tmux, insan etkileşimli oturumları yaşatmakta mükemmeldir; uzun ömürlü otomasyon için ise servisleştirme daha doğru bir yaklaşımdır.

Sonuç
tmux, terminalde çalışan herkesin verimliliğini kökten artıran bir araçtır; pentest'te ise bağlantı kopmalarına karşı sigortanızdır. Önce session/window/pane üçlüsünü ve prefix mantığını oturtun, ardından ~/.tmux.conf ile kendinize göre ayarlayın. Birkaç gün bilinçli kullanımdan sonra kısayollar kas hafızanıza yerleşir ve geri dönmek istemezsiniz.

Kaynakça

tmux Resmi Deposu ve Wiki - https://github.com/tmux/tmux/wiki
tmux(1) Man Sayfası - https://man.openbsd.org/tmux.1
tmux Getting Started - https://github.com/tmux/tmux/wiki/Getting-Started
Kali Belgeleri - https://www.kali.org/docs/
man tmux (yerel man sayfası)

Yasal Uyarı

Alıntı:tmux bir verimlilik aracıdır; onunla yürüttüğünüz tüm testler yalnızca kendi sistemlerinizde veya yazılı izinli hedeflerde yapılmalıdır. İzinsiz erişim ve test Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek DosyalarEkran Görüntüleri

Command Injection: OS Komut Enjeksiyonu ve Güvenli Kodlama Rehberi

BilgeKagan 10-18-2026, 06:31 PM · Web Uygulama Güvenliği

0 38

[center]

[/center]

Selam millet, BlueTornado burada.

Command Injection (OS komut enjeksiyonu), uygulamanın kullanıcı girdisini işletim sistemi kabuğuna güvensiz biçimde iletmesiyle oluşur. SQL Injection veritabanını hedeflerken, command injection doğrudan sunucu sürecini hedefler; etki çoğu zaman kritiktir. Bu yazıda CWE-78 bağlamında teori, DVWA/lab gözlemi ve güvenli kodlama odaklı korunma anlatılır.

Konuda Anlatılacaklar

Command injection nedir?
Kodlama hataları: shell=True, string birleştirme
Lab ortamı ve güvenli gözlem
Metacharacter'lar ve çıktı yorumlama
Korunma: API'ler, allowlist, least privilege
İleri seviye: argument injection, kör enjeksiyon
Kaynakça ve yasal uyarı

1) Teori
Birçok uygulama ping, traceroute, görüntü işleme, yedekleme gibi işler için dış komut çağırır. Girdi kabuğa birleşirse saldırgan ek komut zincirleyebilir.

Kod:
# Tehlikeli Python kalıbı
import os
ip = request.args["ip"]
os.system("ping -c 1 " + ip)
# ip = 127.0.0.1; id   -> kabuk ; ile ikinci komutu çalıştırabilir

Kod:
# Tehlikeli PHP kalıbı
system("ping -c 1 " . $_GET["ip"]);

OWASP Top 10 2021'de Injection (A03) ailesindedir. CWE: CWE-78 (OS Command Injection). Argument injection (CWE-88) yakından ilişkilidir: kabuk olmasa bile program argümanları kötüye kullanılabilir.

2) Lab Kurulumu
DVWA Command Injection sayfası klasik bir örnektir.

Kod:
cd DVWA && docker compose up -d
# Security: Low

Alternatif: kendi izole VM'inizde bilerek zayıf küçük bir Flask uygulaması (internete açmayın).

[center][/center]

3) Kavram Referansı

Kabuk metacharacter örnekleri (bilgi amaçlı):

Kod:
# Komut ayırıcı / zincir (Unix)
; && || |
# Yerine koyma
`...`  $(...)
# Yönlendirme
> >>

Güvenli çağrı: Kabuğu devre dışı bırakıp argüman listesi geçmek.

Kod:
import subprocess
subprocess.run(["ping", "-c", "1", ip], check=False)
# shell=False (varsayılan) — ip artık yeni komut başlatamaz
# AMA ip'nin ping'e özel zararlı argüman olup olmadığı ayrı konudur

Allowlist:

Kod:
import ipaddress
def validate_ip(s: str) -> str:
    return str(ipaddress.ip_address(s))  # geçersizse exception

4) DVWA Low: Adım Adım Gözlem
Yalnızca kendi DVWA'nızda:

Adım 1 - Normal:

Kod:
127.0.0.1
# Beklenen: ping çıktısı

Adım 2 - Zincir gözlemi (lab):

Kod:
127.0.0.1; uname -a

Low seviyede çoğu kurulumda hem ping hem uname çıktısı görünür. Bu, girdinin kabuğa gittiğinin kanıtıdır.

[center][/center]

Adım 3 - Filtreli seviyeler: Medium'da

Kod:
&&

Kod:
;

gibi karakterler engellenmiş olabilir. Kara liste kırılgandır (

Kod:
%0a

satır sonu vb. labda araştırılır). Impossible seviyede allowlist / güvenli API beklenir.

Kod:
# Not şablonu
Seviye: Medium
Payload: 127.0.0.1; id
Sonuç: ; silindi / komut çalışmadı / hata
Çıkarım: blacklist

Adım 4 - Çıktıyı yorumlama:

Ek komut çıktısı görünüyorsa RCE etkisi vardır
Çıktı görünmese bile time-based kör enjeksiyon mümkün olabilir
Uygulama hangi OS kullanıcısı ile çalışıyor? (www-data vb.) — least privilege kritik

5) Güvenli Kodlama

Mümkünse hiç dış komut çağırmayın; dilin kendi kütüphanesini kullanın
Çağrı zorunluysa
Kod:
subprocess
/
Kod:
execve
argüman dizisi;
Kod:
shell=True
yasak
Girdiyi allowlist ile doğrulayın (IP, enum, sabit seçenekler)
Kullanıcı girdisini asla komut şablonuna birleştirmeyin
Uygulamayı düşük yetkili kullanıcı ile çalıştırın; container'da root'tan kaçının
Gerekli binary'lere filesystem izni sınırlayın

Kod:
# İyi: IP doğrulama + argüman listesi
import ipaddress, subprocess
ip = str(ipaddress.ip_address(user_input))
subprocess.run(["ping", "-c", "1", ip], capture_output=True, text=True, timeout=5)

Kod:
# Kötü
subprocess.run(f"ping -c 1 {user_input}", shell=True)

Kod:
# Node.js kötü
const { exec } = require("child_process");
exec("ping -c 1 " + ip);

# Daha iyi yönde: execFile / spawn ile argüman dizisi + doğrulama
const { execFile } = require("child_process");
execFile("ping", ["-c", "1", ip]);

[center][/center]

6) İleri Seviye
Argument injection:

Kod:
tar

Kod:
ffmpeg

Kod:
sendmail

gibi programlar

Kod:
-o

Kod:
--

ile başlayan girdilerde beklenmedik davranış sergileyebilir. Allowlist ve

Kod:
--

ayırıcısı düşünün.

Kod:
# Kavramsal
subprocess.run(["some-tool", "--", user_path])

Blind command injection: Çıktı sayfaya basılmaz;

Kod:
sleep

veya dışarıya DNS/HTTP callback (yalnızca kendi labınız) ile tespit edilir. Üretimde izinsiz outbound callback kullanmayın.

Şablon motorları / CI: Build script'lerine kullanıcı kontrollü alan enjekte etmek de aynı sınıftır.

Kod:
# Rapor
Bulgu: OS Command Injection (CWE-78)
Konum: /vulnerabilities/exec/ ip parametresi
Kanıt: Labda ; uname -a çıktısı
Öneri: subprocess argüman listesi + IP allowlist + düşük yetki

7) Sonuç
Command injection, kabuğa güvenilmeyen veri vermektir. Kara liste değil, güvenli API + allowlist + least privilege ile kapatılır. DVWA'da Low'da görün, Impossible'da doğru kodu okuyun.

Ek: Tespit, Loglama ve Kod İnceleme İpuçları
Mavi takım / kod inceleme perspektifinden şunlara bakın:

Kod:
# Grep ile tehlike işaretleri (kendi repo'nuz)
rg -n "os\\.system|shell=True|exec\\(|popen\\(|child_process\\.exec" .

Kod:
# Uygulama logunda (kavramsal)
{"event":"extcmd","bin":"ping","args":["-c","1","127.0.0.1"],"user":"www-data"}
# Argümanlar ayrık loglanmalı; kabuk satırı tek string olarak loglanıyorsa tasarım zayıf olabilir

WAF ve filtre yanılgısı:

Kod:
;

karakterini engellemek çözüm değildir. Base64 ile kodlanmış ikinci aşama, boşluk yerine

Kod:
$IFS

gibi varyasyonlar lab ortamlarında anlatılır; üretimde kök nedeni (güvenli API) düzeltin.

Konteyner sertleştirme:

Distroless veya minimal imaj;
Kod:
bash
/
Kod:
curl
yoksa etki azalır (yine de binary çalıştırma mümkün olabilir)
Read-only kök dosya sistemi + tmpfs
Capability drop, seccomp, non-root user

Kod:
# Dockerfile parçası
USER nobody
# HEALTHCHECK ve minimal paket seti

[center][/center]

Kod incelemesinde "bu girdi allowlist'ten mi geçiyor?" sorusu, "filtre yeterli mi?" sorusundan daha değerlidir.

Kaynakça

Yasal Uyarı
Komut enjeksiyonu testleri yalnızca kendi sistemleriniz veya yazılı izinli lab/pentest içindir. İzinsiz RCE denemesi TCK 243-245 kapsamında ağır suç olabilir. Sorumluluk uygulayana aittir.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek DosyalarEkran Görüntüleri

Toplam (30) Sayfa:« Önceki 1 … 12 131415 16 … 30 Sonraki »