Siber güvenlik topluluğunun nabzı

Selamlar,

16 Ekim 2026'da Hexacon'da Quentin Kaiser'in anlattığı araştırma, Broadcom'un 802.11 / WPS ayrıştırıcısındaki uzun ömürlü bir hatayı kamuoyuna taşıdı. Özet: Wi-Fi menzilinden, ağ anahtarını bilmeden, normal WPS kaydı tamamlamadan bilgi sızdırma ve kod çalıştırma. Broadcom CVE vermeyi reddetmiş; birçok ISP modeminde "forever day" riski var. Araştırmacı buna WPSplinter diyor.

Etki özeti

• Köken: Broadcom SDK'da en az 2010'dan beri; 2018'de eksik yama, sonra hostapd'ye geçiş önerisi
  
• eCos tabanlı platformlar (BCM3380/3383/33834): yama almayan cihazlarda kalıcı risk
  
• Linux tabanlı Broadcom SoC'ler: OEM hostapd'ye geçmediyse risk sürebilir
  
• Belçika ISP örnekleri (araştırmacı testleri): Proximus BBOX, VOO Netgear/Technicolor, Orange ASKEY TCG3000 — 15 Ekim itibarıyla yamasız örnekler; 20 Ekim güncellemesinde Proximus filoda WPS'yi kapatmış, Telenet etkilenmiyor
  

Demo senaryolarında PSK NVRAM'den okunup 802.11 üzerinden geri gönderiliyor veya ters kabuk 802.11 frame'leriyle geliyor. "Anten yakında" yanılsamasına düşmeyin; menzil iddiası uzun mesafe.

Ev/ofis kullanıcısı ne yapsın?

1. Modem/router modelinizi ve ISP duyurularını kontrol edin; firmware güncellemesi veya WPS'nin merkezden kapatılması var mı bakın.
   
2. WPS'yi (düğme + PIN) kapatın; WPA3-Personal kullanın, misafir ağını ayırın.
   
3. ISP cihazı yönetilemiyorsa: kendi AP'nizi köprü modunda kullanmayı değerlendirin.
   
4. Araştırmacının fingerprint script / YARA'sı ile kendi cihaz envanterinizi çıkarın (yalnızca sahip olduğunuz ekipman).
   

Kurumsal / ISP perspektifi
16 yıllık raf ömrü, sessiz yama ve CVE reddi birleşince OEM'ler haber alamıyor. Nearest-neighbour ve otel ağı senaryoları için biçilmiş kaftan: hava üzerinden, savunmacının görünürlüğü düşük. Segmentasyon ve "CPE'yi güvenilir sayma" varsayımını gözden geçirin.

Alıntı:Broadcom'un kendi yanıtına göre hata 2018'den beri biliniyor; yine de CVE ve kamu iletişimi yok. Bu yüzden birçok OEM yama uygulamadı.

Yasal uyarı
Komşu veya işletme Wi-Fi'sine izinsiz saldırı suçtur. Test yalnızca kendi laboratuvar ekipmanınızda. TCK 243-245.

Kaynaklar

• https://quentinkaiser.be/security/2026/1...-two-bugs/
  
• https://qkaiser.github.io/broadcom-wps/
  
• SANS Stormcast 20 Ekim 2026 özeti (ISC)
  

Türkiye / bölge notu
Araştırma Belçika ISP örnekleriyle somutlaştı; Broadcom tabanlı CPE dünyanın her yerinde. Türkiye'de operatör modemlerinde WPS durumunu kontrol edin, güncelleme kanalını açın, mümkünse kendi AP'nize geçin. Kurumsal misafir Wi-Fi'de ISP CPE'yi doğrudan kullanmayın.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)

1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
   
2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
   
3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
   
4. Yama veya yapılandırma azaltmasını stagingde deneyin.
   
5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
   
6. Servis sağlık kontrolü + log doğrulaması yapın.
   
7. Gerekliyse IOC avı veya compromise assessment planlayın.
   
8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.
   

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi

• Üretici / araştırmacı birincil yazısı (kaynakçada)
  
• CISA KEV veya CERT duyurusu varsa o
  
