Siber güvenlik topluluğunun nabzı

Selam,

PowerShell modern Windows'ta yönetim dili; saldırganlar da bunu biliyor. Script Block Logging kapalıysa SIEM kör kalır. Bu yazıda Script Block, Module Logging ve Transcription'ı labda nasıl açacağınızı ve nelere dikkat edeceğinizi anlatıyorum.

Üç katman

• Module Logging: belirli modüllerin pipeline olayları
  
• Script Block Logging: derlenen script block metni (Event ID 4104)
  
• Transcription: oturumun metin kaydı (dosyaya)
  

GPO / yerel politika
Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell altında ilgili ayarları Enabled yapın. Labda kayıt defteri ile:
Transcription:
OutputDirectory ACL'ini sıkı tutun; transcript içinde parola olabilir.


Logları okumak
Event Viewer > Applications and Services Logs > Microsoft > Windows > PowerShell > Operational
4104 mesajında ScriptBlock metni vardır. EncodedCommand kullanan saldırılarda burada decode edilmiş içerik görünebilir (motor derlediği için).

Gürültü ve gizlilik

• Yoğun yönetim scriptleri log hacmini şişirir; WEF ile merkezi toplayın
  
• Transcription'da secret geçmesin diye SecureString ve gizli kasa kullanın
  
• Constrained Language Mode + AppLocker/WDAC ile birlikte düşünün
  

Saldırgan kaçınması
Logging'i kapatan / log silen davranışları ayrıca izleyin (4104'ün aniden kesilmesi, Event Log servisi oynamaları). Protected Event Logging (dokümante kurulum) ileri adım olabilir.

Kaynaklar

• Microsoft Docs: about_Logging_Windows_PowerShell
  
• FireEye / Mandiant PowerShell logging blogları (tarihsel referans)
  
• Sigma rules: powershell script block
  

Siz Transcription'ı tüm workstation'larda mı açıyorsunuz, yoksa yalnızca sunucu/jump host'ta mı?

4104 boyutları ve WEF
Script Block logları büyük olabilir; WEF'te bandwith planlayın. Gerekirse yalnızca belirli sunucu gruplarında tam logging, workstation'da örnekleme. Yine de jump host / bastion'da tam açın; saldırgan oradan geçer.

PowerShell 7 vs 5.1
Logging ayarları sürüm ve host'a göre değişebilir. pwsh (Core) ve Windows PowerShell için politikaları ayrı doğrulayın. Test: küçük bir script çalıştırıp 4104 düşüyor mu bakı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.

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 Dosyalar

Ekran Görüntüleri
       

Merhaba,

Azure Blob'da yanlışlıkla public container bırakmak hâlâ klasik bulgu. Bu yazıda genel erişim seviyeleri, SAS riskleri ve denetim için pratik kontrolleri anlatıyorum. Örnekler kendi lab aboneliğim üzerinden.

Erişim katmanları

• Private: anonim erişim yok
  
• Blob: anonim kullanıcı blob bilgisini URL ile okuyabilir
  
• Container: listeleme de açık (daha kötü)
  

Depolama hesabında "Allow blob public access" kapalıysa container public yapsanız bile engellenir. İkisini birden kontrol edin.



SAS token tuzakları
Shared Access Signature geçici yetki verir; fakat:

• Çok uzun expiry (yıllarca) = fiilen anahtar
  
• İzinlerin fazla olması (write+delete+list)
  
• HTTPS zorunluluğu olmaması
  
• SAS'ın GitHub'a / mobil uygulamaya gömülmesi
  

Tercihen user delegation SAS (Azure AD kimliğiyle) kullanın; hesap anahtarıyla üretilen SAS sızıntısında rotasyon daha acı olur.

Denetim ve tespit

• Azure Resource Graph / Policy ile public container taraması
  
• Diagnostic settings: StorageRead/Write loglarını Log Analytics'e
  
• Microsoft Defender for Storage (ortamınızda varsa) anomali uyarısı
  
• CI'da Terraform plan: public_access != null ise fail
  

Örnek Resource Graph düşüncesi: storage container'larında publicAccess alanı boş olmayanlar.

Sıkılaştırma adımları

1. Hesapta public access'i kapat
   
2. Gerekli anonim dağıtım varsa Azure CDN + kontrollü origin kullan
   
