Siber güvenlik topluluğunun nabzı

Selamlar,

Bu hafta BIND 9 açığı (CVE-2026-94300) haberlerinde "GSS-TSIG", "named", "yetkili zone" gibi terimler geçti. Siber güvenliğe yeni başlayan arkadaşlar için bunların ne demek olduğunu sıfırdan, basit bir dille anlatmak istedim. DNS'i anlamadan ağ güvenliği, phishing analizi veya web güvenliğinde ilerlemek çok zor; o yüzden bu konu bir temel taşı.

Konuda anlatılacaklar

1. DNS ne işe yarar?
   
2. Bir sorgunun yolculuğu
   
3. Önemli roller: stub, çözümleyici, yetkili sunucu
   
4. Kayıt türleri ve TTL
   
5. DNS güvenliği: TSIG, DNSSEC ve tipik saldırılar
   
6. Kendi bilgisayarınızda ilk denemeler
   

DNS ne işe yarar?
İnsanlar isimleri (turkteam.org), bilgisayarlar IP adreslerini kullanır. DNS, ismi IP adresine çeviren dağıtık bir rehberdir. Tek bir merkez yoktur; sorumluluk hiyerarşik olarak bölünmüştür: kök (.), üst düzey alan (.org, .com.tr) ve alan adının sahibi.

Bir sorgunun yolculuğu
Tarayıcıya www.ornek.com yazdığınızda kabaca şunlar olur:

1. Bilgisayarınızdaki stub çözümleyici önce kendi önbelleğine bakar.
   
