<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Ağ Güvenliği]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:40 +0000 MyBB <![CDATA[Cisco Ekim 2026: 34 Açık, Expressway'de Kritik RCE (CVE-2026-76466) ve Yama Rehberi]]> https://www.turkteam.org/konu-cisco-ekim-2026-34-acik-expressway-de-kritik-rce-cve-2026-76466-ve-yama-rehberi.html Sun, 25 Oct 2026 11:42:13 +0300 Tonyukuk]]> https://www.turkteam.org/konu-cisco-ekim-2026-34-acik-expressway-de-kritik-rce-cve-2026-76466-ve-yama-rehberi.html [Resim: attachment.php?aid=426]
Selamlar,

Cisco, Expressway Serisi, IOS XR, Snort 3 ve Unified Communications ürünleri genelinde 34 zafiyet için yama yayımladı. SecurityWeek'in aktardığına göre en acil başlıklardan biri Expressway'deki kritik uzaktan kod çalıştırma açığı CVE-2026-76466. Cisco bu açıklardan hiçbirinin vahşi doğada sömürüldüğüne dair bilgi olmadığını belirtiyor, ama RCE ciddi. Burada hangi ürünü önce yamalamanız gerektiğini özetliyorum.

Konuda anlatılacaklar
  1. Expressway: kritik RCE
  2. Unified Communications: kritik CVE'ler
  3. Snort 3: 13 CVE
  4. IOS XR ve Secure Client
  5. Yama öncelik sırası

1. Expressway
On zafiyet düzeltildi; en önemlisi CVE-2026-76466:
  • Belirli yapılandırmalarda kalıcı çerezlerin kullanılması ve istemci sertifikalarının yetersiz doğrulanması, saldırganın veritabanı servisine bağlanıp belirli RPC komutlarını çağırmasına izin veriyor.
  • Başarılı sömürü, alttaki işletim sisteminde root olarak komut çalıştırmaya yol açabiliyor.
  • Düzeltildiği sürüm: X15.5.20 (aynı sürüm sekiz ek CVE'yi de kapatıyor).

2. Unified Communications
Dokuz CVE yamalandı (Emergency Responder, Prime Collaboration Deployment, Unified CM, CM IM&P, CM SME, Unity Connection). En ciddileri üç kritik: CVE-2026-76473, CVE-2026-76474, CVE-2026-76475 (uygunsuz kaynak kontrolü, uygunsuz kimlik doğrulama ve uygunsuz girdi nötrlemesi grupları).

3. Snort 3
Birden fazla Cisco ürününde Snort 3'ü etkileyen 13 CVE yamalandı. Kritik olanlar CVE-2026-20236 ve CVE-2026-20043 (yanlış hesaplama ve sınır dışı yazma). Düzeltme Snort 3 sürüm 3.12.4.0 ile ve Cyber Vision, CDFW, Meraki MX, CSA, Secure Firewall ASA, Secure FMC, Secure FTD, IOS XE için UTD güncellemeleriyle geldi.

4. IOS XR ve Secure Client
  • IOS XR'da yüksek önemde bir DoS açığı: CVE-2026-76505.
  • Secure Client'ın Secure Firewall Posture modülünde yüksek önemde yetki yükseltme: CVE-2026-76462.

5. Yama öncelik sırası
  1. Expressway X15.5.20 önce, özellikle internete dönük ise. root RCE en yüksek risk.
  2. Unified Communications kritik üçlüleri ikinci sırada.
  3. Snort 3 3.12.4.0 ve ilgili güvenlik duvarı güncellemeleri; bunlar savunma katmanınız olduğu için önemli.
  4. IOS XR DoS ve Secure Client yetki yükseltme sonraki dalgada.
Hızlı bir envanter notu: cihaz sürümlerinizi SSH ile toplayıp X15.5.20 ve 3.12.4.0 eşiklerine göre karşılaştırın.

Sonuç
Cisco'nun bu toplu yamasında ana başlık Expressway'deki root RCE. Vahşi doğada sömürü raporu olmaması, yamayı ertelemek için gerekçe değil; RCE'ler hızla silahlandırılır. Siz Cisco altyapınızda sürüm envanterini nasıl tutuyorsunuz?

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

.png   10-t10-cisco-ekim-2026.png (Dosya Boyutu: 131.97 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=426]
Selamlar,

Cisco, Expressway Serisi, IOS XR, Snort 3 ve Unified Communications ürünleri genelinde 34 zafiyet için yama yayımladı. SecurityWeek'in aktardığına göre en acil başlıklardan biri Expressway'deki kritik uzaktan kod çalıştırma açığı CVE-2026-76466. Cisco bu açıklardan hiçbirinin vahşi doğada sömürüldüğüne dair bilgi olmadığını belirtiyor, ama RCE ciddi. Burada hangi ürünü önce yamalamanız gerektiğini özetliyorum.

Konuda anlatılacaklar
  1. Expressway: kritik RCE
  2. Unified Communications: kritik CVE'ler
  3. Snort 3: 13 CVE
  4. IOS XR ve Secure Client
  5. Yama öncelik sırası

1. Expressway
On zafiyet düzeltildi; en önemlisi CVE-2026-76466:
  • Belirli yapılandırmalarda kalıcı çerezlerin kullanılması ve istemci sertifikalarının yetersiz doğrulanması, saldırganın veritabanı servisine bağlanıp belirli RPC komutlarını çağırmasına izin veriyor.
  • Başarılı sömürü, alttaki işletim sisteminde root olarak komut çalıştırmaya yol açabiliyor.
  • Düzeltildiği sürüm: X15.5.20 (aynı sürüm sekiz ek CVE'yi de kapatıyor).

2. Unified Communications
Dokuz CVE yamalandı (Emergency Responder, Prime Collaboration Deployment, Unified CM, CM IM&P, CM SME, Unity Connection). En ciddileri üç kritik: CVE-2026-76473, CVE-2026-76474, CVE-2026-76475 (uygunsuz kaynak kontrolü, uygunsuz kimlik doğrulama ve uygunsuz girdi nötrlemesi grupları).

3. Snort 3
Birden fazla Cisco ürününde Snort 3'ü etkileyen 13 CVE yamalandı. Kritik olanlar CVE-2026-20236 ve CVE-2026-20043 (yanlış hesaplama ve sınır dışı yazma). Düzeltme Snort 3 sürüm 3.12.4.0 ile ve Cyber Vision, CDFW, Meraki MX, CSA, Secure Firewall ASA, Secure FMC, Secure FTD, IOS XE için UTD güncellemeleriyle geldi.

4. IOS XR ve Secure Client
  • IOS XR'da yüksek önemde bir DoS açığı: CVE-2026-76505.
  • Secure Client'ın Secure Firewall Posture modülünde yüksek önemde yetki yükseltme: CVE-2026-76462.

5. Yama öncelik sırası
  1. Expressway X15.5.20 önce, özellikle internete dönük ise. root RCE en yüksek risk.
  2. Unified Communications kritik üçlüleri ikinci sırada.
  3. Snort 3 3.12.4.0 ve ilgili güvenlik duvarı güncellemeleri; bunlar savunma katmanınız olduğu için önemli.
  4. IOS XR DoS ve Secure Client yetki yükseltme sonraki dalgada.
Hızlı bir envanter notu: cihaz sürümlerinizi SSH ile toplayıp X15.5.20 ve 3.12.4.0 eşiklerine göre karşılaştırın.

Sonuç
Cisco'nun bu toplu yamasında ana başlık Expressway'deki root RCE. Vahşi doğada sömürü raporu olmaması, yamayı ertelemek için gerekçe değil; RCE'ler hızla silahlandırılır. Siz Cisco altyapınızda sürüm envanterini nasıl tutuyorsunuz?

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

.png   10-t10-cisco-ekim-2026.png (Dosya Boyutu: 131.97 KB / İndirme Sayısı: 1) ]]> <![CDATA[k0t Kampanyası: 70 Bin Sızan Kimlikle FortiGate ve GlobalProtect Avı]]> https://www.turkteam.org/konu-k0t-kampanyasi-70-bin-sizan-kimlikle-fortigate-ve-globalprotect-avi.html Sun, 25 Oct 2026 11:36:54 +0300 Tonyukuk]]> https://www.turkteam.org/konu-k0t-kampanyasi-70-bin-sizan-kimlikle-fortigate-ve-globalprotect-avi.html [Resim: attachment.php?aid=420]
Selamlar,

Group-IB ve NyxLab, internete açık ağ kenarı (edge) cihazlarını hedefleyen geniş çaplı bir kampanyayı ortaya koydu. k0t (diğer adlarıyla CryptoFeel, Scrooge) adlı tehdit aktörü, FortiGate ve FortiWeb güvenlik duvarları ile Palo Alto GlobalProtect portallarını kırıp kalıcı erişim satan bir ilk erişim simsarı (IAB) gibi davranıyor. Araştırmacılar 70.000'den fazla sızan kimlik bilgisi topladı. Burada aktörün yöntemlerini ve kendi edge cihazınızı nasıl sertleştireceğinizi anlatıyorum.

Konuda anlatılacaklar
  1. k0t kim, ne yapıyor?
  2. Keşif: FOFA ve ZoomEye ile toplu tarama
  3. FortiWeb ve FortiGate'e giriş yöntemleri
  4. GlobalProtect çerez sahteciliği (CVE-2026-0257)
  5. Kalıcılık ve yanal hareket araçları
  6. Edge cihaz sertleştirme kontrol listesi

1. k0t kim?
Group-IB'ye göre k0t, hedefe özel araştırma yapmadan, halka açık tarama araçlarıyla internete dönük VPN ve güvenlik duvarı cihazlarını toplu tarayan bir operasyon. Başarılı girişlerden sonra cihazda ek kimlik bilgisi topluyor ve hedeflere OpenConnect VPN ile bağlanıyor. Mağdur örtüsü Qilin ve The Gentlemen gibi fidye gruplarıyla görülüyor; ancak bu bağlantı rapora göre doğrulanmış değil.

2. Keşif
Operatörler FOFA ve ZoomEye gibi saldırı yüzeyi arama motorlarıyla internete açık cihazları ürüne ve maruziyete göre filtreleyip büyük hedef listeleri oluşturuyor. Ders açık: cihazınız Shodan/FOFA'da görünüyorsa zaten listede olabilirsiniz.

3. FortiWeb ve FortiGate
Group-IB'nin aktardığı fort.py / fortnew.py adlı özel betik her hedefte önce CVE-2025-64446'yı deniyor. Bu, FortiWeb'de kimlik doğrulamasız yönetim komutu çalıştırmaya izin veren bir path traversal açığı. Araç, yerleşik "prof_admin" hesabını taklit eden sahte bir CGIINFO başlığıyla şu uç noktaya istek atıyor:
Kod:
POST /api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi
ve rastgele sekiz karakterli, 0.0.0.0/0 trusted-host aralığına sahip yerel bir yönetici oluşturuyor.
Bu başarısız olursa betik, FortiGate REST API'sine karşı ortak kullanıcı/parola listeleriyle kaba kuvvete geçiyor. Başarılı girişten sonra --parse-configs bayrağı, yapılandırmayı indirip CVE-2019-6693 olarak izlenen varsayılan FortiOS AES anahtarıyla saklı sırları (LDAP, AD, yönetici, yerel kullanıcı) çözüyor.

Not: CVE-2025-64446 ve CVE-2019-6693, CISA KEV kataloğunda yer alan, aktif sömürülen açıklar. Yani bunlar teorik değil.

4. GlobalProtect (CVE-2026-0257)
Palo Alto tarafında "BeiDou" imzalı bir araç, hedefin TLS sertifikasındaki açık anahtarla bir kimlik doğrulama atlatma çerezi üreterek boş parolayla /ssl-vpn/login.esp'ye gönderiyor. CVE-2026-0257 CISA KEV'de fidye kullanımı etiketiyle listeli ve EPSS puanı yaklaşık %97 ile çok yüksek; yani sömürülme olasılığı son derece yüksek bir açık.

5. Kalıcılık ve yanal hareket
Group-IB'nin gözlemlediği araç seti: OpenConnect VPN, MeshCentral ve Atera (RMM), AdaptixC2, NetExec, Impacket, Mimikatz; bazı vakalarda Rclone ile bulut depolamaya veri kopyalama. Araştırmacılar bir MeshCentral sunucusuna raporlayan onlarca ele geçirilmiş cihaz buldu.

6. Edge cihaz sertleştirme kontrol listesi
  1. İnternete açık yönetim arayüzlerini kapatın. Yönetim sadece iç ağ veya VPN üzerinden erişilebilir olsun.
  2. Tüm FortiGate/FortiWeb/PAN-OS cihazlarını güncel tutun. CVE-2025-64446, CVE-2026-0257 ve CVE-2019-6693 için yamaları uygulayın.
  3. Varsayılan ve zayıf parolaları değiştirin. Kaba kuvvet listeleri tam da bunları hedefliyor.
  4. Cihaz yapılandırmasındaki saklı sırları döndürün. Varsayılan şifreleme anahtarı ifşası, config bir kez sızınca tüm sırları açar.
  5. trusted-host 0.0.0.0/0 olan yönetici hesaplarını avlayın. Beklenmeyen yeni admin hesapları bir ihlal göstergesidir.
  6. Giden RMM/OpenConnect trafiğini izleyin. MeshCentral, Atera, AdaptixC2 beklenmiyorsa alarm üretin.

Sonuç
k0t kampanyası, "edge cihaz = iç ağın ön kapısı" gerçeğini bir kez daha gösteriyor. İnternete dönük tek bir yamasız güvenlik duvarı, tüm kurumsal kimlik deposuna açılan kapı olabiliyor. Siz edge cihazlarınızın maruziyetini en son ne zaman Shodan/FOFA gözüyle kontrol ettiniz?

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

.png   04-t04-k0t-edge-cihaz-kampanyasi.png (Dosya Boyutu: 117.82 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=420]
Selamlar,

Group-IB ve NyxLab, internete açık ağ kenarı (edge) cihazlarını hedefleyen geniş çaplı bir kampanyayı ortaya koydu. k0t (diğer adlarıyla CryptoFeel, Scrooge) adlı tehdit aktörü, FortiGate ve FortiWeb güvenlik duvarları ile Palo Alto GlobalProtect portallarını kırıp kalıcı erişim satan bir ilk erişim simsarı (IAB) gibi davranıyor. Araştırmacılar 70.000'den fazla sızan kimlik bilgisi topladı. Burada aktörün yöntemlerini ve kendi edge cihazınızı nasıl sertleştireceğinizi anlatıyorum.

Konuda anlatılacaklar
  1. k0t kim, ne yapıyor?
  2. Keşif: FOFA ve ZoomEye ile toplu tarama
  3. FortiWeb ve FortiGate'e giriş yöntemleri
  4. GlobalProtect çerez sahteciliği (CVE-2026-0257)
  5. Kalıcılık ve yanal hareket araçları
  6. Edge cihaz sertleştirme kontrol listesi

1. k0t kim?
Group-IB'ye göre k0t, hedefe özel araştırma yapmadan, halka açık tarama araçlarıyla internete dönük VPN ve güvenlik duvarı cihazlarını toplu tarayan bir operasyon. Başarılı girişlerden sonra cihazda ek kimlik bilgisi topluyor ve hedeflere OpenConnect VPN ile bağlanıyor. Mağdur örtüsü Qilin ve The Gentlemen gibi fidye gruplarıyla görülüyor; ancak bu bağlantı rapora göre doğrulanmış değil.

2. Keşif
Operatörler FOFA ve ZoomEye gibi saldırı yüzeyi arama motorlarıyla internete açık cihazları ürüne ve maruziyete göre filtreleyip büyük hedef listeleri oluşturuyor. Ders açık: cihazınız Shodan/FOFA'da görünüyorsa zaten listede olabilirsiniz.

3. FortiWeb ve FortiGate
Group-IB'nin aktardığı fort.py / fortnew.py adlı özel betik her hedefte önce CVE-2025-64446'yı deniyor. Bu, FortiWeb'de kimlik doğrulamasız yönetim komutu çalıştırmaya izin veren bir path traversal açığı. Araç, yerleşik "prof_admin" hesabını taklit eden sahte bir CGIINFO başlığıyla şu uç noktaya istek atıyor:
Kod:
POST /api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi
ve rastgele sekiz karakterli, 0.0.0.0/0 trusted-host aralığına sahip yerel bir yönetici oluşturuyor.
Bu başarısız olursa betik, FortiGate REST API'sine karşı ortak kullanıcı/parola listeleriyle kaba kuvvete geçiyor. Başarılı girişten sonra --parse-configs bayrağı, yapılandırmayı indirip CVE-2019-6693 olarak izlenen varsayılan FortiOS AES anahtarıyla saklı sırları (LDAP, AD, yönetici, yerel kullanıcı) çözüyor.

Not: CVE-2025-64446 ve CVE-2019-6693, CISA KEV kataloğunda yer alan, aktif sömürülen açıklar. Yani bunlar teorik değil.

4. GlobalProtect (CVE-2026-0257)
Palo Alto tarafında "BeiDou" imzalı bir araç, hedefin TLS sertifikasındaki açık anahtarla bir kimlik doğrulama atlatma çerezi üreterek boş parolayla /ssl-vpn/login.esp'ye gönderiyor. CVE-2026-0257 CISA KEV'de fidye kullanımı etiketiyle listeli ve EPSS puanı yaklaşık %97 ile çok yüksek; yani sömürülme olasılığı son derece yüksek bir açık.

5. Kalıcılık ve yanal hareket
Group-IB'nin gözlemlediği araç seti: OpenConnect VPN, MeshCentral ve Atera (RMM), AdaptixC2, NetExec, Impacket, Mimikatz; bazı vakalarda Rclone ile bulut depolamaya veri kopyalama. Araştırmacılar bir MeshCentral sunucusuna raporlayan onlarca ele geçirilmiş cihaz buldu.

6. Edge cihaz sertleştirme kontrol listesi
  1. İnternete açık yönetim arayüzlerini kapatın. Yönetim sadece iç ağ veya VPN üzerinden erişilebilir olsun.
  2. Tüm FortiGate/FortiWeb/PAN-OS cihazlarını güncel tutun. CVE-2025-64446, CVE-2026-0257 ve CVE-2019-6693 için yamaları uygulayın.
  3. Varsayılan ve zayıf parolaları değiştirin. Kaba kuvvet listeleri tam da bunları hedefliyor.
  4. Cihaz yapılandırmasındaki saklı sırları döndürün. Varsayılan şifreleme anahtarı ifşası, config bir kez sızınca tüm sırları açar.
  5. trusted-host 0.0.0.0/0 olan yönetici hesaplarını avlayın. Beklenmeyen yeni admin hesapları bir ihlal göstergesidir.
  6. Giden RMM/OpenConnect trafiğini izleyin. MeshCentral, Atera, AdaptixC2 beklenmiyorsa alarm üretin.

Sonuç
k0t kampanyası, "edge cihaz = iç ağın ön kapısı" gerçeğini bir kez daha gösteriyor. İnternete dönük tek bir yamasız güvenlik duvarı, tüm kurumsal kimlik deposuna açılan kapı olabiliyor. Siz edge cihazlarınızın maruziyetini en son ne zaman Shodan/FOFA gözüyle kontrol ettiniz?

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

.png   04-t04-k0t-edge-cihaz-kampanyasi.png (Dosya Boyutu: 117.82 KB / İndirme Sayısı: 1) ]]> <![CDATA[HPE ArubaOS'ta 72 Açık, 8'i En Yüksek Önemde: AOS-8 ve AOS-10 İçin Yama Rehberi]]> https://www.turkteam.org/konu-hpe-arubaos-ta-72-acik-8-i-en-yuksek-onemde-aos-8-ve-aos-10-icin-yama-rehberi.html Sat, 24 Oct 2026 11:17:01 +0300 Tonyukuk]]> https://www.turkteam.org/konu-hpe-arubaos-ta-72-acik-8-i-en-yuksek-onemde-aos-8-ve-aos-10-icin-yama-rehberi.html [Resim: attachment.php?aid=391]
Selamlar,