3. Firewall: selected networks + private endpoint
   
4. Shared key access'i mümkünse kapatıp AAD'ye geç
   
5. SAS için kısa TTL + minimum permission
   

Olay senaryosu
Public container'da müşteri verisi bulunduysa: hemen private yap, SAS/account key rotate et, logdan kim indirmiş bak, KVKK sürecini tetikle. "URL'yi gizledik" yetmez; URL zaten indekslenmiş olabilir.

Kaynaklar

• Microsoft Learn: Azure Storage security guide
  
• Azure Security Benchmark - Storage
  
• SAS best practices (Microsoft Docs)
  

Siz storage hesaplarında shared key'i kapatabildiniz mi, yoksa eski uygulamalar mı engelliyor?

Private endpoint ve DNS
Storage'ı private endpoint arkasına alınca eski public URL'ler kırılır; uygulamaları güncelleyin. DNS zone'ları (privatelink) doğru değilse geliştirici "Azure bozuldu" diye public'i geri açar — en sık regressiyon.

Lifecycle ve soft delete
Yanlışlıkla silinen kanıt / yedek için soft delete ve versioning açın. Fidye senaryosunda immutable storage (WORM) politikaları ayrı başlıktır; en azından kritik konteynerlerde versioning açık olsun.


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.

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 Dosyalar

Ekran Görüntüleri
       

Selam,

AWS'te en sık gördüğüm bulgu hâlâ aşırı geniş IAM izinleri: Action "*" ve Resource "*". Bu yazıda en az yetki için Access Analyzer ve Policy Simulator'ı kendi hesabınızda (lab) nasıl kullanacağınızı anlatıyorum.

En az yetki pratiği

• İnsan kullanıcı yerine rol + kısa ömürlü kimlik bilgisi
  
• Admin Access'i günlük iş için vermeyin; break-glass hesabı ayırın
  
• Wildcard Action'ları gerekçelendirin veya kaldırın
  
• SCPs ile organizasyon sınırları (AWS Organizations)
  

IAM Access Analyzer
Analyzer, hesap dışına açılan erişimleri ve (kullanım tipine göre) kullanılmayan izinleri bulmanıza yardım eder. Konsolda IAM > Access Analyzer veya CLI:
Bulgular: public S3, çapraz hesap rol güveni, beklenmeyen principal'lar. Her bulguyu "bilinçli mi?" diye işaretleyin; bilinçliyse arşivleyip gerekçe yazın.


Policy Simulator
Bir rolün belirli Action'ı yapıp yapamayacağını denemek için:
Çıktıdaki EvalDecision: allowed / implicitDeny / explicitDeny. CI boru hattında yeni policy PR'ları için simülasyon koşturmak FP'li prod olaylarını azaltır.

İzin sınırları (permissions boundary)
Geliştiriciye politika ekleme hakkı verirken boundary ile tavan koyun. Böylece kendini admin yapamaz. CloudFormation / Terraform modüllerinde boundary ARN'sini zorunlu tutun.

Son 90 gün erişim önerileri
IAM konsolunda Access Advisor, bir rolün kullandığı servisleri gösterir. Kullanılmayan geniş yönetilen politikaları daraltmak için başlangıç noktasıdır; körlemesine silmeyin, önce staging'de deneyin.

Kontrol listesi

1. Root kullanıcıda MFA + kasa; günlük iş yok
   
2. Access Analyzer aktif, haftalık gözden geçirme
   
3. Public bulgular için alarm (EventBridge)
   
4. CI'da policy-as-code (например, IAM Access Analyzer policy validation / OPA)
   

Kaynaklar

• AWS IAM User Guide - Access Analyzer
  
• AWS Policy Simulator dokümantasyonu
  
• CIS AWS Foundations Benchmark
  

Siz wildcard temizliği için Access Advisor mı, yoksa CloudTrail tabanlı araçlar mı kullanıyorsunuz?

Örnek daraltma hikâyesi
AmazonS3FullAccess yerine ListBucket + GetObject + belirli bucket ARN. PutObject gerekiyorsa ayrı rol. CI rolü ile insan rolünü ayırın. Access Analyzer unused access bulgularını 30 günde bir sprint backlog'una taşıyın; birikirse kimse okumaz.