• Kendi iç runbook'unuzun ilgili maddesi
  

Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

Ek Dosyalar

Ekran Görüntüleri
   

Merhaba,

Siemens Software Center'daki kontrolsüz arama yolu (uncontrolled search path) zafiyeti CVE-2026-110936, 15 Ekim'de açıklanıp 17 Ekim'de güncellendi; 20 Ekim'de CISA KEV'e girdi. Saha tarafında ClickFix senaryosuyla DLL sideloading kullanıldığı bildiriliyor. Endüstriyel yazılım güncelleyicisi yüksek yetkiyle çalıştığı için etki yüzeyi geniş.

Teknik özet
Uygulama DLL'leri kontrol edilmeyen bir arama yolundan yüklüyor. Yerel kimlik doğrulamalı saldırgan, uygulamanın baktığı dizine özel hazırlanmış DLL koyarak uygulama yetkisiyle kod çalıştırabiliyor (NIST/NVD özeti, CVSS 8.4). Düzeltme: Software Center 4.0.9.8 ve sonrası.

ClickFix kalıbı genelde kullanıcıyı Win+R / PowerShell'e yapıştırılmış komutu çalıştırmaya ikna eder; ardından meşru imzalı Siemens çalıştırılabilirinin yanında kötü niyetli DLL gelir. İmza, yanındaki kütüphaneyi "güvenli" yapmaz.

Savunma adımları

1. Kurulu Software Center sürümünü 4.0.9.8+ doğrulayın (otomatik güncellemenin bittiğini teyit edin).
   
2. Siemens'in yayımladığı IOC ve davranışlarla av yapın; yalnızca hash'e güvenmeyin (saldırgan kendi kopyasını taşır).
   
3. Kullanıcı yazılabilir dizinlerden (Downloads, Temp, Desktop) sideloading alarmı test edin.
   
4. Run diyaloğu / kısıtlanmamış PowerShell ile yapıştırma alışkanlığını ASR, AppLocker/WDAC ve farkındalıkla sınırlayın.
   
5. Beklenmeyen MSI kurulumları, kalıcılık ve yayınlanmış altyapıya çıkışları inceleyin.
   

Neden OT/ICS ekipleri dikkat etmeli?
Software Center yazılım indirir, kurar, etkinleştirir, günceller. Yanlış DLL yüklemesi lateral movement ve ek sideloading için köprü olabilir. Arctic Wolf ve Black Hills yorumlarında da vurgulandığı gibi: imzalı exe = güvenilir yükleme zinciri değil.


Yasal uyarı
Yalnızca kendi/izinli sistemlerinizde test edin. TCK 243-245.

Kaynaklar

• https://www.scworld.com/news/siemens-sof...ing-attack
  
• https://www.cisa.gov/news-events/alerts/...es-catalog
  
• Siemens ürün güvenlik duyurusu (CVE-2026-110936, sürüm 4.0.9.8)
  

DLL sideloading genel dersi
İmzalı ana ikili + yazılabilir arama yolu = klasik. Application Directory, %PATH%, CWD sırasını bilin. WDAC/AppLocker ile kullanıcı yazılabilir yoldan DLL yüklemeyi kısıtlayın. ClickFix'e karşı: kullanıcıların Run/PowerShell'e yapıştırma alışkanlığını kırın, güvenlik farkındalığında "destek kodu" senaryolarını işleyin.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)

1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
   
2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
   
3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
   
4. Yama veya yapılandırma azaltmasını stagingde deneyin.
   
5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
   
6. Servis sağlık kontrolü + log doğrulaması yapın.
   
7. Gerekliyse IOC avı veya compromise assessment planlayın.
   
8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.
   

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi

• Üretici / araştırmacı birincil yazısı (kaynakçada)
  
• CISA KEV veya CERT duyurusu varsa o
  
• Kendi iç runbook'unuzun ilgili maddesi
  

Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

Ek Dosyalar

Ekran Görüntüleri
   

Selam,