HPE, kurumsal kablosuz ve kampüs ağlarında yaygın kullanılan ArubaOS (AOS) için 72 güvenlik açığını kapatan güncellemeler yayımladı. BleepingComputer'ın 23 Ekim 2026 tarihli haberine göre bunların sekizi en yüksek önem derecesinde ve çoğu kimlik doğrulama gerektirmeden kod çalıştırmaya imkan veriyor.

Konuda anlatılacaklar
  1. Kritik sekiz açık
  2. AOS-8 ve AOS-10 farkı
  3. İstismar durumu
  4. Geçici önlemler
  5. Yama ve doğrulama adımları

1. Kritik sekiz açık
Kod:
CVE-2026-79844 Kimlik dogrulama atlatma -> RCE (AOS-10) CVE-2026-79845 PAPI kimlik dogrulama atlatma (AOS-10) CVE-2026-79846 Kimlik dogrulamasiz komut enjeksiyonu (AOS-8) CVE-2026-79847 Kimlik dogrulamasiz bellek tasmasi RCE (AOS-10) CVE-2026-79848 Kimlik dogrulamasiz SQLi -> RCE (AOS-8) CVE-2026-79849 Kimlik dogrulamasiz SQLi -> RCE (AOS-8) CVE-2026-79850 Kimlik dogrulama atlatma -> RCE (AOS-8) CVE-2026-79851 Kimlik dogrulamasiz bellek tasmasi RCE (AOS-10)
Geri kalan 64 açık daha düşük önemde olsa da aynı güncellemeyle kapanıyor.

2. AOS-8 ve AOS-10
AOS-8 genellikle Mobility Conductor / Mobility Controller mimarisiyle yerinde yönetilen kurulumlarda, AOS-10 ise Aruba Central ile buluttan yönetilen gateway ve erişim noktalarında görülür. Envanterinizde hangisinin çalıştığını bilmeden doğru bülteni okuyamazsınız.

3. İstismar durumu
Habere göre HPE, bu açıklar için kamuya açık bir PoC veya aktif istismar bilgisinin olmadığını belirtiyor. Kenar cihaz açıklarının yama sonrası günlerde tersine mühendislikle istismar edildiğini bu ay da birçok kez gördük; beklemek için gerekçe değil.

4. Geçici önlemler
HPE'nin önerdiği azaltımlar yönetim düzlemini daraltmaya dayanıyor:
  • CLI ve web tabanlı yönetim arayüzlerini ayrılmış bir L2 VLAN içine alın.
  • Ve/veya L3 güvenlik duvarı ile yalnızca yönetim ağından erişime izin verin.
  • Yönetim erişimleri için hesap kaydı (accounting) ve günlüklemeyi açın.