Policy as code
Terraform aws_iam_policy_document kullanırken heredoc JSON yapıştırmayın; argument'ler review edilebilir kalsın. PR'da simulate-principal-policy veya IAM Access Analyzer policy validation çalıştırı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.

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 Dosyalar

Ekran Görüntüleri
       

Merhaba,

SIEM'e log akıtmaya başlamadan önce en sık atlanan konu: saat senkronu. Dağınık zaman damgaları korelasyonu öldürür; saldırı zaman çizelgesi güveneceği kalmaz. Bu yazıda neden kritik olduğunu ve Linux'ta chrony ile nasıl düzelteceğinizi anlatıyorum.

Ne bozulur?

• Aynı oturumun firewall logu 14:01, sunucu auth logu 13:48 görünür
  
• Kerberos / sertifika doğrulama hataları (saat kayması)
  
• SIEM kuralı "5 dakika içinde 10 fail" eşiğini kaçırır veya yanlış tetikler
  
• Adli zaman çizelgesi mahkemede / postmortem'de çöker
  

chrony kurulumu (Debian/Ubuntu)
Reference ID ve System time satırlarına bakın. "Last offset" mikrosaniye-milisaniye bandındaysa iyidir; saniyelerce kayma varsa kaynak veya firewall UDP/123 sorununa bakın.


Kaynak seçimi
Kurumsal ortamda iç NTP (domain controller veya dedicated NTP) kullanın. Ev labında pool.ntp.org veya ülkenizdeki pool uygun olabilir. /etc/chrony/chrony.conf örneği:
Değişince:

Windows tarafı (kısa)
Domain'e üyeyse genelde DC'den alır. Workgroup labında:
Hyper-V / VMware misafirlerinde host zaman senkronu ile guest NTP çakışabilir; tek kaynak seçin.

SIEM kontrol listesi

1. Tüm kaynaklarda UTC mi, yoksa local time mı? Belgeleyin.
   
2. Normalize ederken timezone alanını koruyun.
   
3. Dashboard'a "en çok kayan host" paneli koyun (offset metric).
   
4. Yeni kaynak onboarding: önce NTP, sonra agent.
   

Hızlı teşhis
Konteynerlerde host saati geçer; VM'lerde RTC + NTP birlikte düşünülmeli.

Kaynaklar

• chrony resmi dokümantasyon
  
• RFC 5905 (NTP)
  
• NIST zaman hizmetleri bilgilendirmeleri
  

Sizin SIEM'inizde saat kaymasından doğan en komik (veya acı) yanlış alarm neydi?

Virtualizasyon tuzakları
VMware Tools / Hyper-V time sync host'u kaynak alırken guest chrony de dış NTP'ye giderse osilasyon görürsünüz. Tek kaynak seçin. Snapshot'a geri dönüş eski saate de döndürebilir; snapshot sonrası chronyc makestep düşünün.

Dağıtık izleme metriği
node_exporter veya osquery ile chrony offset metriğini Prometheus'a alın; 100ms üstü için alarm. SIEM'den önce bu alarm çoğu "garip korelasyon" ticket'ını önler.


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.

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 Dosyalar

Ekran Görüntüleri
       

Merhaba,

"SIEM'de 2000 kuralımız var" demek coverage demek değildir. MITRE ATT&CK ile detection coverage haritası, hangi tekniklerde kör olduğunuzu gösterir. Bu yazıda küçük bir SOC'un Excel/Spreadsheet ile bile yapabileceği pratik yöntemi anlatıyorum.

ATT&CK'ı ne kadar derin kullanmalı?
Enterprise matrisinde yüzlerce teknik var. Hepsini yeşile boyamak hedef değil. Önce kurumunuza uygun tehdit modeli: ransomware, BEC, içeriden tehdit, tedarik zinciri... Sonra ilgili tactic/technique alt kümesi.

Basit harita nasıl kurulur?
Satırlar: Technique ID (ör. T1003.001). Sütunlar: Veri kaynağı (process, auth, dns, proxy, endpoint), Kural var mı?, Test edildi mi?, Son test tarihi, Sahip.
Renk:

• Yeşil: tespit var + son 90 günde test edildi
  
• Sarı: kural var ama test yok / yüksek FP
  
• Kırmızı: veri var, kural yok
  
• Gri: veri yok (önce telemetri)
  