WordPress SEO eklentisi Rank Math PRO'nun 3.0.123 paketleri, 15 Ekim 2026 20:02 UTC ile 16 Ekim 07:12 UTC arasında (yaklaşık 11 saat) zararlı içerikle sunuldu. Ücretsiz WordPress.org sürümü etkilenmedi. Temiz sürüm 3.0.124. Bu yazıda kim etkilenir, neden "sadece güncelle" yetmez ve nasıl temizlenir anlatıyorum.

Kim etkileniyor?

• Pencere içinde rankmath.com'dan 3.0.123 indirip aktive eden siteler: ele geçirilmiş kabul edin.
  
• İndirip hiç aktive etmeyenler: eklenti klasörünü silin, 3.0.124 kurun, yine de tarayın.
  
• Ücretsiz Rank Math SEO (wordpress.org): bu olaydan etkilenmiyor.
  

Zararlının davranışına dair bilinenler
Üretici ve BleepingComputer özetine göre:

• Kalıcı erişim; sayfa ziyaretinde kendini yeniden oluşturabilen gizli backdoor
  
• C2/CDN göstergesi: rank1cdn[.]com (savunmada bloklayın)
  
• IoC örnekleri: wp-includes/class-wp-cache-util.php, wp_options anahtarı _np5pvf754c, cron işareti #ms6v46, wpsupport_ önekli sahte admin hesapları, @wp-mail.net e-postaları
  
• Veritabanı kimlik bilgileri, API anahtarları, bulut sırları risk altında
  

Kurtarma sırası (önerilen)

1. Pencere öncesi temiz yedekten site + DB geri yükleyin (15 Ekim 20:02 UTC öncesi).
   
2. Wordfence/Sucuri veya eşdeğeri ile tarayın.
   
3. Tüm parolaları, tuzları, API anahtarlarını, veritabanı kullanıcısını döndürün.
   
4. Temiz 3.0.124'ü doğrudan rankmath.com hesabınızdan indirip kurun (e-postadaki linklere güvenmeyin).
   
5. rank1cdn.com çıkışını firewall/WAF'ta engelleyin.
   

Yedek yoksa üreticinin manuel temizleme adımları: eklenti klasörünü tamamen silmek, zararlı option/cron kayıtlarını kaldırmak, sahte admin aramak, .htaccess ve .cache dosyalarını incelemek, WordPress dışı (SSH authorized_keys, sistem cron) kontrol. Güncellemek tek başına backdoor'u silmez.

Hızlı av sorguları (lab/üretim, yedekli)

Webmaster notu
Ücretli eklenti güncelleme kanalı = tedarik zinciri yüzeyi. Staging'de önce güncelleyin; prod'da otomatik auto-update'i kritik eklentilerde dikkatli kullanın. Dosya bütünlüğü (Wordfence file diff, git deploy) bu sınıfta hayat kurtarır.

Yasal uyarı
İçerik yalnızca savunma ve bilinçlendirme içindir. Başkalarının sitelerine izinsiz müdahale suçtur (TCK 243-245).

Kaynaklar

• https://rankmath.com/kb/pro-3-0-123-security-incident/
  
• https://www.bleepingcomputer.com/news/se...-websites/
  

WordPress özelinde ek kontroller
wp-config.php izinleri, gereksiz dosya yazma hakları, eklenti/tema dizininde bilinmeyen PHP, users tablosunda son eklenen administrator'lar, options tablosunda base64/garip anahtarlar. Hosting paneli dosya değişim tarihçesi varsa pencere saatlerine bakın.

İletişim
Müşteri sitelerinde " Rank Math kullananlar mail atsın" diye duyuru yapın; utanç yerine net runbook verin. Ücretsiz sürüm kullanıcılarını panikletmeyin; PRO ve zaman penceresini vurgulayın.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)

1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
   
2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
   
3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
   
4. Yama veya yapılandırma azaltmasını stagingde deneyin.
   
5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
   
6. Servis sağlık kontrolü + log doğrulaması yapın.
   
7. Gerekliyse IOC avı veya compromise assessment planlayın.
   
8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.
   

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Ek Dosyalar

Ekran Görüntüleri
   

Merhaba ekip,