5. Yama ve doğrulama
  1. HPE destek portalındaki ilgili güvenlik bültenini açın ve cihaz modeliniz için düzeltilmiş sürümü not edin.
  2. Yapılandırma yedeğini alın, bakım penceresi planlayın.
  3. Yükseltme sonrası sürümü doğrulayın:
    Kod:
    show version show image version
  4. Son haftaların yönetim oturumu günlüklerinde beklenmeyen kaynak IP arayın.

Kurumunuzda Aruba denetleyicilerinin yönetim arayüzü ayrı bir VLAN'da mı?

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

.png   02-t02-hpe-arubaos-72-acik.png (Dosya Boyutu: 129.1 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=391]
Selamlar,

HPE, kurumsal kablosuz ve kampüs ağlarında yaygın kullanılan ArubaOS (AOS) için 72 güvenlik açığını kapatan güncellemeler yayımladı. BleepingComputer'ın 23 Ekim 2026 tarihli haberine göre bunların sekizi en yüksek önem derecesinde ve çoğu kimlik doğrulama gerektirmeden kod çalıştırmaya imkan veriyor.

Konuda anlatılacaklar
  1. Kritik sekiz açık
  2. AOS-8 ve AOS-10 farkı
  3. İstismar durumu
  4. Geçici önlemler
  5. Yama ve doğrulama adımları

1. Kritik sekiz açık
Kod:
CVE-2026-79844 Kimlik dogrulama atlatma -> RCE (AOS-10) CVE-2026-79845 PAPI kimlik dogrulama atlatma (AOS-10) CVE-2026-79846 Kimlik dogrulamasiz komut enjeksiyonu (AOS-8) CVE-2026-79847 Kimlik dogrulamasiz bellek tasmasi RCE (AOS-10) CVE-2026-79848 Kimlik dogrulamasiz SQLi -> RCE (AOS-8) CVE-2026-79849 Kimlik dogrulamasiz SQLi -> RCE (AOS-8) CVE-2026-79850 Kimlik dogrulama atlatma -> RCE (AOS-8) CVE-2026-79851 Kimlik dogrulamasiz bellek tasmasi RCE (AOS-10)
Geri kalan 64 açık daha düşük önemde olsa da aynı güncellemeyle kapanıyor.

2. AOS-8 ve AOS-10
AOS-8 genellikle Mobility Conductor / Mobility Controller mimarisiyle yerinde yönetilen kurulumlarda, AOS-10 ise Aruba Central ile buluttan yönetilen gateway ve erişim noktalarında görülür. Envanterinizde hangisinin çalıştığını bilmeden doğru bülteni okuyamazsınız.

3. İstismar durumu
Habere göre HPE, bu açıklar için kamuya açık bir PoC veya aktif istismar bilgisinin olmadığını belirtiyor. Kenar cihaz açıklarının yama sonrası günlerde tersine mühendislikle istismar edildiğini bu ay da birçok kez gördük; beklemek için gerekçe değil.

4. Geçici önlemler
HPE'nin önerdiği azaltımlar yönetim düzlemini daraltmaya dayanıyor:
  • CLI ve web tabanlı yönetim arayüzlerini ayrılmış bir L2 VLAN içine alın.
  • Ve/veya L3 güvenlik duvarı ile yalnızca yönetim ağından erişime izin verin.
  • Yönetim erişimleri için hesap kaydı (accounting) ve günlüklemeyi açın.

5. Yama ve doğrulama
  1. HPE destek portalındaki ilgili güvenlik bültenini açın ve cihaz modeliniz için düzeltilmiş sürümü not edin.
  2. Yapılandırma yedeğini alın, bakım penceresi planlayın.
  3. Yükseltme sonrası sürümü doğrulayın:
    Kod:
    show version show image version
  4. Son haftaların yönetim oturumu günlüklerinde beklenmeyen kaynak IP arayın.

Kurumunuzda Aruba denetleyicilerinin yönetim arayüzü ayrı bir VLAN'da mı?

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

.png   02-t02-hpe-arubaos-72-acik.png (Dosya Boyutu: 129.1 KB / İndirme Sayısı: 2) ]]> <![CDATA[BIND 9 CVE-2026-94300: GSS-TSIG Mesaj Tekrarıyla Bellek Bozulması ve Olası RCE]]> https://www.turkteam.org/konu-bind-9-cve-2026-94300-gss-tsig-mesaj-tekrariyla-bellek-bozulmasi-ve-olasi-rce.html Fri, 23 Oct 2026 11:18:43 +0300 Tonyukuk]]> https://www.turkteam.org/konu-bind-9-cve-2026-94300-gss-tsig-mesaj-tekrariyla-bellek-bozulmasi-ve-olasi-rce.html [Resim: attachment.php?aid=368]
Selamlar,

DNS altyapısı yönetenler için önemli bir duyuru: ISC, 21 Ekim 2026'da BIND 9'un named servisinde uzaktan istismar edilebilir bir bellek bozulması açığını duyurdu. CVE-2026-94300, CVSS 3.1 puanı 8.1 (High). Özellikle Active Directory tarzı dinamik DNS güncellemeleri için GSS-TSIG (Kerberos imzalama) kullanan ortamları ilgilendiriyor.

Konuda anlatılacaklar
  1. GSS-TSIG nedir, kısaca?
  2. Açığın senaryosu
  3. Etkilenen ve düzeltilen sürümler
  4. Dağıtım durumu
  5. Kontrol ve sertleştirme adımları

GSS-TSIG kısaca
TSIG, DNS mesajlarını paylaşılan bir anahtarla imzalayarak sunucu-sunucu veya istemci-sunucu iletişimini doğrular. GSS-TSIG ise bu anahtarı Kerberos ile müzakere eder; Windows istemcilerinin kendi kayıtlarını güvenli dinamik güncelleme ile yazması bu yöntemle çalışır. BIND'i AD ile entegre eden kurumlarda tkey-gssapi-keytab veya tkey-gssapi-credential ayarı ile açılır.

Açığın senaryosu
ISC'nin bülteni:
  • Daha önce imzalanmış bir UDP mesajını yakalayabilen saldırgan, müzakere edilen TSIG anahtarı hâlâ geçerliyken bu mesajı tekrar gönderebiliyor (replay).
  • Buna ek olarak saldırganın kontrol ettiği bir zone'a özel hazırlanmış sorgular gönderilirse, paylaşılan Kerberos oturum durumu bozulabiliyor.
  • Sonuç: named sürecinin çökmesi ve/veya olası uzaktan kod çalıştırma.
CVSS vektörü AV:N/AC:H/PR:N/UI:N - ağ üzerinden, yetki gerektirmeden ama yüksek karmaşıklıkla (imzalı mesajı yakalamak gerekiyor). ISC'nin düzeltmesi paylaşılan GSS-TSIG oturumuna erişimi seri hale getiriyor. Açık ISC'nin iç testlerinde bulundu ve OpenAI'dan Dave Aitel tarafından bağımsız olarak da bildirildi. ISC aktif istismar bilmiyor.

Sürümler
Kod:
Etkilenen: 9.11.0 - 9.18.50 9.20.0 - 9.20.29 9.21.0 - 9.21.26 Duzeltilen: 9.20.30, 9.21.27 (Preview: 9.20.30-S1) Gecici cozum: YOK
Dikkat: ISC yalnızca desteklenen sürümleri yamalıyor; 9.18 hattı için listede düzeltme yok. pwn.watch'a göre Debian trixie'de yamalı paket var, Debian bookworm ve Ubuntu ise henüz bekliyor.

Kontrol adımları
Kod:
named -v # GSS-TSIG acik mi? grep -REn "tkey-gssapi|tkey-domain" /etc/bind /etc/named* 2>/dev/null # Debian/Ubuntu paket changelog'unda CVE apt changelog bind9 2>/dev/null | grep -n "CVE-2026-94300"

Yama gelene kadar risk azaltma
Geçici çözüm olmadığı için bunlar yalnızca saldırı yüzeyini daraltır:
  • Dinamik güncelleme kabul eden arayüzleri yalnızca iç ağa açın; update-policy ile kimin hangi kayda yazabileceğini daraltın.
  • GSS-TSIG gerçekten gerekmiyorsa kapatın; gerekiyorsa DNS trafiğinin yakalanabileceği ağ segmentlerini (paylaşımlı L2, misafir Wi-Fi) ayırın.
  • Yetkili (authoritative) ve özyinelemeli (recursive) rolleri ayrı sunuculara bölün.
  • named çökmelerini izleyin; systemd yeniden başlatsa bile tekrarlayan çökme bir saldırı denemesinin işareti olabilir.
Kod:
journalctl -u named --since "2026-10-21" | grep -Ei "assert|abort|exiting"
DNS'e yeni başlayanlar için temel kavramları anlatan bir konuyu Başlangıç Rehberi bölümünde paylaşıyoruz.

BIND'i AD ile GSS-TSIG üzerinden entegre eden var mı? Dağıtımınız yamayı yayınladı mı?

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

.png   05-t05-bind-gss-tsig.png (Dosya Boyutu: 117.89 KB / İndirme Sayısı: 3) ]]> [Resim: attachment.php?aid=368]
Selamlar,

DNS altyapısı yönetenler için önemli bir duyuru: ISC, 21 Ekim 2026'da BIND 9'un named servisinde uzaktan istismar edilebilir bir bellek bozulması açığını duyurdu. CVE-2026-94300, CVSS 3.1 puanı 8.1 (High). Özellikle Active Directory tarzı dinamik DNS güncellemeleri için GSS-TSIG (Kerberos imzalama) kullanan ortamları ilgilendiriyor.

Konuda anlatılacaklar
  1. GSS-TSIG nedir, kısaca?
  2. Açığın senaryosu
  3. Etkilenen ve düzeltilen sürümler
  4. Dağıtım durumu
  5. Kontrol ve sertleştirme adımları

GSS-TSIG kısaca
TSIG, DNS mesajlarını paylaşılan bir anahtarla imzalayarak sunucu-sunucu veya istemci-sunucu iletişimini doğrular. GSS-TSIG ise bu anahtarı Kerberos ile müzakere eder; Windows istemcilerinin kendi kayıtlarını güvenli dinamik güncelleme ile yazması bu yöntemle çalışır. BIND'i AD ile entegre eden kurumlarda tkey-gssapi-keytab veya tkey-gssapi-credential ayarı ile açılır.

Açığın senaryosu
ISC'nin bülteni:
  • Daha önce imzalanmış bir UDP mesajını yakalayabilen saldırgan, müzakere edilen TSIG anahtarı hâlâ geçerliyken bu mesajı tekrar gönderebiliyor (replay).
  • Buna ek olarak saldırganın kontrol ettiği bir zone'a özel hazırlanmış sorgular gönderilirse, paylaşılan Kerberos oturum durumu bozulabiliyor.
  • Sonuç: named sürecinin çökmesi ve/veya olası uzaktan kod çalıştırma.
CVSS vektörü AV:N/AC:H/PR:N/UI:N - ağ üzerinden, yetki gerektirmeden ama yüksek karmaşıklıkla (imzalı mesajı yakalamak gerekiyor). ISC'nin düzeltmesi paylaşılan GSS-TSIG oturumuna erişimi seri hale getiriyor. Açık ISC'nin iç testlerinde bulundu ve OpenAI'dan Dave Aitel tarafından bağımsız olarak da bildirildi. ISC aktif istismar bilmiyor.