Veri kaynağı gerçekliği
Kural yazmadan önce telemetri var mı bakın. Process Command Line yoksa "suspicious powershell" kuralı hayaldir. Windows'ta en azından:

• Security 4624/4625/4688
  
• Sysmon 1/3/7/11 (mümkünse)
  
• DNS / proxy log
  
• Kimlik sağlayıcı (AD / Entra) audit
  

Atomik test ile doğrulama
Red Canary Atomic Red Team gibi kontrollü testler (yalnız kendi lab/izinli ortam) kuralın gerçekten tuttuğunu gösterir. Test sonrası:
Üretimde rastgele atomik çalıştırmayın; change penceresi ve izin şart.

Önceliklendirme

1. Kritik varlıkları etkileyen teknikler
   
2. Son 12 ayda sektörünüzde görülen teknikler
   
3. Kolay kazanım: telemetrisi hazır, kuralı basit olanlar
   

Raporu yönetime "yüzde 80 coverage" diye sunmak yerine "ransomware kill chain'de 3 kör nokta" diye sunun; aksiyon çıkar.

Yaygın kör noktalar

• Living-off-the-land (LOLBins) — imza ile zor
  
• Bulut yönetim düzlemi (Azure/AWS API) — endpoint odaklı SOC kaçırır
  
• Mac/Linux endpoint telemetrisi eksikliği
  
• E-posta kimlik doğrulama loglarının SIEM'e gelmemesi
  

Kaynaklar

• MITRE ATT&CK resmi site
  
• ATT&CK Navigator (katman dosyası paylaşımı)
  
• Atomic Red Team
  
• SigmaHQ (kural fikirleri)
  

Siz coverage'ı Navigator ile mi, yoksa servis kataloğuyla mı yönetiyorsunuz? Küçük ekip deneyimleri özellikle değerli.

Navigator katmanı paylaşımı
ATT&CK Navigator JSON katmanını ekipler arası paylaşmak, Excel renginden daha taşınabilirdir. Her major detection eklenince katmanı güncelleyin; çeyreklik gözden geçirmede kırmızı tekniklerden 3 tanesini yeşile çekme hedefi koyun.

Threat-informed defense
Sektörünüze ait tehdit raporlarındaki technique ID'leri haritaya "priority" olarak işaretleyin. Genel matris yüzdesi yerine "bu çeyrek ransomware zinciri coverage" KPI'sı yönetime daha anlamlı gelir.


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.

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 Dosyalar

Ekran Görüntüleri
       

Selam,

Olay müdahalesinde ilk 15 dakika çoğu zaman sonraki 15 saati belirler. Bu yazıda panik yerine karar ağacı kullanan bir L1/L2 disiplini anlatıyorum. Kurum playbook'unuz varsa o üstündür; bu metin boşluğu doldurmak içindir.

Dakika 0-2: ne olduğunu tek cümlede yaz
"Ne gördük, nerede, ne zaman, kim bildirdi?" Ticket'a düz metin. Spekülasyon yok. Örnek: "Satış ekibinden 3 kullanıcı aynı anda sahte Microsoft girişi bildiriyor; 14:02 TRT."

Dakika 2-5: güvenlik hijyeni ve kanıt

• Etkilenen hesabı/cihazı izole etmeden önce politika: izolasyon mu, yoksa izleme mi?
  
• Ekran görüntüsü + ham log zaman damgası
  
• Saat dilimi notu (Europe/Istanbul); SIEM UTC ise dönüşümü yaz
  

Karar ağacı (özet)


Dakika 5-10: iletişim
Tek kanal seçin (IR chat / telefon köprüsü). Herkese ayrı ayrı yazmak kaosu büyütür. Roller:

• Olay komutanı (karar)
  
• Teknik analist
  
• İletişim (iş birimleri)
  
• Varsa hukuk / KVKK noktası
  

"Her şeyi herkese mail atma" kuralı: durum özeti 5-10 dakikada bir, net madde işaretleriyle.

Dakika 10-15: kısa çevreleme

• Etkilenen hesaplarda aktif oturum listesi
  
• Firewall / proxy'de bilinen kötü IOC blok (geçici)
  
• Yedekleme işlerinin çalıştığını doğrula (silme/encryption senaryosu)
  
• Dışa açık yönetim panellerinde anomali
  