2. Yoksa soruyu yapılandırılmış özyinelemeli çözümleyiciye (modeminiz, ISS'niz veya 1.1.1.1 gibi bir servis) sorar.
   
3. Çözümleyici cevabı bilmiyorsa kök sunucuya sorar: "com'dan kim sorumlu?"
   
4. .com sunucusuna sorar: "ornek.com'dan kim sorumlu?"
   
5. ornek.com'un yetkili (authoritative) sunucusuna sorar ve gerçek cevabı alır.
   
6. Cevabı TTL süresi kadar önbelleğe alır ve size döner.
   

Roller

• Özyinelemeli çözümleyici: Sizin adınıza tüm yolu dolaşan sunucu.
  
• Yetkili sunucu: Bir zone'un (örneğin ornek.com) gerçek kayıtlarını tutan sunucu.
  
• BIND / named: BIND, ISC'nin geliştirdiği en yaygın DNS sunucu yazılımı; named onun çalışan sürecinin adı. Hem çözümleyici hem yetkili sunucu olarak çalışabilir.
  

Kayıt türleri ve TTL

DNS güvenliğine giriş

• TSIG: DNS mesajlarını paylaşılan gizli bir anahtarla imzalar; özellikle sunucular arası zone transferi ve dinamik güncellemelerin gerçekten yetkili birinden geldiğini doğrular (RFC 8945).
  
• GSS-TSIG: Aynı imzalamanın anahtarını Kerberos ile müzakere eden sürümü; Windows/Active Directory ortamlarında bilgisayarların kendi DNS kaydını güvenle güncellemesi için kullanılır. BIND açığı tam olarak bu mekanizmada, imzalı bir mesajın tekrar gönderilmesiyle (replay) ilgili.
  
• DNSSEC: Kayıtların kendisini dijital imzayla korur; çözümleyici cevabın değiştirilmediğini doğrulayabilir.
  
• Tipik saldırılar: Önbellek zehirleme (sahte cevabı önbelleğe sokmak), DNS amplifikasyonu (DDoS), alan adı ele geçirme ve benzer isimli alan adlarıyla oltalama.
  

İlk denemeler
Daha ileri komutlar (+trace, DNSSEC doğrulama, sorun giderme) için Araç Tanıtım ve Eğitimleri bölümündeki dig ve delv rehberine göz atabilirsiniz.

Kendinizi test edin

1. Yetkili sunucu ile özyinelemeli çözümleyicinin farkı nedir?
   
2. TTL çok yüksek olursa bir IP değişikliğinde ne olur?
   
3. TSIG neyi korur, DNSSEC neyi korur?
   

Cevaplarınızı yorumlara yazın, birlikte kontrol edelim.

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

Kaynaklar

• https://www.cloudflare.com/learning/dns/what-is-dns/
  
• https://kb.isc.org/docs/cve-2026-94300
  
• https://www.rfc-editor.org/rfc/rfc8945
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Sadece bu haftanın haberlerine bakalım: Symantec, ele geçirdiği LLM'lerle 100.000 adıma kadar kendi başına saldıran bir ajanı (Skynet) belgeledi; ABD bankaları müşteri hesaplarında üçüncü taraf YZ ajanları tespit edip engellemeye başladı; Railway ihlali YZ çıkarım sağlayıcılarının anahtarlarını hedefleyen bir saldırı serisinin parçası olarak açıklandı. "YZ güvenliği" artık bir slayt başlığı değil, günlük operasyon. Bu konuda bu alana girmek isteyenler için gerçekçi bir beceri haritası çıkarmaya çalıştım.

Konuda anlatılacaklar

1. YZ güvenliğinde üç ana iş ailesi
   
2. Temel beceriler (önce bunlar)
   
3. Alana özgü beceriler
   
4. Portföy fikirleri
   
5. Kaçınılması gereken tuzaklar
   

Üç iş ailesi

• LLM uygulama güvenliği (AppSec + YZ): Prompt injection, aşırı yetki (excessive agency), veri sızıntısı, araç/MCP entegrasyonlarının güvenliği. Klasik AppSec'in genişlemiş hali.
  
• YZ red team / değerlendirme: Modelleri ve ajanları izinli kapsamda test etmek, jailbreak dayanıklılığı, değerlendirme setleri hazırlamak.
  
• YZ altyapı savunması (bulut + SOC): Model uç noktalarını, gateway'leri, API anahtarlarını korumak; LLMjacking gibi kötüye kullanımı token ve harcama telemetrisinden tespit etmek.
  

Temel beceriler (önce bunlar)
Bu alana "sadece YZ" bilerek girilmiyor. Skynet raporundaki araç listesine bakın: FOFA ile keşif, Django/Laravel/Next.js exploit modülleri, bulut metadata SSRF'si. Yani saldırgan tarafında da klasik web ve bulut bilgisi var. Sağlam temel:

• Web güvenliği: OWASP Top 10, SSRF, kimlik doğrulama ve yetkilendirme hataları.
  
• Bulut: IAM, gizli anahtar yönetimi, metadata servisleri.
  
• Python ve API'lerle rahat çalışmak.
  
• Log analizi ve temel tespit mühendisliği.
  

Alana özgü beceriler

• OWASP Top 10 for LLM Applications (prompt injection, excessive agency, sistem prompt sızıntısı vb.).
  
• MITRE ATLAS: YZ sistemlerine yönelik saldırı taktiklerinin ATT&CK benzeri haritası.
  
• Ajan mimarisi: araç çağırma, MCP, yetki kapsamı, insan onayı noktaları.
  
• Kötüye kullanım tespiti: token tüketimi anomalileri, anahtar başına bütçe ve hız limitleri.
  

Portföy fikirleri (yasal ve izinli)

1. Yerel bir modelle (Ollama vb.) basit bir RAG uygulaması kurup kendi uygulamanıza karşı prompt injection testleri yazın ve düzeltmeleri belgeleyin.
   
2. Kendi YZ gateway'inizde token kullanım loglarından anomali alarmı üreten küçük bir script yazın.
   
3. Bir ajan için "en az yetki" tasarım dokümanı hazırlayın: hangi araç, hangi kapsam, hangi eylemde insan onayı.
   
4. garak veya PyRIT gibi açık kaynak araçlarla kendi modelinize karşı değerlendirme raporu yayınlayın.
   

Tuzaklar

• Başkasına ait modellere veya API'lere izinsiz jailbreak denemesi portföy değil, hizmet şartı ihlali ve potansiyel suçtur.
  
• Açıkta bulduğunuz bir LLM uç noktasını "denemek" de izinsiz erişimdir; sorumlu açıklama kanalını kullanın.
  
• Sadece prompt yazma becerisi bir güvenlik kariyeri için yeterli değil; temel güvenlik bilgisi olmadan bu alanda kalıcı olmak zor.
  

YZ güvenliğine geçiş yapan veya bu alanda çalışan var mı? İş ilanlarında en sık hangi becerileri görüyorsunuz?

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

Kaynaklar

• https://www.security.com/threat-intellig...ing-skynet
  
• https://genai.owasp.org/llm-top-10/
  
• https://atlas.mitre.org/
  
• https://www.axios.com/2026/10/22/ai-agen...nts-access
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

SOC analisti olmak isteyenlerin sık sorduğu sertifikalardan CompTIA CySA+ için takvim netleşti: V4 (CS0-004) 23 Haziran 2026'da yayına girdi, V3 (CS0-003) İngilizce sınavı 22 Aralık 2026'da emekli oluyor. Japonca, Portekizce ve İspanyolca sürümler ise 23 Mart 2027'ye kadar sürüyor. Şu an V3'e çalışıyorsanız elinizde iki aydan az zaman var. Bu konuda iki sürümü karşılaştırıp karar vermeye yardımcı olmaya çalışacağım.

Konuda anlatılacaklar

1. CS0-004 alan ağırlıkları
   
2. Yenilikler
   
3. Kimler CS0-003 ile devam etmeli?
   
4. Kimler doğrudan CS0-004'e geçmeli?
   
5. Diğer yaklaşan sınav değişiklikleri
   
6. Çalışma planı önerisi
   

CS0-004 alan ağırlıkları
CompTIA'nın resmi sınav hedeflerine göre:
Alan isimleri V3'e benziyor; fark içerikte.

Yenilikler
CompTIA'nın V4 sayfasına göre yeni sürüm SOC'ta yapay zeka kullanımına, modern bulut ortamlarına, tehdit avına ve zafiyet risk önceliklendirmesine daha fazla yer veriyor. Yani "bir zafiyet taraması çıktısını oku" yetmiyor; hangi bulgunun iş riskine göre önce kapatılacağını gerekçelendirmek bekleniyor. Bu, bu hafta gördüğümüz PHP2Shell, GitLab ve Node2Shell gibi aynı anda yağan kritik açık dalgalarında gerçek bir SOC'un yaşadığı problemle birebir örtüşüyor.

CS0-003 ile devam etmeli misiniz?
Şu durumdaysanız mantıklı olabilir:

• Materyallerinizi tamamladınız ve deneme sınavlarında güvenli puan alıyorsunuz.
  
• Sınavı Aralık başına kadar planlayabiliyorsunuz (son haftalara bırakmak randevu bulamama riski taşır).
  

Sertifika hangi sürümle alınırsa alınsın aynı unvanı verir ve aynı süre geçerlidir; işverenler genelde sürüm numarasına bakmaz.

CS0-004'e geçmeli misiniz?

• Yeni başlıyorsanız veya materyalin yarısından azındaysanız.
  
• Sınavı 2027'de planlıyorsanız (zaten başka seçeneğiniz yok).
  
• Bulut SOC veya tehdit avı rolü hedefliyorsanız; yeni içerik doğrudan işinize yarar.
  

Not: Yeni sürümlerin ilk aylarında üçüncü taraf kaynak sayısı azdır; resmi hedefler PDF'ini çalışma listesinin omurgası yapın.

Yaklaşan diğer değişiklikler

• Security+ V8 (SY0-801): 17 Kasım 2026 civarı planlanıyor; SY0-701 İngilizce 11 Haziran 2027'de emekli.
  
• ISACA CISM yeni içerik planı: 3 Kasım 2026.
  
• OSCP+ ölçeklendirilmiş puanlama: 1 Aralık 2026.
  

8 haftalık örnek plan (CS0-004)

1. Hafta 1-2: Security Operations: log analizi, SIEM sorguları, e-posta başlık analizi (kendi labınızda Wazuh veya ELK).
   
2. Hafta 3-4: Vulnerability Management: tarama sonuçlarını okuma, CVSS ve KEV ile önceliklendirme.
   
3. Hafta 5-6: Incident Response: olay döngüsü, kanıt toplama, ATT&CK eşleme.
   
4. Hafta 7: Reporting: yöneticiye özet, metrikler, iletişim.
   
5. Hafta 8: Deneme sınavları ve zayıf alan tekrarı.
   

Tarih ve bilgiler CompTIA'nın resmi sayfalarına göredir; kayıt öncesi güncel duyuruyu kontrol edin.

CySA+ sınavına giren veya hazırlanan var mı? Hangi sürümü seçtiniz ve neden?

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

Kaynaklar

• https://www.comptia.org/en-us/certificat...nalyst/v4/
  
• https://www.comptia.org/en-us/certificat...nalyst/v3/
  
• https://www.comptia.org/en-us/resources/...t-roadmap/
  
• https://decipheru.com/data/exam-changes.csv
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar arkadaşlar,

Evde eski bir mini PC'de Plex Media Server çalıştırıyorum, dışarıdan da film izleyebilmek için uzaktan erişim açık. CISA'nın Plex2Shell açıklarını aktif istismar listesine (KEV) eklediğini ve ABD federal kurumlarına 23 Ekim'e kadar yama süresi verdiğini okudum. Kurum değilim ama ev ağımda bu kutu açık duruyor. Araştırdıklarımı ve yaptıklarımı yazıyorum; eksik varsa düzeltin.

Anladığım kadarıyla durum
AppSec News ve Root2Sec'in özetine göre Plex2Shell, dört Plex Media Server açığının zinciri:
Zincir birleşince saldırgan sunucu sahibinin yönetici token'ını alıp yükseltilmiş yetkiyle kod çalıştırabiliyor. Araştırmacı Zach Main zincirin tamamına 9.8 puan vermiş. İlk saldırılar 17 Ekim'de Plex honeypot'larına kripto madencisi kurmak için yapılmış.

Yaptıklarım

1. Sürüm kontrolü: Plex Web > Ayarlar > Genel bölümünde sürüme baktım. Linux'ta terminalden de bakılabiliyor:
   
   Kod:

   dpkg -l | grep plexmediaserver # Debian/Ubuntu paket kurulumu docker exec plex cat /usr/lib/plexmediaserver/Resources/VERSION 2>/dev/null
2. Güncelleme: 1.43.3.10861 veya sonrasına geçtim. Docker kullananlar için imajı çekip konteyneri yeniden oluşturmak gerekiyor, sadece restart yetmiyor.
   
3. Uzaktan erişim: Güncelleme bitene kadar Ayarlar > Uzaktan Erişim'i kapattım. Modemde 32400 için elle açtığım port yönlendirmesini sildim, UPnP'yi de kapattım.
   
4. İz kontrolü: Sunucuda tanımadığım süreç veya yüksek CPU kullanımı var mı diye baktım (madenci belirtisi).
   
   Kod:

   top -o %CPU ls -la /tmp /var/tmp

Sorularım

1. Güncelledikten sonra uzaktan erişimi tekrar açmak mantıklı mı, yoksa Tailscale/WireGuard gibi bir VPN üzerinden mi izlemeli?
   
2. Ele geçirilmiş olma ihtimaline karşı Plex hesabımın parolasını değiştirip tüm cihazlardan çıkış yapmak yeterli mi? Token çalındıysa bu onu geçersiz kılar mı?
   
3. Plex kutusunu ev ağında ayrı bir VLAN'a almak ev kullanıcısı için abartı mı?
   

Kendi denemelerim: VPN ile izlemek biraz uğraştırıyor ama portu internete açmamak gönlümü rahatlatıyor. Tecrübesi olanların fikirlerini bekliyorum.

Ev sunucusu çalıştıranlar: medya sunucunuzu dışarıya nasıl açıyorsunuz, port yönlendirme mi VPN mi?

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

Kaynaklar

• https://appsecnews.com/news/cisa-kev-ple...-exploited
  
• https://root2sec.com/news/cisa-hackers-c...h-servers/
  
• https://support.plex.tv/articles/2002895...te-access/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Capcom ID sızıntısında 11,7 milyondan fazla e-posta adresi, son giriş zamanı ve son giriş IP'siyle birlikte açığa çıktı. Bu hafta pek çok kişi "mailim sızmış, şimdi ne olacak?" diye soruyor. İyi haber: sadece e-posta adresinin sızması tek başına hesabınızın ele geçtiği anlamına gelmez. Kötü haber: bundan sonraki haftalarda size gelecek sahte mailler çok daha inandırıcı olacak. Bu rehber, sakin ve sıralı bir kontrol listesi sunuyor.

Konuda anlatılacaklar

1. Sızıntıda ne çıktığını anlamak
   
2. İlk 15 dakika: parola ve oturumlar
   
3. Parola tekrarını kırmak
   
4. İki adımlı doğrulama
   
5. Önümüzdeki haftalar: oltalamayı tanımak
   
6. Yapmamanız gerekenler
   

1. Ne sızdı?
Her sızıntı farklıdır. Şirketin resmi duyurusunu okuyun (haber sitelerinin yorumunu değil). Capcom örneğinde müşteri parolalarının sızdığı doğrulanmadı ve kart verisi etkilenmedi; e-posta, giriş zamanları ve IP sızdı, 196 hesapta parola izinsiz değiştirildi. Adresinizin bilinen sızıntılarda yer alıp almadığını Have I Been Pwned gibi tanınmış servislerden kontrol edebilirsiniz; bu servis parolanızı istemez, sadece e-posta ile arama yapar.

2. İlk 15 dakika

1. Etkilenen servise adres çubuğundan kendiniz girerek parolanızı değiştirin (maildeki bağlantıdan değil).
   
2. Hesap ayarlarında "tüm cihazlardan çıkış yap" seçeneği varsa kullanın.
   
3. Bağlı hesapları (Steam, PlayStation, Xbox, Google ile giriş) kontrol edin.
   

3. Parola tekrarını kırmak
Asıl tehlike buradadır: aynı parolayı e-posta hesabınızda veya bankada da kullandıysanız, saldırganlar başka sızıntılardan gelen parolalarla deneme yapar (credential stuffing). Yapılacaklar:

• Önce e-posta hesabınızın parolasını benzersiz ve uzun yapın; e-posta, diğer tüm hesapların "parola sıfırlama" anahtarıdır.
  
• Bir parola yöneticisi kullanın ve her siteye farklı parola üretin.
  

4. İki adımlı doğrulama
SMS yerine authenticator uygulaması veya passkey tercih edin. Kurtarma kodlarınızı çevrimdışı bir yerde saklayın. E-posta hesabınızda 2FA yoksa, bugün açılacak tek ayar budur.

5. Oltalamayı tanımak
Sızan veriler (e-posta + son giriş zamanı + IP) şu tür mailler için kullanılabilir:

Alıntı:"Hesabınıza 19 Ekim'de yeni bir konumdan giriş yapıldı. Siz değilseniz 24 saat içinde doğrulayın, aksi halde hesabınız kapatılacak."

Kırmızı bayraklar:

• Aciliyet ve tehdit ("24 saat içinde", "kalıcı olarak silinecek").
  
• Gönderen adresinin alan adı resmi alan adıyla birebir aynı değil.
  
• Bağlantının üzerine gelince farklı bir adres görünüyor.
  
• Parola, kart bilgisi veya doğrulama kodu isteniyor.
  

Türkiye'den şüpheli bir oltalama sitesini USOM'a bildirebilirsiniz.

6. Yapmayın

• "Sızıntı listesinde adını arat" diyen bilinmeyen sitelere veya Telegram botlarına e-posta ve parola girmeyin.
  
• Sızan veri setlerini indirip bakmaya çalışmayın; hem yasa dışıdır hem zararlı yazılım riski taşır.
  
• Panikle tüm hesapları silmeyin; sıralı ve sakin ilerleyin.
  

Sizin e-postanız daha önce bir sızıntıda çıktı mı? İlk ne yaptınız, neyi keşke daha önce yapsaydım dediniz?

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

Kaynaklar

• https://www.capcom.co.jp/ir/english/news...61022.html
  
• https://haveibeenpwned.com/FAQs
  
• https://www.usom.gov.tr/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

BIND 9 açığı (CVE-2026-94300) gündemdeyken DNS araçlarına sağlam bir giriş yapalım. dig ve delv, BIND projesinin parçası olan ve neredeyse her Linux dağıtımında bulunan iki sorgu aracı. dig her şeyi ham olarak gösterir; delv ise yanıtları DNSSEC zinciriyle doğrulamaya odaklanır. Bu rehberdeki tüm örnekleri kendi alan adlarınızda veya herkese açık örnek alan adlarında güvenle deneyebilirsiniz.

Konuda anlatılacaklar

1. Kurulum
   
2. dig temelleri ve çıktıyı okumak
   
3. Kayıt türleri: A, AAAA, MX, TXT, NS, CAA
   
4. +trace ile çözümleme yolunu izlemek
   
5. delv ile DNSSEC doğrulama
   
6. Sık kullanılan sorun giderme senaryoları
   

Kurulum

dig temelleri
Çıktıda bakılacak yerler:

• status: NOERROR (başarılı), NXDOMAIN (alan adı yok), SERVFAIL (sunucu yanıt üretemedi; DNSSEC hatası da olabilir).
  
• flags: qr (yanıt), rd (özyineleme istendi), ra (özyineleme sunuldu), aa (yetkili yanıt), ad (DNSSEC doğrulandı).
  
• ANSWER SECTION: kayıt ve TTL değeri.
  
• SERVER: yanıtı hangi çözümleyicinin verdiği.
  

Kısa çıktı için +short, belirli bir çözümleyici için @ kullanın:

Kayıt türleri
Kendi alan adınızda CAA kaydı yoksa, kurallara uyan herhangi bir CA sizin adınıza sertifika verebilir. CAA kaydıyla yalnızca kullandığınız CA'ları yetkilendirmek, yanlış veya sahte sertifika talebine karşı ucuz bir sertleştirmedir.

+trace ile çözümleme yolu
Kökten (.) başlayıp TLD'ye, oradan yetkili sunucuya kadar her adımı gösterir. "Bazı yerlerden çözülüyor, bazı yerlerden çözülmüyor" sorunlarında yanlış NS delegasyonunu bulmanın en hızlı yolu budur.

delv ile DNSSEC doğrulama
Başarılı doğrulamada çıktının başında "; fully validated" görürsünüz; imzasız zone'larda "; unsigned answer". dig ile de DO bitini isteyip ad bayrağına ve RRSIG kayıtlarına bakabilirsiniz:

Sorun giderme senaryoları

• Yeni kayıt görünmüyor: Yetkili sunucuya doğrudan sorun (dig @ns1.ornek.com kayit). Orada varsa sorun çözümleyici önbelleğinde; TTL dolmasını bekleyin.
  
• SERVFAIL ama başka çözümleyicide çalışıyor: dig +cd ile (checking disabled) tekrar sorun; +cd ile çalışıyorsa DNSSEC imza sorunu var.
  
• TCP/büyük yanıt sorunları: dig +tcp ile deneyin; güvenlik duvarı 53/TCP'yi engelliyor olabilir.
  

Hatırlatma: Başkasına ait DNS sunucularında zone transferi (AXFR) denemeleri izinsiz tarama sayılabilir; bu tür testleri yalnızca kendi sunucularınızda yapın.

DNS sorun gidermede en çok hangi dig seçeneğini kullanıyorsunuz? Favori tek satırlıklarınızı ekleyin.

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

Kaynaklar

• https://bind9.readthedocs.io/en/stable/manpages.html
  
• https://kb.isc.org/docs/cve-2026-94300
  
• https://www.rfc-editor.org/rfc/rfc4033
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

BIND 9 açığı (CVE-2026-94300) gündemdeyken DNS araçlarına sağlam bir giriş yapalım. dig ve delv, BIND projesinin parçası olan ve neredeyse her Linux dağıtımında bulunan iki sorgu aracı. dig her şeyi ham olarak gösterir; delv ise yanıtları DNSSEC zinciriyle doğrulamaya odaklanır. Bu rehberdeki tüm örnekleri kendi alan adlarınızda veya herkese açık örnek alan adlarında güvenle deneyebilirsiniz.

Konuda anlatılacaklar

1. Kurulum
   
2. dig temelleri ve çıktıyı okumak
   
3. Kayıt türleri: A, AAAA, MX, TXT, NS, CAA
   
4. +trace ile çözümleme yolunu izlemek
   
5. delv ile DNSSEC doğrulama
   
6. Sık kullanılan sorun giderme senaryoları
   

Kurulum

dig temelleri
Çıktıda bakılacak yerler:

• status: NOERROR (başarılı), NXDOMAIN (alan adı yok), SERVFAIL (sunucu yanıt üretemedi; DNSSEC hatası da olabilir).
  
• flags: qr (yanıt), rd (özyineleme istendi), ra (özyineleme sunuldu), aa (yetkili yanıt), ad (DNSSEC doğrulandı).
  
• ANSWER SECTION: kayıt ve TTL değeri.
  
• SERVER: yanıtı hangi çözümleyicinin verdiği.
  

Kısa çıktı için +short, belirli bir çözümleyici için @ kullanın:

Kayıt türleri
Kendi alan adınızda CAA kaydı yoksa, kurallara uyan herhangi bir CA sizin adınıza sertifika verebilir. CAA kaydıyla yalnızca kullandığınız CA'ları yetkilendirmek, yanlış veya sahte sertifika talebine karşı ucuz bir sertleştirmedir.

+trace ile çözümleme yolu
Kökten (.) başlayıp TLD'ye, oradan yetkili sunucuya kadar her adımı gösterir. "Bazı yerlerden çözülüyor, bazı yerlerden çözülmüyor" sorunlarında yanlış NS delegasyonunu bulmanın en hızlı yolu budur.

delv ile DNSSEC doğrulama
Başarılı doğrulamada çıktının başında "; fully validated" görürsünüz; imzasız zone'larda "; unsigned answer". dig ile de DO bitini isteyip ad bayrağına ve RRSIG kayıtlarına bakabilirsiniz:

Sorun giderme senaryoları

• Yeni kayıt görünmüyor: Yetkili sunucuya doğrudan sorun (dig @ns1.ornek.com kayit). Orada varsa sorun çözümleyici önbelleğinde; TTL dolmasını bekleyin.
  
• SERVFAIL ama başka çözümleyicide çalışıyor: dig +cd ile (checking disabled) tekrar sorun; +cd ile çalışıyorsa DNSSEC imza sorunu var.
  
• TCP/büyük yanıt sorunları: dig +tcp ile deneyin; güvenlik duvarı 53/TCP'yi engelliyor olabilir.
  

Hatırlatma: Başkasına ait DNS sunucularında zone transferi (AXFR) denemeleri izinsiz tarama sayılabilir; bu tür testleri yalnızca kendi sunucularınızda yapın.

DNS sorun gidermede en çok hangi dig seçeneğini kullanıyorsunuz? Favori tek satırlıklarınızı ekleyin.

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

Kaynaklar

• https://bind9.readthedocs.io/en/stable/manpages.html
  
• https://kb.isc.org/docs/cve-2026-94300
  
• https://www.rfc-editor.org/rfc/rfc4033
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

İngiltere Bilgi Komisyonluğu (ICO) 20 Ekim 2026'da iki Galli kuruluşa, Ogi Networks Limited (ONL) ve Data Cymru'ya kınama verdi. Kasım 2024'teki fidye yazılımı saldırısında, 12 yıldan uzun süredir var olan "Test2" adlı bir test hesabı kullanıldı. Hesabın parolası baştan beri "Password1" idi ve bir parola gücü aracına göre bir saniyeden kısa sürede kırılabiliyordu. Saldırıda 182,7 GB veri şifrelendi, 42 GB veri çalındı; çoğu çocuk 3.300 kişinin bilgisi etkilendi. Bu konu, aynı hatayı kendi AD ortamınızda nasıl yakalayacağınızı anlatıyor.

Konuda anlatılacaklar

1. ICO kararından çıkan somut hatalar
   
2. Pasif hesapları bulmak
   
3. Parolası hiç değişmemiş hesaplar
   
4. Test/servis hesabı adlandırma avı
   
5. Güvenli devre dışı bırakma süreci
   

ICO'nun tespitleri

• Test hesabı Ocak 2012'de "Password1" ile oluşturulmuş, parola karmaşıklığı kuralı uygulanmamış.
  
• Hesaplar düzenli denetlenmemiş; gereksiz hesap 12 yıl yaşamış.
  
• Üç sistemde yerel yönetici hesapları 12 yıldan uzun süre aynı parolayı korumuş.
  
• Data Cymru'nun hesap incelemeleri planlı ve rutin değilmiş, AD'nin tamamını kapsamıyormuş.
  
• Dış kaynak sağlayıcı ile kurum arasında sorumluluk ve veri işleme sözleşmesi net değilmiş.
  

1. Pasif hesapları bulmak
Not: LastLogonDate, lastLogonTimestamp özniteliğinden gelir ve DC'ler arasında varsayılan olarak 9-14 gün gecikmeyle çoğaltılır. Pasiflik tespiti için yeterli, anlık giriş takibi için değil.

2. Parolası yıllardır değişmeyenler

3. Test ve geçici hesap avı
Yerel yönetici parolaları için Windows LAPS kullanın; her makinede benzersiz ve döndürülen parola, ICO kararındaki "12 yıl aynı yerel admin parolası" sorununu kökten çözer.

4. Güvenli devre dışı bırakma
Hesabı hemen silmeyin. Önerilen süreç:

1. Sahibini bulun (yönetici, dış kaynak firması). Sahibi yoksa bu zaten bir bulgu.
   
2. Devre dışı bırakın, açıklamaya tarih ve talep numarası yazın, ayrı bir "Disabled" OU'ya taşıyın.
   
3. 30-90 gün bekleyin; kimse şikayet etmezse silin.
   

Kalıcı çözüm
ICO'nun önerileriyle uyumlu olarak: zayıf ve yaygın parolaları engelleyen bir parola filtresi (Entra Password Protection gibi), uzaktan erişimde varsayılan MFA, tüm AD'yi kapsayan çeyreklik hesap incelemesi ve dış kaynak sözleşmelerinde hesap yaşam döngüsünün kimde olduğunun yazılı tanımı. Komutları önce lab ortamında deneyin.

Kendi ortamınızda (veya labınızda) bu komutları çalıştırdığınızda kaç pasif hesap çıktı? Rakam paylaşabilirsiniz, isim değil.

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

Kaynaklar

• https://ico.org.uk/about-the-ico/media-c...-password/
  
• https://www.theregister.com/cyber-crime/...er/5304139
  
• https://learn.microsoft.com/en-us/powers...-adaccount
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Node.js'in 21 Ekim 2026 güvenlik sürümleri (Node2Shell, CVE-2026-111497 dahil) yalnızca 22.x, 24.x ve 26.x hatlarına geldi. Node.js'in kendi uyarısı net: güvenlik sürümü çıktığında EOL (ömrü dolmuş) sürümler her zaman etkilenmiş kabul edilir. OX Security de 25.x, 23.x ve 20.x ile öncesinin düzeltme almayacağını vurguluyor. Bu konu, eski bir Node sürümünde kalmış projeyi güvenli ve tekrarlanabilir şekilde taşımanın pratik adımlarını anlatıyor.

Konuda anlatılacaklar

1. Hangi sürüm hattındayım?
   
2. nvm ile yerel geçiş
   
3. .nvmrc ve engines ile sürümü sabitlemek
   
4. Docker ve CI tarafı
   
5. Geçiş sonrası test kontrol listesi
   

1. Envanter
Kural: tek sayılı hatlar (23, 25) kısa ömürlüdür; üretimde çift sayılı LTS hatlarını (22, 24, 26) tercih edin. Güncel destek takvimi için Node.js'in "Previous Releases" sayfasına bakın.

2. nvm ile yerel geçiş
Native modül kullanan projelerde (bcrypt, sharp, sqlite3) node_modules'u silip yeniden kurun; ABI değiştiği için eski derlenmiş modüller çalışmaz.

3. Sürümü sabitlemek
package.json içinde:
.npmrc içine engine-strict=true eklerseniz yanlış sürümde kurulum hata verir. Böylece ekipte biri eski sürümle çalışınca hemen fark edilir.

4. Docker ve CI
Daha da sıkı kontrol isterseniz imajı digest ile sabitleyin (dün bu konuyu ayrıca işlemiştik). CI'da:
Konteynerde eski imajı yeniden başlatmak yetmez; yeniden build edip deploy edin.

5. Geçiş sonrası test

1. Birim ve entegrasyon testleri yeni sürümde geçiyor mu?
   
2. npm audit ve npm outdated çıktısı temiz mi?
   
3. Brotli kullanan yollar (Content-Encoding: br kabul eden body parser, fetch ile çekilen yanıtlar) yeni runtime'da test edildi mi?
   
4. Üretimde node -v gerçekten yeni sürümü gösteriyor mu? (PM2 veya systemd eski binary'yi tutuyor olabilir.)
   

En eski Node sürümünü hangi projede gördünüz ve geçişte en çok ne sorun çıkardı?

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

Kaynaklar

• https://nodejs.org/en/blog/vulnerability...y-releases
  
• https://nodejs.org/en/about/previous-releases
  
• https://github.com/nvm-sh/nvm
  
• https://www.ox.security/blog/node-js-bro...26-111497/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

ZDI raporlarının herkese açık listeye düşmesiyle ksmbd'de iki yamasız RCE (ZDI-CAN-33774 ve ZDI-CAN-33549, CVSS 9.0) gündemde. Bunlardan biri kimlik doğrulaması gerektirmiyor ve 445 portunda ksmbd çalıştıran her sunucuyu etkiliyor. Çekirdek düzeltmesi dağıtımlara ulaşana kadar yapabileceğiniz en etkili şey, ksmbd'ye gerçekten ihtiyacınız olup olmadığını bilmek. Bu rehber adım adım kontrol ve kapatma yöntemini anlatıyor.

Konuda anlatılacaklar

1. ksmbd ile Samba farkı
   
2. ksmbd yüklü ve çalışıyor mu?
   
3. Kullanmıyorsanız: kapatma ve kara listeye alma
   
4. Kullanıyorsanız: saldırı yüzeyini daraltma
   
5. Doğrulama
   

ksmbd ile Samba farkı
Samba (smbd) kullanıcı alanında çalışan klasik SMB sunucusudur. ksmbd ise çekirdek belgelerine göre performans için çekirdek alanında çalışan bir SMB3 sunucusu; kullanıcı alanındaki ksmbd.mountd yardımcı servisiyle birlikte çalışır. Çekirdek alanında çalıştığı için bir bellek hatası doğrudan çekirdek seviyesinde sonuç doğurur. Red Hat'e göre RHEL varsayılan olarak ksmbd içermiyor; bazı NAS dağıtımları ve elle kurulmuş ksmbd-tools paketleri ise kullanıyor olabilir.

1. Kontrol
ss çıktısında süreç adı smbd ise Samba kullanıyorsunuz; süreç adı görünmüyor ama 445 dinleniyorsa ve lsmod ksmbd gösteriyorsa çekirdek sunucusu aktif demektir.

2. Kullanmıyorsanız: kapatın
modprobe -r "module is in use" hatası verirse önce paylaşımları kapatın (servis durdurulmalı), gerekirse bakım penceresinde yeniden başlatın.

3. Kullanıyorsanız: yüzeyi daraltın

• 445'i internete açmayın. Yalnızca güvenilir LAN veya VPN aralığına izin verin.
  
• Misafir (guest) paylaşımlarını kapatın. pwn.watch'a göre dağıtım yarışı açığı misafir paylaşımı gerektiren senaryoda tetikleniyor; The Hacker News'e göre ise ön-kimlik doğrulama yolu da var. İkisini birden daraltmak gerekiyor.
  
• SMB Direct/RDMA kullanmıyorsanız rdma_rxe gibi yazılım RDMA sürücülerini yüklemeyin.
  
• Mümkünse geçici olarak Samba'ya geçin.
  

4. Doğrulama

Takip
Düzeltmeler mainline'a girip CVE atandığında dağıtımınızın çekirdek güncellemesini kurun ve yeniden başlatın. O zamana kadar bu konuyu kendi envanterinizde "açık risk" olarak işaretleyin.

Kontrol sonucunuz ne çıktı: Samba mı, ksmbd mi, hiçbiri mi? Özellikle NAS kullananların deneyimini merak ediyorum.

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

Kaynaklar

• https://thehackernews.com/2026/10/two-cv...flaws.html
  
• https://docs.kernel.org/filesystems/smb/ksmbd.html
  
• https://pwn.watch/d/2026-10-22
  

Ek Dosyalar

Ekran Görüntüleri