20 Ekim 2026'da BleepingComputer ve OVHcloud CEO'su Octave Klaba'nın açıklamalarıyla netleşen olay: OVHcloud CLI'nin GitHub release'leri kısa süreliğine bilgisayarı çalan (infostealer) sürümlerle değiştirildi. CI/CD bozulmadı; saldırgan geliştirici hesabını ele geçirip release immutability kapalıyken mevcut paketleri değiştirdi. Bu yazı "ne oldu / kim etkilenir / ne yapmalı" özeti.

Ne oldu?

• Etkilenen sürümler: v0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0
  
• Temiz: v0.10.0 ve olay sonrası çıkan v0.16.0
  
• Pencere: 19 Ekim 2026 ~14:47 ile ~16:21 arası (müşteri bildirimiyle yakalandı)
  
• Hedef platformlar (OpenSourceMalware): macOS Intel/ARM, Linux x86_64/ARM64, Windows x86-64
  
• Kaynak derlemeler ve Docker imajları etkilenmedi (rapora göre)
  

Amaç diskteki sırları toplamak. Klaba'nın ifadesiyle binary kalitesi düşük ama "sonuna kadar gidebiliyor". GlassWorm operasyonuyla bağlantı kuruluyor; aynı GitHub hesabında aylardır izler (Solana memo dead drop vb.) görülmüş.

Geliştirici olarak kontrol

Etkilenen bir binary çalıştırdıysanız:

1. Aracı kaldırın, temiz 0.16.0 veya 0.10.0'a geçin.
   
2. Makinedeki tüm sırları ele geçirilmiş kabul edin: OVH API token, SSH anahtarları, cloud credential dosyaları, .env, parola yöneticisi dışa aktarımları.
   
3. Token/anahtar rotate; GitHub/GitLab PAT, CI secret'ları dahil.
   
4. Release immutability ve branch koruması kendi org'unuzda açık mı kontrol edin.
   

Tedarik zinciri dersi
"CI yeşil = release güvenli" yetmez. GitHub release asset'leri değiştirilebilirse (immutability kapalı) pipeline hiç dokunulmadan zehirlenir. Pin hash, Cosign/Sigstore, internal mirror ve "son 24 saatte inen CLI'yi gözden geçir" alışkanlığı bu sınıf olaylarda fark yaratır. npm/VSCode uzantı ekosisteminde gördüğümüz GlassWorm tarzı kampanyaların GitHub release katmanına sıçraması sürpriz değil.

Organizasyon için mini playbook

Yasal uyarı
Yalnızca bilgilendirme. Başkalarının hesap veya sistemlerine yetkisiz erişim TCK 243-245 kapsamında suçtur. Zararlı örnekleri analiz edecekseniz izole lab kullanın.

Kaynaklar

• https://www.bleepingcomputer.com/news/se...r-secrets/
  
• https://github.com/ovh/ovhcloud-cli/issues/300
  
• OpenSourceMalware topluluk analizi (GlassWorm göstergeleri)
  

Sizde CLI paketleri hash ile mi pinleniyor, yoksa "latest" mı çekiliyor? Yorumlara yazın.

Geliştirici iş istasyonu temizliği
Etkilenen CLI çalıştıysa yalnızca OVH token'ı yetmez. ssh-agent'ta yükü anahtarlar, tarayıcı kayıtlı parolalar, cloud-cli cache (~/.config altında), Docker credsStore, Terraform state içi secret'lar gözden geçirilmeli. Mümkünse makinede taze profil veya yeniden kurulum düşünün.

Kurumsal CI runner
Self-hosted runner imajlarında "convenience" diye eklenen cloud CLI'lar unutulur. Golden image'ı yeniden üretin; secret scanning ile geçmiş job log'larını tarayın. Release immutability + zorunlu code review + 2FA enforced org ayarlarını aynı sprintte kapatın.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)

1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
   
2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
   
3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
   
4. Yama veya yapılandırma azaltmasını stagingde deneyin.
   
5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
   
6. Servis sağlık kontrolü + log doğrulaması yapın.
   
7. Gerekliyse IOC avı veya compromise assessment planlayın.
   