Windows'ta oturum düşürme örneği (lab/politika dahilinde):
Entra ID / bulut için Unified Audit Log ve "Revoke sessions" prosedürünüzü hazır tutun.

Yapmayın

• Kanıt almadan disk silmek / yeniden kurmak
  
• Saldırganla "pazarlık" maili
  
• Herkese açık Slack'te IOC paylaşmak (sızıntı riski)
  
• Saat senkronu bozuk sunucuda zaman çizelgesi kurmak
  

15. dakikada elde olması gerekenler

1. Tek cümlelik durum
   
2. Etki tahmini (düşük/orta/yüksek) — gerekçeli
   
3. Uygulanan çevreleme adımları
   
4. Sonraki checkpoint zamanı
   
5. Escalate edildi mi?
   

Kaynaklar

• NIST SP 800-61 (Computer Security Incident Handling Guide)
  
• SANS PICERL modeli
  
• Kurumunuzun IR runbook'u
  

Sizin ilk 15 dakikada en çok atlanan adım hangisi oldu? Bizde uzun süre "tek cümlelik durum" eksikti.

Severity'yi erken sabitlemeyin
İlk 15 dakikada "critical" ilan etmek panik yaratır; "bilinmiyor, çevreleme uygulandı" daha dürüsttür. Severity'yi checkpoint'te güncelleyin. Yönetime giden mesajda teknik jargon yerine iş etkisi: "fatura sistemi yazılamıyor", "e-posta gecikiyor".

Müşteri / regülasyon hattı
Kişisel veri sızıntısı şüphesinde KVKK bildirim süreleri devreye girebilir. IR ekibi hukuk ile erken konuşsun; teknik ekip tek başına "bildirmeyelim" kararını vermesin. İlk 15 dakikanın işi hukuku bilgilendirmek olabilir, resmi bildirimi tamamlamak değil.


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.

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 Dosyalar

Ekran Görüntüleri
       

L1 SOC'ta phishing kuyruğu hiç bitmez. SOAR yoksa bile tutarlı bir 10 adımlık liste işleri hızlandırır ve kaçanı azaltır. Bu yazı kendi kullandığım SOAR'sız triage notlarıdır; kurum politikasını ezmez, üzerine giydirin.

0. Güvenlik hijyeni
Analizi izole bir VM'de veya sandbox'ta yapın. Üretim hesabınızda şüpheli eki açmayın. Linklere kendi tarayıcınızdan tıklamak yerine URL'yi kopyalayıp sandbox'ta açın.

10 adım
1) Bildirimi kaydet
Ticket no, bildirenin birimi, zaman (UTC+3 notuyla). Orijinal .eml/.msg dosyasını ekleyin; ekran görüntüsü yetmez.

2) Başlıkları oku (header)
From, Reply-To, Return-Path, Received zinciri. Display name "IT Destek" iken adres rastgele domain ise klasik.

3) Kimlik doğrulama sonuçları
SPF / DKIM / DMARC Authentication-Results satırına bakın. fail/softfail tek başına yeterli değil ama skorunuzu etkiler.

4) URL'leri çıkar, çöz
Kısaltıcıları sandbox'ta expand edin. Benzer domain (rnicrosoft.com) avı yapın.


5) Ekleri hash'le, açma
Hash'i VT / kurum sandbox'ına sorun (politikanıza göre). Makro'lu Office ve ISO/IMG taşıyıcılar hâlâ yaygın.

6) İçerik dili ve senaryo
Aciliyet, korku, ödül; fatura, kargo, HR, IT reset. Senaryoyu bir cümlede ticket'a yazın.

7) İç / dış etki
Aynı mail 1 kişiye mi, 500 kişiye mi geldi? Mail gateway logunda subject + message-id arayın.

8) IOC listesi üret
Domain, URL, ek SHA-256, varsa gönderen IP. Paylaşım formatını standardize edin (CSV yeterli).

9) Kontrol önerisi
Gateway'de blok, URL rewrite kategorisi, kullanıcıya "tıklama" duyurusu. L2'ye escalate kriterleri: credential harvest sayfasına giriş yapılmış olması, ek çalıştırılmış olması.

10) Kapanış
Yanlış pozitif ise nedenini yazın (öğrenme). Gerçek phishing ise kısa postmortem: hangi kontrol kaçırdı?