Sürümler
Kod:
Etkilenen: 9.11.0 - 9.18.50 9.20.0 - 9.20.29 9.21.0 - 9.21.26 Duzeltilen: 9.20.30, 9.21.27 (Preview: 9.20.30-S1) Gecici cozum: YOK
Dikkat: ISC yalnızca desteklenen sürümleri yamalıyor; 9.18 hattı için listede düzeltme yok. pwn.watch'a göre Debian trixie'de yamalı paket var, Debian bookworm ve Ubuntu ise henüz bekliyor.

Kontrol adımları
Kod:
named -v # GSS-TSIG acik mi? grep -REn "tkey-gssapi|tkey-domain" /etc/bind /etc/named* 2>/dev/null # Debian/Ubuntu paket changelog'unda CVE apt changelog bind9 2>/dev/null | grep -n "CVE-2026-94300"

Yama gelene kadar risk azaltma
Geçici çözüm olmadığı için bunlar yalnızca saldırı yüzeyini daraltır:
  • Dinamik güncelleme kabul eden arayüzleri yalnızca iç ağa açın; update-policy ile kimin hangi kayda yazabileceğini daraltın.
  • GSS-TSIG gerçekten gerekmiyorsa kapatın; gerekiyorsa DNS trafiğinin yakalanabileceği ağ segmentlerini (paylaşımlı L2, misafir Wi-Fi) ayırın.
  • Yetkili (authoritative) ve özyinelemeli (recursive) rolleri ayrı sunuculara bölün.
  • named çökmelerini izleyin; systemd yeniden başlatsa bile tekrarlayan çökme bir saldırı denemesinin işareti olabilir.
Kod:
journalctl -u named --since "2026-10-21" | grep -Ei "assert|abort|exiting"
DNS'e yeni başlayanlar için temel kavramları anlatan bir konuyu Başlangıç Rehberi bölümünde paylaşıyoruz.

BIND'i AD ile GSS-TSIG üzerinden entegre eden var mı? Dağıtımınız yamayı yayınladı mı?

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

.png   05-t05-bind-gss-tsig.png (Dosya Boyutu: 117.89 KB / İndirme Sayısı: 3) ]]> <![CDATA[Tor Çıkış Röleleri SSH'yi Yönlendirdi: 333 Röle, Ebury ve Host Anahtarı Uyarısı]]> https://www.turkteam.org/konu-tor-cikis-roleleri-ssh-yi-yonlendirdi-333-role-ebury-ve-host-anahtari-uyarisi.html Thu, 22 Oct 2026 11:19:55 +0300 Tonyukuk]]> https://www.turkteam.org/konu-tor-cikis-roleleri-ssh-yi-yonlendirdi-333-role-ebury-ve-host-anahtari-uyarisi.html [Resim: attachment.php?aid=343]
Selamlar,

Tor üzerinden SSH yapanlar için Ekim 2026'nın en kritik ağı olayı: Araştırmacı kaba (kaba.cx) 2 Ekim'de Tor'un yaklaşık 3000 çıkış rölesinden 333'ünün (kabaca %10) SSH trafiğini 12 adet ara sunucuya yönlendirdiğini tespit etti. Röleler Ağustos'ta ele geçirilmiş ve Ebury 1.8.3 (Linux için OpenSSH arka kapısı) yerleştirilmişti. Tor Network Health ekibi 4 Ekim'de röleleri BadExit olarak işaretledi; 5 Ekim'de enfekte sunucular kapatıldı.

Konuda anlatılacaklar
  1. Saldırı nasıl çalışıyordu?
  2. Araştırmacı nasıl buldu?
  3. Zaman çizelgesi
  4. SSH kullanıcıları için pratik dersler

Saldırı nasıl çalışıyordu?
kaba'nın yazısına göre saldırının iki hedefi vardı: şifrelenmemiş posta trafiğini toplamak ve SSH bağlantılarını MITM ile dinlemek. Belirli portları engelleyerek çıkış rölelerini yalnızca şifrelenmemiş posta trafiğine yönlendirdiler. SSH tarafında ise port 22'ye giden bağlantı, kullanıcının fark etmeyeceği şekilde 12 ara sunucudan birine yönlendiriliyordu. Şifreli web trafiği normal iletiliyordu.

Araştırmacı kendi bağlantısı yönlendirildiğinde klasik OpenSSH uyarısını gördü:
Kod:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Bu uyarıyı yok sayıp parola ile giriş yapan kullanıcı için saldırgan üç şey yapıyordu: parolayı çalmak, gerçek sunucuya bağlanıp yazılan komutları izlemek ve sunucuya ikinci bir bağlantıyla Ebury bulaştırmak.

Nasıl bulundu?
Araştırmacı exitmap ile her çıkış rölesini sabitleyip kendi sunucu A'sından sunucu B'sine SSH açtı. A, B'nin beklenen parmak izini alıp almadığını; B ise bağlantının sabitlediği çıkıştan mı yoksa 12 ara sunucudan mı geldiğini kontrol etti. Yaklaşık bir düzine röle sahte parmak izi verdi; 300'den fazlası ise aynı ara sunucular üzerinden yönlendirdi. Yönlendirme tek başına enfeksiyon kanıtı sayıldı.

Honeypot (sshesame) ile yapılan ek analizde MITM tarafının paramiko (Python SSH kütüphanesi) kullandığı ve Ebury'yi Perl ile, base64 kodlu bir komut üzerinden yüklemeye çalıştığı görüldü.

Zaman çizelgesi
  • Ağustos: Röle sunucularına erişim ve Ebury 1.8.3 yerleşimi
  • 2 Ekim Cuma: 333 çıkış rölesinde eşgüdümlü yönlendirme başlıyor
  • 2 Ekim akşamı: Araştırmacı Tor Network Health'e bildiriyor
  • 4 Ekim: Operatörlere duyuru, BadExit işaretleme, kapatmalar başlıyor
  • 5 Ekim: Saldırganlar birçok röleyi yeniden başlatıyor ama BadExit olduğu için yalnızca orta (middle) röle olarak kalıyorlar; enfekte sunucular kapatılıyor
Tor ekibinin duyurusunda dikkat çeken cümle: saldırganın Linux hostlara eriştikten sonra, çıkış olmayan rölelerin torrc dosyasını düzenleyip onları çıkışa çevirdiği.

SSH kullanıcıları için pratik dersler
  1. Host anahtarı uyarısını asla yok saymayın. "Someone could be eavesdropping" cümlesi burada edebiyat değil, gerçek MITM'i tarif ediyor.
  2. Parola kimlik doğrulamayı kapatın. Saldırı, parolasız (anahtar tabanlı) ve host anahtarını doğrulayan kullanıcılara karşı işe yaramıyordu.
  3. 1-5 Ekim arası Tor üzerinden parola ile SSH yaptıysanız o parolayı değiştirin, sunucudaki yetkili anahtarları ve giriş kayıtlarını gözden geçirin.
  4. StrictHostKeyChecking=yes ve bilinen host anahtarlarını bir güvenli kanaldan (ör. yönetici paneli, out-of-band) doğrulayın.

Kod:
# Kendi istemcinizde (OpenSSH) - parola kimlik doğrulamayı kapat # ~/.ssh/config örneği Host * PasswordAuthentication no PubkeyAuthentication yes StrictHostKeyChecking yes UpdateHostKeys yes # Host anahtarını out-of-band doğrulama ssh-keyscan -t ed25519 hedef.ornek 2>/dev/null | ssh-keygen -lf -

Açık sorular
Araştırmacı, saldırganların bu kadar çok sunucuya ilk erişimi nasıl kazandığını ve arkasında kimlerin olduğunu henüz bilinmeyen noktalar olarak bırakıyor. Tor listelerinde barındırma firmasının ele geçirilmiş olabileceği spekülasyonu dolaşıyor; bu henüz kanıtlanmış bir gerçek değil. Sonuç net: Tor çıkışları "güvenilir proxy" değil; uçtan uca kimlik doğrulama (SSH anahtarı + host anahtarı doğrulama) olmadan geçen her parola risk altındadır.

Tor üzerinden yönetim yapan var mı aranızda? Host anahtarı değişikliği yaşadınız mı?

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

.png   06-t06-tor-ssh-ebury.png (Dosya Boyutu: 115.24 KB / İndirme Sayısı: 4) ]]> [Resim: attachment.php?aid=343]
Selamlar,

Tor üzerinden SSH yapanlar için Ekim 2026'nın en kritik ağı olayı: Araştırmacı kaba (kaba.cx) 2 Ekim'de Tor'un yaklaşık 3000 çıkış rölesinden 333'ünün (kabaca %10) SSH trafiğini 12 adet ara sunucuya yönlendirdiğini tespit etti. Röleler Ağustos'ta ele geçirilmiş ve Ebury 1.8.3 (Linux için OpenSSH arka kapısı) yerleştirilmişti. Tor Network Health ekibi 4 Ekim'de röleleri BadExit olarak işaretledi; 5 Ekim'de enfekte sunucular kapatıldı.

Konuda anlatılacaklar
  1. Saldırı nasıl çalışıyordu?
  2. Araştırmacı nasıl buldu?
  3. Zaman çizelgesi
  4. SSH kullanıcıları için pratik dersler

Saldırı nasıl çalışıyordu?
kaba'nın yazısına göre saldırının iki hedefi vardı: şifrelenmemiş posta trafiğini toplamak ve SSH bağlantılarını MITM ile dinlemek. Belirli portları engelleyerek çıkış rölelerini yalnızca şifrelenmemiş posta trafiğine yönlendirdiler. SSH tarafında ise port 22'ye giden bağlantı, kullanıcının fark etmeyeceği şekilde 12 ara sunucudan birine yönlendiriliyordu. Şifreli web trafiği normal iletiliyordu.

Araştırmacı kendi bağlantısı yönlendirildiğinde klasik OpenSSH uyarısını gördü:
Kod:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Bu uyarıyı yok sayıp parola ile giriş yapan kullanıcı için saldırgan üç şey yapıyordu: parolayı çalmak, gerçek sunucuya bağlanıp yazılan komutları izlemek ve sunucuya ikinci bir bağlantıyla Ebury bulaştırmak.

Nasıl bulundu?
Araştırmacı exitmap ile her çıkış rölesini sabitleyip kendi sunucu A'sından sunucu B'sine SSH açtı. A, B'nin beklenen parmak izini alıp almadığını; B ise bağlantının sabitlediği çıkıştan mı yoksa 12 ara sunucudan mı geldiğini kontrol etti. Yaklaşık bir düzine röle sahte parmak izi verdi; 300'den fazlası ise aynı ara sunucular üzerinden yönlendirdi. Yönlendirme tek başına enfeksiyon kanıtı sayıldı.

Honeypot (sshesame) ile yapılan ek analizde MITM tarafının paramiko (Python SSH kütüphanesi) kullandığı ve Ebury'yi Perl ile, base64 kodlu bir komut üzerinden yüklemeye çalıştığı görüldü.