8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.
   

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Ev sunucusu kuranların çoğu Plex'i internete açıyor; port 32400 açıkken "sadece medya" diye düşünüyor. 16 Ekim 2026'da kamuoyuna çıkan Plex2Shell zinciri bu varsayımı bozdu. CISA 20 Ekim'de dört CVE'yi KEV kataloğuna aldı: CVE-2026-96652, 96654, 96655 ve 96656. Kimlik doğrulaması olmadan RCE. Bu yazıda zinciri, neden loopback güveninin kırıldığını ve ev/ofis labında ne yapmanız gerektiğini özetliyorum.

Konuda anlatılacaklar

1. Plex Media Server'ın auth modeli (WAN / LAN / loopback / owner token)
   
2. Beş aşamalı zincir: SSRF -> loopback pivot -> owner token -> transcoder -> dlopen
   
3. Kimler etkileniyor, yama ve varsayılan sızdırma kontrolü
   
4. Beyaz şapka perspektifi: kendi sunucunuzda risk azaltma
   

Neden bu kadar kritik?
PMS büyük bir C++ ikili + gömülü Python eklenti çerçevesi. İnternetten gelen istekler token ister; 127.0.0.1'den gelenlere ise /system/agents/* gibi aileler token olmadan açılır. Üstüne, eklenti çerçevesi http://127.0.0.1 ile başlayan dış isteklere sahibin local-* admin token'ını otomatik ekler. Bu iki davranış ayrı ayrı "mantıklı" görünür; zincirlenince internetteki saldırgan owner token çalıp transcoder üzerinden kod çalıştırabiliyor.

Zincir özeti (yüksek seviye)
Araştırmacı zmain'in yazdığı akış kabaca şöyle (PoC depozitosu GitHub'da code-zm/plex2shell):

1. /player/timeline: X-Plex-Token başlığının varlığı kontrol ediliyor, değeri değil. junk token yeterli.
   
2. Companion abonelik akışında protocol/host/port ile callback URL üretiliyor; protocol temizlenmiyor. Unsubscribe anında sunucu kendi loopback'ine POST atıyor (gerçek 127.0.0.1 kaynağı).
   
3. /system/agents/.../searchOne[/b] loopback'te tokensuz. identifier enjeksiyonu ile herhangi bir eklenti fonksiyonuna sahte çağrı.
   
4. TheTVDB ajanındaki GetResultFromNetwork, http://127.0.0.1 öneki gördüğünde owner token ekliyor. sslip.io tarzı DNS ile önek geçer, çözüm saldırgan IP'sine gider; token dinlenir.
   
5. Owner token ile /video/:/transcode/universal ve TranscoderH264Options=dump-yuv yolu: taşıyıcı video bit-exact olarak .so yazar; sonraki transcode dlopen ile constructor çalıştırır (uid=plex).
   

Bu bir "tek CVE" değil; dört CVE'nin zinciri. Sömürü saha raporlarında aktif görünüyor; internete açık PMS'yi varsayılan olarak ele geçirilmiş kabul etmek mantıklı.

Hızlı kontrol listesi (kendi sunucunuz)

• Plex'in yayınladığı güvenlik güncellemesini uygulayın; yama öncesi internete açık sunucuda compromise assessment yapın.
  
• Remote Access'i kapatın veya VPN/Tailscale arkasına alın; CGNAT arkasında bile "kolay erişim" tuzağına düşmeyin.
  
• Admin token'ları döndürün; paylaşılan kütüphane hesaplarını gözden geçirin.
  
• Transcoder dizinlerini (Codecs) bütünlük açısından izleyin; beklenmeyen .so dosyaları kırmızı bayraktır.
  

Savunma dersi
"Loopback güvenli" varsayımı SSRF ile birleşince çöker. Token kontrolünde varlık ≠ geçerlilik klasik bir anti-pattern. Pref'e yazılabilen encoder bayrakları (dump-yuv gibi) debug özelliğinin üretimde kalmasının bedelidir. Benzer mimariyi kendi araçlarınızda görürseniz: loopback API'lerini tokensuz bırakmayın, outbound URL önek kontrollerini hostname parse ile yapın, debug seçeneklerini production build'den çıkarın.