Kullanıcıya dönüş şablonu (kısa)
"Bildirdiğiniz ileti phishing olarak değerlendirildi. Lütfen bağlantıya tıklamayın / ek açmayın. Parola girdiyseniz hemen IT ile parola sıfırlama prosedürünü uygulayın."

Sık L1 hataları

• Yalnızca spam kutusu gibi davranıp header okumamak
  
• IOC'siz "phishing'tir" deyip kapatmak
  
• Kullanıcıya suçlayıcı dil
  
• Sandbox dışında ek çalıştırmak
  

Kaynaklar

• CIS Controls - Email and Browser Protections
  
• RFC 7208/6376/7489 (SPF/DKIM/DMARC kavramsal)
  
• Kurumunuzun IR playbook'u (asıl kaynak)
  

Sizin 11. adımınız ne olurdu? SOAR'a geçerken hangi adımı ilk otomatikleştirdiniz?

Header'da Received zinciri
En alttaki Received genelde kullanıcıya en yakın sunucudur; yukarı çıktıkça köken görünür. Sahte "Received" uydurmak mümkündür; SPF/DKIM ile çaprazlayın. Relay gibi görünen üçüncü taraf (pazarlama platformu) meşru olabilir; domain benzerliği tek başına karar değildir.

Kullanıcı tıklamışsa
URL rewrite / proxy logunda 200 mü dönmüş, kimlik bilgisi formu mu açılmış bakın. EDR'da process tree: outlook -> browser -> powershell zinciri var mı? L2'ye "tıklanmış olabilir" diye değil, kanıtla escalate edin.


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.

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 Dosyalar

Ekran Görüntüleri
       

Ev Wi-Fi'sinde WPA3 görünüp Transition Mode açık kalınca aslında WPA2 istemciler hâlâ ağa girebiliyor. Bu yazıda WPA3-Personal (SAE), Transition Mode'un ne anlama geldiğini ve evde neyi açıp neyi kapalı tutmanızı önerdiğimi anlatıyorum. Modelden modele menü adı değişir; mantık aynı.

WPA3-Personal ne getiriyor?
Klasik WPA2-Personal (PSK) önceden paylaşılan parolaya dayanır. El sıkışme yakalanırsa (ve parola zayıfsa) çevrimdışı kırma denemeleri yapılabilir. WPA3-Personal'da SAE (Simultaneous Authentication of Equals) kullanılır; forward secrecy açısından daha iyi bir el sıkışme sunar. Parola hâlâ güçlü olmalıdır; WPA3 sihirli değnek değildir.

Transition Mode nedir?
Üreticiler uyumluluk için "WPA2/WPA3-Personal" veya "Transition" sunar. Ağ hem SAE hem de WPA2-PSK istemcileri kabul eder. Eski TV / IoT cihazınız bağlanır; fakat ağın saldırı yüzeyi WPA2'ye de açık kalır. Yani "WPA3 yazıyor" görmek tek başına yeterli değil.


Ev için önerdiğim ayar

1. Ana SSID: mümkünse WPA3-Personal only (Pure WPA3)
   
2. Eski cihazlar için ayrı IoT / misafir SSID: WPA2-PSK + güçlü parola + istemci izolasyonu
   
3. WPS: kapalı
   
4. UPnP: mümkünse kapalı veya yalnızca güvendiğiniz cihazlara
   
5. Yönetim arayüzü: yalnızca kablolu veya ayrı yönetim VLAN; WAN'dan erişim kapalı
   
6. Firmware: güncel
   

Router'da kontrol listesi
Arayüzde şu satırları arayın:

• Authentication: WPA3-SAE / WPA3-Personal
  
• WPA2 + WPA3 mixed / transition: IoT SSID dışında kapalı
  
• PMF / Protected Management Frames: WPA3'te zorunlu; WPA2'de "capable/required" seçenekleri
  
• Şifreleme: AES; TKIP kalıntısı varsa kapatın
  

İstemci tarafı
Windows 11, güncel Android ve iOS WPA3'ü destekler. Desteklemeyen cihazları zorla ana ağa almak yerine IoT ağında izole edin. Misafir ağında AP/istemci izolasyonu, komşu odadaki misafirin ev NAS'ını taramasını engeller.

Parola ve kurtarma

• En az 16+ karakter, parola; her SSID için farklı
  