Zaman çizelgesi
  • Ağustos: Röle sunucularına erişim ve Ebury 1.8.3 yerleşimi
  • 2 Ekim Cuma: 333 çıkış rölesinde eşgüdümlü yönlendirme başlıyor
  • 2 Ekim akşamı: Araştırmacı Tor Network Health'e bildiriyor
  • 4 Ekim: Operatörlere duyuru, BadExit işaretleme, kapatmalar başlıyor
  • 5 Ekim: Saldırganlar birçok röleyi yeniden başlatıyor ama BadExit olduğu için yalnızca orta (middle) röle olarak kalıyorlar; enfekte sunucular kapatılıyor
Tor ekibinin duyurusunda dikkat çeken cümle: saldırganın Linux hostlara eriştikten sonra, çıkış olmayan rölelerin torrc dosyasını düzenleyip onları çıkışa çevirdiği.

SSH kullanıcıları için pratik dersler
  1. Host anahtarı uyarısını asla yok saymayın. "Someone could be eavesdropping" cümlesi burada edebiyat değil, gerçek MITM'i tarif ediyor.
  2. Parola kimlik doğrulamayı kapatın. Saldırı, parolasız (anahtar tabanlı) ve host anahtarını doğrulayan kullanıcılara karşı işe yaramıyordu.
  3. 1-5 Ekim arası Tor üzerinden parola ile SSH yaptıysanız o parolayı değiştirin, sunucudaki yetkili anahtarları ve giriş kayıtlarını gözden geçirin.
  4. StrictHostKeyChecking=yes ve bilinen host anahtarlarını bir güvenli kanaldan (ör. yönetici paneli, out-of-band) doğrulayın.

Kod:
# Kendi istemcinizde (OpenSSH) - parola kimlik doğrulamayı kapat # ~/.ssh/config örneği Host * PasswordAuthentication no PubkeyAuthentication yes StrictHostKeyChecking yes UpdateHostKeys yes # Host anahtarını out-of-band doğrulama ssh-keyscan -t ed25519 hedef.ornek 2>/dev/null | ssh-keygen -lf -

Açık sorular
Araştırmacı, saldırganların bu kadar çok sunucuya ilk erişimi nasıl kazandığını ve arkasında kimlerin olduğunu henüz bilinmeyen noktalar olarak bırakıyor. Tor listelerinde barındırma firmasının ele geçirilmiş olabileceği spekülasyonu dolaşıyor; bu henüz kanıtlanmış bir gerçek değil. Sonuç net: Tor çıkışları "güvenilir proxy" değil; uçtan uca kimlik doğrulama (SSH anahtarı + host anahtarı doğrulama) olmadan geçen her parola risk altındadır.

Tor üzerinden yönetim yapan var mı aranızda? Host anahtarı değişikliği yaşadınız mı?

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

.png   06-t06-tor-ssh-ebury.png (Dosya Boyutu: 115.24 KB / İndirme Sayısı: 4) ]]> <![CDATA[RFC 1918 Özel Ağlar: Lab Segmentasyonu ve Yanlış Yönlendirme Tuzakları]]> https://www.turkteam.org/konu-rfc-1918-ozel-aglar-lab-segmentasyonu-ve-yanlis-yonlendirme-tuzaklari.html Wed, 21 Oct 2026 11:31:34 +0300 KulTigin]]> https://www.turkteam.org/konu-rfc-1918-ozel-aglar-lab-segmentasyonu-ve-yanlis-yonlendirme-tuzaklari.html [Resim: attachment.php?aid=334]
Merhaba,

Ev labı kurarken IP planı sık sık ihmal edilir. RFC 1918 özel IPv4 bloklarını tanımlar; bunları doğru kullanmak hem NAT karmaşasını hem de "lab yanlışlıkla ofise sızdı" felaketini önler. Kısa ve uygulamalı bir hatırlatma.

Bloklar
  • 10.0.0.0/8
  • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
  • 192.168.0.0/16
Bu adresler internette route edilmez (olmamalıdır). ISP'niz size bunları vermez; siz içeride kullanırsınız.

Lab önerisi
Kod:
# Örnek plan # 10.50.0.0/24 - hypervisor / yönetim # 10.50.10.0/24 - saldırgan (Kali) # 10.50.20.0/24 - hedefler (DVWA, Metasploitable) # 10.50.30.0/24 - mavi takım (SIEM, DC lab)
Sanal switch'lerde promiscuous/host-only ayrımı yapın. Hedef VLAN'dan yönetim ağına varsayılan rota vermeyin.

Sık tuzaklar
  • Şirket VPN'i 10.0.0.0/8 kullanıyorsa ev labı ile çakışma → split tunnel veya farklı blok (172.16.x)
  • Docker bridge 172.17.0.0/16 ile lab çakışması
  • Özel IP'yi internete advertise etmeye çalışmak / sızıntı
  • "IP gizleme" sanmak: RFC1918 gizlilik sağlamaz, yalnızca adres alanıdır

Hızlı kontrol
Kod:
ip -4 route ip -4 addr # Beklenmeyen default route var mı?

Yasal uyarı
Ağ segmentasyonu başkalarının ağlarına izinsiz girmek için kullanılmaz.

Kaynaklar
Dokümantasyon
IP planını tek sayfalık diyagram + tablo olarak wiki'ye koyun. Yeni VM açan herkes aynı sayfadan adres alsın. Çakışma ticket'ı "kim 10.0.0.0/8'i kapmış" diye aranması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
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
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.

Kısa senaryo
Diyelim ki bu konuyu pazartesi sabah toplantısında anlatacaksınız: bir slaytta risk, bir slaytta etkilenen varlık sorusu, bir slaytta bugün yapılacak tek eylem. Üç slayttan fazlası dikkat dağıtır. Toplantı bitince eylem sahibinin adını ticket'a yazın.

.png   17-k02-rfc1918.png (Dosya Boyutu: 115.33 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=334]
Merhaba,

Ev labı kurarken IP planı sık sık ihmal edilir. RFC 1918 özel IPv4 bloklarını tanımlar; bunları doğru kullanmak hem NAT karmaşasını hem de "lab yanlışlıkla ofise sızdı" felaketini önler. Kısa ve uygulamalı bir hatırlatma.

Bloklar
  • 10.0.0.0/8
  • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
  • 192.168.0.0/16
Bu adresler internette route edilmez (olmamalıdır). ISP'niz size bunları vermez; siz içeride kullanırsınız.

Lab önerisi
Kod:
# Örnek plan # 10.50.0.0/24 - hypervisor / yönetim # 10.50.10.0/24 - saldırgan (Kali) # 10.50.20.0/24 - hedefler (DVWA, Metasploitable) # 10.50.30.0/24 - mavi takım (SIEM, DC lab)
Sanal switch'lerde promiscuous/host-only ayrımı yapın. Hedef VLAN'dan yönetim ağına varsayılan rota vermeyin.

Sık tuzaklar
  • Şirket VPN'i 10.0.0.0/8 kullanıyorsa ev labı ile çakışma → split tunnel veya farklı blok (172.16.x)
  • Docker bridge 172.17.0.0/16 ile lab çakışması
  • Özel IP'yi internete advertise etmeye çalışmak / sızıntı
  • "IP gizleme" sanmak: RFC1918 gizlilik sağlamaz, yalnızca adres alanıdır

Hızlı kontrol
Kod:
ip -4 route ip -4 addr # Beklenmeyen default route var mı?

Yasal uyarı
Ağ segmentasyonu başkalarının ağlarına izinsiz girmek için kullanılmaz.

Kaynaklar
Dokümantasyon
IP planını tek sayfalık diyagram + tablo olarak wiki'ye koyun. Yeni VM açan herkes aynı sayfadan adres alsın. Çakışma ticket'ı "kim 10.0.0.0/8'i kapmış" diye aranması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
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
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.

Kısa senaryo
Diyelim ki bu konuyu pazartesi sabah toplantısında anlatacaksınız: bir slaytta risk, bir slaytta etkilenen varlık sorusu, bir slaytta bugün yapılacak tek eylem. Üç slayttan fazlası dikkat dağıtır. Toplantı bitince eylem sahibinin adını ticket'a yazın.

.png   17-k02-rfc1918.png (Dosya Boyutu: 115.33 KB / İndirme Sayısı: 9) ]]> <![CDATA[tcpdump ile Sahada En Çok Kullandığım Filtreler: BPF Mantığı ve Örnekler]]> https://www.turkteam.org/konu-tcpdump-ile-sahada-en-cok-kullandigim-filtreler-bpf-mantigi-ve-ornekler.html Sun, 18 Oct 2026 22:16:39 +0300 KulTigin]]> https://www.turkteam.org/konu-tcpdump-ile-sahada-en-cok-kullandigim-filtreler-bpf-mantigi-ve-ornekler.html [Resim: attachment.php?aid=259]
Merhaba,

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

Önce temel bayraklar
Her komutta neredeyse refleks olarak kullandığım seçenekler:
Kod:
sudo tcpdump -nn -i eth0 -c 50
  • -n: isim çözümlemesi yapma (DNS sorgusu üretmesin, çıktı hızlı gelsin)
  • -nn: hem host hem port isimlerini çözme
  • -i: arayüz seçimi; emin değilseniz -i any veya ip link ile bakın
  • -c: paket sayısı sınırı; unutunca terminali kilitleyen klasik hata
  • -w dosya.pcap: diske yaz; sonra Wireshark ile açarsınız
  • -r dosya.pcap: kayıtlı dosyayı oku
  • -A / -X: ASCII / hex+ASCII; HTTP gibi protokoller için
Yetki notu: ham paket yakalamak genelde CAP_NET_RAW ister. sudo veya setcap kullanın; üretimde setcap'i bilinçli verin.

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

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

Sahada en çok işime yarayan filtreler

1) SYN taraması / yeni bağlantı avı
Kod:
sudo tcpdump -nn -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'
Sadece SYN (ACK yok) paketlerini gösterir. Ani SYN yağmuru port taraması veya flood belirtisi olabilir. Daha kısa yazım:
Kod:
sudo tcpdump -nn -i eth0 'tcp[13] & 2 != 0 and tcp[13] & 16 == 0'
13. bayt TCP bayrak alanı; 2=SYN, 16=ACK.

Labda örnek çıktı:
[Resim: attachment.php?aid=260]

2) DNS sorguları
Kod:
sudo tcpdump -nn -i eth0 port 53
Olay müdahalesinde C2 alan adlarını yakalamak için ilk bakacağım yerlerden biri. UDP 53 dışında DoH (443) varsa bu filtre yetmez; o zaman DNS loguna geçersiniz.

3) Belirli bir HTTP host başlığı (şifresiz trafik)
Kod:
sudo tcpdump -nn -i eth0 -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
Karmaşık görünüyor ama anlamı "HTTP payload taşıyan paketler". Daha pratik alternatif: -A ile port 80'i yakalayıp greplemek veya hemen -w yazıp Wireshark'ta http.host filtresi kullanmak.

4) ARP ve yerel ağ gariplikleri
Kod:
sudo tcpdump -nn -i eth0 arp sudo tcpdump -nn -i eth0 'arp and arp[6:2] == 2'
İkinci satır ARP reply'leri gösterir. Aynı IP için farklı MAC'ler görürseniz spoofing şüphesi.

5) Belirli bir konuşmayı (conversation) yakalamak
Kod:
sudo tcpdump -nn -i eth0 -w oturum.pcap 'host 10.0.0.5 and host 10.0.0.9'
İki uç arasındaki tüm trafiği kaydedip sonra Wireshark'ta Follow TCP Stream yaparsınız.