Yasal uyarı
Bu yazı bilgilendirme amaçlıdır. Plex veya üçüncü taraf sistemlerde izinsiz deneme TCK 243-245 kapsamında suçtur. Testleri yalnızca kendi laboratuvarınızda veya yazılı izinle yapın. PoC'yi internette rastgele hostlara karşı çalıştırmayın.

Kaynaklar

• https://zmain.info/blog/plex2shell
  
• https://www.cisa.gov/news-events/alerts/...es-catalog
  
• https://github.com/code-zm/plex2shell (araştırmacı PoC deposu; yalnızca kendi labınız)
  

Sizde PMS internete açık mıydı, yoksa baştan VPN arkasında mı tutuyordunuz? Deneyimi yorumda yazın.

Ev kullanıcısı için ekstra sertleştirme
Plex'i yalnızca Tailscale/WireGuard arkasından açın. Shared kullanıcıları düzenli ayıklayın. Transcoder'ı gerekmiyorsa sınırlayın. NAS üzerinde PMS çalıştırıyorsanız NAS web arayüzünü de aynı VPN disiplinine alın. "Arkadaşlar uzak izlesin" ihtiyacı için ayrı, zayıf yetkili hesap kullanın; owner hesabını paylaşmayın.

Kurumsal BYOD riski
Çalışan laptop'unda PMS açıp Remote Access işaretlemek, kurumsal VPN ile birleşince beklenmedik lateral yüzey üretebilir. MDMde kişisel medya sunucusu politikası net olsun. SOC tarafında 32400/TCP internete çıkan iç host'ları periyodik bulun.