• QR ile paylaşım pratik; parolayı buzdolabı magnetine yazmayın
  
• ISP'nin verdiği varsayılan SSID/parola kombinasyonunu değiştirin
  

Nasıl doğrularsınız?
Telefondan bağlanıp bağlantı detayında "WPA3" göründüğünü kontrol edin. Linux'ta:
Gelişmiş: Wireshark ile kendi el sıkışmanızı labda incelemek (yalnız kendi ağınız).

Sık yanlışlar

• Transition açık bırakıp "ben WPA3'eyim" demek
  
• Aynı parolayı 5 yıldır hiç değiştirmemek
  
• Misafir ağını ana LAN ile köprülemek
  
• Uzaktan yönetim (WAN HTTP/HTTPS) açık bırakmak
  

Kaynaklar

• Wi-Fi Alliance WPA3 spesifikasyon özeti
  
• Üretici firmware güvenlik bültenleri
  
• NIST kablosuz güvenlik rehberleri (genel prensipler)
  

Sizin evinizde Pure WPA3'e engel olan cihaz neydi? IoT SSID ayıranlar deneyimini yazarsa faydalı olur.

Kurumsal / WPA3-Enterprise notu
Ev odaklı bu yazının dışında kurumlarda WPA3-Enterprise (EAP-TLS) tercih edilir. Transition Mode burada da benzer tuzaklar taşır. BYOD ve misafir ağlarını ayrı SSID + ayrı VLAN olmadan "biraz WPA3" ile çözmeye çalışmayın.

Komşu saldırı yüzeyi
Aynı kanal kalabalığı ve sahte AP (evil twin) WPA3 ile de sosyal mühendislik vektörüdür. Evde SSID yayınını gizleme güvenlik sağlamaz; güçlü parola + WPA3 + yönetici arayüzü sıkılaştırması asıl işi yapar. Misafire ana NAS erişimi vermeyin.


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 Dosyalar

Ekran Görüntüleri
       

Merhaba,

Her pentest lab oturumunda aynı uzun komutları yazmak can sıkıcı. Ama rastgele alias da tehlikeli: yanlış host'a agresif tarama göndermek bir tuş kadar yakın olabilir. Bu yazıda kendi .bashrc notlarımı, güvenli alışkanlıklarla birlikte paylaşıyorum.

Temel: nerede tutmalı?
Kali/Parrot'ta bazen .zshrc kullanırsınız; shell'inizi bilin. Alias'ları git ile dotfiles reposunda tutuyorum (sır yok; API anahtarı koymayın).

Güvenli ve faydalı alias örnekleri


Fonksiyon > uzun alias
Parametre alan işler için function yazın:
Bu pattern "çıktıyı kaydetmeyi unuttum" felaketini azaltır.

Tehlikeli kısayollar (yapmayın)

• alias nmap='nmap -T5 -A -p-' — her seferinde agresif; yanlış hedefte felaket
  
• Hedefi sabit kodlayan alias'lar (eski müşteri IP'si kalabilir)
  
• curl | sh benzeri kısayollar
  
• Parola / API anahtarı içeren export'lar (dotfiles sızarsa biter)
  

Onay isteyen sarmalayıcı
Agresif işler için bilinçli onay:

Ortam değişkenleri
Proxy gereken labda:
Kalıcı proxy alias'ı yerine direnv veya elle export tercih ederim; unutulmuş proxy daha sonra her curl'ü bozar.

tmux ile birleştirmek
Alias'lar tek terminalde işe yarar; uzun taramayı tmux'ta koşturun. Benim sık kullandığım:

Paylaşılabilir dotfiles disiplini

• Sırları ayrı tut (pass, gopass, 1Password CLI)
  
• Makineye özel dosyayı .bashrc.local diye ayırıp git'e koyma
  
• alias listesini periyodik gözden geçir; kullanılmayanı sil
  

Kaynaklar

• bash(1) ALIASES ve FUNCTIONS bölümleri
  
• tmux wiki
  
• trash-cli
  

Sizin en çok zaman kazandıran fonksiyonunuz hangisi? Zararsız olanları yorumda paylaşın; agresif tarama one-liner'larını lütfen paylaşmayın.