6) ICMP (ping, unreachable)
Kod:
sudo tcpdump -nn -i eth0 icmp
Path sorunlarında ve bazı tarama türlerinde işe yarar.

7) IPv6
Kod:
sudo tcpdump -nn -i eth0 ip6 sudo tcpdump -nn -i eth0 'ip6 and tcp port 22'
Birçok ortamda IPv6 unutuluyor; saldırganlar bunu seviyor.

Ring buffer ile uzun süre dinlemek
Disk doldurmadan saatlerce dinlemek için:
Kod:
sudo tcpdump -nn -i eth0 -W 10 -C 100 -w /var/tmp/capture.pcap 'not port 22'
-C 100: her dosya ~100 MB, -W 10: 10 dosyalık döngü. SSH oturumunuzu kendi yakalamanızdan boğmamak için not port 22 sık kurtarıcı olur.

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

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

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

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

VLAN ve tünel paketlerinde BPF
Saha ağında mirror port VLAN tag taşıyorsa basit host filtresi yetmeyebilir:
Kod:
sudo tcpdump -nn -i eth0 'vlan and host 10.0.0.5' sudo tcpdump -nn -e -i eth0 'vlan 120'
-e Ethernet başlığını gösterir; hangi VLAN'dan geldiğini anında görürsünüz. GRE/VXLAN için önce dış başlığı, sonra içeriği düşünün. Şüphede önce -w ile ham yakalayıp Wireshark'ta decode edin; canlı karmaşık BPF yazmak vakit kaybı olabilir.

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


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

Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n02-ea3ffc.png (Dosya Boyutu: 64.23 KB / İndirme Sayısı: 9)

.png   n02-inner.png (Dosya Boyutu: 20.46 KB / İndirme Sayısı: 11) ]]> [Resim: attachment.php?aid=259]
Merhaba,

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

Önce temel bayraklar
Her komutta neredeyse refleks olarak kullandığım seçenekler:
Kod:
sudo tcpdump -nn -i eth0 -c 50
  • -n: isim çözümlemesi yapma (DNS sorgusu üretmesin, çıktı hızlı gelsin)
  • -nn: hem host hem port isimlerini çözme
  • -i: arayüz seçimi; emin değilseniz -i any veya ip link ile bakın
  • -c: paket sayısı sınırı; unutunca terminali kilitleyen klasik hata
  • -w dosya.pcap: diske yaz; sonra Wireshark ile açarsınız
  • -r dosya.pcap: kayıtlı dosyayı oku
  • -A / -X: ASCII / hex+ASCII; HTTP gibi protokoller için
Yetki notu: ham paket yakalamak genelde CAP_NET_RAW ister. sudo veya setcap kullanın; üretimde setcap'i bilinçli verin.

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

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

Sahada en çok işime yarayan filtreler

1) SYN taraması / yeni bağlantı avı
Kod:
sudo tcpdump -nn -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'
Sadece SYN (ACK yok) paketlerini gösterir. Ani SYN yağmuru port taraması veya flood belirtisi olabilir. Daha kısa yazım:
Kod:
sudo tcpdump -nn -i eth0 'tcp[13] & 2 != 0 and tcp[13] & 16 == 0'
13. bayt TCP bayrak alanı; 2=SYN, 16=ACK.

Labda örnek çıktı:
[Resim: attachment.php?aid=260]

2) DNS sorguları
Kod:
sudo tcpdump -nn -i eth0 port 53
Olay müdahalesinde C2 alan adlarını yakalamak için ilk bakacağım yerlerden biri. UDP 53 dışında DoH (443) varsa bu filtre yetmez; o zaman DNS loguna geçersiniz.

3) Belirli bir HTTP host başlığı (şifresiz trafik)
Kod:
sudo tcpdump -nn -i eth0 -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
Karmaşık görünüyor ama anlamı "HTTP payload taşıyan paketler". Daha pratik alternatif: -A ile port 80'i yakalayıp greplemek veya hemen -w yazıp Wireshark'ta http.host filtresi kullanmak.

4) ARP ve yerel ağ gariplikleri
Kod:
sudo tcpdump -nn -i eth0 arp sudo tcpdump -nn -i eth0 'arp and arp[6:2] == 2'
İkinci satır ARP reply'leri gösterir. Aynı IP için farklı MAC'ler görürseniz spoofing şüphesi.

5) Belirli bir konuşmayı (conversation) yakalamak
Kod:
sudo tcpdump -nn -i eth0 -w oturum.pcap 'host 10.0.0.5 and host 10.0.0.9'
İki uç arasındaki tüm trafiği kaydedip sonra Wireshark'ta Follow TCP Stream yaparsınız.

6) ICMP (ping, unreachable)
Kod:
sudo tcpdump -nn -i eth0 icmp
Path sorunlarında ve bazı tarama türlerinde işe yarar.

7) IPv6
Kod:
sudo tcpdump -nn -i eth0 ip6 sudo tcpdump -nn -i eth0 'ip6 and tcp port 22'
Birçok ortamda IPv6 unutuluyor; saldırganlar bunu seviyor.

Ring buffer ile uzun süre dinlemek
Disk doldurmadan saatlerce dinlemek için:
Kod:
sudo tcpdump -nn -i eth0 -W 10 -C 100 -w /var/tmp/capture.pcap 'not port 22'
-C 100: her dosya ~100 MB, -W 10: 10 dosyalık döngü. SSH oturumunuzu kendi yakalamanızdan boğmamak için not port 22 sık kurtarıcı olur.

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

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

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

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

VLAN ve tünel paketlerinde BPF
Saha ağında mirror port VLAN tag taşıyorsa basit host filtresi yetmeyebilir:
Kod:
sudo tcpdump -nn -i eth0 'vlan and host 10.0.0.5' sudo tcpdump -nn -e -i eth0 'vlan 120'
-e Ethernet başlığını gösterir; hangi VLAN'dan geldiğini anında görürsünüz. GRE/VXLAN için önce dış başlığı, sonra içeriği düşünün. Şüphede önce -w ile ham yakalayıp Wireshark'ta decode edin; canlı karmaşık BPF yazmak vakit kaybı olabilir.

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


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

Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n02-ea3ffc.png (Dosya Boyutu: 64.23 KB / İndirme Sayısı: 9)

.png   n02-inner.png (Dosya Boyutu: 20.46 KB / İndirme Sayısı: 11) ]]> <![CDATA[Zeek ile Ag Guvenlik Izleme: Kurulum ve Ilk Loglarin Okunmasi]]> https://www.turkteam.org/konu-zeek-ile-ag-guvenlik-izleme-kurulum-ve-ilk-loglarin-okunmasi.html Sat, 17 Oct 2026 11:27:28 +0300 BilgeKagan]]> https://www.turkteam.org/konu-zeek-ile-ag-guvenlik-izleme-kurulum-ve-ilk-loglarin-okunmasi.html [Resim: attachment.php?aid=103]
Merhaba arkadaslar,

Wireshark paketi tek tek incelemek icin harika ama surekli calisan, olay ureten bir ag gorunurlugu istiyorsaniz Zeek (eski adiyla Bro) cok daha uygun. Zeek ham trafigi zengin, yapilandirilmis loglara cevirir. Bu konuda kurulumu ve ilk loglari okumayi anlatacagim.

Konuda Anlatilacaklar
  1. Zeek nedir, IDS'ten farki
  2. Kurulum
  3. Pcap'ten log uretme
  4. Onemli log dosyalari
  5. Basit bir tespit mantigi

1) Zeek Nedir?
Zeek bir imza tabanli IDS degil; bir ag analiz cercevesidir. Snort/Suricata "bu imzaya uyan paketi yakala" derken, Zeek "agda ne olup bittigini" ayrintili olarak kaydeder: hangi IP hangi IP ile konustu, hangi DNS sorgusu yapildi, hangi dosya transfer edildi. Bu loglar sonradan avlanma (threat hunting) icin paha bicilmezdir.

2) Kurulum
Debian/Ubuntu uzerinde resmi depo ile:

Kod:
echo 'deb http://download.opensuse.org/repositories/security:/zeek/Debian_12/ /' | sudo tee /etc/apt/sources.list.d/zeek.list sudo apt update && sudo apt install -y zeek export PATH=$PATH:/opt/zeek/bin

3) Pcap'ten Log Uretme
Canli arayuz yerine once elinizdeki bir pcap ile denemek guvenli yoldur:

Kod:
zeek -r ornek.pcap ls # conn.log dns.log http.log ssl.log files.log ...

Zeek her protokol icin ayri bir log uretir. Canli dinleme icin
Kod:
sudo zeek -i eth0
yeterli (yalnizca kendi aginizda).

4) Onemli Loglar
  • conn.log: tum baglantilarin ozeti (kaynak, hedef, sure, bayt)
  • dns.log: DNS sorgulari, DGA/tunnel avinda altin deger
  • http.log: istekler, user-agent, URI
  • ssl.log: TLS el sikismalari, sertifikalar (JA3 ile birlikte)
  • files.log: transfer edilen dosyalar ve hash'leri

Loglari okumak icin zeek-cut pratiktir:

Kod:
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p service duration | head

5) Basit Tespit
Ornegin cok sayida farkli porta kisa baglantilar bir port taramasina isaret edebilir. dns.log'da anormal derecede uzun veya cok sayida alt alan adi DNS tunnel suphesi yaratir. Bu loglari Elastic veya baska bir SIEM'e besleyip panolar kurabilirsiniz.

Kaynaklar
Alıntı:Yasal not: Trafik izlemeyi yalnizca sahibi oldugunuz veya izinli oldugunuz aglarda yapin.

Siz Zeek loglarini hangi SIEM ile besliyorsunuz?

.png   bilgekagan-b06.png (Dosya Boyutu: 82.67 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=103]
Merhaba arkadaslar,

Wireshark paketi tek tek incelemek icin harika ama surekli calisan, olay ureten bir ag gorunurlugu istiyorsaniz Zeek (eski adiyla Bro) cok daha uygun. Zeek ham trafigi zengin, yapilandirilmis loglara cevirir. Bu konuda kurulumu ve ilk loglari okumayi anlatacagim.

Konuda Anlatilacaklar
  1. Zeek nedir, IDS'ten farki
  2. Kurulum
  3. Pcap'ten log uretme
  4. Onemli log dosyalari
  5. Basit bir tespit mantigi

1) Zeek Nedir?
Zeek bir imza tabanli IDS degil; bir ag analiz cercevesidir. Snort/Suricata "bu imzaya uyan paketi yakala" derken, Zeek "agda ne olup bittigini" ayrintili olarak kaydeder: hangi IP hangi IP ile konustu, hangi DNS sorgusu yapildi, hangi dosya transfer edildi. Bu loglar sonradan avlanma (threat hunting) icin paha bicilmezdir.

2) Kurulum
Debian/Ubuntu uzerinde resmi depo ile:

Kod:
echo 'deb http://download.opensuse.org/repositories/security:/zeek/Debian_12/ /' | sudo tee /etc/apt/sources.list.d/zeek.list sudo apt update && sudo apt install -y zeek export PATH=$PATH:/opt/zeek/bin

3) Pcap'ten Log Uretme
Canli arayuz yerine once elinizdeki bir pcap ile denemek guvenli yoldur:

Kod:
zeek -r ornek.pcap ls # conn.log dns.log http.log ssl.log files.log ...