Göstergeler (yüksek seviye)
Beklenmeyen /player/* abonelik gürültüsü, loopback'e giden garip POST'lar, Codecs dizininde tanımsız .so, ani transcoder tercih değişikliği. Bunlar tek başına suçlama değildir; yama öncesi dönem için inceleme tetikleyicisidir.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)

1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
   
2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
   
3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
   
4. Yama veya yapılandırma azaltmasını stagingde deneyin.
   
5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
   
6. Servis sağlık kontrolü + log doğrulaması yapın.
   
7. Gerekliyse IOC avı veya compromise assessment planlayın.
   
8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.
   

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Ek Dosyalar

Ekran Görüntüleri
   

Merhaba,

Ücretli kurs şart değil; kaliteli ücretsiz kaynakla çok yol alınır. 2026 için kendi tavsiye listemi güncelledim. Bağlantılar zamanla değişebilir; resmi sayfalardan doğrulayın.

Lab ve pratik

• TryHackMe - ücretsiz odalar + abonelik seçenekleri
  
• Hack The Box - starting point / retired (koşullara göre)
  
• OverTheWire, picoCTF, pwn.college
  
• DVWA, Juice Shop, Metasploitable (kendi VM)
  

Kitap / metin

• OWASP Top 10 ve Cheat Sheet Series
  
• NIST SP serisi (800-61 IR, 800-63 kimlik...)
  
• Linux man sayfaları ve Arch Wiki (genel Linux)
  
• The Web Application Hacker's Handbook (klasik; kütüphane / eski baskı)
  

Video / kurs

• Professor Messer (Security+)
  
• NetworkChuck / John Hammond (seçici izleyin; eğlence + teknik)
  
• Üniversite açık dersleri (ağ, işletim sistemleri)
  

Mavi takım

• SigmaHQ kuralları
  
• DetectionLab / Wazuh quickstart
  
• MITRE ATT&CK + Navigator
  

Topluluk

• TurkTeam (burası)
  
• Yerel siber güvenlik toplulukları / meetup
  
• Resmi Discord/forumlar (etik kurallara uyun)
  

Nasıl tüketmeli?
Rastgele video yerine hedef seçin: 30 günde X lab + Y writeup. Notları kendi dilinizde yazın; kopyala-yapıştır öğrenme olmaz.

Kaynaklar (meta)

• OWASP
  
• NIST
  
• TryHackMe / HTB resmi
  
• MITRE
  

Listenize eklediğiniz ücretsiz bir kaynak var mı? Kaliteliyse ekleyelim.

30 günlük örnek plan
Hafta 1: Linux komutları + ağ temelleri (TryHackMe Pre Security). Hafta 2: Web temel (OWASP Top 10 odaları). Hafta 3: Blue — Event Log + Wazuh quickstart. Hafta 4: bir writeup + CV güncelleme. Ücretsiz kaynak çok; odak az olsun.

Türkçe içerik
TurkTeam yazıları, yerli bloglar ve çeviri OWASP metinleri dil engelini azaltır. İngilizce kaçınılmazdır; ama ilk adımı Türkçe atmak bırakma oranını düşürü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.

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

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

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

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

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

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

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

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

Ek Dosyalar

Ekran Görüntüleri
       

Selam,

"Microsoft / Windows Destek hattıyız, bilgisayarınızda virüs var" diye gelen aramalar ve ekran paylaşımı istekleri klasik dolandırıcılık. Bu yazıda ne yapmanızı, bağlantıyı nasıl keseceğinizi ve sonrasında hangi kontrolleri yapacağınızı anlatıyorum.

Nasıl işler?

• Soğuk arama veya korkutucu pop-up ("ara +1-...")
  
• AnyDesk / TeamViewer / Quick Assist ile tam kontrol
  
• "Virüs temizliği" adı altında uzak erişim hesabı açma, kripto / kart parası, sahte fatura
  

Microsoft, Apple, Google sizi arayıp virüs uyarısı yapmaz.

O anda yapılacaklar

1. Ekran paylaşımını hemen sonlandırın
   
2. İnternet bağlantısını kesin (kablo / Wi-Fi)
   
3. Telefonu kapatın; geri aramayın
   
4. Başka bir temiz cihazdan parola yöneticisi ile kritik hesap oturumlarını düşürün
   

Sonrası kontrol listesi

• Yeni kullanıcı hesabı / RDP / AnyDesk kalmış mı?
  
• Başlangıç programları ve zamanlanmış görevler
  
• Bilinmeyen tarayıcı eklentileri
  
• Banka / e-posta / parola yöneticisi parolalarını temiz cihazdan değiştirin
  
• Şüpheli banka hareketi varsa bankayı arayın (resmi numaradan)
  

Windows'ta hızlı bakış:

Yaşlı / aile için önlem

• Pop-up'ta yazan numarayı aramama kuralı
  
• Ekran paylaşım uygulamalarını varsayılan kurmayın
  
• Ayrı sınırlı kullanıcı hesabı
  
• Şüphede ailedeki "teknoloji kişisini" arama kartı
  

Kaynaklar

• Microsoft güvenlik blogları: tech support scam
  
• BTK / yerel siber suç bildirim kanalları
  
• Tüketici dernekleri uyarıları
  

Yakın çevrenizde bu dolandırıcılığa denk gelen oldu mu? Hangi uygulama istendi?

Pop-up kilidi
Tam ekran "virüs" uyarısı bazen tarayıcıyı kilitlemiş gibi gösterir. Ctrl+Alt+Del / başka tarayıcı / güvenli mod. Bilgisayarı formatlatmaya ikna eden aramalar da aynı dolandırıcılık ailesindendir.

Bildirim
Ödeme yaptıysanız banka + yerel siber suç birimleri. Ekran görüntüsü, arayan numara, verilen IBAN/BTC adresi kanıttır. Utanmayın; bildirmek başkalarını korur.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ek Dosyalar

Ekran Görüntüleri
       

Merhaba,

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

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

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


Ne kazanırız?

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

Ne kaybeder / zorlaşır?

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

Tamamlayıcı kontroller

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

Kaynaklar

• Docker Docs: Rootless mode
  
• rootlesskit projesi
  
• CIS Docker Benchmark
  

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ek Dosyalar

Ekran Görüntüleri
       

Selam,

Bug bounty programı olmayan bir üründe açık bulduysanız yol sorumlu açıklama (coordinated vulnerability disclosure). Bu yazıda üreticiye nasıl bildireceğinizi, süreleri ve kanıt paketini anlatıyorum.

Hazırlık

• Yalnızca kendi labınızda / izinli ortamda doğrulayın
  
• Exploit'i minimal tutun; zarar vermeyin, veri silmeyin
  
• Tarihçe tutun (ne zaman buldunuz, ne test ettiniz)
  

Üreticiyi bulma
security@, PSIRT sayfası, security.txt (/.well-known/security.txt), GitHub Security Advisories. Yoksa destek formu + açıkça "güvenlik açığı" başlığı.


Bildirim içeriği

• Özet etki
  
• Etkilenen sürüm / ortam
  
• Adım adım yeniden üretim
  
• Kanıt (ekran, sanitized log)
  
• Önerdiğiniz düzeltme (varsa)
  
• Sizin iletişim kanalınız
  
• İstenen süre: örn. 90 gün koordinasyon (ISO 29147 / sektör pratikleri referans)
  

Süre ve açıklama
Birçok araştırmacı 90 gün bekler; üretici yama isterse uzatılabilir. Yama yok ve kritik risk varsa CERT/uluslararası koordinasyon kanalları düşünülebilir. "Full disclosure" bombası son çaredir; etik ve hukuki sonuçlarını bilin.

Yapmayın

• Veriyi sızdırarak "kanıt" sunmak
  
• Müşterileri korkutarak şantaj
  
• Aynı açığı pazarlık bitmeden Twitter'da detaylı yayınlamak
  

Kaynaklar

• ISO/IEC 29147, 30111 (CVD kavramları)
  
• CISA / CERT disclosure rehberleri
  
• security.txt spesifikasyonu
  

Üreticiden hiç cevap alamadığınız oldu mu? Nasıl escalate ettiniz?

security.txt örneği
Kendi sitenize koyarak araştırmacıya yol gösterin. PGP anahtarı varsa belirtin.

Ödül yoksa bile
VDP'de ödeme olmayabilir; CVE kredisi / hall of fame / deneyim vardır. Şantaj diline asla kaymayın. Yazışmaları saklayın.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.

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,

Bug bounty programı olmayan bir üründe açık bulduysanız yol sorumlu açıklama (coordinated vulnerability disclosure). Bu yazıda üreticiye nasıl bildireceğinizi, süreleri ve kanıt paketini anlatıyorum.

Hazırlık

• Yalnızca kendi labınızda / izinli ortamda doğrulayın
  
• Exploit'i minimal tutun; zarar vermeyin, veri silmeyin
  
• Tarihçe tutun (ne zaman buldunuz, ne test ettiniz)
  

Üreticiyi bulma
security@, PSIRT sayfası, security.txt (/.well-known/security.txt), GitHub Security Advisories. Yoksa destek formu + açıkça "güvenlik açığı" başlığı.


Bildirim içeriği

• Özet etki
  
• Etkilenen sürüm / ortam
  
• Adım adım yeniden üretim
  
• Kanıt (ekran, sanitized log)
  
• Önerdiğiniz düzeltme (varsa)
  
• Sizin iletişim kanalınız
  
• İstenen süre: örn. 90 gün koordinasyon (ISO 29147 / sektör pratikleri referans)
  

Süre ve açıklama
Birçok araştırmacı 90 gün bekler; üretici yama isterse uzatılabilir. Yama yok ve kritik risk varsa CERT/uluslararası koordinasyon kanalları düşünülebilir. "Full disclosure" bombası son çaredir; etik ve hukuki sonuçlarını bilin.

Yapmayın

• Veriyi sızdırarak "kanıt" sunmak
  
• Müşterileri korkutarak şantaj
  
• Aynı açığı pazarlık bitmeden Twitter'da detaylı yayınlamak
  

Kaynaklar

• ISO/IEC 29147, 30111 (CVD kavramları)
  
• CISA / CERT disclosure rehberleri
  
• security.txt spesifikasyonu
  

Üreticiden hiç cevap alamadığınız oldu mu? Nasıl escalate ettiniz?

security.txt örneği
Kendi sitenize koyarak araştırmacıya yol gösterin. PGP anahtarı varsa belirtin.

Ödül yoksa bile
VDP'de ödeme olmayabilir; CVE kredisi / hall of fame / deneyim vardır. Şantaj diline asla kaymayın. Yazışmaları saklayın.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.

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