direnv ve proje bazlı ortam
Her müşteri labı için ayrı dizin + .envrc (direnv) kullanıyorum. Proxy, hedef IP, VPN arayüzü o dizine girince yüklenir; çıkınca iner. Global alias'a hedef IP gömmek yerine bu yöntem yanlış müşteriye paket gönderme riskini azaltır.

Tamamlama ve güvenlik
bash-completion nmap için kullanışlıdır ama tab-complete ile yanlış bayrağı seçebilirsiniz. Kritik komutlarda --help satırını bir kez daha okuma alışkanlığı, agresif alias'tan daha çok can kurtarır.


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 Dosyalar

Ekran Görüntüleri
       

CTF forensics sorularında en çok pcap geliyor. Bu yazıda Wireshark ile flag avında izlediğim yolu, filtreleri ve sık görülen tuzakları kendi pratik notlarımdan derledim. Örnekler genel teknik; spesifik yarışma sorusu spoiler'ı yok.

İlk 60 saniye kontrol listesi

1. Capture Options değil; File > Open ile pcap'i aç
   
2. Statistics > Protocol Hierarchy: hangi protokoller var?
   
3. Statistics > Conversations / Endpoints: kim kiminle konuşmuş?
   
4. File > Export Objects: HTTP, SMB, IMF... dosya sızmış mı?
   

Protocol Hierarchy'de birdenbire "Data" şişmesi, tünel veya özel protokol ipucu olabilir.

Display filter vs capture filter
Capture filter BPF'dir (tcpdump ile aynı aile). Display filter Wireshark'a özgüdür ve daha ifade gücüdür. CTF'de dosya zaten kaydedilmiş olduğu için display filter kullanırsınız.


HTTP üzerinden dosya çıkarmak
Sonra Export Objects > HTTP. İndirilen PNG/JPEG içinde stego olabilir; strings + binwalk laboratuvarı ayrı hikâye.

TCP stream takip
Şüpheli pakette sağ tık > Follow > TCP Stream. Aynı bağlantının uygulama verisini birleşik görürsünüz. "Show data as" seçeneğini ASCII / Hex / UTF-8 arasında değiştirin; flag bazen Base64'tür.

DNS tüneli ve şüpheli sorgular
Uzun, rastgele alt alan adları veya TXT kayıtları tünel olabilir. Statistics > DNS ile sorgu dağılımına bakın.

USB / diğer link katmanı
Bazı CTF pcap'leri USBPcap ile alınmıştır. Protocol Hierarchy'de USB görürseniz korkmayın; Wireshark USB dekoratörleriyle cihaz tanımlayıcılarını ve interrupt transferlerini gösterebilir. Flag bazen HID tuş vuruşu olarak gelir (keystroke reconstruction).

Zaman ve parçalama

• View > Time Display Format > Seconds Since Beginning — akışı görmek kolaylaşır
  
• Parçalanmış IP / yeniden montaj: tercihlerde reassembly açık olsun
  
• VLAN etiketleri: vlan.id filtresi
  

Sık tuzaklar

• Yalnızca http.filter ile bakıp HTTPS içine flag aramak (şifreli; anahtar yoksa göremezsiniz)
  
• Export Objects'te "saved" sanıp aslında boş dosya kaydetmek
  
• Wrong stream numarası: Conversations'dan stream index doğrulayın
  
• Flag formatını okumamak (bazen flag{...} değil TEAM{...})
  

Kaynaklar

• Wireshark User's Guide
  
• pcap challenge arşivleri (yasal CTF setleri)
  
• tshark -Y ile aynı filtreleri CLI'da koşturma
  

Sizin forensics CTF'de "ilk baktığım yer" neresi? USB keystroke sorusu çözenler yorumda ipucu (spoiler etiketiyle) bırakabilir.

TLS trafiğinde flag aramak
Şifreli trafikte düz metin flag yoksa anahtar materyali (SSLKEYLOGFILE) verilmiş olabilir; CTF yazarları bazen bunu ayrı dosyada sunar. Wireshark'ta Preferences > Protocols > TLS > (Pre)-Master-Secret log filename. Key olmadan "HTTPS içinde ara" zaman kaybıdır; başka kanala (DNS, dosya export) bakın.

tshark ile otomasyon
Birden fazla pcap gelen CTF'de bash döngüsü:
İlk eleme böyle biter; derin Follow Stream'i GUI'de yaparsınız.


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 Dosyalar

Ekran Görüntüleri