Zeek her protokol icin ayri bir log uretir. Canli dinleme icin
Kod:
sudo zeek -i eth0
yeterli (yalnizca kendi aginizda).

4) Onemli Loglar
  • conn.log: tum baglantilarin ozeti (kaynak, hedef, sure, bayt)
  • dns.log: DNS sorgulari, DGA/tunnel avinda altin deger
  • http.log: istekler, user-agent, URI
  • ssl.log: TLS el sikismalari, sertifikalar (JA3 ile birlikte)
  • files.log: transfer edilen dosyalar ve hash'leri

Loglari okumak icin zeek-cut pratiktir:

Kod:
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p service duration | head

5) Basit Tespit
Ornegin cok sayida farkli porta kisa baglantilar bir port taramasina isaret edebilir. dns.log'da anormal derecede uzun veya cok sayida alt alan adi DNS tunnel suphesi yaratir. Bu loglari Elastic veya baska bir SIEM'e besleyip panolar kurabilirsiniz.

Kaynaklar
Alıntı:Yasal not: Trafik izlemeyi yalnizca sahibi oldugunuz veya izinli oldugunuz aglarda yapin.

Siz Zeek loglarini hangi SIEM ile besliyorsunuz?

.png   bilgekagan-b06.png (Dosya Boyutu: 82.67 KB / İndirme Sayısı: 6) ]]> <![CDATA[VPN, Proxy ve Tor Farkı: Hangisi Neyi Gizler, Ne Zaman Kullanılır?]]> https://www.turkteam.org/konu-vpn-proxy-ve-tor-farki-hangisi-neyi-gizler-ne-zaman-kullanilir.html Sat, 17 Oct 2026 11:26:14 +0300 Tonyukuk]]> https://www.turkteam.org/konu-vpn-proxy-ve-tor-farki-hangisi-neyi-gizler-ne-zaman-kullanilir.html [Resim: attachment.php?aid=100]
"Anonim olmak istiyorum, hangisini kullanayım: VPN mi, proxy mi, Tor mu?" Bu soru foruma en sık gelenlerden. Sorun şu ki üçü de "IP gizler" diye özetleniyor, oysa tehdit modeline göre tamamen farklı araçlar. Bu yazıda üçünü teknik olarak ayırıp "hangisi kimden korur" sorusunu netleştireceğim.

Konuda anlatılacaklar
  1. Temel kavram: kim neyi görüyor?
  2. Proxy nedir, türleri
  3. VPN nedir, nasıl çalışır?
  4. Tor nedir, soğan yönlendirme mantığı
  5. Karşılaştırma tablosu
  6. Hangi senaryoda hangisi?
  7. Sık yapılan hatalar ve yasal not

Temel Kavram: Kim Neyi Görüyor?

Anonimlik/gizlilik araçlarını anlamanın tek sağlıklı yolu şu soruyu sormaktır: bu araç, hangi gözlemciden neyi gizliyor? Gözlemciler şunlar olabilir:
  • İnternet servis sağlayıcınız (ISS)
  • Bağlandığınız web sitesi/sunucu
  • Aradaki araç sağlayıcısı (proxy/VPN/Tor düğümü)
  • Yerel ağdaki biri (ör. aynı Wi-Fi)

Her araç bu gözlemcilerden farklı bir alt kümeyi engeller. "Tam anonimlik" diye bir ürün yoktur.

Proxy

Proxy, isteklerinizi sizin yerinize ileten aracı bir sunucudur. Genelde tek uygulama seviyesinde çalışır (ör. tarayıcı).
  • HTTP proxy: Sadece web trafiği; şifreleme sağlamaz (HTTPS zaten uçtan uca şifreli olsa da proxy bağlantıyı görür).
  • SOCKS proxy: Protokolden bağımsız, daha genel amaçlı.

Önemli: Çoğu basit proxy trafiğinizi şifrelemez. Hedef siteye karşı IP'nizi gizler ama proxy sağlayıcısı her şeyi görebilir ve ISS'niz proxy'ye gittiğinizi görür. Hızlı IP değiştirme için iyidir, gizlilik aracı olarak zayıftır.

VPN

VPN (Virtual Private Network), cihazınız ile VPN sunucusu arasında şifreli bir tünel kurar ve tüm cihaz trafiğini (sadece tarayıcı değil) bu tünelden geçirir.

Kimin ne gördüğü:
  • ISS'niz: VPN'e bağlandığınızı görür ama içeriği ve gittiğiniz siteleri göremez.
  • Hedef site: VPN sunucusunun IP'sini görür, sizinkini değil.
  • VPN sağlayıcısı: Her şeyi görebilir. Bu yüzden VPN'de güven meselesi merkezidir; "no-log" iddiası denetlenmiş mi diye bakmak gerekir.

VPN; genel Wi-Fi'de trafiği korumak, coğrafi kısıtları aşmak ve ISS'den içerik gizlemek için iyidir. Mutlak anonimlik aracı değildir, çünkü güveni tek bir sağlayıcıya verirsiniz.

Tor

Tor (The Onion Router), trafiği en az üç gönüllü düğümden (giriş, orta, çıkış) geçirir ve her katmanda ayrı şifreleme uygular (soğan yönlendirme). Hiçbir tek düğüm hem kim olduğunuzu hem nereye gittiğinizi aynı anda bilemez.
  • Giriş düğümü: Kim olduğunuzu (IP) bilir, nereye gittiğinizi bilmez.
  • Çıkış düğümü: Nereye gittiğinizi bilir, kim olduğunuzu bilmez.
  • Hedef site: Çıkış düğümünün IP'sini görür.

Tor, güveni dağıtarak tek sağlayıcı sorununu çözer ve gerçek anonimlik için en güçlü yaygın araçtır. Dezavantajı: yavaştır ve çıkış düğümü trafiği (şifreli değilse) görebilir, bu yüzden HTTPS şart.

Karşılaştırma

Kod:
Özellik Proxy VPN Tor Şifreleme Genelde yok Var (tünel) Var (çok katmanlı) Kapsam Uygulama Tüm cihaz Tarayıcı/uygulama IP gizleme Siteye karşı Siteye karşı Çok katmanlı Güven modeli Sağlayıcı Tek sağlayıcı Dağıtık Hız Hızlı Hızlı Yavaş Anonimlik Zayıf Orta Güçlü

Hangi Senaryoda Hangisi?
  • Genel Wi-Fi'de güvenlik: VPN.
  • Coğrafi kısıt aşma / ISS'den içerik gizleme: VPN.
  • Tek uygulama için hızlı IP değişimi: Proxy.
  • Gazeteci/aktivist, güçlü anonimlik: Tor (tercihen Tor Browser veya Tails).

Bazı durumlarda katmanlı kullanım tercih edilir (ör. VPN üzerinden Tor), ama bu, yanlış kurulunca anonimliği azaltabilir; acemiyseniz tek bir aracı doğru kullanmak daha güvenlidir.

Sık Yapılan Hatalar
  • Tor Browser yerine normal tarayıcıyı Tor'a bağlamak (parmak izi sızar).
  • Ücretsiz "anonim" VPN'lerin trafiği satabileceğini unutmak.
  • Proxy'yi gizlilik aracı sanmak; çoğu şifrelemez.
  • Oturum açtığınız hesaplarla anonim kalmayı beklemek (IP gizlense de kimliğiniz hesaptan belli olur).

Sonuç

Özetle: proxy IP değiştirir, VPN tüneller ve güveni bir sağlayıcıya verir, Tor güveni dağıtır. Doğru araç, "neyi kimden gizlemek istediğinize" bağlı. Siz hangi senaryoda hangisini tercih ediyorsunuz, yorumlarda tartışalım.

Yasal Not

Bu araçlar mahremiyet ve güvenlik içindir. Yasa dışı faaliyetlerde kullanımı suçtur; amaç kendi gizliliğinizi korumaktır.

Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-13-vpn.jpg (Dosya Boyutu: 75.11 KB / İndirme Sayısı: 12) ]]> [Resim: attachment.php?aid=100]
"Anonim olmak istiyorum, hangisini kullanayım: VPN mi, proxy mi, Tor mu?" Bu soru foruma en sık gelenlerden. Sorun şu ki üçü de "IP gizler" diye özetleniyor, oysa tehdit modeline göre tamamen farklı araçlar. Bu yazıda üçünü teknik olarak ayırıp "hangisi kimden korur" sorusunu netleştireceğim.

Konuda anlatılacaklar
  1. Temel kavram: kim neyi görüyor?
  2. Proxy nedir, türleri
  3. VPN nedir, nasıl çalışır?
  4. Tor nedir, soğan yönlendirme mantığı
  5. Karşılaştırma tablosu
  6. Hangi senaryoda hangisi?
  7. Sık yapılan hatalar ve yasal not

Temel Kavram: Kim Neyi Görüyor?

Anonimlik/gizlilik araçlarını anlamanın tek sağlıklı yolu şu soruyu sormaktır: bu araç, hangi gözlemciden neyi gizliyor? Gözlemciler şunlar olabilir:
  • İnternet servis sağlayıcınız (ISS)
  • Bağlandığınız web sitesi/sunucu
  • Aradaki araç sağlayıcısı (proxy/VPN/Tor düğümü)
  • Yerel ağdaki biri (ör. aynı Wi-Fi)

Her araç bu gözlemcilerden farklı bir alt kümeyi engeller. "Tam anonimlik" diye bir ürün yoktur.

Proxy

Proxy, isteklerinizi sizin yerinize ileten aracı bir sunucudur. Genelde tek uygulama seviyesinde çalışır (ör. tarayıcı).
  • HTTP proxy: Sadece web trafiği; şifreleme sağlamaz (HTTPS zaten uçtan uca şifreli olsa da proxy bağlantıyı görür).
  • SOCKS proxy: Protokolden bağımsız, daha genel amaçlı.

Önemli: Çoğu basit proxy trafiğinizi şifrelemez. Hedef siteye karşı IP'nizi gizler ama proxy sağlayıcısı her şeyi görebilir ve ISS'niz proxy'ye gittiğinizi görür. Hızlı IP değiştirme için iyidir, gizlilik aracı olarak zayıftır.

VPN

VPN (Virtual Private Network), cihazınız ile VPN sunucusu arasında şifreli bir tünel kurar ve tüm cihaz trafiğini (sadece tarayıcı değil) bu tünelden geçirir.

Kimin ne gördüğü:
  • ISS'niz: VPN'e bağlandığınızı görür ama içeriği ve gittiğiniz siteleri göremez.
  • Hedef site: VPN sunucusunun IP'sini görür, sizinkini değil.
  • VPN sağlayıcısı: Her şeyi görebilir. Bu yüzden VPN'de güven meselesi merkezidir; "no-log" iddiası denetlenmiş mi diye bakmak gerekir.

VPN; genel Wi-Fi'de trafiği korumak, coğrafi kısıtları aşmak ve ISS'den içerik gizlemek için iyidir. Mutlak anonimlik aracı değildir, çünkü güveni tek bir sağlayıcıya verirsiniz.

Tor

Tor (The Onion Router), trafiği en az üç gönüllü düğümden (giriş, orta, çıkış) geçirir ve her katmanda ayrı şifreleme uygular (soğan yönlendirme). Hiçbir tek düğüm hem kim olduğunuzu hem nereye gittiğinizi aynı anda bilemez.
  • Giriş düğümü: Kim olduğunuzu (IP) bilir, nereye gittiğinizi bilmez.
  • Çıkış düğümü: Nereye gittiğinizi bilir, kim olduğunuzu bilmez.
  • Hedef site: Çıkış düğümünün IP'sini görür.

