• TurkTeam | Türk Siber Güvenlik Topluluğu
    • ›
  • Portal
    • TürkTeam Portal

    Siber güvenlik topluluğunun nabzı

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

    Forumlar Yeni Mesajlar Kurallar
    Duyurular
     Burger King Japonya Veri Sızıntısı: 11,18 Milyon Uygulama Üyesinin Bilgileri Çalındı
    Tonyukuk 10-18-2026, 08:06 AM · Siber Güvenlik Haberleri
    0 31
    [Resim: attachment.php?aid=141]

    Selam arkadaşlar,

    Japonya'da şirket ihlallerinin art arda geldiği bir dönemdeyiz ve listeye büyük bir isim daha eklendi. Burger King'in Japonya operasyonu, resmi mobil uygulamasının üye bilgilerini tutan sisteme yetkisiz erişim yaşandığını ve yaklaşık 11,18 milyon üye kaydının sızdığını duyurdu. Kayıt sayısı Türkiye'deki birçok büyük perakende uygulamasının kullanıcı tabanıyla kıyaslanabilir düzeyde; bu yüzden olayı biraz detaylı ele almak istedim.

    Konuda Anlatılacaklar
    1. Ne oldu, ne zaman oldu?
    2. Hangi bilgiler sızdı, hangileri sızmadı?
    3. Şirketin yaptıkları
    4. Japonya'daki ihlal dalgası ve saldırganların yöneldiği zayıflıklar
    5. Etkilenen kullanıcılar ve uygulama geliştiriciler için dersler
    6. Kaynaklar

    Ne Oldu?

    Şirketin 15 Ekim 2026 tarihli Japonca açıklamasına göre resmi uygulamanın üye bilgilerini yöneten sisteme üçüncü bir tarafın yetkisiz erişim sağlamış olabileceği tespit edilmiş ve inceleme başlatılmış. İncelemenin sonucunda şu zaman çizelgesi ortaya çıkıyor:
    • 2 Ekim (Cuma) - 7 Ekim (Çarşamba) 2026: Yetkisiz erişimin gerçekleştiği dönem.
    • 13 Ekim (Salı) 2026: Üye bilgilerinin sızdığının kesinleştiği gün.
    • 15 Ekim (Perşembe) 2026: Kamuoyu açıklaması.

    Şirket, yetkisiz erişimi fark ettikten sonra ilgili kaynaktan gelen bağlantıları hemen engellediğini söylüyor. Saldırganın sisteme nasıl girdiği ise henüz açıklanmadı; açıklamada nedenin dış uzman kuruluşlarla birlikte araştırıldığı belirtiliyor. Herhangi bir grup sorumluluk üstlendi mi, fidye talebi var mı, bu konularda da kaynaklarda bilgi yok. Bu yüzden ben de spekülasyona girmeyeceğim.

    BleepingComputer, şirketin verilerin ekim başında çalındığını ve "çevrimiçi olarak sızdırıldığını" belirttiğini aktarıyor. Şirketin resmi açıklamasındaki ifade ise "漏えい" (sızıntı) kelimesi; verinin belirli bir yerde yayımlanıp yayımlanmadığına dair ayrıntı vermiyor.



    Hangi Bilgiler Sızdı?

    Şirket açıklamasında sızan bilgiler tek tek sayılmış. Etkilenen kayıt: yaklaşık 11,18 milyon resmi uygulama üye bilgisi. İçerik:
    • Üye kimliği (ID)
    • E-posta adresi
    • Kayıt türü
    • İkamet edilen il (prefecture)
    • Cinsiyet
    • Doğum tarihi
    • Ad soyad (kanji ve kana)
    • Telefon numarası
    • Mobil sipariş geçmişinin olup olmadığı
    • E-posta adresinin doğrulanıp doğrulanmadığı

    Sızmadığı belirtilenler:
    • Kredi kartı numaraları: Şirket bu bilgiyi kendisi tutmadığını, dolayısıyla sızmadığını söylüyor.
    • Giriş parolaları: Şu ana kadar sızdığına dair bir bulgu olmadığı belirtiliyor. Dikkat edin, ifade "sızmadı" değil, "sızdığı doğrulanmadı".

    Kyodo News da sızan verilerin ad, doğum tarihi, e-posta, telefon ve cinsiyet içerdiğini, kredi kartı bilgisinin şirket tarafından saklanmadığını aktarıyor. Şirkete göre bilgilerin kötüye kullanıldığına dair henüz bir ikincil zarar tespit edilmedi.

    Liste ilk bakışta "kart yok, parola yok, o kadar da kötü değil" dedirtebilir. Ama ad, telefon, e-posta ve doğum tarihinin bir arada olması oltalama ve sosyal mühendislik açısından çok değerli bir paket. Saldırgan, kurbanın adını, doğum gününü ve hangi markanın uygulamasını kullandığını bilerek mesaj yazdığında, sahte bir "üyelik doğrulama" e-postası oldukça inandırıcı hale gelir.

    Şirketin Yaptıkları

    Açıklamaya göre tamamlanan adımlar:
    • Yetkisiz erişim kaynağıyla iletişimin kesilmesi
    • Geçici önlemlerin uygulanması
    • Kriz masası kurulması
    • Japonya Kişisel Bilgilerin Korunması Komisyonu'na (PPC) bildirim

    Devam eden ve sırayla uygulanacak adımlar ise kalıcı önlemler, dış uzmanlarla yürütülen inceleme ve etkilenen müşterilere e-postayla bilgilendirme. Şirket ayrıca sistem güvenliğini ve izleme kapasitesini güçlendireceğini söylüyor.

    BleepingComputer'ın aktardığına göre şirket, etkilenen müşterileri Burger King Japonya'yı taklit eden şüpheli e-posta, SMS ve telefon aramalarına karşı uyarıyor; bağlantılara tıklamamalarını, ek açmamalarını ve üye bilgisi ya da parola girmemelerini istiyor.

    Japonya'daki İhlal Dalgası

    Bu olay tekil değil. Kyodo, son haftalarda Times Car araç paylaşım servisi, East Japan Railway ve Yamaha Motor gibi şirketlerin de ihlal bildirdiğini hatırlatıyor. BleepingComputer'ın listesi daha da uzun: Daiichi Kosho, IDC Frontier, Nikkei, Keio, Sakura Internet, Nihon Kotsu, KDDI ve diğerleri.

    Asıl dikkat çekici veri BleepingComputer'ın aktardığı Macnica araştırmacısı Yutaka Sejiyama'nın çalışması. Sejiyama bu yıl kişisel bilgi hırsızlığı veya ifşası içeren 119 siber güvenlik olayı kaydetmiş ve saldırganların web sitelerini ve API'leri erişim kontrolü, yapılandırma ve kimlik doğrulama zayıflıkları açısından yokladığını, bilinen (n-day) açıkları da sömürdüğünü tespit etmiş.

    Bu tespit bizim için de önemli. Mobil uygulamaların arkasındaki API'ler, çoğu zaman web sitesinden daha az test edilen, daha az izlenen bir katman. Burger King Japonya olayında giriş yolu henüz açıklanmadı, o yüzden bu olayı doğrudan bir API açığına bağlamıyorum; ama genel eğilim tam olarak oraya işaret ediyor.



    Kullanıcılar İçin Öneriler

    Bu uygulamayı kullanmış olabilecek, Japonya'da yaşayan ya da oraya seyahat eden okurlarımız varsa:
    • Uygulama hesabınızın parolasını değiştirin ve aynı parolayı başka bir yerde kullanıyorsanız orada da değiştirin. Şirket parola sızıntısı doğrulamadı ama önlem almak bedava.
    • "Üyeliğinizi doğrulayın", "kampanya hediyeniz hazır" gibi mesajlara karşı ekstra şüpheci olun. Gönderici adresini ve bağlantının gittiği alan adını kontrol edin.
    • Telefonla arayıp kendini şirket yetkilisi olarak tanıtan ve bilgi isteyen kişilere bilgi vermeyin; şirketin resmi kanalından kendiniz arayarak teyit edin.
    • E-posta adresinizin hangi sızıntılarda geçtiğini Have I Been Pwned gibi servislerle düzenli kontrol edin.

    Uygulama Geliştiriciler İçin Dersler
    • Veri minimizasyonu: Bir hamburger siparişi için doğum tarihi ve ikamet ili gerçekten gerekli mi? Tutmadığınız veri sızmaz. Şirketin kart verisini hiç tutmaması bu olayda zararı belirgin şekilde sınırlamış.
    • API erişim kontrolü: Kullanıcı kimliğini istemciden gelen bir parametreye değil, sunucu tarafındaki oturuma bağlayın. IDOR tipi hatalar toplu veri çekmenin en yaygın yollarından biri.
    • Hız sınırı ve anomali tespiti: Erişim 2-7 Ekim arasında yaklaşık beş gün sürmüş. Milyonlarca kaydın dışarı çıkması normal trafikten farklı bir desen üretir; bunu fark edecek bir izleme kurmak gerekir.
    • Log saklama: Olay sonrası "saldırgan nereden girdi" sorusuna cevap verebilmek için API ve kimlik doğrulama loglarının yeterli süre saklanması şart.

    Sizce mobil uygulama üyelik sistemlerinde en çok ihmal edilen kontrol hangisi? Bug bounty yapan arkadaşlar API tarafında en çok ne tür bulgulara rastlıyor, yorumlarda paylaşırsanız güzel bir tartışma olur.

    Kaynaklar
    Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Sızdırılmış verileri aramak, indirmek, paylaşmak veya kullanmak suçtur; bu forumda sızıntı verisi paylaşımı yasaktır. İzinsiz erişim ve kişisel verilerin hukuka aykırı olarak ele geçirilmesi 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri ve 6698 sayılı KVKK kapsamında yaptırıma tabidir.

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

    Ek DosyalarEkran Görüntüleri
       
     CSRF Cross-Site Request Forgery Nedir? Tespit ve Korunma Rehberi
    BilgeKagan 10-18-2026, 08:05 AM · Web Uygulama Güvenliği
    0 29
    [center]
    [Resim: attachment.php?aid=140]
    [/center]

    Selam TurkTeam, BlueTornado yazıyor.

    CSRF (Cross-Site Request Forgery), kimliği doğrulanmış bir kullanıcının tarayıcısını kandırarak, kullanıcının haberi olmadan siteye istek attırmaktır. XSS "saldırganın script'ini kurbanın tarayıcısında çalıştırır"; CSRF ise kurbanın mevcut oturumunu kullanarak istenmeyen bir eylemi tetikler. Bu rehberde teori, lab gözlemi, token/SameSite korunmaları ve modern API'lerdeki durumu inceliyoruz.

    Konuda Anlatılacaklar
    1. CSRF nedir, hangi koşullarda çalışır?
    2. XSS ile farkı
    3. Lab: DVWA CSRF sayfası
    4. Klasik PoC formu ve cookie davranışı
    5. Korunma: Anti-CSRF token, SameSite, pratikler
    6. İleri seviye: JSON API, SameSite=None, login CSRF
    7. Kaynakça ve yasal uyarı

    1) CSRF Nedir?
    Tarayıcılar, bir siteye istek atarken o siteye ait çerezleri (oturum çerezi dahil) varsayılan kurallara göre ekler. Saldırgan, kötü amaçlı bir sayfada şu tür bir istek tetiklerse:

    Kod:
    <!-- Kavramsal kötü sayfa (lab dışında kullanmayın) --> <form action="https://bank.example/transfer" method="POST"> <input type="hidden" name="to" value="attacker"> <input type="hidden" name="amount" value="1000"> </form> <script>document.forms[0].submit()</script>

    Kurban o anda bank.example oturumu açıksa, tarayıcı çerezi ekleyebilir ve transfer isteği "kurbandan gelmiş" gibi görünür. Sunucu, isteğin kullanıcının isteyerek mi yoksa başka siteden mi geldiğini ayırt edemiyorsa CSRF oluşur.

    Gerekli koşullar (özet):
    • İlgili sitede geçerli oturum (çerez tabanlı)
    • Tarayıcının çerezi o isteğe eklemesi
    • Sunucuda istek sahteciliğini engelleyen ek doğrulama olmaması
    • Değiştirici (state-changing) bir eylem (POST ile para transferi, e-posta değiştirme vb.)

    Alıntı:CSRF, "çerezi çalmak" zorunda değildir. Çerez tarayıcıda kalır; saldırgan sadece isteği tetikler.

    2) XSS ile Fark
    • XSS: Güvenilmeyen verinin sayfada script olarak çalışması
    • CSRF: Güvenilen sitenin state-changing endpoint'ine çapraz siteden istek
    • XSS varsa çoğu CSRF koruması da aşılabilir (token okunur); ikisi ayrı ayrı kapatılmalıdır

    3) Lab: DVWA CSRF
    Kod:
    git clone https://github.com/digininja/DVWA.git cd DVWA docker compose up -d

    DVWA menüsünden CSRF sayfasına gidin. Low seviyede parola değiştirme formu genelde anti-CSRF tokensızdır.

    [center][/center]

    Adım 1: Normal şekilde parolayı değiştirip isteği DevTools/Burp ile inceleyin.

    Kod:
    POST /vulnerabilities/csrf/ password_new=...&password_conf=...&Change=Change Cookie: PHPSESSID=...; security=low

    Adım 2: Aynı parametrelerle, labınızda yerel bir HTML dosyasından formu işaret ederek davranışı gözlemleyin (yalnızca 127.0.0.1 DVWA). Impossible seviyede token eklenmiş olduğunu göreceksiniz.

    Kod:
    <!-- Yerel lab HTML iskeleti --> <form method="POST" action="http://127.0.0.1/vulnerabilities/csrf/"> <input type="hidden" name="password_new" value="hacked"> <input type="hidden" name="password_conf" value="hacked"> <input type="hidden" name="Change" value="Change"> </form>

    Çıktı yorumu: Low'da oturum açıkken bu sayfa yüklendiğinde parola değişiyorsa CSRF vardır. Impossible'da token eksik/yanlışsa işlem reddedilir.

    [center][/center]

    4) Kavram Referansı

    Anti-CSRF synchronizer token: Sunucu, forma rastgele token koyar; POST'ta token oturumdaki ile eşleşmelidir. Saldırganın sitesi bu token'ı okuyamaz (same-origin policy), XSS yoksa.

    Kod:
    <!-- Kavramsal --> <input type="hidden" name="csrf_token" value="a3f9...">

    Kod:
    # Sunucu tarafı (kavramsal) if not hmac.compare_digest(session["csrf"], request.form["csrf_token"]): abort(403)

    SameSite çerez özelliği:
    Kod:
    Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax
    • Kod:
      Strict
      : Çapraz site isteklerinde çerez gönderilmez (en sıkı; bazı akışları bozabilir)
    • Kod:
      Lax
      : Top-level GET navigasyonunda gönderilir; çoğu CSRF POST senaryosunu keser
    • Kod:
      None
      : Secure zorunlu; çapraz site çerez (dikkatli kullanın)

    Origin / Referer kontrolü: Ek katman; Referer eksik olabilir, Origin daha güvenilirdir ama her istemci/senaryoda yetmeyebilir. Token ile birlikte düşünün.

    Kod:
    # Örnek kontrol (kavramsal) origin = request.headers.get("Origin") if origin and origin not in ALLOWED_ORIGINS: abort(403)

    5) Korunma Kontrol Listesi
    • State-changing işlemleri POST/PUT/DELETE ile yapın; önemli işleri GET'e bağlamayın
    • Anti-CSRF token (framework'ün built-in'i: Django, Rails, ASP.NET, Spring)
    • SameSite=Lax veya Strict + Secure + HttpOnly
    • Mümkünse oturumu çerez dışında authorization header (Bearer) ile taşıyan SPA'larda CSRF yüzeyi küçülür; XSS'e dikkat
    • Kritik işlemlerde re-auth (şifre yeniden sor)
    • CORS'u sıkı tutun; credentials ile * kullanmayın

    Kod:
    # Django'da middleware varsayılan olarak CSRF korur # Şablon: {% csrf_token %}

    Kod:
    # Flask-WTF örneği form = FlaskForm() # csrf_token alanı otomatik

    [center][/center]

    6) İleri Seviye
    Login CSRF: Kurbanı saldırganın hesabına zorla giriş yaptırma; sonra kurban o oturuma veri kaydeder. Login formuna da token koyun.

    JSON API + simple request:
    Kod:
    Content-Type: application/json
    olan istekler tarayıcıda CORS preflight tetikleyebilir; yine de cookie tabanlı oturumda doğru CORS/CSRF tasarımı şarttır.

    SameSite=None gereken üçüncü parti gömülü senaryolarda CSRF riski geri gelir; ek token zorunlu düşünün.

    Double-submit cookie: Token'ı hem çerezde hem formda göndermek. Basit ama subdomain XSS/cookie injection varsa zayıflayabilir; synchronizer pattern genelde tercih edilir.

    Kod:
    # Rapor dili Bulgu: CSRF (CWE-352) Endpoint: POST /vulnerabilities/csrf/ Kanıt: Labda tokensız POST ile parola değişimi Öneri: synchronizer token + SameSite=Lax

    7) Sonuç
    CSRF, tarayıcının çerez ekleme davranışından beslenir. Token + SameSite + güvenli metod kullanımı temel üçlüdür. DVWA Low/Impossible karşılaştırması korumayı somut gösterir.



    Ek: Framework Notları ve Test Kontrol Listesi
    Modern çerçeveler CSRF için hazır çözüm sunar; asıl risk "korumayı kapatmak"tır.

    Kod:
    # Django: CSRF_TRUSTED_ORIGINS doğru ayarlanmalı (HTTPS arkasında) # @csrf_exempt yalnızca çok bilinçli istisnalarda; API için token veya auth tasarımını gözden geçirin

    Kod:
    # ASP.NET Core: Antiforgery middleware # ValidateAntiForgeryToken attribute

    Kod:
    # SPA + cookie oturumu: # 1) Frontend, login yanıtından veya cookie-olmayan bir endpoint'ten CSRF token alsın # 2) Her state-changing istekte header olarak göndersin (ör. X-CSRF-Token) # 3) SameSite=Lax + Secure

    Manuel test listesi (izinli lab):
    • Oturum açıkken çapraz origin HTML formu ile POST deneyin
    • Token'ı silerek/değiştirerek 403 bekleyin
    • Content-Type ve metod kombinasyonlarını not edin
    • Logout sonrası token'ın geçersiz olduğunu doğrulayın

    [center][/center]

    Unutmayın: CSRF koruması XSS varken zayıflar çünkü script token'ı okuyabilir. İkisini birlikte ele alın.

    Kaynakça
    Yasal Uyarı
    CSRF testleri yalnızca kendi labınızda veya yazılı yetkili pentest kapsamında yapılmalıdır. Başkalarının oturumunu kötüye kullanmak TCK 243-245 ve ilgili maddeler kapsamında suç olabilir. Eğitim amaçlıdır.

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

    Ek DosyalarEkran Görüntüleri
       
     SSH Sertleştirme: Anahtar Tabanlı Giriş, Port ve Fail2ban Rehberi
    KulTigin 10-18-2026, 08:03 AM · Linux Genel
    0 33
    Selam TurkTeam,

    SSH, uzak sunucu yönetiminin bel kemiğidir; aynı nedenle de saldırganların en çok kaba kuvvet denediği servislerden biridir. İnternete açık bir SSH servisi, saatler içinde otomatik parola denemeleriyle dolar. Bu rehberde SSH'ı adım adım sertleştiriyoruz: anahtar tabanlı kimlik doğrulama, parola girişinin kapatılması, güvenli sunucu yapılandırması ve Fail2ban ile otomatik engelleme. Tüm adımlar kendi sunucunuz içindir.

    Konuda Anlatılacaklar
    1. SSH neden hedeftir, tehdit modeli
    2. Anahtar çifti oluşturma ve sunucuya kurma
    3. sshd_config ile güvenli yapılandırma
    4. Önemli yapılandırma parametreleri referansı
    5. Fail2ban kurulumu ve sshd jail yapılandırması
    6. Doğrulama ve ileri ipuçları
    7. Sonuç, kaynakça ve yasal uyarı

    1. SSH Neden Hedeftir?
    SSH genelde 22 portunda, internete açık çalışır ve doğrudan kabuk erişimi sağlar. Bu yüzden botnet'ler sürekli olarak yaygın kullanıcı adları (root, admin, ubuntu) ve zayıf parolalarla otomatik deneme yapar. Savunmanın özü iki ilkedir: tahmin edilebilir kimlik doğrulamayı (parola) ortadan kaldırmak ve kötü niyetli deneme trafiğini otomatik engellemek. Anahtar tabanlı giriş birincisini, Fail2ban ikincisini çözer.

    2. Anahtar Çifti Oluşturma ve Kurma
    İstemci makinenizde modern ve güçlü bir anahtar türü olan ed25519 ile çift oluşturun:
    Kod:
    ssh-keygen -t ed25519 -C "kullanici@ismakinesi"
    Varsayılan olarak ~/.ssh/id_ed25519 (özel) ve id_ed25519.pub (açık) dosyaları oluşur. Parola koruması (passphrase) belirlemeniz, anahtar çalınsa bile koruma sağlar.

    Açık anahtarı sunucuya kolayca kurmak için:
    Kod:
    ssh-copy-id -i ~/.ssh/id_ed25519.pub kullanici@sunucu_ip
    Bu komut, açık anahtarı sunucudaki ~/.ssh/authorized_keys dosyasına ekler. Artık anahtarla giriş yapabilmelisiniz:
    Kod:
    ssh kullanici@sunucu_ip
    [Resim: attachment.php?aid=139]

    3. sshd_config ile Güvenli Yapılandırma
    Sunucuda /etc/ssh/sshd_config dosyasını düzenleyin (bir yedek alın):
    Kod:
    sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sudo nano /etc/ssh/sshd_config
    Önerilen ayarlar:
    Kod:
    PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes PermitEmptyPasswords no MaxAuthTries 3 X11Forwarding no AllowUsers kullanici
    Değişiklikten önce söz dizimini test edin, sonra servisi yeniden başlatın:
    Kod:
    sudo sshd -t sudo systemctl restart ssh
    Kritik uyarı: PasswordAuthentication no yapmadan önce anahtarla girebildiğinizden kesinlikle emin olun; aksi halde kendinizi kilitlersiniz. İlk bağlantıyı açık tutarak ikinci bir oturumdan test etmek güvenli bir alışkanlıktır.


    4. Önemli Parametreler Referansı
    PermitRootLogin no - Root ile doğrudan girişi kapatır; yönetici işleri sudo ile yapılır:
    Kod:
    PermitRootLogin no

    PasswordAuthentication no - Parola girişini tamamen kapatır, yalnızca anahtar kalır:
    Kod:
    PasswordAuthentication no

    MaxAuthTries - Bir bağlantıda izin verilen deneme sayısı:
    Kod:
    MaxAuthTries 3

    AllowUsers / AllowGroups - Yalnızca belirli kullanıcı/grupların girişine izin:
    Kod:
    AllowUsers ahmet mehmet

    Port - Standart dışı port, otomatik tarama gürültüsünü azaltır (güvenlik önlemi değil, sadece gürültü azaltma):
    Kod:
    Port 2222

    ClientAliveInterval / ClientAliveCountMax - Atıl oturumları kapatma:
    Kod:
    ClientAliveInterval 300 ClientAliveCountMax 2

    5. Fail2ban ile Otomatik Engelleme
    Fail2ban, log dosyalarını izleyip belirli sayıda başarısız girişten sonra kaynak IP'yi güvenlik duvarında geçici olarak engeller.
    Kod:
    sudo apt update sudo apt install fail2ban
    Yerel ayarlarınızı varsayılanı ezmeyecek şekilde jail.local içine yazın:
    Kod:
    sudo nano /etc/fail2ban/jail.local
    Kod:
    [sshd] enabled = true maxretry = 4 findtime = 10m bantime = 1h
    Burada maxretry izin verilen başarısız deneme sayısını, findtime bu denemelerin sayılacağı pencereyi, bantime engel süresini belirtir. Servisi başlatıp etkinleştirin:
    Kod:
    sudo systemctl enable --now fail2ban
    Durumu ve engellenen IP'leri görün:
    Kod:
    sudo fail2ban-client status sshd
    Çıktı, aktif engelleri ve toplam yakalanan deneme sayısını gösterir:
    Kod:
    Status for the jail: sshd |- Filter | `- Currently failed: 1 `- Actions |- Currently banned: 2 `- Banned IP list: 203.0.113.10 198.51.100.20


    Bir IP'yi elle engelden çıkarmak için:
    Kod:
    sudo fail2ban-client set sshd unbanip 203.0.113.10

    6. Doğrulama ve İleri İpuçları
    • Yapılandırmayı doğrulayın: Yeni bir terminalden anahtarla bağlanın; parola istenmemsini ve root girişinin reddedildiğini kontrol edin.
    • 2FA ekleyin: Kritik sunucularda Google Authenticator PAM modülüyle anahtar + TOTP ikili doğrulama kurulabilir.
    • Güvenlik duvarı: UFW/nftables ile SSH portunu yalnızca gereken ağlara açın; mümkünse bir VPN arkasına alın.
    • Anahtar hijyeni: Özel anahtar dosyası 600 izinli olmalı ve bir passphrase ile korunmalı; eski/yetkisiz anahtarları authorized_keys'ten temizleyin.
    • İzleme: Başarılı girişleri de izleyin; beklenmedik bir kaynaktan başarılı giriş, en önemli alarmdır.

    6.1. Neden Anahtar Tabanlı Giriş Parolayı Yener?
    Anahtar tabanlı kimlik doğrulamanın parolaya üstünlüğünü anlamak, bu sertleştirmenin neden bu kadar etkili olduğunu kavramanın anahtarıdır. Parola, tahmin edilebilen ve tekrar kullanılan bir sırdır; bir botnet saniyede yüzlerce parolayı deneyebilir ve zayıf bir parola er ya da geç bulunur. SSH anahtarı ise asimetrik kriptografiye dayanır: sunucu yalnızca açık anahtarı tutar, özel anahtar hiçbir zaman ağdan geçmez. Bir ed25519 anahtarını kaba kuvvetle bulmak pratikte imkansızdır. Dolayısıyla PasswordAuthentication no yaptığınız anda, saldırganların en sık kullandığı saldırı yüzeyini tamamen ortadan kaldırmış olursunuz; loglardaki başarısız giriş selinin aniden kesilmesi bunun gözle görülür kanıtıdır.

    Bu noktada sık sorulan bir soru şudur: "Anahtar giriş zaten bu kadar güçlüyse Fail2ban'a ne gerek var?" Cevap katmanlı savunmadır. Fail2ban yalnızca parola denemelerini değil, portunuzu sürekli yoklayan gürültülü tarayıcıları da engelleyerek log kirliliğini ve kaynak tüketimini azaltır; ayrıca anahtar girişe geçişi henüz tamamlamadığınız veya bir servisin geçici olarak parola kullandığı durumlarda ek bir güvenlik ağı sağlar. Güvenlik tek bir mükemmel önleme değil, birbirini tamamlayan birden çok katmana dayanır.

    Son bir pratik tavsiye: standart dışı port kullanımını bir güvenlik önlemi sanmayın. Portu 2222'ye almak otomatik tarama gürültüsünü azaltır, ancak hedefli bir saldırgan birkaç saniyede gerçek portu bulur. Gerçek güvenliği anahtar tabanlı giriş, root erişiminin kapatılması, güvenlik duvarı kısıtlaması ve mümkünse VPN sağlar; port değişikliği yalnızca bunların üstüne eklenen küçük bir konfordur, onların yerine geçmez.

    Sonuç
    SSH sertleştirmenin özü nettir: parolayı anahtarla değiştir, root ve gereksiz kullanıcı girişini kapat, deneme trafiğini Fail2ban ile otomatik engelle ve servisi güvenlik duvarı/VPN ile sınırla. Bu katmanlar birlikte, internete açık bir SSH'ı kaba kuvvete karşı pratikte işe yaramaz hale getirir. Her değişiklikten önce yedek alın, söz dizimini test edin ve kendinizi kilitlemeyin.

    Kaynakça
    Yasal Uyarı
    Alıntı:Bu yapılandırmalar yalnızca kendi sunucularınızda veya yönetim yetkiniz olan sistemlerde uygulanmalıdır. Başkasının sistemine izinsiz erişim Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

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

    Ek DosyalarEkran Görüntüleri
       
     LLMNR ve NBT-NS Zehirlenmesi: Neden Kapatılmalı ve Nasıl Tespit Edilir
    Tonyukuk 10-18-2026, 08:02 AM · Active Directory & Kurumsal
    0 31
    [Resim: attachment.php?aid=138]

    Selam,

    LLMNR ve NBT-NS, isim çözümlemesi başarısız olunca Windows'un yerel ağda "bu isim kimde?" diye bağırdığı protokoller. Saldırgan Responder benzeri araçlarla cevap verip kimlik bilgisi yakalayabilir. Bu yazıda neden kapatılacağını ve nasıl tespit edileceğini anlatıyorum. Lab ve kendi ağınız için.

    Sorun özeti
    Kullanıcı \\dosyaadi yazınca DNS bulamazsa LLMNR/NBT-NS devreye girer. Sahte yanıtla kurban saldırgana bağlanır; NTLMv2 challenge/response yakalanabilir. İç ağda hâlâ en sık lateral movement başlangıçlarından biri.

    Kapatma (GPO)
    • LLMNR: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution = Enabled
    • NBT-NS: arayüz özelliklerinden NetBIOS over TCP/IP disable veya PowerShell/GPO ile
    Kod:
    # Lab örneği: belirli arayüzde NetBIOS kapatma (indeks ortama göre) Get-CimInstance Win32_NetworkAdapterConfiguration | Where-Object {$_.IPEnabled} | Select Description, TcpipNetbiosOptions



    Tespit
    • Ağda LLMNR/NBT-NS sorgularını IDS ile görün (Zeek/Suricata kuralları)
    • Windows'ta şüpheli logon Type 3 + kaynak IP olarak bilinmeyen cihaz
    • Honey- cred / decoy hesap ile Responder avı (kontrollü tatbikat)
    Savunma tatbikatında kendi Responder'ınızı lab VLAN'ında çalıştırıp kapatma politikasının işe yaradığını doğrulayın.

    Tamamlayıcı kontroller
    • SMB imzalama zorunlu
    • LDAP signing / channel binding
    • Yerel yönetici parolası rastgele (LAPS)
    • Tiering: günlük kullanıcıda local admin yok

    Kaynaklar
    • Microsoft Docs: LLMNR
    • MITRE ATT&CK: Adversary-in-the-Middle, LLMNR/NBT-NS poisoning
    • SANS / çeşitli red team blogları (savunma odaklı okuyun)

    Siz LLMNR'yi kurum genelinde kapattığınızda kırılan eski uygulamanız oldu mu?

    DNS doğru mu?
    LLMNR'yi kapatmadan önce iç DNS'in düzgün çalıştığından emin olun. Yanlış DNS + kapalı LLMNR = paylaşım ve yazıcı erişimi kırılır; kullanıcılar politikayı geri açtırır. Önce DNS sağlığı, sonra kapatma.

    IPv6 komşuluk
    Benzer zehirleme IPv6'da da mümkün (mitm6 senaryoları). IPv6'yı "kullanmıyoruz" diye açık bırakmayın; ya yönetin ya da bilinçli kapatın (kurum politikasına göre).


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ek DosyalarEkran Görüntüleri
       
     Sosyal Mühendislik ve Phishing Nasıl Tanınır? Farkındalık ve Savunma Rehberi
    BilgeKagan 10-18-2026, 04:00 AM · Sosyal Mühendislik ve Farkındalık
    0 38
    [center]
    [Resim: attachment.php?aid=137]
    [/center]

    Selam TurkTeam, BlueTornado ile.

    Teknik kontroller ne kadar iyi olursa olsun, insan faktörü hâlâ en geniş saldırı yüzeylerinden biridir. Bu konu saldırı "nasıl yapılır" diye değil; nasıl tanınır ve nasıl savunulur diye yazıldı. Phishing, vishing, smishing ve iş e-postası dolandırıcılığı (BEC) belirtilerini, güvenli doğrulama alışkanlıklarını ve kurumsal kontrolleri ele alıyoruz.

    Konuda Anlatılacaklar
    1. Sosyal mühendislik nedir?
    2. Phishing türleri (e-posta, SMS, ses, QR, BEC)
    3. Tanıma ipuçları ve güvenli kontrol listesi
    4. Lab: kendi test e-postanızı analiz etme
    5. Kurumsal ve bireysel savunma
    6. İleri seviye: MFA yorgunluğu, evilginx tarzı reverse proxy farkındalığı (savunma)
    7. Kaynakça ve yasal uyarı

    1) Sosyal Mühendislik Nedir?
    Sosyal mühendislik, insanları manipüle ederek gizli bilgiyi ifşa ettirme, zararlı eylem yaptırma veya güvenlik kontrollerini atlatma sanatıdır. Teknik zafiyet yerine güven, acele, korku, hiyerarşi ve yardımseverlik kullanılır.
    • Phishing: Sahte iletişimle kimlik bilgisi veya zararlı dosya/link
    • Spear phishing: Belirli kişi/kuruma özel hazırlanmış
    • Whaling: Üst düzey yönetici hedefi
    • Vishing: Telefon
    • Smishing: SMS
    • Pretexting: Sahte senaryo (IT destek, kargo, banka)
    • BEC: Sahte CEO/tedarikçi ile havale talimatı

    Alıntı:İyi bir oltalama maili "kötü Türkçe ve kırmızı bayraklarla dolu" olmak zorunda değildir. Kurumsal dile benzeyen, kişiselleştirilmiş ve acil görünen içerikler daha tehlikelidir.

    2) Phishing Nasıl Tanınır?

    Gönderen ve domain:
    Kod:
    # Gözle kontrol Görünen ad: "IT Destek" <[email protected]> # Gerçek domaininiz turkteam.org ise bu şüphelidir # Homoglyph: rn -> m, IDN punycode

    Linkler:
    • Üzerine gelince (hover) görünen URL ile metin farklı mı?
    • Kısaltılmış linkler (bit.ly vb.) bilinmeyen gönderende riskli
    • Kod:
      https://turkteam.org.güvenlik-kontrolü.evil.example
      gibi alt alan adı oyunları

    İçerik psikolojisi:
    • Aşırı aciliyet: "Hesabınız 1 saat içinde kapanacak"
    • Korku: "Yasal işlem başlatılacak"
    • Ödül: "Kargo sizden ücret bekliyor / ikramiye"
    • Otorite: "Yönetim Kurulu gereği hemen onay"

    Ekler:
    Kod:
    .html
    , çift uzantı
    Kod:
    fatura.pdf.exe
    , makro'lu Office, ISO/IMG. Beklemediğiniz bir fatura eki klasik vektördür.

    [center][/center]

    3) Güvenli Doğrulama Alışkanlıkları
    • Maildeki linke tıklamak yerine tarayıcıya kurumu sizin bildiğiniz adresten yazın
    • Para/havale taleplerini ikinci bir kanaldan (bilinen telefon) doğrulayın
    • IT'nin parolanızı mail ile istemeyeceğini bilin; SSO sayfasına mail içinden gitmeyin
    • Şüpheli maili "bildir" ile SOC/IT'ye iletin; silmeden önce kurum prosedürünü izleyin
    • Kişisel hesaplarda da aynı şüphecilik

    Kod:
    # Bireysel hızlı kontrol listesi [ ] Gönderen domain gerçek mi? [ ] Ben bu maili bekliyor muydum? [ ] Aciliyet baskısı var mı? [ ] Link hover / ek şüpheli mi? [ ] İkinci kanal doğrulaması yaptım mı?

    4) Uygulamalı: Zararsız Analiz Labı
    Kendi kendinize gönderdiğiniz veya kurumsal phishing simülasyonundan gelen bir örneği (güvenli ortamda) inceleyin. Üretimde şüpheli ekleri açmayın.

    Kod:
    # E-posta kaynak başlıklarını görmek (Gmail: Show original) # İncelenecek başlıklar: From: Return-Path: Reply-To: Received: (zincir) Authentication-Results: (SPF/DKIM/DMARC)

    Kod:
    # Örnek Authentication-Results satırı (kavramsal) spf=pass dkım=pass dmarc=pass # Hepsi fail ise yüksek şüphe; hepsi pass olsa bile içerik sahte olabilir (hesap ele geçirme)

    [center][/center]

    URL'yi açmadan önce:
    Kod:
    # VirusTotal / urlscan.io gibi servislere URL yapıştırın (kurum politikasına uygun) # Kendi sandbox'ınız yoksa ekleri çalıştırmayın

    5) Kurumsal Savunma Kontrolleri
    • SPF, DKIM, DMARC yayınlayın; DMARC politikasını kademeli sıkılaştırın
    • Gelen kutusu güvenliği: link rewriting, ek sandbox (imkân varsa)
    • MFA zorunlu; mümkünse phishing-resistant (FIDO2 / passkey)
    • BEC için mali süreç: çift onay, bilinen tedarikçi hesap listesi
    • Düzenli farkındalık eğitimi + ölçülebilir simülasyon (cezalandırıcı değil öğretici)
    • SOC playbook: phishing bildirimi -> URL/hash -> IOC -> kullanıcı etkisi

    Kod:
    # DMARC kayıt örneği (DNS TXT, kavramsal) v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

    Kod:
    # SPF örneği (aşırı geniş +all kullanmayın) v=spf1 include:_spf.google.com -all

    6) İleri Seviye Farkındalık (Savunma)
    MFA yorgunluğu (fatigue): Saldırgan parolayı bir şekilde elde edip telefonunuza peş peşe MFA bildirimi yağdırabilir. Alışkanlık: beklemediğiniz onayları reddedin; parolayı değiştirin; IT'ye bildirin.

    Proxy / Adversary-in-the-middle phishing: Sahte sayfa, gerçek login ile kurban arasında aracılık ederek oturum çerezini/token'ı yakalayabilir. Klasik SMS OTP bu senaryoda yetersiz kalabilir. Passkey/FIDO2 ve Conditional Access (cihaz uyumu, imkânsız gezinti) savunmada öne çıkar.

    QR phishing (quishing): Afiş, PDF veya mail içindeki QR bilinmeyen yere götürebilir. Kurumsal cihazda rastgele QR okutmayın.

    [center][/center]

    Raporlama dili (kullanıcıdan SOC'a):
    Kod:
    Konu: Şüpheli e-posta bildirimi Gönderen: ... Zaman: 2026-10-17 14:10 Europe/Istanbul Tıkladım mı?: Hayır Ek açtım mı?: Hayır Ekran görüntüsü / .eml ekte

    7) Sonuç
    Sosyal mühendislik teknik bir açık değil, insan ve süreç açığıdır. Tanıma refleksleri, ikinci kanal doğrulama, DMARC/MFA/passkey ve iyi bir bildirim kültürü en etkili savunma paketidir. Merak ettiğiniz teknik detayları izinsiz sistemlerde denemeyin; kurumsal simülasyon programlarına katılın.



    Ek: Ev ve Küçük İşletme İçin 10 Dakikalık Sertleştirme
    Büyük bir SOC'unuz olmasa bile uygulanabilir adımlar:
    • E-posta hesabında MFA açın (mümkünse uygulama veya güvenlik anahtarı; SMS son çare)
    • Tarayıcıda şüpheli eklentileri kaldırın; otomatik indirme klasörünü izleyin
    • Kargo/banka SMS'lerindeki linklere değil, resmi uygulamaya gidin
    • İş bilgisayarında yönetici hesabıyla gezmeyin
    • Yedek alın; ransomware'li oltalama ekleri hâlâ yaygındır
    • Aile bireylerine "parola isteme" ve "acil havale" senaryolarını anlatın

    Kod:
    # Kişisel alan adı kullanıyorsanız (ör. küçük işletme) # DNS'te SPF + DKIM + DMARC'ı hosting panelinden etkinleştirin # DMARC raporlarını ilk ay "p=none" ile izleyip sonra quarantine/reject'e geçin

    [center][/center]

    Şüpheli bir mesaj aldığınızda duygusal tepkiyi (korku/acele) bilinçli olarak yavaşlatmak, teknik bilgiden önce gelen en ucuz kontroldür. "Bu mail beni ne hissettiriyor?" sorusu bile birçok oltalamayı boşa çıkarır.

    Kaynakça
    Yasal Uyarı
    Bu içerik farkındalık ve savunma eğitimidir. Phishing altyapısı kurmak, başkalarına oltalama yapmak veya izinsiz kimlik bilgisi toplamak suçtur. TCK 243-245 ve ilgili dolandırıcılık maddeleri kapsamında ağır yaptırımlar uygulanabilir. Yalnızca yetkili simülasyon ve kendi labınızda çalışın.

    Ek DosyalarEkran Görüntüleri
       
     Sosyal Mühendislik ve Phishing Nasıl Tanınır? Farkındalık ve Savunma Rehberi
    BilgeKagan 10-18-2026, 01:35 AM · Sosyal Mühendislik ve Farkındalık
    0 38
    [center]
    [Resim: attachment.php?aid=136]
    [/center]

    Selam TurkTeam, BlueTornado ile.

    Teknik kontroller ne kadar iyi olursa olsun, insan faktörü hâlâ en geniş saldırı yüzeylerinden biridir. Bu konu saldırı "nasıl yapılır" diye değil; nasıl tanınır ve nasıl savunulur diye yazıldı. Phishing, vishing, smishing ve iş e-postası dolandırıcılığı (BEC) belirtilerini, güvenli doğrulama alışkanlıklarını ve kurumsal kontrolleri ele alıyoruz.

    Konuda Anlatılacaklar
    1. Sosyal mühendislik nedir?
    2. Phishing türleri (e-posta, SMS, ses, QR, BEC)
    3. Tanıma ipuçları ve güvenli kontrol listesi
    4. Lab: kendi test e-postanızı analiz etme
    5. Kurumsal ve bireysel savunma
    6. İleri seviye: MFA yorgunluğu, evilginx tarzı reverse proxy farkındalığı (savunma)
    7. Kaynakça ve yasal uyarı

    1) Sosyal Mühendislik Nedir?
    Sosyal mühendislik, insanları manipüle ederek gizli bilgiyi ifşa ettirme, zararlı eylem yaptırma veya güvenlik kontrollerini atlatma sanatıdır. Teknik zafiyet yerine güven, acele, korku, hiyerarşi ve yardımseverlik kullanılır.
    • Phishing: Sahte iletişimle kimlik bilgisi veya zararlı dosya/link
    • Spear phishing: Belirli kişi/kuruma özel hazırlanmış
    • Whaling: Üst düzey yönetici hedefi
    • Vishing: Telefon
    • Smishing: SMS
    • Pretexting: Sahte senaryo (IT destek, kargo, banka)
    • BEC: Sahte CEO/tedarikçi ile havale talimatı

    Alıntı:İyi bir oltalama maili "kötü Türkçe ve kırmızı bayraklarla dolu" olmak zorunda değildir. Kurumsal dile benzeyen, kişiselleştirilmiş ve acil görünen içerikler daha tehlikelidir.

    2) Phishing Nasıl Tanınır?

    Gönderen ve domain:
    Kod:
    # Gözle kontrol Görünen ad: "IT Destek" <[email protected]> # Gerçek domaininiz turkteam.org ise bu şüphelidir # Homoglyph: rn -> m, IDN punycode

    Linkler:
    • Üzerine gelince (hover) görünen URL ile metin farklı mı?
    • Kısaltılmış linkler (bit.ly vb.) bilinmeyen gönderende riskli
    • Kod:
      https://turkteam.org.güvenlik-kontrolü.evil.example
      gibi alt alan adı oyunları

    İçerik psikolojisi:
    • Aşırı aciliyet: "Hesabınız 1 saat içinde kapanacak"
    • Korku: "Yasal işlem başlatılacak"
    • Ödül: "Kargo sizden ücret bekliyor / ikramiye"
    • Otorite: "Yönetim Kurulu gereği hemen onay"

    Ekler:
    Kod:
    .html
    , çift uzantı
    Kod:
    fatura.pdf.exe
    , makro'lu Office, ISO/IMG. Beklemediğiniz bir fatura eki klasik vektördür.

    [center][/center]

    3) Güvenli Doğrulama Alışkanlıkları
    • Maildeki linke tıklamak yerine tarayıcıya kurumu sizin bildiğiniz adresten yazın
    • Para/havale taleplerini ikinci bir kanaldan (bilinen telefon) doğrulayın
    • IT'nin parolanızı mail ile istemeyeceğini bilin; SSO sayfasına mail içinden gitmeyin
    • Şüpheli maili "bildir" ile SOC/IT'ye iletin; silmeden önce kurum prosedürünü izleyin
    • Kişisel hesaplarda da aynı şüphecilik

    Kod:
    # Bireysel hızlı kontrol listesi [ ] Gönderen domain gerçek mi? [ ] Ben bu maili bekliyor muydum? [ ] Aciliyet baskısı var mı? [ ] Link hover / ek şüpheli mi? [ ] İkinci kanal doğrulaması yaptım mı?

    4) Uygulamalı: Zararsız Analiz Labı
    Kendi kendinize gönderdiğiniz veya kurumsal phishing simülasyonundan gelen bir örneği (güvenli ortamda) inceleyin. Üretimde şüpheli ekleri açmayın.

    Kod:
    # E-posta kaynak başlıklarını görmek (Gmail: Show original) # İncelenecek başlıklar: From: Return-Path: Reply-To: Received: (zincir) Authentication-Results: (SPF/DKIM/DMARC)

    Kod:
    # Örnek Authentication-Results satırı (kavramsal) spf=pass dkım=pass dmarc=pass # Hepsi fail ise yüksek şüphe; hepsi pass olsa bile içerik sahte olabilir (hesap ele geçirme)

    [center][/center]

    URL'yi açmadan önce:
    Kod:
    # VirusTotal / urlscan.io gibi servislere URL yapıştırın (kurum politikasına uygun) # Kendi sandbox'ınız yoksa ekleri çalıştırmayın

    5) Kurumsal Savunma Kontrolleri
    • SPF, DKIM, DMARC yayınlayın; DMARC politikasını kademeli sıkılaştırın
    • Gelen kutusu güvenliği: link rewriting, ek sandbox (imkân varsa)
    • MFA zorunlu; mümkünse phishing-resistant (FIDO2 / passkey)
    • BEC için mali süreç: çift onay, bilinen tedarikçi hesap listesi
    • Düzenli farkındalık eğitimi + ölçülebilir simülasyon (cezalandırıcı değil öğretici)
    • SOC playbook: phishing bildirimi -> URL/hash -> IOC -> kullanıcı etkisi

    Kod:
    # DMARC kayıt örneği (DNS TXT, kavramsal) v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

    Kod:
    # SPF örneği (aşırı geniş +all kullanmayın) v=spf1 include:_spf.google.com -all

    6) İleri Seviye Farkındalık (Savunma)
    MFA yorgunluğu (fatigue): Saldırgan parolayı bir şekilde elde edip telefonunuza peş peşe MFA bildirimi yağdırabilir. Alışkanlık: beklemediğiniz onayları reddedin; parolayı değiştirin; IT'ye bildirin.

    Proxy / Adversary-in-the-middle phishing: Sahte sayfa, gerçek login ile kurban arasında aracılık ederek oturum çerezini/token'ı yakalayabilir. Klasik SMS OTP bu senaryoda yetersiz kalabilir. Passkey/FIDO2 ve Conditional Access (cihaz uyumu, imkânsız gezinti) savunmada öne çıkar.

    QR phishing (quishing): Afiş, PDF veya mail içindeki QR bilinmeyen yere götürebilir. Kurumsal cihazda rastgele QR okutmayın.

    [center][/center]

    Raporlama dili (kullanıcıdan SOC'a):
    Kod:
    Konu: Şüpheli e-posta bildirimi Gönderen: ... Zaman: 2026-10-17 14:10 Europe/Istanbul Tıkladım mı?: Hayır Ek açtım mı?: Hayır Ekran görüntüsü / .eml ekte

    7) Sonuç
    Sosyal mühendislik teknik bir açık değil, insan ve süreç açığıdır. Tanıma refleksleri, ikinci kanal doğrulama, DMARC/MFA/passkey ve iyi bir bildirim kültürü en etkili savunma paketidir. Merak ettiğiniz teknik detayları izinsiz sistemlerde denemeyin; kurumsal simülasyon programlarına katılın.



    Ek: Ev ve Küçük İşletme İçin 10 Dakikalık Sertleştirme
    Büyük bir SOC'unuz olmasa bile uygulanabilir adımlar:
    • E-posta hesabında MFA açın (mümkünse uygulama veya güvenlik anahtarı; SMS son çare)
    • Tarayıcıda şüpheli eklentileri kaldırın; otomatik indirme klasörünü izleyin
    • Kargo/banka SMS'lerindeki linklere değil, resmi uygulamaya gidin
    • İş bilgisayarında yönetici hesabıyla gezmeyin
    • Yedek alın; ransomware'li oltalama ekleri hâlâ yaygındır
    • Aile bireylerine "parola isteme" ve "acil havale" senaryolarını anlatın

    Kod:
    # Kişisel alan adı kullanıyorsanız (ör. küçük işletme) # DNS'te SPF + DKIM + DMARC'ı hosting panelinden etkinleştirin # DMARC raporlarını ilk ay "p=none" ile izleyip sonra quarantine/reject'e geçin

    [center][/center]

    Şüpheli bir mesaj aldığınızda duygusal tepkiyi (korku/acele) bilinçli olarak yavaşlatmak, teknik bilgiden önce gelen en ucuz kontroldür. "Bu mail beni ne hissettiriyor?" sorusu bile birçok oltalamayı boşa çıkarır.

    Kaynakça
    Yasal Uyarı
    Bu içerik farkındalık ve savunma eğitimidir. Phishing altyapısı kurmak, başkalarına oltalama yapmak veya izinsiz kimlik bilgisi toplamak suçtur. TCK 243-245 ve ilgili dolandırıcılık maddeleri kapsamında ağır yaptırımlar uygulanabilir. Yalnızca yetkili simülasyon ve kendi labınızda çalışın.

    Ek DosyalarEkran Görüntüleri
       
     OSINT Nedir? Ücretsiz Açık Kaynak İstihbarat Araçları Rehberi
    BilgeKagan 10-17-2026, 03:05 PM · OSINT
    0 42
    [center]
    [Resim: attachment.php?aid=135]
    [/center]

    Selam millet, BlueTornado burada.

    OSINT (Open Source Intelligence), herkese açık kaynaklardan bilgi toplama ve analiz etme disiplinidir. Gazetecilik, tehdit istihbaratı, red team keşfi, kayıp kişi araştırması ve kurumsal marka koruması gibi alanlarda kullanılır. Bu rehber ücretsiz araçlara, etik sınırlara ve yasal lab/pratik akışına odaklanır. Google Dorks ve Shodan için forumda ayrı konular vardır; burada genel çerçeveyi kuruyoruz.

    Konuda Anlatılacaklar
    1. OSINT nedir, ne değildir?
    2. Etik ve yasal çerçeve
    3. Süreç: planlama, toplama, doğrulama, raporlama
    4. Ücretsiz araç seti (web, kullanıcı adı, e-posta, DNS, görsel)
    5. Uygulamalı mini senaryo (kendi lab hesabınız)
    6. İleri seviye: sock puppet, OPSEC, otomasyon
    7. Kaynakça ve yasal uyarı

    1) OSINT Nedir?
    "Açık kaynak", yalnızca haber siteleri demek değildir. Şunlar OSINT kapsamına girebilir:
    • Herkese açık web sayfaları, sosyal medya profilleri
    • DNS/WHOIS kayıtları, sertifika şeffaflık logları
    • Şirket kayıtları, ihale ilanları, mahkeme kararları (ülkeye göre)
    • Herkese açık kod depoları (GitHub), paste siteleri
    • Uydu/harita görüntüleri (yasal ve herkese açık olanlar)

    OSINT, sisteme izinsiz girmek değildir. Kapalı bir panele brute-force yapmak, hesabı ele geçirmek veya ödeme duvarını aşmak OSINT değildir; saldırıdır.

    Alıntı:İyi OSINT, gürültüden sinyal çıkarmaktır. Çok araç kullanmak değil; soruyu netleştirmek ve kaynakları doğrulamaktır.

    2) Etik ve Yasal Sınırlar
    • Hedef: yalnızca izinli araştırma, kendi varlıklarınız veya kamuya açık bilgi
    • Topladığınız veriyi doxxing, tehdit veya dolandırıcılık için kullanmayın
    • Platform ToS'una ve KVKK'ya saygı gösterin; kişisel veriyi gerekmeden işlemeyin
    • Teknik olarak erişilebilir her şey yasal/etik olmayabilir (ör. yanlışlıkla açık S3 ama özel veri)

    Türkiye'de bilişim sistemine izinsiz girme ve engelleme TCK 243-245 kapsamında düzenlenir. OSINT çalışması kamuya açık bilgiyle sınırlı kalsa bile, elde edilen verinin kötüye kullanımı başka suçlara yol açabilir.

    3) Süreç
    Kod:
    # 1) Soru "X şirketinin halka açık alt alan adları ve e-posta formatı nedir?" # 2) Kaynak planı DNS, CRT.sh, şirket kariyer sayfası, LinkedIn (manuel), GitHub org # 3) Toplama Araç çıktıları + manuel not # 4) Doğrulama İkinci kaynakla çapraz kontrol; eski/yanlış bilgiyi işaretle # 5) Rapor Bulgular, güven seviyesi, tarih, kaynak URL'leri

    [center][/center]

    4) Ücretsiz Araç Seti

    4.1 Kullanıcı adı araştırması - Sherlock
    Kod:
    pipx install sherlock-project sherlock turkteam_ornek --print-found
    Çıktı: hangi platformlarda aynı handle'ın var göründüğü. Yanlış pozitif olabilir; profile girip doğrulayın.

    4.2 E-posta / sızıntı kontrolü (kendi hesabınız)
    Kod:
    # haveibeenpwned.com üzerinden kendi e-postanızı kontrol edin # API kullanımı için resmi dokümantasyona bakın; başkasının e-postasını izinsiz sorgulamayın
    "Verilerim sızdı mı?" senaryosunda önce kendi adreslerinizi kontrol etmek meşru bir alışkanlıktır.

    4.3 DNS ve sertifika
    Kod:
    dig turkteam.org ANY +noall +answer dig turkteam.org MX +short whois turkteam.org | head -n 40

    Kod:
    # Certificate Transparency # https://crt.sh/?q=%25.turkteam.org curl -s "https://crt.sh/?q=%25.example.com&output=json" | head

    [center][/center]

    4.4 Alt alan adı keşifi (pasif)
    Kod:
    # Amass pasif örnek (kendi/izinli domain) amass enum -passive -d example.com -o amass.txt # veya subfinder subfinder -d example.com -silent
    Aktif brute-force ve port taraması, izinsiz hedeflerde yasal risk taşır; kendi domaininizde yapın.

    4.5 Wayback / arşiv
    Kod:
    # web.archive.org üzerinden eski sayfa anlık görüntüleri # Gizlenmiş ama daha önce public olan içerik için

    4.6 Görsel OSINT
    • Google / Yandex görsel arama (tersine)
    • Exif verisi: birçok platform sıyırır; orijinal dosyada kalmış olabilir
    • Harita üzerinde gölge, tabela, bitki örtüsü ile konum tahmini (etik sınırlara dikkat)

    Kod:
    exiftool photo.jpg | egrep -i "GPS|Date|Model"

    4.7 Kod ve sır sızıntısı (kendi repolarınız)
    Kod:
    # GitHub'da kendi org'unuzda gizli arama # gitleaks veya trufflehog ile kendi CI'nızda tarama gitleaks detect -s . -v

    4.8 Tehdit istihbaratı feed'leri
    • AlienVault OTX (ücretsiz hesap)
    • urlhaus / malware bazaar (zararlı URL/hash, araştırma)
    • CISA KEV kataloğu (bilinen sömürülen zafiyetler)

    Kod:
    # Örnek: bir hash'i VirusTotal'da kendi lab örneğiniz için sorgulama # API anahtarınızı paylaşmayın

    5) Uygulamalı Mini Senaryo
    Hedef: kendi yan projenizin veya bilerek açtığınız lab domain'inin dışarıdan görünümü.

    Kod:
    # Adım 1 dig +short lab.sizin-domaininiz.com # Adım 2 curl -I https://lab.sizin-domaininiz.com # Adım 3 sherlock sizin_lab_kullaniciadiniz --print-found # Adım 4 # Kariyer/about sayfasından e-posta formatını not alın (public ise) # Adım 5 # Bulguları tarih damgalı markdown rapora yazın

    [center][/center]

    Rapor şablonu:
    Kod:
    # OSINT Notu Tarih: 2026-10-17 (Europe/Istanbul) Soru: ... Kaynaklar: - URL / araç / saat Bulgular (güven: yüksek/orta/düşük): - ... Açık sorular: - ... Yapılmayanlar (bilinçli): - Aktif port taraması yapılmadı

    6) İleri Seviye
    Sock puppet / araştırma hesapları: Kişisel hesabınızla agresif araştırma yapmak OPSEC ve ToS riski taşır. Ayrı araştırma kimlikleri, izole tarayıcı profilleri (konteyner) düşünün. Sahte kimlikle dolandırıcılık yapmayın.

    Otomasyon: ReconFTW, Maltego CE (sınırlı), SpiderFoot gibi araçlar süreci hızlandırır; gürültüyü de artırır. Her otomatik bulguyu doğrulayın.

    Shodan / Censys: İnternete açık cihaz arama motorlarıdır. Etik kullanım ve kendi IP alanlarınız için ayrı konuda derinleşin; başkasının altyapısını izinsiz yoklamayın.

    Dezinformasyon: Sahte profiller, eski WHOIS, belirsiz forum iddiaları. Tek kaynakla karar vermeyin.

    [center][/center]

    7) Sonuç
    OSINT, açık kaynaklardan disiplinli bilgi üretmektir. Ücretsiz araçlar yeterince güçlidir; farkı süreç, doğrulama ve etik oluşturur. Kendi varlıklarınız üzerinde pratik yapın, dork ve Shodan konularıyla devam edin.

    Kaynakça
    Yasal Uyarı
    Bu rehber eğitim ve meşru güvenlik araştırması içindir. İzinsiz sistem erişimi, veri hırsızlığı veya kişileri hedef alan taciz amaçlı kullanım yasaktır. TCK 243, 244, 245 ve KVKK yükümlülüklerine uyun. Sorumluluk uygulayana aittir.

    Ek DosyalarEkran Görüntüleri
       
     SQL Injection Sıfırdan: DVWA ile Uygulamalı Rehber (Yasal Lab)
    BilgeKagan 10-17-2026, 03:03 PM · Web Uygulama Güvenliği
    0 41
    [center]
    [Resim: attachment.php?aid=134]
    [/center]

    Selam TurkTeam, BlueTornado ile devam.

    SQL Injection (SQLi), uygulamanın SQL sorgusunu kullanıcı girdisiyle güvensiz biçimde birleştirmesi sonucu ortaya çıkan klasik bir enjeksiyon zafiyetidir. Bu rehberde sıfırdan teori, DVWA üzerinde Low/Medium/Impossible karşılaştırması, parametreli sorgular ve modern ORM hatalarını ele alıyoruz. Tüm örnekler yalnızca yerel lab içindir.

    Konuda Anlatılacaklar
    1. SQL Injection nedir, hangi riskleri taşır?
    2. DVWA lab kurulumu
    3. Kavramlar: union, boolean, error-based, blind
    4. Low seviyede adım adım gözlem
    5. Medium filtre ve prepared statement'a geçiş
    6. Korunma: parametreli sorgu, ORM, least privilege
    7. İleri seviye: second-order, WAF yanılsaması
    8. Kaynakça ve yasal uyarı

    1) SQL Injection Nedir?
    Veritabanı, uygulamanın gönderdiği SQL metnini yorumlar. Saldırgan, girdi alanına SQL sözdizimi parçaları ekleyerek sorgunun mantığını değiştirebiliyorsa injection vardır.

    Kod:
    # Tehlikeli kalıp (kavramsal) id = request.GET["id"] sql = "SELECT first_name, last_name FROM users WHERE user_id = '" + id + "'" # id = 1' OR '1'='1 olduğunda mantık bozulur

    Olası etkiler: kimlik doğrulamayı atlama, veri okuma/değiştirme, bazı DB/konfigürasyonlarda OS komutuna giden yollar (ör. xp_cmdshell gibi özellikler açıksa). Etki, DB kullanıcısının yetkisine ve uygulama mimarisine bağlıdır.

    OWASP Top 10 2021'de Injection A03:2021 altındadır. CWE karşılığı başlıca CWE-89'dur.

    2) Lab Kurulumu
    Kod:
    git clone https://github.com/digininja/DVWA.git cd DVWA docker compose up -d

    Kurulum sonrası DVWA Security'yi Low yapın. SQL Injection ve SQL Injection (Blind) sayfalarını kullanacağız.

    [center][/center]

    İsteğe bağlı olarak kendi MySQL/MariaDB labınızda da aynı mantığı kurabilirsiniz; önemli olan üretim verisine dokunmamaktır.

    3) Kavram Referansı

    In-band (Union / Error): Sonuç veya hata mesajı aynı kanalda döner.

    Kod:
    # Union temelli keşif (yalnızca lab, sözdizimi DB'ye göre değişir) 1' UNION SELECT null, null-- 1' UNION SELECT user(), database()--

    Boolean-based blind: Sayfa içeriği doğru/yanlış cevaba göre değişir; veri bit bit çıkarılır.

    Kod:
    1' AND 1=1-- 1' AND 1=2--

    Time-based blind:
    Kod:
    SLEEP()
    /
    Kod:
    WAITFOR DELAY
    ile zaman farkından çıkarım (labda dikkat: kendini DoS etme).

    Kod:
    # MySQL lab örneği (kendi DVWA'nız) 1' AND SLEEP(3)--

    Prepared statement / parametreli sorgu: SQL yapısı ile verinin ayrılması. Asıl savunma budur.

    Kod:
    # Python psycopg / MySQL connector tarzı cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))

    4) DVWA Low: Adım Adım

    Adım 1 - Normal davranış:
    Kod:
    User ID: 1 # Beklenen: o kullanıcıya ait ad/soyad

    Adım 2 - Mantığı bozma:
    Kod:
    1' OR '1'='1 # Low seviyede genellikle birden fazla satır döner

    Çıktıyı yorumlayın: Uygulama girdi etrafına tırnak koyup birleştiriyorsa bu payload tüm satırları getirir. Bu, zafiyetin varlığını gösterir.

    [center][/center]

    Adım 3 - Sütun sayısını anlama (Union):
    DVWA Low'da klasik union yolu kullanılır. Önce sütun sayısını bulun:

    Kod:
    1' ORDER BY 1-- 1' ORDER BY 2-- 1' ORDER BY 3-- # Hata aldığınız nokta sütun sayısını aştığınız yerdir

    Kod:
    1' UNION SELECT user, password FROM users-- # Labda hash'lerin görünmesi, üretimde felaket senaryosudur

    Adım 4 - Hata mesajlarını okuma:
    Verbose SQL hataları hem enjeksiyonu kolaylaştırır hem bilgi sızdırır. Production'da genel hata sayfası kullanın; detayı loglayın.

    Kod:
    # Kötü: ham SQL exception'ı kullanıcıya göstermek # İyi: "Bir hata oluştu" + sunucu tarafı log

    5) Blind SQLi Sayfası
    DVWA SQL Injection (Blind) sayfasında sonuç satırları doğrudan basılmayabilir; "User ID exists" benzeri mesajlar görürsünüz.

    Kod:
    1' AND '1'='1 1' AND '1'='2

    Birinde "exists", diğerinde farklı mesaj varsa boolean blind mümkündür. Otomatik araçlar (sqlmap) bu farkları ölçer; yalnızca kendi labınızda ve yasal kapsamda kullanın.

    Kod:
    # sqlmap lab örneği (DVWA localhost, kendi ortamınız) sqlmap -u "http://127.0.0.1/vulnerabilities/sqli_blind/?id=1&Submit=Submit" \ --cookie="security=low; PHPSESSID=..." \ --batch --technique=B

    sqlmap çıktısını yorumlarken: DBMS tipi, baner, tablolar. Üretimde izinsiz sqlmap çalıştırmak hem etik dışıdır hem yasadışıdır.

    [center][/center]

    6) Medium ve Impossible: Ne Değişiyor?
    Medium'da DVWA genelde POST + mysql_real_escape_string benzeri kaçış veya seçim kutusu kullanır. Escape, yanlış bağlamda (ör. sayısal alan, farklı karakter seti) yeterli olmayabilir; asıl çözüm prepared statement'tır.

    Impossible seviyede parametreli sorgu görürsünüz. Kaynak kodu (DVWA PHP) inceleyerek farkı not edin:

    Kod:
    # Kavramsal güvenli PHP $stmt = $mysqli->prepare("SELECT first_name, last_name FROM users WHERE user_id = ?"); $stmt->bind_param("s", $id); $stmt->execute();

    Kod:
    # ORM örneği (Django) User.objects.filter(id=user_id) # Dikkat: raw() / extra() ile tekrar injection açabilirsiniz

    7) Korunma Katmanları
    • Birincil: Parametreli sorgu / ORM güvenli API
    • Girdi doğrulama: Beklenen tip (int), uzunluk, allowlist
    • Least privilege: Uygulama DB kullanıcısına DROP/FILE vermeyin
    • Hata yönetimi: Detaylı SQL hatalarını gizleyin
    • WAF: Savunma derinliği; tek başına çözüm değil
    • Test: SAST, DAST, kod incelemesi, unit test ile raw SQL denetimi

    Kod:
    # Beklenen tip kontrolü if not user_id.isdigit(): abort(400)

    Kod:
    # PostgreSQL rol örneği (kavramsal) GRANT SELECT, INSERT, UPDATE ON app_schema.* TO app_user; -- FILE, SUPERUSER yok

    [center][/center]

    8) İleri Seviye
    Second-order SQLi: Girdi önce güvenli saklanır, sonra başka bir sorguda güvensiz birleştirilir.

    ORM / query builder tuzakları:
    Kod:
    # Tehlikeli: kullanıcı girdisini SQL parçası sanmak User.objects.raw("SELECT * FROM users WHERE name = '%s'" % name)

    NoSQL injection: MongoDB'de operatör enjeksiyonu (
    Kod:
    $gt
    vb.) ayrı bir ailedir; "SQL yoksa injection yok" yanılgısına düşmeyin.

    Rapor şablonu:
    Kod:
    Bulgu: SQL Injection (CWE-89) Endpoint: GET /vulnerabilities/sqli?id= Kanıt: Labda OR '1'='1 ile çoklu satır Etki: users tablosu okuma (lab) Öneri: prepared statement + least privilege

    9) Sonuç
    SQLi, girdinin sorgu yapısına karışmasıdır. DVWA Low'da görün, Impossible'da doğru kodu okuyun, kendi projelerinizde raw string birleştirmeyi yasaklayın. Araçlar yardımcı olur; kök neden kod ve tasarımda kalır.

    Kaynakça
    Yasal Uyarı
    SQL Injection testleri yalnızca kendi sistemlerinizde veya yazılı izinli lab/pentest kapsamında yapılmalıdır. İzinsiz veritabanı sorgulama ve araç kullanımı TCK 243, 244, 245 maddeleri kapsamında suç olabilir. Bu yazı eğitim amaçlıdır; sorumluluk uygulayana aittir.

    Ek DosyalarEkran Görüntüleri
       
     Kali Linux mu Parrot OS mu? 2026 Detaylı Karşılaştırma ve Kurulum
    KulTigin 10-17-2026, 02:16 PM · Kali / Parrot OS
    0 52
    Selamlar TurkTeam,

    Siber güvenliğe adım atan herkesin eninde sonunda sorduğu bir soru var: "Kali Linux mu kuralım, Parrot OS mu?" İkisi de Debian tabanlı, önceden yüklü yüzlerce güvenlik aracı içeren dağıtımlardır; ama felsefeleri, varsayılanları ve kullanıcı deneyimleri farklıdır. Bu rehberde iki dağıtımı tarafsız biçimde karşılaştırıyor, ardından güvenli bir sanal makineye temiz kurulumu adım adım gösteriyoruz.

    Konuda Anlatılacaklar
    1. Kali ve Parrot nedir, kim geliştirir
    2. Mimari, masaüstü ve kaynak kullanımı farkları
    3. Araç setleri, güncelleme modeli ve güvenlik yaklaşımı
    4. Hangi profil için hangisi uygun
    5. Uygulamalı: sanal makineye temiz kurulum
    6. Kurulum sonrası ilk adımlar
    7. Sonuç, kaynakça ve yasal uyarı

    1. Kısaca Kali ve Parrot
    Kali Linux, Offensive Security (OffSec) tarafından geliştirilen, sızma testi ve adli bilişime odaklı Debian testing tabanlı bir dağıtımdır. Sektörde fiili standart kabul edilir ve OffSec'in eğitim/sertifika ekosistemiyle (OSCP gibi) sıkı entegredir.

    Parrot Security OS, Parrot Security topluluğu/Parrot Dev ekibi tarafından geliştirilir; yine Debian tabanlıdır ancak sızma testinin yanında gizlilik (anonimlik), geliştirme ve günlük kullanım senaryolarını da hedefler. Varsayılan olarak daha hafif bir masaüstü ve bütünleşik gizlilik araçlarıyla gelir.

    2. Mimari, Masaüstü ve Kaynak
    Her iki dağıtım da Debian paket yönetimini (APT) kullanır, bu yüzden paket kurma/güncelleme komutları aynıdır. Öne çıkan farklar:
    • Varsayılan masaüstü: Kali varsayılan olarak Xfce ile gelir (GNOME/KDE seçenekleri de vardır). Parrot, hafif MATE masaüstünü tercih eder; ayrıca KDE sürümü sunar.
    • Kaynak kullanımı: Parrot genelde daha düşük RAM ile idare eder ve eski donanımda daha akıcı hissettirir. Kali de Xfce ile hafiftir, fakat Parrot'un MATE tabanı tipik olarak biraz daha ekonomiktir.
    • Gizlilik araçları: Parrot, AnonSurf gibi anonimlik araçlarını ve geliştirme ortamlarını kutudan çıktığı gibi daha fazla vurgular.

    3. Araç Setleri, Güncelleme ve Güvenlik
    Çekirdek araç setleri büyük ölçüde örtüşür: nmap, Metasploit, Burp Suite, Wireshark, aircrack-ng, John, Hashcat gibi araçlar ikisinde de bulunur. Kali, meta-paketlerle (kali-linux-default, kali-linux-large, kali-tools-web vb.) araç gruplarını esnek biçimde kurmanızı sağlar.

    Güncelleme modeli her ikisinde de "rolling release"tir; yani sürekli güncellenen bir akış izlenir. İki dağıtım da artık root with sudo yaklaşımını benimsemiştir: günlük işler ayrıcalıksız bir kullanıcıyla yapılır, yetki gerektiğinde sudo kullanılır. Bu, eski "her şey root" modeline göre çok daha güvenlidir.

    Her iki projenin de resmi önerisi nettir: bu dağıtımlar birincil/günlük masaüstü işletim sistemi olarak değil, sızma testi görevleri için kullanılmalıdır. Yeni başlayan biri için genel amaçlı bir dağıtımda (örn. Ubuntu/Debian) araçları ayrı kurmak da geçerli bir yoldur.

    4. Hangisi Kime Uygun?
    • OSCP/OffSec yolundaysanız: Kali, eğitim materyalleriyle birebir uyumlu olduğundan sürtünmeyi azaltır.
    • Eski/az kaynaklı donanım veya gizlilik odağı: Parrot hafifliği ve anonimlik araçlarıyla öne çıkar.
    • Topluluk ve belge bolluğu: Kali'nin kullanıcı tabanı ve belgeleri daha geniştir; sorun çözerken daha çok kaynak bulursunuz.
    Doğru cevap çoğu zaman "ikisini de bir sanal makinede dene, hangisinde rahat edersen onu kullan"dır. Araçlar ortak olduğu için birinden diğerine geçiş zor değildir.

    5. Uygulamalı: Sanal Makineye Temiz Kurulum
    En güvenli yol, dağıtımı bir sanal makinede (VirtualBox/VMware) çalıştırmaktır; ana sisteminizi riske atmadan deneyebilirsiniz.

    Adım 1 - ISO ve bütünlük doğrulama. Resmi siteden ISO'yu indirin ve SHA256 özetini yayınlanan değerle karşılaştırın:
    Kod:
    sha256sum kali-linux-2026-installer-amd64.iso
    Çıktıyı resmi sitedeki değerle karşılaştırın; tutmuyorsa indirmeyi tekrarlayın. Bu adım, değiştirilmiş/zararlı bir imaj kurmanızı engeller.
    [Resim: attachment.php?aid=133]

    Adım 2 - Sanal makine oluşturma. Önerilen minimumlar: 2 vCPU, 4 GB RAM (mümkünse 8 GB), 40+ GB disk. Ağı önce NAT bırakın; lab hedefleriyle çalışırken Host-Only ekleyin.

    Adım 3 - Kurulum sihirbazı. ISO'dan açılışta "Graphical Install" seçin; dil, klavye, ayrıcalıksız kullanıcı adı/parola ve disk bölümlemeyi (yeni başlayan için "Guided - use entire disk") adım adım tamamlayın. Parrot kurulumu da Calamares sihirbazıyla benzer biçimde ilerler.


    Adım 4 - İlk açılış ve doğrulama. Giriş yaptıktan sonra sürümü ve çekirdeği kontrol edin:
    Kod:
    cat /etc/os-release uname -r


    6. Kurulum Sonrası İlk Adımlar
    Tam güncelleme:
    Kod:
    sudo apt update && sudo apt full-upgrade -y
    Sanal makine araçlarını kurma (VirtualBox misafir eklentileri):
    Kod:
    sudo apt install -y build-essential dkms linux-headers-$(uname -r)
    Kali'de ek araç grupları:
    Kod:
    sudo apt install -y kali-linux-large
    Anlık görüntü (snapshot) alın: Temiz kurulum ve güncelleme sonrası bir snapshot alın; bir şey bozulursa saniyeler içinde geri dönersiniz. Bu alışkanlık, deneme-yanılmayla öğrenirken paha biçilmezdir.

    6.1.a. Faydalı Doğrulama ve Ayar Komutları
    Kurulumdan hemen sonra işinize yarayacak birkaç pratik komut. Hangi masaüstü ortamında olduğunuzu görmek için:
    Kod:
    echo "$XDG_CURRENT_DESKTOP"
    Kurulu paket sayısına ve belleğe hızlı bakış (donanımı değerlendirmek için):
    Kod:
    dpkg --get-selections | wc -l free -h
    Günlük iş için ayrıcalıksız bir kullanıcıyı sudo grubuna eklemek (her iki dağıtımda da iyi uygulama):
    Kod:
    sudo usermod -aG sudo kullanici
    Kali'de araç meta-paketlerini listelemek ve belirli bir grubu kurmak:
    Kod:
    apt-cache search kali-tools | head sudo apt install -y kali-tools-top10
    Parrot tarafında bütünleşik anonimlik aracını (AnonSurf) kontrol etmek:
    Kod:
    sudo anonsurf status
    Her iki dağıtımda da güvenlik duvarının durumunu görmek:
    Kod:
    sudo ufw status verbose

    6.1. Özet Karşılaştırma ve Sık Sorulanlar
    Karar verirken şu noktaları aklınızda tutun. Paket yönetimi, çekirdek araçlar ve rolling-release akışı iki dağıtımda neredeyse aynıdır; dolayısıyla "hangisi daha çok araç içeriyor" tartışması pratikte çoğu kullanıcı için anlamsızdır, çünkü eksik aracı tek komutla kurabilirsiniz. Asıl fark varsayılan deneyimde ve ekosistemdedir.

    Donanım: 4 GB RAM ve altı makinelerde Parrot MATE genelde daha rahat nefes aldırır; 8 GB ve üzeri modern makinelerde ikisi arasında hissedilir fark kalmaz. Öğrenme kaynakları: Türkçe ve İngilizce eğitim içeriklerinin, forum çözümlerinin ve kurs materyallerinin çoğu Kali üzerinden anlatıldığı için yeni başlayan biri Kali ile daha az "benim ekranımda neden farklı" sorunu yaşar. Gizlilik: Anonimlik ve geliştirme araçlarını kutudan çıktığı gibi isteyenler Parrot tarafında daha donanımlı başlar.

    Sık sorulan bir soru da "canlı USB mi, sanal makine mi, ana sistem mi?" olur. Öğrenme ve çoğu test için sanal makine en esnek ve en güvenli seçimdir: snapshot alır, bozarsanız geri dönersiniz, ana sisteminizi riske atmazsınız. Donanıma doğrudan erişim gerektiren işler (örneğin bazı kablosuz denetimlerde harici adaptör) için canlı USB veya ikinci bir diske kurulum düşünülebilir. Ana işletim sistemi olarak kurmak ise her iki projenin de önermediği bir yoldur.

    Bir diğer pratik nokta: hangisini seçerseniz seçin, kurulumdan sonra ilk iş tam güncelleme ve snapshot almaktır. Rolling-release dağıtımlarda bazen bir güncelleme beklenmedik davranışa yol açabilir; snapshot bu durumda sigortanızdır. Böylece dağıtım tercihiniz ne olursa olsun, istikrarlı ve geri alınabilir bir çalışma ortamına sahip olursunuz.

    Sonuç
    Kali ve Parrot, aynı Debian temelini paylaşan, araç setleri büyük ölçüde örtüşen iki güçlü dağıtımdır. Kali daha geniş topluluk ve OffSec uyumu sunar; Parrot hafiflik ve gizlilik odağıyla öne çıkar. "En iyi" olan, sizin donanımınıza ve hedefinize göre değişir. İkisini de bir sanal makinede deneyip karar vermek en sağlıklı yoldur. Her durumda bu dağıtımları izinli test ortamlarında kullanın.

    Kaynakça
    Yasal Uyarı
    Alıntı:Kali ve Parrot içindeki araçlar yalnızca kendi sistemlerinizde veya yazılı izinli hedeflerde kullanılmalıdır. İzinsiz test/erişim Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

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

    Ek DosyalarEkran Görüntüleri
       
     John the Ripper ile Parola Kırma: Kurulum, Modlar ve Uygulamalı Örnekler
    KulTigin 10-17-2026, 02:08 PM · Araç Tanıtım ve Eğitimleri
    0 32
    Merhaba TurkTeam,

    John the Ripper (JtR), parola güvenliğini denetlemek için kullanılan, açık kaynaklı ve çok eski köklere sahip bir parola kırma aracıdır. Bu rehberde community sürümü "jumbo" üzerinden kurulumu, çalışma modlarını (single, wordlist, incremental), hash biçimlerini ve en çok kullanılan yardımcı araçları (unshadow, zip2john gibi) uygulamalı olarak ele alıyoruz. Tüm örnekler yalnızca kendi hesaplarınız ve lab verileriniz içindir.

    Konuda Anlatılacaklar
    1. John the Ripper nedir, nasıl çalışır
    2. Kurulum: paket deposu ve jumbo sürüm
    3. Hash biçimi tespiti ve *2john yardımcıları
    4. Çalışma modları: single, wordlist, incremental
    5. Uygulamalı: Linux shadow parolası kırma
    6. Kural (rules), maske ve ilerleme yönetimi
    7. Sonuç, kaynakça ve yasal uyarı

    1. John the Ripper Nedir, Nasıl Çalışır?
    Parolalar sistemlerde açık metin değil, geri döndürülemez bir hash olarak saklanır. JtR, bir aday parolayı aynı algoritmayla hashleyip saklanan hash ile karşılaştırarak çalışır; eşleşirse parola bulunmuş olur. Yani JtR hash'i "çözmez", doğru adayı tahmin edip doğrular. Bu yüzden başarı; wordlist kalitesine, kurallara ve hash algoritmasının yavaşlığına bağlıdır.

    Jumbo sürümü (openwall/john), topluluk tarafından yüzlerce hash türü, OpenCL/GPU desteği ve zengin yardımcı araçlarla genişletilmiş versiyondur ve pentest için önerilen sürümdür.

    2. Kurulum
    Kali/Parrot üzerinde jumbo sürümü genelde "john" paketiyle gelir:
    Kod:
    sudo apt update sudo apt install john
    Sürümü ve derlenmiş özellikleri doğrulayın:
    Kod:
    john --version john --list=build-info
    Desteklenen hash biçimlerini listelemek için:
    Kod:
    john --list=formats | tr ',' '\n' | head

    3. Hash Biçimi ve *2john Yardımcıları
    JtR, pek çok dosya türünü kırılabilir hash biçimine çeviren yardımcı betikler içerir. Bunlar genelde /usr/share/john/ veya /usr/sbin altında bulunur.

    unshadow - /etc/passwd ve /etc/shadow dosyalarını JtR'nin anlayacağı tek dosyada birleştirir:
    Kod:
    sudo unshadow /etc/passwd /etc/shadow > hashes.txt

    zip2john / rar2john - Parolalı arşivlerin hash'ini çıkarır:
    Kod:
    zip2john gizli.zip > zip.hash

    ssh2john - Parolalı özel anahtarın hash'ini çıkarır:
    Kod:
    ssh2john id_rsa > key.hash

    Bir hash'in türünden emin değilseniz, biçim tahmini için önce incelenmelidir; JtR çoğu zaman biçimi otomatik tanır, ancak --format ile zorlayabilirsiniz:
    Kod:
    john --format=sha512crypt hashes.txt

    4. Çalışma Modları
    single - Kullanıcı adı, GECOS alanı gibi bilgilerden türetilen akıllı tahminler; hızlı ilk geçiş için idealdir:
    Kod:
    john --single hashes.txt

    wordlist - Bir kelime listesi üzerinden deneme; isteğe bağlı kurallarla güçlenir:
    Kod:
    john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

    --rules - Kelimeleri dönüştürerek (büyük harf, sona rakam ekleme vb.) varyasyon üretir:
    Kod:
    john --wordlist=/usr/share/wordlists/rockyou.txt --rules hashes.txt

    incremental - Karakter uzayını istatistiksel sırayla deneyen brute-force modu (uzun sürebilir):
    Kod:
    john --incremental hashes.txt

    5. Uygulamalı: Linux Shadow Parolası Kırma
    Aşağıdaki akışı yalnızca KENDİ test makinenizde deneyin.

    Adım 1 - Test kullanıcısı oluşturun ve basit bir parola verin (lab):
    Kod:
    sudo useradd -m testkullanici echo 'testkullanici:password123' | sudo chpasswd

    Adım 2 - Hash'leri birleştirin:
    Kod:
    sudo unshadow /etc/passwd /etc/shadow > hashes.txt
    Çıktı satırı şuna benzer; $6$ öneki parolanın sha512crypt ile saklandığını gösterir:
    Kod:
    testkullanici:$6$xyz...$abcdef...:1002:1002::/home/testkullanici:/bin/bash
    [Resim: attachment.php?aid=132]

    Adım 3 - rockyou ile kırma:
    rockyou.txt Kali'de genelde sıkıştırılmıştır; önce açın:
    Kod:
    sudo gzip -d /usr/share/wordlists/rockyou.txt.gz 2>/dev/null john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt
    JtR parolayı bulunca şuna benzer bir satır yazar ve kırılan kayıtları john.pot dosyasına ekler:
    Kod:
    password123 (testkullanici)


    Adım 4 - Sonuçları görüntüleme:
    Kırılmış parolaları tekrar çalıştırmadan görmek için:
    Kod:
    john --show hashes.txt
    Bu komut "testkullanici:password123" gibi çözülmüş kayıtları listeler.


    6. İleri Seviye: Kurallar, Maske ve İlerleme
    Durum takibi: JtR çalışırken herhangi bir tuşa basınca ilerlemeyi gösterir. Oturum kaydetme ve devam ettirme:
    Kod:
    john --session=denetim --wordlist=rockyou.txt hashes.txt john --restore=denetim

    Mask modu: Parola kalıbını biliyorsanız (örn. 6 küçük harf + 2 rakam) hedefli brute-force çok hızlanır:
    Kod:
    john --mask='?l?l?l?l?l?l?d?d' --min-length=8 hashes.txt
    Burada ?l küçük harfi, ?d rakamı temsil eder.

    Özel kural seti: /etc/john/john.conf içine kendi kurallarınızı ekleyip --rules=KuralAdi ile çağırabilirsiniz. Kurumsal denetimlerde parola politikasına uygun özel kurallar yazmak, gerçekçi sonuç verir.

    Performans: Yavaş hash'lerde (bcrypt, sha512crypt) CPU hızı sınırlayıcıdır; büyük kampanyalar için GPU desteği olan Hashcat'i değerlendirin. JtR'nin güçlü yanı esnek kural motoru ve geniş biçim desteğidir.

    6.1. Hash Türleri ve Pratik Notlar
    Parola denetiminde karşılaşacağınız hash türlerini tanımak, doğru stratejiyi seçmenin yarısıdır. Modern Linux dağıtımları parolaları yavaş ve tuzlu (salted) algoritmalarla saklar: MD5-crypt, , ve öneklerini gösterir. Yavaş algoritmalar bir aday parolayı doğrulamayı kasıtlı olarak pahalı kılar; bu yüzden milyonlarca deneme saniyeler değil dakikalar-saatler alır. Bu da neden güçlü ve uzun parolaların kaba kuvvete karşı etkili olduğunu açıklar.

    Windows ortamlarında NTLM hash'leri tuzsuzdur ve hızlı kırılır; bu yüzden kurumsal denetimlerde özellikle önemlidir. JtR bu biçimleri de destekler, ancak büyük NTLM koleksiyonlarında GPU hızı için Hashcat sıklıkla tercih edilir. İki aracı rakip değil tamamlayıcı görün: JtR'nin kural motoru ve biçim çeşitliliği keşif ve küçük setlerde, Hashcat'in GPU gücü büyük kampanyalarda parlar.

    Denetim raporunuzda yalnızca "kaç parola kırıldı" demek yetmez; kırılan parolaların uzunluk ve karmaşıklık dağılımını, politikaya uymayanları ve yeniden kullanılan parolaları da belgeleyin. Asıl değer, bulguların düzeltici öneriye dönüşmesindedir: minimum uzunluk artırma, yaygın parolaların engellenmesi (deny list) ve çok faktörlü kimlik doğrulama.

    Son olarak, john.pot dosyasının önceki sonuçları sakladığını unutmayın; yeni bir denetime temiz başlamak isterseniz bu dosyayı yedekleyip temizleyin. Aksi halde JtR, zaten kırılmış hash'leri atlayıp sonuçları birleştirir ve ilerleme olduğundan daha hızlı görünebilir.

    Sonuç
    John the Ripper, parola denetiminde hâlâ en pratik araçlardan biridir. Doğru yaklaşım; önce --single, sonra kurallı wordlist, en son maske/incremental sırasıyla ilerlemektir. Amaç saldırmak değil, zayıf parolaları ortaya koyup düzeltmektir. Bu yüzden denetim sonuçlarını mutlaka güçlü parola politikasıyla eşleştirin.

    Kaynakça
    Yasal Uyarı
    Alıntı:Parola kırma yalnızca kendi hesaplarınızda veya yazılı yetki verilmiş denetimlerde yapılmalıdır. Başkasına ait parolaları izinsiz kırmak Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

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

    Ek DosyalarEkran Görüntüleri