Tor, güveni dağıtarak tek sağlayıcı sorununu çözer ve gerçek anonimlik için en güçlü yaygın araçtır. Dezavantajı: yavaştır ve çıkış düğümü trafiği (şifreli değilse) görebilir, bu yüzden HTTPS şart.

Karşılaştırma

Kod:
Özellik Proxy VPN Tor Şifreleme Genelde yok Var (tünel) Var (çok katmanlı) Kapsam Uygulama Tüm cihaz Tarayıcı/uygulama IP gizleme Siteye karşı Siteye karşı Çok katmanlı Güven modeli Sağlayıcı Tek sağlayıcı Dağıtık Hız Hızlı Hızlı Yavaş Anonimlik Zayıf Orta Güçlü

Hangi Senaryoda Hangisi?
  • Genel Wi-Fi'de güvenlik: VPN.
  • Coğrafi kısıt aşma / ISS'den içerik gizleme: VPN.
  • Tek uygulama için hızlı IP değişimi: Proxy.
  • Gazeteci/aktivist, güçlü anonimlik: Tor (tercihen Tor Browser veya Tails).

Bazı durumlarda katmanlı kullanım tercih edilir (ör. VPN üzerinden Tor), ama bu, yanlış kurulunca anonimliği azaltabilir; acemiyseniz tek bir aracı doğru kullanmak daha güvenlidir.

Sık Yapılan Hatalar
  • Tor Browser yerine normal tarayıcıyı Tor'a bağlamak (parmak izi sızar).
  • Ücretsiz "anonim" VPN'lerin trafiği satabileceğini unutmak.
  • Proxy'yi gizlilik aracı sanmak; çoğu şifrelemez.
  • Oturum açtığınız hesaplarla anonim kalmayı beklemek (IP gizlense de kimliğiniz hesaptan belli olur).

Sonuç

Özetle: proxy IP değiştirir, VPN tüneller ve güveni bir sağlayıcıya verir, Tor güveni dağıtır. Doğru araç, "neyi kimden gizlemek istediğinize" bağlı. Siz hangi senaryoda hangisini tercih ediyorsunuz, yorumlarda tartışalım.

Yasal Not

Bu araçlar mahremiyet ve güvenlik içindir. Yasa dışı faaliyetlerde kullanımı suçtur; amaç kendi gizliliğinizi korumaktır.

Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-13-vpn.jpg (Dosya Boyutu: 75.11 KB / İndirme Sayısı: 12) ]]> <![CDATA[Wireshark ile HTTP ve DNS Trafik Analizi: Adım Adım Rehber]]> https://www.turkteam.org/konu-wireshark-ile-http-ve-dns-trafik-analizi-adim-adim-rehber.html Fri, 16 Oct 2026 11:16:42 +0300 Tonyukuk]]> https://www.turkteam.org/konu-wireshark-ile-http-ve-dns-trafik-analizi-adim-adim-rehber.html [Resim: attachment.php?aid=18]
Wireshark ile HTTP ve DNS Trafik Analizi

Merhaba,

Wireshark, paket seviyesinde gören gözünüzdür. Bu rehberde Wireshark 4.6.x (güncel kararlı sürüm ailesi) ile kendi lab trafiğinizde HTTP ve DNS analizi yapmayı adım adım anlatıyoruz.

Konuda Anlatılacaklar
  1. Kurulum ve yakalama arayüzü seçimi
  2. Görüntüleme filtreleri (display filter)
  3. DNS sorgularını okuma
  4. HTTP isteği / yanıtı inceleme
  5. TLS trafiğinde ne görebilirsiniz?
  6. Kaynakça

1) Kurulum
Kod:
# Debian/Ubuntu sudo apt update && sudo apt install -y wireshark # Paket kurulumu sırasında non-root yakalama için wireshark grubuna eklenmeyi kabul edin sudo usermod -aG wireshark $USER # Oturumu kapatıp açın; ardından: wireshark --version

2) Yakalama
  1. Wireshark'ı açın, kendi lab arayüzünüzü seçin (ör. eth0, wlan0, veya bir VM bridge).
  2. Mavi köpekbalığı düğmesiyle yakalamayı başlatın.
  3. Labınızda bir tarayıcıdan http://example.com gibi bir HTTP sitesine gidin (HTTPS yerine önce HTTP lab'ı önerilir).
  4. Yakalamayı durdurun ve dosyayı kaydedin: File -> Save As -> lab_http_dns.pcapng

3) Temel Görüntüleme Filtreleri
Kod:
dns http tcp.port == 80 ip.addr == 10.10.10.5 dns.qry.name contains "example" http.request.method == "GET" tcp.flags.syn == 1 && tcp.flags.ack == 0
Filtreler araç çubuğundaki kutuya yazılır; yeşil = sözdizimi doğru.

4) DNS Analizi
Kod:
dns.flags.response == 0 # sorgu dns.flags.response == 1 # yanıt dns.a # A kaydı içeren paketler
Bir DNS paketini seçip ortadaki ağaçta görürsünüz:
  • Queries -> Name: sorulan alan adı
  • Answers -> Address: dönen IP
  • Response code: No Error / NXDOMAIN / ServFail
Anormal durumlar: Aynı host'tan saniyede onlarca NXDOMAIN (DGA şüphesi), beklenmeyen uzun alt alan adları, bilinen kötüye kullanım çözümleyicilerine giden trafik.

5) HTTP Analizi
Kod:
http.request http.response.code == 200 http.host == "hedef.lab" http.cookie
Bir GET isteğinde bakılacaklar:
  • Request URI ve Host
  • User-Agent
  • Cookie / Authorization başlıkları (lab dışında paylaşmayın)
  • Yanıtta Set-Cookie, Location, Server başlıkları
Takip için: pakete sağ tık -> Follow -> TCP Stream veya HTTP Stream.

6) TLS'te Ne Görürsünüz?
HTTPS içeriği şifreli olduğu için URI ve gövdeyi göremezsiniz; ama şunları görebilirsiniz:
  • SNI (Server Name Indication) - hangi host'a bağlanıldığı
  • Sertifika zinciri
  • TLS sürümü ve şifre takımı
  • JA3/JA4 parmak izi (ekstra eklentilerle)
Kod:
tls.handshake.type == 1 # Client Hello tls.handshake.extensions_server_name

7) Küçük Alıştırma (Kendi Labınız)
  1. HTTP lab sunucunuza 10 istek atın.
  2. Wireshark'ta http.request.method == "GET" filtresiyle sayın.
  3. dns.qry.name filtresiyle hangi alan adlarının çözüldüğünü listeleyin.
  4. Statistics -> Protocol Hierarchy ile protokol dağılımına bakın.

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Trafik yakalama yalnızca kendi ağınızda veya açık rızası olan ortamlarda yapılmalıdır. Başkasının trafiğini izinsiz dinlemek TCK 243-245 ve KVKK kapsamında hukuka aykırıdır.


.jpg   tonyukuk-11.jpg (Dosya Boyutu: 97.1 KB / İndirme Sayısı: 8) ]]> [Resim: attachment.php?aid=18]
Wireshark ile HTTP ve DNS Trafik Analizi

Merhaba,

Wireshark, paket seviyesinde gören gözünüzdür. Bu rehberde Wireshark 4.6.x (güncel kararlı sürüm ailesi) ile kendi lab trafiğinizde HTTP ve DNS analizi yapmayı adım adım anlatıyoruz.

Konuda Anlatılacaklar
  1. Kurulum ve yakalama arayüzü seçimi
  2. Görüntüleme filtreleri (display filter)
  3. DNS sorgularını okuma
  4. HTTP isteği / yanıtı inceleme
  5. TLS trafiğinde ne görebilirsiniz?
  6. Kaynakça

1) Kurulum
Kod:
# Debian/Ubuntu sudo apt update && sudo apt install -y wireshark # Paket kurulumu sırasında non-root yakalama için wireshark grubuna eklenmeyi kabul edin sudo usermod -aG wireshark $USER # Oturumu kapatıp açın; ardından: wireshark --version

2) Yakalama
  1. Wireshark'ı açın, kendi lab arayüzünüzü seçin (ör. eth0, wlan0, veya bir VM bridge).
  2. Mavi köpekbalığı düğmesiyle yakalamayı başlatın.
  3. Labınızda bir tarayıcıdan http://example.com gibi bir HTTP sitesine gidin (HTTPS yerine önce HTTP lab'ı önerilir).
  4. Yakalamayı durdurun ve dosyayı kaydedin: File -> Save As -> lab_http_dns.pcapng

3) Temel Görüntüleme Filtreleri
Kod:
dns http tcp.port == 80 ip.addr == 10.10.10.5 dns.qry.name contains "example" http.request.method == "GET" tcp.flags.syn == 1 && tcp.flags.ack == 0
Filtreler araç çubuğundaki kutuya yazılır; yeşil = sözdizimi doğru.

4) DNS Analizi
Kod:
dns.flags.response == 0 # sorgu dns.flags.response == 1 # yanıt dns.a # A kaydı içeren paketler
Bir DNS paketini seçip ortadaki ağaçta görürsünüz:
  • Queries -> Name: sorulan alan adı
  • Answers -> Address: dönen IP
  • Response code: No Error / NXDOMAIN / ServFail
Anormal durumlar: Aynı host'tan saniyede onlarca NXDOMAIN (DGA şüphesi), beklenmeyen uzun alt alan adları, bilinen kötüye kullanım çözümleyicilerine giden trafik.

5) HTTP Analizi
Kod:
http.request http.response.code == 200 http.host == "hedef.lab" http.cookie
Bir GET isteğinde bakılacaklar:
  • Request URI ve Host
  • User-Agent
  • Cookie / Authorization başlıkları (lab dışında paylaşmayın)
  • Yanıtta Set-Cookie, Location, Server başlıkları
Takip için: pakete sağ tık -> Follow -> TCP Stream veya HTTP Stream.

6) TLS'te Ne Görürsünüz?
HTTPS içeriği şifreli olduğu için URI ve gövdeyi göremezsiniz; ama şunları görebilirsiniz:
  • SNI (Server Name Indication) - hangi host'a bağlanıldığı
  • Sertifika zinciri
  • TLS sürümü ve şifre takımı
  • JA3/JA4 parmak izi (ekstra eklentilerle)
Kod:
tls.handshake.type == 1 # Client Hello tls.handshake.extensions_server_name

7) Küçük Alıştırma (Kendi Labınız)
  1. HTTP lab sunucunuza 10 istek atın.
  2. Wireshark'ta http.request.method == "GET" filtresiyle sayın.
  3. dns.qry.name filtresiyle hangi alan adlarının çözüldüğünü listeleyin.
  4. Statistics -> Protocol Hierarchy ile protokol dağılımına bakın.

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Trafik yakalama yalnızca kendi ağınızda veya açık rızası olan ortamlarda yapılmalıdır. Başkasının trafiğini izinsiz dinlemek TCK 243-245 ve KVKK kapsamında hukuka aykırıdır.


.jpg   tonyukuk-11.jpg (Dosya Boyutu: 97.1 KB / İndirme Sayısı: 8) ]]>