TürkTeam Portal

Siber güvenlik topluluğunun nabzı

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

Duyurular
 Yerel LLM Güvenliği 2026: Ollama'yı Güvenli Çalıştırma ve Açıkta Kalan Sunucular
Tonyukuk 10-18-2026, 06:30 PM · Yapay Zeka Güvenliği
0 38
[Resim: attachment.php?aid=242]

Merhaba arkadaşlar,

Kendi bilgisayarınızda veya sunucunuzda yerel bir dil modeli çalıştırmak (Ollama, LM Studio, vLLM vb.) mahremiyet ve maliyet açısından harika. Ama yanlış yapılandırılmış bir yerel LLM sunucusu, internete açık ve kimlik doğrulaması olmayan bir kapı haline gelebilir. Araştırmalar, internette binlerce korumasız Ollama örneği bulunduğunu gösteriyor. Bu rehberde Ollama örneği üzerinden yerel LLM sunucularının güvenli yapılandırmasını resmi belgelere dayanarak anlatıyorum. Amaç saldırmak değil, kendi sunucunuzu güvenli kurmak.

Konuda Anlatılacaklar
  1. Yerel LLM sunucusunun saldırı yüzeyi
  2. Ollama varsayılanları: bind adresi ve kimlik doğrulama
  3. Açıkta kalan sunucular: gerçek rakamlar
  4. CVE-2024-37032 (Probllama)
  5. Güvenli yapılandırma adımları
  6. Ters proxy ile kimlik doğrulama
  7. İzleme ve sertleştirme

Yerel LLM Sunucusunun Saldırı Yüzeyi

Yerel bir LLM sunucusu bir HTTP API sunar. Bu API açığa çıkarsa saldırgan; sizin donanımınızda ücretsiz çıkarım (inference) yapabilir, modelleri listeleyip indirebilir veya silebilir, sistem kaynaklarınızı tüketebilir (OWASP LLM10: Unbounded Consumption) ve bazı durumlarda sunucudaki açıklar üzerinden kod çalıştırabilir. Temel sorun çoğu zaman tek şeydir: API'nin internete, kimlik doğrulaması olmadan açılması. Bulut üzerinde bir GPU sunucusu kiralayıp Ollama kurduğunuzda bu risk daha da büyür, çünkü sunucu zaten herkese açık bir IP'ye sahiptir; tek eksik güvenlik duvarı kuralı bile API'yi dünyaya açabilir.

[Resim: attachment.php?aid=243]

Ollama Varsayılanları: Bind Adresi ve Kimlik Doğrulama

Resmi Ollama belgelerine (FAQ) göre:
  • Ollama varsayılan olarak 127.0.0.1 (localhost), port 11434 dinler. Yani varsayılan halde yalnızca aynı makineden erişilebilir.
  • Bind adresini değiştirmek için OLLAMA_HOST ortam değişkeni kullanılır. Örneğin OLLAMA_HOST=0.0.0.0:11434 yaparsanız sunucu tüm ağ arayüzlerinde dinlemeye başlar; loopback-only koruması kalkar.
Kritik nokta: Ollama'nın yerel API'si için yerleşik kimlik doğrulama yoktur. Bu yüzden 0.0.0.0'a bind edip portu internete açmak, API'yi herkese açmak demektir. Varsayılanı bilinçli bir sebep olmadan değiştirmeyin.

Açıkta Kalan Sunucular: Gerçek Rakamlar

Bu teorik bir risk değil. Açık kaynak araştırmalarına göre:
  • Censys, Eylül 2025'te internette yaklaşık 10.600 açık Ollama örneği tespit etti.
  • Cisco'nun Shodan tabanlı araştırması 1.139 açık Ollama sunucusu buldu; bunlardan 214'ü aktif olarak model sunuyordu.
Bu sunucuların çoğu muhtemelen "hızlıca deneyeyim" diyip OLLAMA_HOST=0.0.0.0 yapan ve güvenlik duvarını unutan kullanıcılara ait. Kendi sunucunuzun bu listeye girmemesi tamamen sizin yapılandırmanıza bağlı.

[Resim: attachment.php?aid=244]

CVE-2024-37032 (Probllama)

Wiz ekibinin bulduğu CVE-2024-37032 ("Probllama"), Ollama'nın 0.1.34 öncesi sürümlerini etkiler. Zafiyet, model yolu çözümlemesinde digest alanının yetersiz doğrulanmasından kaynaklanır ve yol geçişi (path traversal) ile özellikle açığa çıkmış API'li Docker kurulumlarında uzaktan kod çalıştırmaya (RCE) yol açabilir. Çözüm nettir: 0.1.34 veya üzeri sürüme güncelleyin. Bu örnek, yerel LLM araçlarını da diğer yazılımlar gibi güncel tutmanın neden şart olduğunu gösterir.

Sürümünüzü kontrol edin ve güncelleyin (Linux için resmi yöntem):

Kod:
ollama --version curl -fsSL https://ollama.com/install.sh | sh

Güvenli Yapılandırma Adımları

  1. Varsayılan bind'i koruyun: Gerçekten gerekmedikçe OLLAMA_HOST'u 0.0.0.0 yapmayın; localhost'ta bırakın.
  2. Güncel tutun: En az 0.1.34, tercihen en güncel sürüm.
  3. Güvenlik duvarı: 11434 portunu dışarıya kapatın.

systemd ile çalışan bir Ollama'da ortam değişkenini güvenli ayarlamak (resmi belgeye göre):

Kod:
sudo systemctl edit ollama.service # [Service] altina: # Environment="OLLAMA_HOST=127.0.0.1:11434" sudo systemctl daemon-reload sudo systemctl restart ollama

Portun dışarıya kapalı olduğunu kendi sunucunuzda doğrulayın (ufw örneği):

Kod:
sudo ss -tlnp | grep 11434 sudo ufw deny 11434/tcp

Ters Proxy ile Kimlik Doğrulama

Ollama'yı bir ağ üzerinden paylaşmanız gerekiyorsa, onu doğrudan açmak yerine kimlik doğrulamalı bir ters proxy arkasına koyun. Ollama FAQ'in Nginx örneğini temel alıp üstüne temel kimlik doğrulama (basic auth) ekleyebilirsiniz:

Kod:
server { listen 443 ssl; server_name llm.benimsunucum.local; location / { auth_basic "LLM"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:11434; proxy_set_header Host localhost:11434; } }

Böylece Ollama yalnızca localhost'ta dinlerken, dışarıdan erişim TLS ve parola ile korunur. Kullanıcı dosyasını htpasswd ile oluşturun ve güçlü bir parola seçin.

[Resim: attachment.php?aid=245]

İleri Seviye: İzleme ve Sertleştirme
  • Erişim loglama: Ters proxy loglarını izleyin; beklenmeyen IP'lerden gelen istekleri yakalayın. Elastic gibi SIEM'lerde "Ollama API harici erişim" için hazır kurallar bulunur.
  • CORS kısıtı: OLLAMA_ORIGINS'i yalnızca gereken kaynaklarla sınırlayın; gereksiz yere tüm uzantılara izin vermeyin.
  • Kaynak sınırı: Eşzamanlı istek ve kuyruk sınırlarını (OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE) yapılandırarak kaynak tükenmesine karşı koruyun.
  • Konteyner izolasyonu: Docker ile çalıştırıyorsanız portu yalnızca gereken arayüze bağlayın (-p 127.0.0.1:11434:11434).
Aynı prensipler diğer yerel LLM sunucuları (vLLM, LM Studio, text-generation-webui) için de geçerlidir: varsayılanı bil, internete açma, kimlik doğrulama ekle, güncel tut.

Sonuç

Yerel LLM sunucuları güçlü ama varsayılan güvenli kurulum sizin sorumluluğunuzda. Ollama localhost'ta dinler ve kimlik doğrulaması yoktur; onu 0.0.0.0'a açıp internete bırakmak binlerce örnekte görülen hatadır. Güncel tutun (en az 0.1.34, Probllama yaması), portu kapatın ve paylaşım gerekiyorsa kimlik doğrulamalı ters proxy kullanın. Siz yerel LLM'leri nasıl çalıştırıyorsunuz? Yorumlarda paylaşın.

Kaynakça
Yasal Uyarı

Bu rehberdeki tüm yapılandırma ve komutlar yalnızca kendi sunucunuzda veya yazılı olarak yetkilendirildiğiniz sistemlerde uygulanmalıdır. İnternette açık bulunan üçüncü taraf LLM sunucularına izinsiz erişim, 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur; "açıkta kalmış" olması erişim için izin anlamına gelmez. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

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
               
 Parolaları Güvenli Saklama: Salt, bcrypt ve Argon2 Rehberi
BilgeKagan 10-18-2026, 06:04 PM · Kriptografi
0 39
[center]
[Resim: attachment.php?aid=241]
[/center]

Selam millet, BlueTornado yazıyor.

Veri sızıntılarında en acı senaryolardan biri, kullanıcı parolalarının düz metin veya hızlı hash ile saklanmış olmasıdır. Bu rehberde salt'ın rolünü, neden düz SHA-256 yetmediğini, bcrypt ve Argon2id kullanımını ve OWASP önerilerini lab örnekleriyle anlatıyoruz. Hashcat konusu ayrıca işlendiği için burada kırma değil, doğru saklama odaklıyız.

Konuda Anlatılacaklar
  1. Parola saklama tehdit modeli
  2. Salt, pepper, yavaşlık (key stretching)
  3. bcrypt kullanımı
  4. Argon2id (tercih edilen modern seçim)
  5. Migrasyon ve doğrulama akışı
  6. İleri seviye: parametre seçimi, MFA, passkey
  7. Kaynakça ve yasal uyarı

1) Tehdit Modeli
Saldırgan veritabanı yedeğinizi ele geçirdiğinde ne olur?
  • Düz metin: tüm hesaplar anında açılır; parola reuse ile başka siteler risk altında
  • Hızlı hash (MD5/SHA-1/SHA-256, tuzsuz): GPU ile toplu kırma pratik
  • Yavaş KDF + unique salt: her parola için maliyetli deneme; iyi parolalar korunur

Alıntı:Hash'lemek "şifrelemek" değildir. Parolayı geri çözmeniz gerekmez; her girişte aynı KDF ile doğrularsınız.

OWASP Password Storage Cheat Sheet, modern uygulamalar için Argon2id'yi tercih edilen seçenek olarak listeler; bcrypt kabul edilebilir bir alternatiftir.

2) Salt ve Pepper
Salt: Her kullanıcı/parola için benzersiz rastgele değer. Aynı parola farklı hash üretir; rainbow table etkisizleşir. Salt gizlidir sanılmamalı; hash ile birlikte DB'de tutulur.

Pepper: Uygulama/sunucu tarafında tutulan ek gizli değer (KMS veya config). DB sızsa bile pepper olmadan doğrulama zorlaşır. Pepper'ı git'e yazmayın.

Kod:
# Kavramsal stored = argon2id(password, salt, params, pepper?) # Doğrulama: aynı params ile verify

[center][/center]

3) bcrypt Lab
Kod:
pip install bcrypt python3 - <<'PY' import bcrypt password = b"LabParola!2026" hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12)) print(hashed) print(bcrypt.checkpw(password, hashed)) print(bcrypt.checkpw(b"yanlis", hashed)) PY

Kod:
# Çıktı örneği (her seferinde farklı salt -> farklı string) # $2b$12$...

Dikkat: bcrypt bazı uygulamalarda 72 byte sınırına sahiptir; çok uzun parolalarda önce SHA-256 sonra bcrypt gibi sarmalamalar tartışılır — kütüphane dokümantasyonunu okuyun. Mümkünse Argon2id tercih edin.

4) Argon2id Lab
Argon2, Password Hashing Competition kazananıdır. Argon2id, side-channel ve GPU saldırılarına karşı dengeli bir varyanttır.

Kod:
pip install argon2-cffi python3 - <<'PY' from argon2 import PasswordHasher from argon2.exceptions import VerifyMismatchError ph = PasswordHasher( time_cost=3, memory_cost=65536, # KiB cinsinden; donanımınıza göre ayarlayın parallelism=2, ) h = ph.hash("LabParola!2026") print(h) print(ph.verify(h, "LabParola!2026")) try: ph.verify(h, "yanlis") except VerifyMismatchError: print("mismatch ok") print("needs_rehash", ph.check_needs_rehash(h)) PY

[center][/center]

Parametreleri seçerken: giriş başına CPU/RAM maliyeti kabul edilebilir olmalı; brute-force ise pahalı olmalı. OWASP cheat sheet güncel parametre önerilerini kontrol edin (donanım yıllarına göre değişebilir).

5) Uygulama Akışı
Kod:
# Kayıt hash = ph.hash(password) db.save(user, password_hash=hash) # Giriş if ph.verify(user.password_hash, password): if ph.check_needs_rehash(user.password_hash): user.password_hash = ph.hash(password) db.save(user) login_success() else: login_fail() # sabit zamanlı mesaj; kullanıcı var/yok sızdırmayın

Kod:
# YANLIŞ hashlib.sha256(password.encode()).hexdigest() # YANLIŞ base64.b64encode(password.encode()) # YANLIŞ AES_encrypt(password, server_key) # parola saklama için KDF tercih edilir

Migrasyon: Eski SHA-256 kullanıcıları giriş yaptığında yeni Argon2id'ye yükseltin (transparent rehash). Toplu "hepsini bir gecede dönüştür" için eski hash'leri bilemiyorsanız kullanıcı parola sıfırlama gerekebilir.

6) Ek Kontroller
  • Kayıt/şifre değişiminde uzunluk ve breached password kontrolü (Have I Been Pwned Pwned Passwords API, k-anonymity)
  • Rate limit + MFA
  • Password reset token'ları tek kullanımlık ve kısa ömürlü
  • Loglarda parola ve hash yazmayın
  • Yedekleri şifreleyin; DB erişimini least privilege yapın

Kod:
# Pwned Passwords k-anonymity fikri (kavramsal) # SHA-1(parola)'nın ilk 5 karakterini API'ye gönder, sonek listesinde ara # Parolanın tamamını göndermeyin

[center][/center]

7) İleri Seviye
Passkey / WebAuthn: Parola yerine phishing-resistant kimlik doğrulama. Parola yükünü azaltır.

Composition policy: NIST SP 800-63B, karmaşık zorunlu karakter setlerinden ziyade uzunluk + blacklist (yaygın/parola sızıntısı) vurgular. Kurum politikanızı güncel rehberlerle hizalayın.

HSM / KMS pepper: Pepper'ı uygulama belleğinden ayrı tutmak ihlal etkisini azaltır.

Kod:
# Rapor / mimari not dili Parola saklama: Argon2id (argon2-cffi), time_cost=3, memory_cost=65536, parallelism=2 Salt: kütüphane tarafından unique Pepper: yok/var (KMS) Migrasyon: SHA-256 -> Argon2id on-login

8) Sonuç
Parolaları Base64 veya düz SHA ile saklamayın. Unique salt + Argon2id (veya bcrypt) + dengeli parametreler + MFA temel pakettir. Sızıntı olsa bile iyi parolaların toplu kırılmasını zorlaştırmak hedeflenir.



Ek: Operasyonel Senaryolar
Sızıntı sonrası: Tüm oturumları iptal edin, kullanıcıları bilgilendirin (KVKK süreçleri), zorla parola yenileme veya "girişte rehash + MFA zorunlu" uygulayın. Hash algoritmanız zayıfsa aciliyet artar.

Eski mobil uygulama: Eski istemci hâlâ SHA-1 hash gönderiyorsa sunucu tarafında kabul etmeyin; protokolü yükseltin.

Kod:
# Doğrulama maliyeti ölçümü (lab) python3 - <<'PY' import time from argon2 import PasswordHasher ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=2) t0=time.time(); ph.hash("x"*12); print("hash_s", round(time.time()-t0,3)) PY

Hedef: meşru girişte yüzlerce ms kabul edilebilir; kitle brute-force'ta ise pahalı. Aşırı yüksek maliyet DoS'a dönüşebilir; login rate limit ile birlikte düşünün.

[center][/center]

Unutmayın: Teknik KDF doğru olsa bile kullanıcı "123456" seçerse risk devam eder; breached password engeli ve passkey geçişi tamamlayıcıdır.



Ek Lab Komutları
Kod:
# bcrypt maliyeti karşılaştırması python3 - <<'PY' import bcrypt, time for r in (10, 12, 14): t=time.time(); bcrypt.hashpw(b"x", bcrypt.gensalt(r)); print(r, round(time.time()-t,3),"s") PY

Kod:
# Argon2 parametre dizesini okuma python3 - <<'PY' from argon2 import PasswordHasher h=PasswordHasher().hash("demo") print(h.split("$")[:5]) PY

Kod:
# Secrets ile salt üretimi (elle saklama senaryosu - genelde kütüphane yapar) python3 -c "import secrets; print(secrets.token_bytes(16).hex())"

Kaynakça
Yasal Uyarı
Bu içerik savunma ve güvenli yazılım geliştirme içindir. Başkalarına ait parola hash'lerini izinsiz kırmaya çalışmak veya sistemlere yetkisiz girmek TCK 243-245 kapsamında suç olabilir. Lab parolalarını üretimde kullanmayın; sorumluluk uygulayana aittir.

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
   
 ISC2 CC Sertifikası 2026: Yeni Sınav Formatı, Beş Alan ve Çalışma Planı Rehberi
Tonyukuk 10-18-2026, 06:03 PM · Sertifikalar
0 30
[Resim: attachment.php?aid=237]

Merhaba arkadaşlar,

Siber güvenliğe sıfırdan girenlerin "ilk sertifikam ne olsun?" sorusuna en çok verilen cevaplardan biri ISC2'nin Certified in Cybersecurity (CC) sertifikasıdır. Giriş seviyesi, deneyim şartı aramayan ve dünya çapında tanınan bir ISC2 üyeliği kapısı. 1 Eylül 2026 itibarıyla sınav içeriği güncellendi ve ISC2'nin "One Million Certified in Cybersecurity" ücretsiz programı 20 Mayıs 2026'da yeni kayıtlara kapandı. Bu rehberde CC'nin güncel sınav formatını, beş bilgi alanını ve resmi kaynaklara dayalı bir çalışma planını anlatıyorum.

Konuda Anlatılacaklar
  1. CC nedir, kime uygundur?
  2. Ücretsiz program durumu ve ücretlendirme
  3. Sınav formatı (CAT) ve geçme skoru
  4. 2026 güncel beş alan ve ağırlıkları
  5. Her alanda ne çalışılmalı?
  6. Çalışma planı ve kaynaklar
  7. CC sonrası: deneyim ve kariyer adımı

CC Nedir, Kime Uygundur?

CC, ISC2'nin siber güvenlik temelleri sertifikasıdır. Hedef kitlesi; öğrenciler, kariyer değiştirenler ve BT'den güvenliğe geçmek isteyenlerdir. Sınava girmek için deneyim şartı yoktur. Sınavı geçip ISC2 üyesi olduğunuzda, ileride CISSP veya CCSP gibi ileri sertifikalara giden yolun ilk basamağını atmış olursunuz. ISC2'nin açıklamasına göre programın sonuna kadar 65 binden fazla kişi CC sertifikası kazandı.

Ücretsiz Program Durumu ve Ücretlendirme

ISC2'nin resmi duyurusuna göre "One Million Certified in Cybersecurity" programı 20 Mayıs 2026'da yeni kayıtlara kapandı. Elinde süresi dolmamış bir sınav kodu olanlar 31 Aralık 2026'ya kadar sınava girebilir. Bu tarihten sonra CC sınavı ve eğitimi, diğer ISC2 sınavları gibi ücretlidir. Resmi fiyatlandırmaya göre tek başına sınav ücreti çoğu bölgede 199 ABD dolarıdır. Yani artık "bedava sertifika" beklentisiyle değil, ücretli ama erişilebilir bir giriş sertifikası olarak planlamak gerekiyor.

[Resim: attachment.php?aid=238]

Sınav Formatı (CAT) ve Geçme Skoru

ISC2'nin Computerized Adaptive Testing (CAT) sayfasına göre CC sınavı artık uyarlamalı (adaptive) formattadır:
  • Soru sayısı: 100-125 arası (25'i puanlanmayan ön test sorusu; en az 75 puanlanan soru yanıtlanır).
  • Süre: en fazla 2 saat.
  • Geçme skoru: 1000 üzerinden 700.
  • Soru tipi: çoktan seçmeli.

Uyarlamalı sınavda her doğru/yanlış cevap sonraki sorunun zorluğunu etkiler; bu yüzden "sona bırakıp geri döneme" alışkanlığı burada işlemez, her soruya o an karar verirsiniz.

2026 Güncel Beş Alan ve Ağırlıkları

ISC2, 1 Eylül 2026'da yürürlüğe giren güncel sınav taslağında (exam outline) alan adlarını yeniledi. Güncel beş alan ve ağırlıkları:
  • Domain 1 - Security Principles: %24
  • Domain 2 - Security Governance: %17,3
  • Domain 3 - Identity and Access Management (IAM) Concepts: %20
  • Domain 4 - Networking and Cloud Security Concepts: %21,3
  • Domain 5 - Security Operations and Incident Response: %17,3

En büyük değişiklik, yönetişim (governance) konularının ayrı ve ağırlıklı bir alana taşınması; olay müdahalesinin de Domain 5'in önemli bir parçası haline gelmesidir. Eski taslaktaki "Access Controls" alanı, "Identity and Access Management (IAM) Concepts" olarak; "Network Security" ise bulut konularını da kapsayacak şekilde "Networking and Cloud Security Concepts" olarak yeniden adlandırıldı.

[Resim: attachment.php?aid=239]

Her Alanda Ne Çalışılmalı?

Domain 1 - Security Principles: CIA üçlüsü (gizlilik, bütünlük, erişilebilirlik), kimlik doğrulama/yetkilendirme, inkar edilemezlik, mahremiyet, risk yönetimi temelleri, güvenlik kontrolü türleri, ISC2 etik kuralları.

Domain 2 - Security Governance: Politika, standart, prosedür ve kılavuz farkı; yasa ve düzenlemelere uyum; iş sürekliliği (BC), felaket kurtarma (DR) kavramları.

Domain 3 - IAM: Kimlik yaşam döngüsü, kimlik doğrulama faktörleri, çok faktörlü kimlik doğrulama (MFA), en az yetki ve görevler ayrılığı, erişim denetim modelleri (RBAC, DAC, MAC), fiziksel ve mantıksal erişim.

Domain 4 - Networking and Cloud Security: OSI/TCP-IP modelleri, yaygın portlar ve protokoller, güvenlik duvarları, IDS/IPS, VPN, bulut hizmet modelleri (IaaS/PaaS/SaaS) ve paylaşımlı sorumluluk.

Domain 5 - Security Operations and Incident Response: Şifreleme temelleri, veri yönetimi, yapılandırma yönetimi, farkındalık eğitimi, olay müdahale yaşam döngüsü, loglama ve izleme.

Kavramları pekiştirmek için evde küçük denemeler yapabilirsiniz. Örneğin erişim denetimi kavramını Linux izinleriyle somutlaştırmak (yalnızca kendi dosyalarınızda):

Kod:
touch gizli.txt chmod 600 gizli.txt # en az yetki: sadece sahip okur/yazar ls -l gizli.txt getfacl gizli.txt 2>/dev/null

Veya şifreleme (gizlilik) ile özet (bütünlük) farkını görmek:

Kod:
echo "ISC2 CC" | openssl enc -aes-256-cbc -pbkdf2 -a # geri cozulebilir sifreleme echo -n "ISC2 CC" | sha256sum # tek yonlu butunluk ozeti

Çalışma Planı ve Kaynaklar

4-6 haftalık bir plan çoğu aday için yeterlidir:

Kod:
Hafta 1: Domain 1 (Security Principles) + ISC2 etik kurallari Hafta 2: Domain 2 (Governance) + Domain 3 (IAM) Hafta 3: Domain 4 (Networking & Cloud) Hafta 4: Domain 5 (Security Operations & Incident Response) Hafta 5: Resmi exam outline uzerinden eksik kapatma Hafta 6: Deneme sorulari + zayif alan tekrari

Birincil kaynak olarak ISC2'nin güncel CC Exam Outline belgesini kullanın; çalıştığınız her konuyu bu taslaktaki maddelerle eşleştirin. ISC2'nin resmi self-paced eğitimi ve ücretsiz/ücretli deneme soruları ikincil kaynaklardır. Türkçe kaynaklara ek olarak kavramların İngilizce terimlerini de öğrenin; sınav İngilizce ağırlıklıdır.

[Resim: attachment.php?aid=240]

İleri Seviye: CC Sonrası Deneyim Şartı

Sınavı geçmek sizi "ISC2 Candidate" yapar. Tam CC üyeliği için ISC2 Etik Kurallarını kabul etmeniz ve yıllık üyelik aidatını (AMF) ödemeniz gerekir. CC'nin, CISSP gibi ileri sertifikaların aksine ek bir çalışma deneyimi şartı yoktur; bu yüzden gerçekten giriş seviyesidir. CC'den sonraki mantıklı adımlar, ilgi alanınıza göre SSCP (operasyon), CCSP (bulut) ya da uzun vadede CISSP olabilir. Sertifika tek başına iş getirmez; onu bir lab portföyü (kendi projeleriniz, CTF çözümleriniz) ile birleştirin.

Sonuç

CC, deneyim şartı olmadan girilebilen, dünya çapında tanınan ve güncel içeriğiyle temelleri sağlam öğreten bir giriş sertifikası. 2026 itibarıyla ücretsiz program kapandığı için ücretli planlamak, güncel beş alanı resmi exam outline üzerinden çalışmak ve kavramları küçük lab denemeleriyle pekiştirmek en verimli yol. Siz ilk sertifika olarak CC'yi mi yoksa başka bir seçeneği mi düşünüyorsunuz? Yorumlarda tartışalım.

Kaynakça
Yasal Uyarı

Bu rehberdeki komutlar yalnızca kendi bilgisayarınızda, kendi dosyalarınız üzerinde öğrenme amacıyla çalıştırılmalıdır. Başkalarına ait sistemlere izinsiz erişim 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

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
               
 Ahold Delhaize Siber Olayı: Albert Heijn, Delhaize ve Stop & Shop Sistemleri Kapalı
Tonyukuk 10-18-2026, 06:00 PM · Siber Güvenlik Haberleri
0 44
[Resim: attachment.php?aid=236]

Selam arkadaşlar,

Avrupa ve ABD'nin en büyük gıda perakendecilerinden Ahold Delhaize, 11 Ekim pazar günü yaşadığı bir siber güvenlik olayı nedeniyle bazı sistemlerini kendi eliyle kapattı. Mağazalar açık kaldı, ama web siteleri, mobil uygulamalar, çevrimiçi sipariş ve müşteri hizmetleri günlerce çalışmadı. Hollanda'nın en büyük zinciri Albert Heijn'de dağıtım merkezleri aksadı, bazı mağazalarda manav reyonları boş kaldı. Bir haftaya yaklaşan kesinti, perakendede siber olayların raflara kadar nasıl yansıdığını çok net gösteriyor.

Konuda Anlatılacaklar
  1. Ahold Delhaize kimdir?
  2. Ne oldu? Zaman çizelgesi
  3. Hangi markalar ve hizmetler etkilendi?
  4. Şirket ne açıkladı, ne açıklamadı?
  5. Hollanda Adalet Bakanı'nın çağrısı
  6. 2024'teki fidye yazılımı saldırısı
  7. Perakende ve lojistik için dersler
  8. Kaynaklar

Ahold Delhaize Kimdir?

BleepingComputer'ın aktardığına göre Ahold Delhaize, Avrupa, ABD ve Endonezya'da 9.400'den fazla mağaza işleten, yaklaşık 400 bin kişiyi istihdam eden ve her hafta yaklaşık 60 milyon müşteriye hizmet veren bir grup. Şirketin 2024 yıllık net satışları 104 milyar doları aştı.

Grubun markaları arasında Avrupa'da Albert Heijn, Delhaize, Maxi, Mega Image, Albert, bol, Alfa Beta, Etos, Gall & Gall ve Profi; ABD'de ise Food Lion, Stop & Shop, Giant Food ve Hannaford var. Yani bu, tek bir zincirin değil, iki kıtaya yayılmış bir perakende ağının olayı.

Zaman Çizelgesi

Kaynaklardan derlediğim sıralama şöyle:
  • 11 Ekim (pazar): Olay başladı. Reuters'a göre kesinti bu tarihte başladı; Brussels Times da olayın pazar günü yaşandığını aktarıyor.
  • 12 Ekim (pazartesi): Şirket kısa bir açıklamayla "ağında bir güvenlik sorunu" yaşadığını, bazı sistemleri korumak için çevrimdışı aldığını ve mağazaların açık olduğunu duyurdu.
  • 13 Ekim: Şirket güncelleme yayımlayarak bazı sistemlerin kontrollü şekilde yeniden devreye alınmasına başlandığını söyledi. Açıklama 14 Ekim'de güncellendi.
  • 16 Ekim (cuma): Reuters, web siteleri ve çevrimiçi teslimatın beşinci gününde hâlâ kapalı olduğunu yazdı. Hollanda Adalet Bakanı şirketi suç duyurusunda bulunmaya çağırdı.
  • 17 Ekim (cumartesi): Delhaize, çevrimiçi sipariş hizmetinin tamamen yeniden çalıştığını duyurdu. Albert Heijn ise çevrimiçi sipariş ve eve teslimatın en erken salıya kadar kapalı kalacağını açıkladı.



Hangi Markalar ve Hizmetler Etkilendi?

Hollanda ve Belçika:
BleepingComputer'a göre Hollanda'da Albert Heijn, Etos ve Gall & Gall, Belçika'da ise Delhaize müşterileri web sitelerini, uygulamaları ve müşteri hizmetleri platformlarını kullanamadı. Reuters, Albert Heijn'de kesintinin dağıtım merkezlerini aksattığını ve manav reyonlarının boşalmasına yol açtığını aktarıyor.

Brussels Times'ın Delhaize sözcüsü Roel Dekelver'e dayanarak verdiği bilgiler, işin operasyonel boyutunu çok iyi anlatıyor:
  • Delhaize mağazaları kendi siparişlerini cumadan itibaren yeniden verebiliyor, ama bunu eski bir sistem üzerinden yapıyor. Normal sipariş sistemi hâlâ kullanılamıyor.
  • Hafta başında mağazalara yapılan teslimatlar, önceki hafta ve ayların sipariş desenlerine göre planlandı.
  • Sadakat kartı sahiplerine sunulan haftalık kişisel kampanyalar (e-Deals) hâlâ geçici olarak kullanılamıyor.

ABD:
BleepingComputer'a göre Stop & Shop çalışanları vardiya programlarına ve maaş bordrolarına erişmekte zorlandı. Food Lion çalışanlarının paylaştığı bir iç notta olay "BT kesintisi" olarak tanımlanmış ve mağazaların siparişleri hazırlayamayabileceği, teslim edemeyebileceği belirtilmiş. Reuters, ABD markalarının (Stop & Shop, Giant Food, Hannaford, Food Lion) toplu olarak ülkenin en büyük gıda perakendecilerinden birini oluşturduğunu hatırlatıyor; ancak şirket sözcüsü ana şirketin tek tek zincirlerdeki duruma yorum yapamayacağını söylüyor.

Şirket Ne Açıkladı, Ne Açıklamadı?

Şirketin 13 Ekim tarihli, 14 Ekim'de güncellenen açıklamasının ana noktaları:
  • Ağında bir siber güvenlik sorunu yaşıyor ve önlem olarak bazı sistemleri çevrimdışı aldı.
  • İç ekipler ve dış siber güvenlik uzmanlarıyla çalışıyor, ilgili makamlarla temas halinde.
  • Soruşturma sürdüğü için güvenlik önlemlerini tehlikeye atabilecek ayrıntıları paylaşmıyor.
  • Şu an için müşteri, çalışan ve iş ortağı verisinin alındığına dair bir kanıt bulunmadığını söylüyor.
  • Önlemlerin etkisi markadan markaya farklılık gösteriyor.

Açıklanmayanlar ise en az açıklananlar kadar önemli:
  • Olayın türü: fidye yazılımı mı, başka bir saldırı mı?
  • Herhangi bir cihazın şifrelenip şifrelenmediği. BleepingComputer bunu sorduğunda şirket sözcüsü yalnızca resmi açıklamayı işaret etti.
  • Saldırganın sisteme nasıl girdiği.
  • Herhangi bir grubun olayı üstlenip üstlenmediği.

Dikkatli okursanız, şirketin ifadesi "veri alınmadı" değil, "veri alındığına dair şu an kanıt yok". Soruşturma sürerken bu iki ifade arasındaki fark önemli.

Hollanda Adalet Bakanı'nın Çağrısı

Reuters'ın aktardığına göre Hollanda Adalet Bakanı David van Weel, 16 Ekim'de şirketi olay için suç duyurusunda bulunmaya çağırdı. Bakan, Hollanda haber ajansı ANP'ye şunları söyledi: Böyle bir şirketin ilk anda sistemlerine gelecek zararı önlemeye odaklanmasını anlıyor; ama artık "daha sakin sulara" girildiğini ve bu adımı atmanın zamanının geldiğini düşünüyor.

Reuters ayrıca şirketin olayı "hack" olarak nitelendirmekten kaçındığını not ediyor. Şirket sözcüsü bakanın sözlerine yanıt veremeyeceğini söyleyip 14 Ekim tarihli açıklamaya atıfta bulundu.

2024'teki Fidye Yazılımı Saldırısı

Bu, Ahold Delhaize'nin son yıllarda yaşadığı ilk büyük siber olay değil. BleepingComputer'a göre Kasım 2024'te şirketin ABD sistemlerini etkileyen ve INC Ransom fidye yazılımı grubunun üstlendiği saldırıda 2,2 milyondan fazla kişinin kişisel, finansal ve sağlık bilgileri çalınmıştı. Bu geçmiş, şirketin bu kez iletişimde neden temkinli davrandığını kısmen açıklayabilir; ama yeni olayın 2024 saldırısıyla bir bağlantısı olduğuna dair kaynaklarda bilgi yok.



Perakende ve Lojistik İçin Dersler

Bu olay teknik ayrıntıları bilinmese de operasyonel açıdan çok şey öğretiyor:

1. "Mağazalar açık" yetmiyor. Kasalar çalışsa bile sipariş, stok ve dağıtım planlaması merkezi sistemlere bağlıysa raflar birkaç gün içinde boşalıyor. Delhaize'nin geçmiş sipariş desenlerine göre teslimat planlaması, iyi düşünülmüş bir geçici çözüm ama ancak birkaç gün idare ediyor.

2. Eski sistemi atmayın, hazır tutun. Delhaize mağazalarının siparişleri eski bir sistem üzerinden verebilmesi, kesintinin süresini kısalttı. Ana sistem çöktüğünde devreye alınabilecek, test edilmiş bir yedek süreç altın değerinde.

3. Önleyici kapatma kararı maliyetlidir ama bazen doğrudur. Şirket sistemleri "korumak için" kendisi kapattı. Saldırının yayılmasını durdurmak için bu sık başvurulan bir yöntem; ama kararın etkisini önceden simüle etmemiş bir kurum, kapatmanın kendisinin saldırıdan daha fazla zarar verdiğini görebilir. Hangi sistemin hangi sırayla kapatılıp açılacağı olay müdahale planında yazılı olmalı.

4. İletişim stratejisi baştan belirlenmeli. Şirketin temkinli dili, Hollanda'da siyasi tepkiye dönüştü. Kamuya ve müşterilere ne zaman, ne kadar bilgi verileceği olay anında değil, önceden kararlaştırılmalı.

5. Çalışan sistemleri de kritik. Vardiya ve bordro sistemlerine erişilememesi, binlerce çalışanı doğrudan etkiliyor. Bu sistemler genelde "kritik" listesinde yer almaz, ama olay anında operasyonun devamı için en az e-ticaret kadar önemli.

Çevrimiçi sipariş, sadakat programı ve merkezi stok sistemi kullanan her perakendeci için soru aynı: Sizin çalıştığınız ya da danışmanlık verdiğiniz yerlerde merkezi sistem bir hafta dursa mağazalar nasıl tedarik edilir, hiç tatbikatı yapıldı mı? Yorumlarda konuşalım.

Kaynaklar
Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 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
   
 Arch Linux AUR'da Sahte yay ve paru Paketleri: Kurulumda Root Yetkisiyle Zararlı Kod
Tonyukuk 10-18-2026, 05:37 PM · Siber Güvenlik Haberleri
0 40
[Resim: attachment.php?aid=235]

Selam arkadaşlar,

Arch kullanan arkadaşlar, bu konu doğrudan sizi ilgilendiriyor. Arch User Repository'de (AUR) en popüler iki AUR yardımcısı olan yay ve paru adlarını taklit eden sahte paketler tespit edildi. Bu paketler kurulum ya da güncelleme sırasında internetten bir betik indirip root yetkisiyle çalıştırıyordu. Paketler kısa sürede kaldırıldı ama AUR'un bu yıl yaşadığı üçüncü büyük olay olması nedeniyle konuyu detaylı ele almak istedim.

Konuda Anlatılacaklar
  1. Ne oldu, nasıl tespit edildi?
  2. Sahte paketler nasıl çalışıyordu?
  3. Zararlı yükün kaynağı
  4. AUR'un 2026'daki olay geçmişi
  5. Sisteminizi nasıl kontrol edersiniz?
  6. AUR'u güvenli kullanmak için alışkanlıklar
  7. Kaynaklar

Ne Oldu?

BleepingComputer ve Help Net Security'nin aktardığına göre sahte paketler 13 Ekim'de tespit edildi. Paketleri "marchos1as" adlı bir kullanıcı yüklemişti ve isimler yay ile paru'nun yazım hatalı varyasyonlarıydı; örneğin "yyay". Bu teknik typosquatting olarak biliniyor: Hızlı yazarken bir harfi fazla ya da eksik basan kullanıcıyı hedefliyor.

Olayın tespit ve müdahale süreci, topluluğun ne kadar hızlı reaksiyon gösterebildiğini de gösteriyor:
  • James Smith, durumu aur-general e-posta listesine bildirdi.
  • Andreas Reichel paketleri analiz etti.
  • Emiliano Gandini Outeda, TrustSight aracıyla sahte paketleri tespit etti.
  • AUR bakımcılarından DeepChirp, kullanıcıyı yasakladı ve paketleri yaklaşık bir saat içinde sildi.

Bir saatlik müdahale süresi gayet iyi; ama bu sürede paketi kuran herkes etkilenmiş olabilir.

Sahte Paketler Nasıl Çalışıyordu?

Burada saldırganın kurnazca bir tasarım yaptığını görüyoruz. Raporlara göre sahte paketler:
  • Meşru yay kaynak kodunu kullanıyordu. Yani paket kurulduğunda gerçekten çalışan bir yay elde ediyordunuz; kullanıcı bir terslik fark etmiyordu.
  • Pakete zararlı bir install betiği (install scriptlet) eklenmişti.
  • Betik içindeki kurulum fonksiyonları boş bırakılmış, zararlı komut ise bu fonksiyonların dışına yerleştirilmişti. Bu, PKGBUILD ve install dosyasına hızlıca göz atan birinin fonksiyonların içine bakıp "boş, sorun yok" demesini sağlamaya yönelik bir gizleme yöntemi.
  • pacman paketi kurduğunda ya da güncellediğinde, bu komut linux.sh adlı bir betiği indirip root olarak çalıştırıyordu.

Kritik nokta şu: makepkg derleme aşamasında root yetkisi kullanmaz, ama pacman paket kurulumunu root olarak yapar. install betikleri de pacman tarafından çalıştırıldığı için, derleme aşamasında temiz görünen bir paket kurulum aşamasında sisteminizin tamamını ele geçirebilir.



Zararlı Yükün Kaynağı

BleepingComputer'a göre zararlı betik, doğrudan bir sunucudan değil, Wayback Machine (Internet Archive) üzerinden indiriliyordu. Arşivlenmiş URL, gitflic.ru üzerindeki "hellscripter/install-scripts" deposuna işaret ediyordu. Wayback Machine gibi meşru ve yaygın bir alan adını kullanmak, basit alan adı tabanlı engelleme ve itibar kontrollerini atlatmaya yönelik bilinen bir taktik.

Kaynaklarda bu olayın npm ekosistemindeki "DirtyBlanket" kampanyasıyla (SafeDep'in raporladığı, CHAOS RAT dağıtan kampanya) bağlantılı olabileceği konuşuluyor; ancak bu bağlantı doğrulanmış değil. Ben de kesin bilgi olarak aktarmıyorum.

AUR'un 2026'daki Olay Geçmişi

Bu, AUR'un bu yıl yaşadığı ilk olay değil:
  • Haziran: Büyük çaplı bir zararlı paket dalgası yaşandı. Help Net Security yaklaşık 1.500 paketten, BleepingComputer ise 400 paketten bahsediyor; kaynaklar arasında rakam farkı var.
  • Temmuz: Yeni bir olayın ardından sahipsiz paketlerin devralınması (adoption) askıya alındı ve yeni yüklemeler durduruldu.
  • Ekim: Sahte yay/paru paketleri.

AUR'un tasarımı gereği kullanıcı tarafından yüklenen, resmi olarak denetlenmeyen paketlerden oluştuğunu unutmamak gerekiyor. Arch Wiki de AUR paketlerinin kullanıcının kendi sorumluluğunda olduğunu her zaman vurgular. Ama popüler araçların adını taklit eden paketlerin sık sık ortaya çıkması, topluluğun ve bakımcıların üzerindeki yükü artırıyor.

Sisteminizi Nasıl Kontrol Edersiniz?

AUR'dan ya da resmi depolar dışından kurulmuş tüm paketleri listeleyin:
Kod:
pacman -Qm

Çıktıda yay veya paru'ya benzeyen ama tam olarak o isimde olmayan bir paket arayın:
Kod:
pacman -Qm | grep -iE "y+a+y|p+a+r+u"

Bu arama "yay", "yay-bin", "paru", "paru-bin" gibi meşru paketleri de gösterecektir; önemli olan beklemediğiniz, yazım hatalı bir isim görüp görmediğiniz. Şüpheli bir paket bulursanız, hangi tarihte kurulduğunu pacman logundan kontrol edin:
Kod:
grep -iE "installed|upgraded" /var/log/pacman.log | grep -iE "y+a+y|p+a+r+u"

Kurulu bir paketin install betiğini görmek için paket veritabanındaki ilgili dizine bakabilirsiniz:
Kod:
ls /var/lib/pacman/local/ | grep -iE "y+a+y|p+a+r+u"

Önemli: Sahte paketlerden birini kurduğunuzu tespit ederseniz, paketi kaldırmak yeterli değil. Betik root olarak çalıştığı için sistemde ne yaptığını bilemezsiniz. Kaynakların da önerdiği gibi sistemi ele geçirilmiş kabul edin: önemli verilerinizi yedekleyin (yedekleri temiz bir sistemde inceleyin), sistemi sıfırdan kurun ve o sistemde kullanılan tüm parola, SSH anahtarı ve token'ları değiştirin.



AUR'u Güvenli Kullanmak İçin Alışkanlıklar
  • Paket adını iki kez kontrol edin. Özellikle "yay" gibi kısa isimlerde bir harf farkı fark edilmeyebilir.
  • PKGBUILD ve install dosyasını okuyun. AUR yardımcıları kurulumdan önce bu dosyaları gösterir; "geç" demek yerine gerçekten okuyun. Fonksiyonların dışındaki satırlara, curl/wget ile indirilip çalıştırılan komutlara ve kodlanmış (base64 vb.) içeriklere dikkat edin.
  • Paketin geçmişine bakın. AUR sayfasında paketin ne zaman oluşturulduğunu, kaç oy aldığını ve bakımcısının kim olduğunu kontrol edin. Yeni açılmış, oy almamış bir paket ile yıllardır kullanılan paket aynı güveni hak etmez.
  • yay/paru'yu ilk kurulumda resmi talimatla kurun. Bu araçların kendi depolarındaki kurulum talimatını takip edin; arama sonuçlarındaki ilk paketi körü körüne seçmeyin.
  • Güncelleme sırasında da dikkatli olun. Bu olayda zararlı kod güncelleme sırasında da çalışıyordu; yardımcı aracınızın güncellemelerde diff göstermesini etkinleştirin.

AUR, Arch'ı Arch yapan şeylerden biri; ama "kullanıcı deposu" olduğunu unutmamak lazım. Siz AUR paketlerini kurmadan önce PKGBUILD'i ne sıklıkla okuyorsunuz? Dürüst cevaplarınızı yorumlarda bekliyorum.

Kaynaklar
Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 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
   
 Nikto ve WhatWeb ile Web Sunucu Keşfi: Uygulamalı Rehber
0 37
Merhaba TurkTeam,

Bir web hedefine karşı iş yapmadan önce "karşımızda ne var?" sorusunu yanıtlamamız gerekir: Hangi web sunucusu, hangi teknolojiler, hangi sürümler, bilinen yanlış yapılandırmalar ve tehlikeli dosyalar? Bu pasif/aktif keşif için iki klasik araç öne çıkar: teknolojileri parmak izinden tanıyan WhatWeb ve web sunucusunu bilinen sorunlara karşı tarayan Nikto. Bu rehberde ikisini birlikte, resmi kullanımlarına sadık kalarak ele alıyoruz.

Konuda Anlatılacaklar
  1. Web sunucu keşfi nedir, neden ilk adımdır
  2. WhatWeb ve Nikto nedir, farkları
  3. Kurulum
  4. WhatWeb parametre referansı ve uygulama
  5. Nikto parametre referansı ve uygulama
  6. Çıktıları yorumlama ve ileri ipuçları
  7. Sonuç, kaynakça ve yasal uyarı

1. Web Sunucu Keşfi Nedir?
Keşif (reconnaissance), hedef hakkında bilgi toplama aşamasıdır ve bir testin kalitesini doğrudan belirler. Web tarafında bu; sunucu yazılımını (Apache, nginx, IIS), uygulama çatısını (WordPress, Laravel, vb.), kullanılan kütüphaneleri, HTTP başlıklarını, çerez yapılandırmasını ve bilinen riskli dosya/dizinleri ortaya çıkarmayı kapsar. Bu bilgi, sonraki adımları (zafiyet araştırması, hedefli testler) yönlendirir.

2. WhatWeb ve Nikto: Farkları
WhatWeb bir "web teknoloji parmak izi" aracıdır: sayfayı alır, başlıkları ve içerik desenlerini 1800'den fazla eklentiyle eşleştirip hangi teknolojilerin kullanıldığını söyler. Düşük agresiflikte neredeyse pasiftir.

Nikto ise bir "web sunucu zafiyet tarayıcısı"dır: sunucuya binlerce istek göndererek bilinen tehlikeli dosyaları, eski sürümleri, yanlış yapılandırılmış başlıkları ve varsayılan içerikleri arar. Nikto gürültülüdür ve loglarda kolayca görünür; bu yüzden izinli test şarttır.

3. Kurulum
Her ikisi de Kali/Parrot depolarında bulunur:
Kod:
sudo apt update sudo apt install whatweb nikto
Sürümleri doğrulayın:
Kod:
whatweb --version nikto -Version

4. WhatWeb Parametre Referansı ve Uygulama
Temel kullanım:
Kod:
whatweb http://192.168.56.101

-v - Ayrıntılı çıktı (hangi eklenti neyi eşledi):
Kod:
whatweb -v http://192.168.56.101

-a - Agresiflik düzeyi (1 pasif/stealthy, 3 agresif, 4 ağır):
Kod:
whatweb -a 3 http://192.168.56.101

--log-json / toplu tarama:
Kod:
whatweb --log-json=sonuc.json -i hedefler.txt
Örnek bir çıktı satırı şuna benzer:
Kod:
http://192.168.56.101 [200 OK] Apache[2.2.8], PHP[5.2.4], Country[RESERVED][ZZ], HTTPServer[Apache/2.2.8 (Ubuntu) DAV/2]
Buradan sunucunun eski bir Apache ve PHP sürümü çalıştırdığını tek bakışta görürsünüz; bu, bilinen zafiyet araştırması için değerli bir başlangıçtır.
[Resim: attachment.php?aid=232]

5. Nikto Parametre Referansı ve Uygulama
-h - Hedef host/URL:
Kod:
nikto -h http://192.168.56.101

-p - Port (birden çok virgülle):
Kod:
nikto -h 192.168.56.101 -p 80,443,8080

-ssl - HTTPS zorlama:
Kod:
nikto -h https://192.168.56.101 -ssl

-Tuning - Belirli test kategorilerini seçme (örn. 1 dosya, 2 yanlış yapılandırma, 9 SQLi):
Kod:
nikto -h http://192.168.56.101 -Tuning 123b

-o / -Format - Rapor çıktısı:
Kod:
nikto -h http://192.168.56.101 -o rapor.html -Format htm

Örnek bir Nikto bulgusu şöyle görünür:
Kod:
+ Server: Apache/2.2.8 (Ubuntu) DAV/2 + The anti-clickjacking X-Frame-Options header is not present. + /phpinfo.php: Output from the phpinfo() function was found. + OSVDB-3233: /icons/README: Apache default file found.
[Resim: attachment.php?aid=233]
Her satır bir gözlemdir: eksik güvenlik başlıkları, bilgi sızdıran phpinfo.php, varsayılan Apache dosyaları gibi. Bunlar doğrudan "açık" olmayabilir ama saldırı yüzeyini ve yanlış yapılandırmaları gösterir.
[Resim: attachment.php?aid=234]

6. Çıktıları Yorumlama ve İleri İpuçları
  • Önce WhatWeb, sonra Nikto: Teknolojiyi tanıyın, sonra o teknolojiye uygun Nikto ayarlarıyla derinleşin.
  • Yanlış pozitifler: Nikto bulgularını körü körüne "zafiyet" saymayın; her satırı manuel doğrulayın. phpinfo.php varlığı gerçek ve ciddidir, ama bazı OSVDB kayıtları bağlama göre geçersiz olabilir.
  • Gürültü yönetimi: Nikto çok istek üretir; üretim ortamında -Tuning ile kapsamı daraltın ve zamanlamaya dikkat edin.
  • Proxy ile görünürlük: -useproxy ile Burp üzerinden geçirip istek/yanıtları inceleyebilirsiniz.
  • Güncel tutun: Nikto'nun veritabanı güncel olmalı; aracı ve imzalarını güncel tutmak bulgu kalitesini artırır.
İki aracın birlikte verdiği tablo, bir sonraki adıma (örneğin dizin keşfi, CMS'e özel tarayıcılar ya da elle test) sağlam bir zemin oluşturur.

7. Savunma Perspektifi
Keşif araçlarının bulduğu çoğu şey aslında savunma eksiğidir. Sunucu sürüm bilgisini gizlemek (ServerTokens Prod), gereksiz varsayılan dosyaları (README, test sayfaları, phpinfo.php) kaldırmak, güvenlik başlıklarını (X-Frame-Options, Content-Security-Policy, X-Content-Type-Options) eklemek ve yazılımları güncel tutmak, bu araçların döndürdüğü bulguların çoğunu ortadan kaldırır. Yani Nikto/WhatWeb çıktısını bir "yapılacaklar listesi" gibi okumak, savunmacı için en verimli yaklaşımdır.

7.1. İki Aracı Bir İş Akışına Oturtmak
Nikto ve WhatWeb'i tek tek öğrenmek kolaydır; asıl ustalık, onları tutarlı bir iş akışına oturtmaktır. Pratikte sıralama şöyle işler: önce hedefin canlı ve hangi portlarda web servisi sunduğunu bir port taramasıyla (örneğin Nmap) teyit edersiniz. Ardından WhatWeb'i düşük agresiflikle çalıştırıp teknolojiyi, sürümleri ve çatıyı tespit edersiniz. Bu bilgi elinizdeyken Nikto'yu daha bilinçli yaparsınız: HTTPS ise -ssl ekler, standart dışı port varsa -p ile belirtir, ilgisiz test kategorilerini -Tuning ile eler ve raporu dosyaya yazdırırsınız.

Bu araçların en büyük tuzağı, çıktıyı olduğu gibi "bulgu" olarak rapora kopyalamaktır. Profesyonel yaklaşım, her satırı bağlamıyla değerlendirmektir. Örneğin eksik bir X-Frame-Options başlığı gerçek ama düşük önemli bir bulgudur; erişilebilir bir phpinfo.php ise sunucu yolunu, yüklü modülleri ve ortam değişkenlerini sızdırdığı için çok daha ciddidir. Eski bir sunucu sürümü ise tek başına bir açık değildir, ancak o sürüme ait bilinen zafiyetleri araştırmanız için güçlü bir ipucudur. İyi bir testçi, aracın söylediğini doğrulayan, önceliklendiren ve etkisini açıklayan kişidir; aracı yalnızca çalıştıran değil.

Son olarak tekrarlanabilirlik için her taramanın komutunu, zamanını ve çıktısını kaydedin. Bir hedefi haftalar sonra yeniden test ettiğinizde, eski WhatWeb ve Nikto raporlarıyla karşılaştırmak, nelerin düzeltildiğini ve nelerin hâlâ açık olduğunu görmenin en hızlı yoludur. Bu alışkanlık, hem denetim kalitenizi hem de müşteriye sunduğunuz değeri belirgin biçimde artırır.

Sonuç
WhatWeb hedefin "ne" olduğunu, Nikto ise "nerede zayıf olabileceğini" hızlıca gösterir. İkisi birlikte, web keşfinin omurgasını oluşturur. Bulguları her zaman elle doğrulayın, gürültüyü yönetin ve sonuçları ya bir sonraki test adımına ya da savunma iyileştirmelerine dönüştürün. Keşif ne kadar iyi olursa, testin geri kalanı o kadar isabetli olur.

Kaynakça
Yasal Uyarı
Alıntı:Web keşif ve tarama araçları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde kullanılmalıdır. İzinsiz tarama Türk Ceza Kanunu 243-245. maddeleri kapsamında suç oluşturabilir.

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
           
 Hydra ile Çevrimiçi Parola Saldırıları: SSH ve HTTP Form Brute Force
0 30
Selam TurkTeam,

Parola denetiminin iki ayrı dünyası vardır: çevrimdışı (hash kırma) ve çevrimiçi (canlı servise deneme yapma). Bu rehber çevrimiçi tarafa odaklanıyor ve sektörün en bilinen aracı THC-Hydra ile SSH ve HTTP form tabanlı giriş noktalarına karşı kaba kuvvet/sözlük denemelerini uygulamalı anlatıyor. Tüm örnekler yalnızca kendi lab servislerinizde ve yetkili denetimlerde geçerlidir.

Konuda Anlatılacaklar
  1. Çevrimiçi parola saldırısı nedir, çevrimdışından farkı
  2. Hydra nedir, hangi protokolleri destekler
  3. Lab kurulumu ve kelime listeleri
  4. Hydra parametre referansı
  5. Uygulamalı: SSH ve HTTP POST form denemesi
  6. İleri seviye: oran sınırlama, devam ettirme, savunma
  7. Sonuç, kaynakça ve yasal uyarı

1. Çevrimiçi vs Çevrimdışı
Çevrimdışı saldırıda elinizde bir hash vardır ve onu yerelde, hedefle konuşmadan kırarsınız (John/Hashcat). Çevrimiçi saldırıda ise canlı bir servise (SSH, FTP, bir web giriş formu) gerçek giriş denemeleri gönderirsiniz. Çevrimiçi saldırılar çok daha yavaştır, ağ gecikmesine bağlıdır ve tespit edilebilir: başarısız girişler loglanır, hesap kilitleme ve oran sınırlama tetiklenir. Bu yüzden gerçek denetimlerde dikkatli, hedefli ve izinli yapılmalıdır.

2. Hydra Nedir?
THC-Hydra, çok sayıda protokole (ssh, ftp, http-get/post-form, smb, rdp, mysql ve daha fazlası) paralel giriş denemesi yapabilen hızlı bir çevrimiçi parola denetim aracıdır. Paralelliği sayesinde tek tek denemeye göre çok daha verimlidir, ancak bu aynı zamanda hedefe yük bindirir; eşzamanlılığı bilinçli ayarlamak gerekir.

3. Lab Kurulumu ve Wordlist'ler
Kod:
sudo apt update sudo apt install hydra seclists
Pratik için kendi makinenizde bir SSH servisi ve bilinen bir test kullanıcısı kurabilir, ya da Metasploitable2 gibi izole bir lab hedefi kullanabilirsiniz. Kullanıcı ve parola listeleri:
Kod:
ls /usr/share/seclists/Usernames/ ls /usr/share/seclists/Passwords/ # klasik parola listesi ls -l /usr/share/wordlists/rockyou.txt*

4. Hydra Parametre Referansı
-l / -L - Tek kullanıcı / kullanıcı listesi:
Kod:
hydra -l admin ... hydra -L kullanicilar.txt ...

-p / -P - Tek parola / parola listesi:
Kod:
hydra -P /usr/share/wordlists/rockyou.txt ...

-t - Paralel görev sayısı (varsayılan 16; SSH için düşürmek gerekebilir):
Kod:
hydra -t 4 ...

-s - Standart dışı port:
Kod:
hydra -s 2222 ...

-f - İlk geçerli kimlik bulununca dur; -V her denemeyi göster:
Kod:
hydra -f -V ...

-o - Sonuçları dosyaya yaz:
Kod:
hydra -o bulgu.txt ...

5. Uygulamalı Adımlar
Adım 1 - SSH sözlük denemesi. Bilinen bir kullanıcı için parola listesi deneyin (yalnızca kendi lab hedefinizde):
Kod:
hydra -l msfadmin -P /usr/share/wordlists/rockyou.txt -t 4 -f -V ssh://192.168.56.101
SSH el sıkışması pahalı olduğu için -t değerini düşük (4 civarı) tutmak daha kararlı sonuç verir. Hydra parolayı bulunca şuna benzer bir satır yazar:
Kod:
[22][ssh] host: 192.168.56.101 login: msfadmin password: msfadmin
[Resim: attachment.php?aid=229]

Adım 2 - HTTP POST form denemesi. Web giriş formlarında http-post-form modülü kullanılır. Üç alanı iki nokta ile ayırırsınız: yol:POST gövdesi:başarısızlık işareti. ^USER^ ve ^PASS^ yer tutucularını Hydra doldurur:
Kod:
hydra -l admin -P /usr/share/wordlists/rockyou.txt 192.168.56.101 \ http-post-form "/login.php:username=^USER^&password=^PASS^:F=Login failed"
Buradaki F=Login failed, yanıtta bu metin varsa denemenin başarısız sayılacağını belirtir. Doğru metni bulmak için önce tarayıcıda hatalı bir giriş yapıp sunucunun döndürdüğü hata ifadesini (örn. "Invalid credentials") not edin. Alternatif olarak başarı koşulu için S= kullanılabilir.
[Resim: attachment.php?aid=230]

Adım 3 - Gövde ve çerez detayları. Form bir CSRF token veya oturum çerezi istiyorsa, POST gövdesine ilgili alanı ekler ve C=/çerez seçeneğiyle çerezi geçirirsiniz. Doğru POST alan adlarını tarayıcı geliştirici araçlarının "Network" sekmesinden teyit edin; yanlış alan adı tüm denemeleri boşa çıkarır.

6. İleri Seviye ve Savunma
  • Eşzamanlılık ve gecikme: Hesap kilitleme ve tespit riskini azaltmak için -t değerini düşürün; bazı modüllerde denemeler arası bekleme için -W / -c seçenekleri yardımcı olur.
  • Hedefli liste: Devasa listeler yerine, keşifte toplanan bağlama uygun (kurum adı, yıl, sızıntı listeleri) küçük ve akıllı listeler çok daha etkilidir.
  • Birden çok hedef: -M dosya ile birden çok host'u aynı anda test edebilirsiniz.
Savunma tarafı: Çevrimiçi kaba kuvvete karşı en etkili önlemler; güçlü ve benzersiz parolalar, çok faktörlü kimlik doğrulama (MFA), başarısız giriş sınırlama (fail2ban gibi), hesap kilitleme politikaları ve SSH'te parola yerine anahtar tabanlı kimlik doğrulamadır. Bu önlemler devrede olduğunda Hydra tipi saldırılar pratik olarak işe yaramaz hale gelir; bu yüzden denetimin asıl değeri bu kontrollerin eksikliğini ortaya koymaktır.
[Resim: attachment.php?aid=231]

6.1. Neden Çoğu Çevrimiçi Saldırı Başarısız Olur?
Yeni başlayanlar sık sık "Hydra'yı rockyou ile çalıştırdım ama hiçbir şey bulamadım" der. Bunun nedeni genellikle aracın değil, yöntemin yanlış olmasıdır. Çevrimiçi saldırıda milyonlarca parolayı denemek pratikte imkansızdır: her deneme bir ağ turu ve sunucu yanıtı gerektirir, SSH gibi protokollerde el sıkışma pahalıdır ve saniyede yalnızca birkaç deneme yapabilirsiniz. Üstelik modern sistemler fail2ban, hesap kilitleme veya oran sınırlama ile kısa sürede IP'nizi engeller. Dolayısıyla "listeyi büyüt" yaklaşımı değil, "listeyi akıllı seç" yaklaşımı kazandırır.

Profesyonel bir denetimde doğru sıralama şudur: önce keşif (hangi kullanıcı adları gerçekten var, kurumun parola politikası ne, sızıntı veritabanlarında bu kuruma ait kimlik var mı), sonra bu bağlama göre küçük ve hedefli bir liste, en sonunda düşük eşzamanlılıkla dikkatli bir deneme. Çoğu zaman tek bir zayıf veya varsayılan parola (admin/admin, root/toor, kurum adı + yıl gibi) tüm kapıyı açar; dev listeler ise yalnızca gürültü üretir ve sizi engelletir.

Bir diğer sık hata, HTTP form modülünde yanlış "başarısızlık işareti" belirlemektir. F= ile verdiğiniz metin yanıtta her zaman görünüyorsa Hydra hiçbir denemeyi başarılı saymaz; hiç görünmüyorsa her denemeyi başarılı sanır. Bu yüzden önce elle bir hatalı ve bir doğru giriş yapıp yanıtların farkını net görmek, modülü doğru kurmanın anahtarıdır.

Sonuç
Hydra, çevrimiçi parola denetiminde hızlı ve esnek bir araçtır; gücü protokol çeşitliliği ve paralelliğinde yatar. Ancak çevrimiçi saldırılar gürültülü ve tespit edilebilirdir; başarı büyük ölçüde doğru kullanıcı/parola listesi ve doğru modül yapılandırmasına bağlıdır. Her zaman yetki dahilinde, hedefi yormadan ve bulguları savunma önerilerine (MFA, anahtar tabanlı giriş, fail2ban) dönüştürerek çalışın.

Kaynakça
Yasal Uyarı
Alıntı:Çevrimiçi parola denemeleri yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde yapılmalıdır. İzinsiz giriş denemeleri 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
           
 OpenBSD Çekirdeğinde 37 Yıllık shmat Açığı: KARL, SMAP ve SMEP Aşılarak Root Alındı
Tonyukuk 10-18-2026, 05:31 PM · Siber Güvenlik Haberleri
0 30
[Resim: attachment.php?aid=228]

Selam arkadaşlar,

"Güvenlik odaklı işletim sistemi" denince akla ilk gelen isimlerden olan OpenBSD için bu hafta ilginç bir araştırma yayımlandı. Güvenlik firması Calif, OpenBSD 7.9'da yerel bir kullanıcının root yetkisi almasını sağlayan bir istismar zinciri yayımladı. Zincirin başlangıç noktası, kökleri yaklaşık 37 yıl öncesine, orijinal BSD kaynak kodlarına uzanan bir tam sayı taşması. İyi haber: Her iki açık da eylülde yamalandı. Kötü haber: Tam çalışan kavram kanıtı (PoC) kodu artık herkese açık; yani syspatch'i ihmal edenler için risk artık teorik değil.

Konuda Anlatılacaklar
  1. Ne yayımlandı?
  2. 37 yıllık sayaç: hata nereden geliyor?
  3. Zincir nasıl çalışıyor? (Üst düzey bakış)
  4. Neden "reliability fix" etiketi önemli?
  5. Düzeltmeler ve errata numaraları
  6. Sisteminizi nasıl kontrol edersiniz?
  7. Calif'in önerdiği sıkılaştırmalar
  8. Kaynaklar

Ne Yayımlandı?

Calif araştırmacısı Andrew Griffiths, 16 Ekim 2026'da "Big Fish" başlıklı bir yazı yayımladı. Calif'e göre şirket bu yılın başlarında OpenBSD'ye bazı açıkları, çoğunlukla önerilen yamalarla birlikte bildirmiş. The Hacker News'in aktardığına göre Calif, OpenBSD her iki açık için de eylülde yama yayımladıktan sonra ayrıntılı teknik yazıyı ve tam PoC kodunu kamuya açtı; kod GitHub'da bulunuyor.

Temel bilgiler:
  • Etki: Yerel ayrıcalık yükseltme (local privilege escalation), root yetkisi
  • Test edilen sürüm: OpenBSD 7.9
  • Atlatılan korumalar: KARL (çekirdek adres rastgeleleştirme), SMAP ve SMEP donanım korumaları
  • Bilgi sızdırma açığı gerekiyor mu?: Hayır
  • CVE: The Hacker News'e göre yayın itibarıyla iki açık için de CVE atanmadı
  • Gerçek dünyada sömürü: The Hacker News'e göre kanıt yok

Saldırganın önce sistemde yerel bir hesaba ya da kod çalıştırma imkânına sahip olması gerekiyor. Yani bu, uzaktan doğrudan sömürülebilen bir açık değil. Ama çok kullanıcılı sistemler, kabuk erişimi verilen sunucular ya da başka bir servisteki açık üzerinden düşük yetkili erişim elde edilmiş makineler için ciddi bir yetki yükseltme yolu.

37 Yıllık Sayaç: Hata Nereden Geliyor?

Hatanın merkezinde System V paylaşımlı bellek (shared memory) mekanizması var. Bir paylaşımlı bellek segmentine kaç sürecin bağlı olduğunu tutan shm_nattch alanı, The Hacker News'in aktardığına göre 1988 tarihli orijinal BSD kaynaklarında işaretli 16 bitlik bir short olarak tanımlanmış. Bu tipin alabileceği en büyük değer 32.767. OpenBSD bu tipi miras almış ve hiç genişletmemiş.

Calif'in açıklamasına göre paylaşımlı bellek bağlantı kayıtlarına sahip bir süreci tekrar tekrar çatallamak (fork), bu sayacı en büyük değerinin ötesine itip negatif bir değere taşırabiliyor. Bu tam sayı taşması, bir yarış durumu (race condition) üzerinden use-after-free'ye yol açabiliyor: Bozulan referans sayısı, çekirdeğin hâlâ başka süreçlerin kullandığı belleği serbest bırakmasına neden oluyor.

Bu, eski kodun neden tehlikeli olabileceğinin klasik bir örneği. 1988'de bir paylaşımlı bellek segmentine 32 binden fazla bağlantı olması muhtemelen hayal bile edilmiyordu; bugün ise bir saldırgan bunu bilerek tetikleyebiliyor.



Zincir Nasıl Çalışıyor? (Üst Düzey Bakış)

Savunma odaklı bir forum olduğumuz için adım adım istismar ayrıntısına girmeyeceğim; meraklılar teknik detayları Calif'in yazısında bulabilir. Kavramsal olarak zincir üç parçadan oluşuyor:

  1. Tam sayı taşması (shmat): Paylaşımlı bellek bağlantı sayacı taşırılıyor.
  2. Use-after-free (SysV IPC): Bozulan referans sayısı ve bir yarış durumu sayesinde serbest bırakılmış bellek yeniden kullanılıyor.
  3. Ayrı bir sınır dışı yazma (out-of-bounds write): Çekirdekteki çok noktaya yayın (multicast) üyelik verisinde bir sınır dışı yazma kullanılıyor. The Hacker News'e göre bu yazma sonucunda sayfa tablosu girdileri değişiyor ve bir kullanıcı belleği eşlemesi çekirdek tarafından erişilebilir hale gelerek SMAP ve SMEP atlatılıyor. Son adımda öngörülebilir bir çekirdek adresindeki işlev işaretçisinin üzerine yazılıyor.

Calif'in vurguladığı asıl dikkat çekici nokta, KARL'ın nasıl aşıldığı. Griffiths'in ifadesiyle KARL çekirdek ikili dosyasını yeniden bağlayarak işlev ve veri adreslerini rastgeleleştiriyor; ancak çekirdeğin bellek ayırıcıları deterministik kalıyor. Açılış sırasında yapılan bazı ayırmalar, aynı donanımda her açılışta aynı adreslere düşüyor. Bu öngörülebilirlik, istismarın ayrı bir bilgi sızdırma açığına ihtiyaç duymadan çalışmasını sağlıyor.

Neden "Reliability Fix" Etiketi Önemli?

The Hacker News'in altını çizdiği bir ayrıntı, sistem yöneticileri için çok önemli: Zincirin giriş noktası olan tam sayı taşmasını düzelten errata 018, OpenBSD tarafından güvenlik düzeltmesi değil, güvenilirlik düzeltmesi (RELIABILITY FIX) olarak sınıflandırıldı. OpenBSD 7.9 errata sayfasında da 018 bu etiketle, "shmat(4)'te tam sayı taşmasını önle" açıklamasıyla yer alıyor.

Pek çok kurumda yama politikası "güvenlik düzeltmelerini hemen uygula, diğerlerini bakım penceresinde" şeklinde işler. Bu olay, güvenilirlik olarak etiketlenmiş bir düzeltmenin de bir istismar zincirinin kritik parçası olabileceğini gösteriyor. OpenBSD'de syspatch zaten tüm errata'ları birlikte uyguladığı için düzenli syspatch çalıştıranlar etkilenmiyor; ama yamaları seçerek uygulayanlar dikkat etmeli.

Düzeltmeler ve Errata Numaraları

OpenBSD 7.9:
  • 018 - RELIABILITY FIX, 14 Eylül 2026: shmat(4)'te tam sayı taşmasının önlenmesi
  • 026 - SECURITY FIX, 30 Eylül 2026: Çekirdekte use-after-free'ye yol açabilen referans sayma hatası

OpenBSD 7.8:
  • 054 - RELIABILITY FIX, 14 Eylül 2026: shmat(4)'te tam sayı taşmasının önlenmesi
  • 062 - SECURITY FIX, 30 Eylül 2026: Çekirdekte use-after-free'ye yol açabilen referans sayma hatası

The Hacker News'e göre düzeltmeler syspatch üzerinden tüm mimariler için mevcut. Bir not: Calif ve haber kaynakları zincirde kullanılan multicast sınır dışı yazma hatası için ayrı bir errata numarası vermiyor; OpenBSD errata sayfalarını takip etmekte fayda var.

Sisteminizi Nasıl Kontrol Edersiniz?

Sürümünüzü kontrol edin:
Kod:
uname -a sysctl kern.version

Uygulanmış ikili yamaları listeleyin:
Kod:
syspatch -l

Uygulanabilir ama henüz kurulmamış yamaları görün:
Kod:
syspatch -c

7.9 için çıktıda 018 ve 026'yı, 7.8 için 054 ve 062'yi arayın:
Kod:
syspatch -l | grep -E "018|026|054|062"

Eksikse tüm yamaları uygulayın ve çekirdek yamaları olduğu için sistemi yeniden başlatın:
Kod:
syspatch reboot

OpenBSD errata sayfasına göre ikili güncellemeler amd64, i386 ve arm64 için sunuluyor; diğer mimarilerde imzalı kaynak kodu yamalarının uygulanması gerekiyor.



Calif'in Önerdiği Sıkılaştırmalar

Calif, yamaların ötesinde bu tür açık sınıflarını bütünüyle zorlaştıracak dört yaklaşım öneriyor:
  • Safe-unlinking: Çekirdekteki çift bağlı listelerde silme işleminden önce liste bütünlüğünü kontrol etmek. Calif'e göre FreeBSD ve NetBSD'nin sys/queue.h uygulamalarında bu zaten var.
  • Sayfa tablosu öz-referans eşlemesinin rastgeleleştirilmesi: İstismarın hedef aldığı adreslerin öngörülemez hale gelmesi.
  • Çekirdek bellek ayırıcısının rastgeleleştirilmesi: Açılıştaki taban adresin ve çalışma zamanındaki ayırma sırasının rastgeleleştirilmesi.
  • Derleyici tabanlı sınır kontrolleri: Array bounds sanitizer gibi özellikler. Calif, FreeBSD'ye bu özelliği sürüm derlemelerinde etkinleştirmeyi önerdiğini ve bu sanitizer'ın yakalayabileceği 21 sorunu özel olarak bildirdiğini söylüyor.

Calif'in kapanış notu da önemli: Yapay zeka destekli açık keşfi çağında, tek tek açıkları kapatmanın yanında bütün açık sınıflarını etkisiz kılan önlemler daha da kritik hale geliyor.

OpenBSD'yi güvenlik duvarı, VPN geçidi ya da DNS sunucusu olarak kullanan arkadaşlar, en son ne zaman syspatch çalıştırdınız? Ve yama politikanızda "reliability" etiketli düzeltmeleri nasıl ele alıyorsunuz? Yorumlarda görüşlerinizi bekliyorum.

Kaynaklar
Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 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
   
 Prowler ile AWS Güvenlik Denetimi 2026: Açık Kaynak CSPM ile Kendi Hesabınızı Tarayın
Tonyukuk 10-18-2026, 05:13 PM · Bulut Güvenliği
0 36
[Resim: attachment.php?aid=224]

Merhaba arkadaşlar,

Bulut hesabınızda yüzlerce kaynak varsa, "acaba bir yerde açık bir S3 bucket ya da fazla yetkili bir IAM kullanıcısı mı kaldı?" sorusunu elle cevaplamak imkansızdır. İşte bu noktada bulut güvenlik duruşu yönetimi (CSPM) araçları devreye girer. Prowler, AWS başta olmak üzere birçok sağlayıcıyı tarayan, açık kaynak ve ücretsiz bir CSPM aracıdır. Bu rehberde Prowler'ı resmi belgelerine dayanarak kurup kendi AWS hesabınızda nasıl güvenlik denetimi yapacağınızı, raporları nasıl okuyacağınızı ve bulguları nasıl önceliklendireceğinizi anlatıyorum. Tüm komutlar yalnızca kendi hesabınızda veya yazılı izniniz olan hesaplarda çalıştırılmalıdır.

Konuda Anlatılacaklar
  1. CSPM nedir, Prowler ne yapar?
  2. Kurulum ve kimlik doğrulama
  3. En az yetkili denetim kullanıcısı
  4. İlk tarama ve raporlar
  5. Uyumluluk çerçeveleriyle tarama
  6. Belirli servis/kontrol çalıştırma
  7. Bulguları önceliklendirme ve düzenli denetim

CSPM Nedir, Prowler Ne Yapar?

CSPM araçları, bulut yapılandırmanızı bilinen güvenlik en iyi uygulamaları ve uyumluluk çerçeveleriyle karşılaştırır; yanlış yapılandırmaları (açık bucket, şifresiz disk, MFA'sız kök hesap, aşırı geniş IAM) tespit eder. Prowler, resmi belgelerine göre AWS, Azure, GCP, Kubernetes, Microsoft 365, GitHub ve daha fazlasını destekler. Yüzlerce hazır kontrol ve CIS, NIST gibi uyumluluk çerçeveleriyle gelir.

[Resim: attachment.php?aid=225]

Kurulum ve Kimlik Doğrulama

Prowler, Python ile kurulur (resmi belgelere göre Python 3.10-3.13):

Kod:
pip install prowler prowler -v

Prowler, komut çalıştırıldığında ortam değişkeni veya profil üzerinden AWS kimlik bilgilerini kullanır. Önce AWS CLI ile kimliğinizi doğrulayın:

Kod:
aws sts get-caller-identity

Prowler sağlayıcıyı ilk argüman olarak alır (belirtmezseniz geriye dönük uyumluluk için AWS varsayılır):

Kod:
prowler aws prowler aws --profile kendi-profilim

En Az Yetkili Denetim Kullanıcısı

Prowler yalnızca okuma yapar; bu yüzden ona yazma yetkisi vermeyin. AWS'nin yönetilen SecurityAudit ve ViewOnlyAccess politikaları çoğu kontrol için yeterlidir. En az yetki ilkesine uygun olarak Prowler için ayrı bir IAM rolü/kullanıcısı oluşturun ve yalnızca bu salt okunur politikaları bağlayın. Kök hesapla veya AdministratorAccess ile tarama yapmak, gereksiz risktir.

İlk Tarama ve Raporlar

En basit haliyle tüm hesabı tüm bölgelerde tarayın:

Kod:
prowler aws

Prowler resmi belgelerine göre varsayılan olarak CSV, JSON-OCSF ve HTML raporları üretir ve bunları output dizinine kaydeder. Çıktı formatını kendiniz de seçebilirsiniz:

Kod:
prowler aws -M csv json-ocsf html

Belirli bir profil ve bölgeyle sınırlamak:

Kod:
prowler aws --profile kendi-profilim -f eu-central-1 eu-west-1

HTML raporu tarayıcıda açıp bulguları önem (severity) ve servis bazında filtreleyebilirsiniz. İlk taramada yüzlerce bulgu görmek normaldir; panik yapmayın, önceliklendirin.

[Resim: attachment.php?aid=226]

Uyumluluk Çerçeveleriyle Tarama

Prowler, taramayı bir uyumluluk çerçevesine göre yapabilir. Örneğin CIS AWS Benchmark'a göre:

Kod:
prowler aws --compliance cis_3.0_aws

Mevcut çerçeveleri ve kontrolleri listelemek için:

Kod:
prowler aws --list-compliance prowler aws --list-checks prowler aws --list-services

Uyumluluk modu, denetim raporlarına ve yönetime sunum yaparken özellikle değerlidir; her bulguyu bir çerçeve maddesiyle eşler.

Belirli Servis veya Kontrol Çalıştırma

Tüm hesabı taramak yerine tek bir servise odaklanabilirsiniz. Belgelerdeki örneklere göre:

Kod:
prowler aws --services s3 ec2 prowler aws --checks s3_bucket_public_access

Belirli kontrolleri hariç tutmak da mümkündür:

Kod:
prowler aws --excluded-checks s3_bucket_public_access

Böylece "önce S3'ü düzeltelim" gibi odaklı iyileştirme turları yapabilirsiniz.

Prowler Nasıl Tarar? Kontrol Mantığı

Prowler her kontrolü küçük, bağımsız bir modül olarak çalıştırır. Bir kontrol, ilgili AWS API'sini salt okunur biçimde çağırır (örneğin S3 için get-public-access-block, bucket politikası), sonucu beklenen güvenli duruma göre değerlendirir ve PASS/FAIL olarak işaretler. Bu yüzden Prowler hiçbir şeyi değiştirmez; yalnızca mevcut yapılandırmayı okur ve yorumlar. Her bulgu; kontrol kimliği, önem düzeyi, etkilenen kaynak, açıklama ve düzeltme (remediation) önerisiyle birlikte gelir. Bu alanlar HTML raporunda sütun olarak görünür ve JSON-OCSF çıktısında makine tarafından işlenebilir biçimde yer alır, böylece bulguları bir SIEM'e veya tablolama aracına aktarabilirsiniz.

İleri Seviye: Bulguları Önceliklendirme ve Düzenli Denetim

İlk taramadan sonra bir eylem planı çıkarın:
  • Önce kritik ve yüksek (critical/high) bulgular: açık bucket, herkese açık güvenlik grubu (0.0.0.0/0), MFA'sız kök hesap, şifresiz veritabanı.
  • Sonra orta (medium): loglama eksikleri, eski erişim anahtarları.
  • Düzenli tekrar: Prowler'ı CI/CD veya zamanlanmış bir görev olarak çalıştırıp değişimi izleyin.

Taramayı tarih damgalı bir dizine kaydedip zamanla karşılaştırmak, duruşunuzun iyileşip iyileşmediğini gösterir:

Kod:
prowler aws -M json-ocsf html \ --output-directory ./denetim-$(date +%F)

[Resim: attachment.php?aid=227]

Not: Çoklu hesap (AWS Organizations) ortamlarında Prowler'ı bir denetim rolüyle tüm hesaplarda çalıştırabilirsiniz; ancak bu, yalnızca bu hesapların sahibi veya yetkili yöneticisiyseniz yapılmalıdır. Prowler'ın yönetilen SaaS sürümü (Prowler Cloud) ve açık kaynak yerel paneli de sürekli izleme için kullanılabilir.

Sonuç

Prowler, kendi AWS hesabınızın güvenlik duruşunu ücretsiz ve hızlı biçimde ölçmenin en pratik yollarından biri. Salt okunur bir denetim kullanıcısıyla kurun, varsayılan CSV/JSON/HTML raporlarıyla başlayın, CIS gibi bir çerçeveye göre tarayın ve kritik bulgulardan başlayarak düzenli iyileştirme turları yapın. Siz hangi CSPM aracını kullanıyorsunuz, ilk taramada en çok hangi bulguyla karşılaştınız? Yorumlarda paylaşın.

Kaynakça
Yasal Uyarı

Bu rehberdeki tarama komutları yalnızca kendi AWS hesabınızda veya yazılı olarak yetkilendirildiğiniz hesaplarda çalıştırılmalıdır. Başkasına ait bulut kaynaklarını izinsiz taramak veya bunlara erişmek 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

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
               
 Frida ile Android Dinamik Analiz 2026: Lab Uygulamanızda Çalışma Zamanı İnceleme
Tonyukuk 10-18-2026, 05:11 PM · Mobil Güvenlik
0 50
[Resim: attachment.php?aid=220]

Merhaba arkadaşlar,

Statik analiz bir uygulamanın kodunu çalıştırmadan inceler; ama bazı davranışlar ancak uygulama çalışırken ortaya çıkar: hangi fonksiyonun ne değer döndürdüğü, SSL doğrulamasının gerçekte yapılıp yapılmadığı, bir kök kontrolünün nasıl çalıştığı. İşte burada dinamik analiz ve Frida devreye girer. Frida, çalışan bir sürece kod enjekte ederek fonksiyonları canlı izlemenizi (hooking) sağlayan açık kaynak bir araçtır. Bu rehberde Frida'yı resmi belgelerine dayanarak kurmayı ve yalnızca kendi geliştirdiğiniz, kendi cihazınızdaki bir lab uygulaması üzerinde temel dinamik analizi anlatıyorum. Başkasına ait uygulamalarda kullanmak yasa ve lisans ihlalidir.

Konuda Anlatılacaklar
  1. Dinamik analiz ve hooking nedir?
  2. Lab ortamı: emülatör ve kendi uygulamanız
  3. Frida kurulumu (host ve cihaz)
  4. Süreçleri listeleme ve bağlanma
  5. İlk hook: bir fonksiyonu izleme
  6. Örnek: kendi kök kontrolünüzü gözlemleme
  7. Etik sınırlar ve savunma dersleri

Dinamik Analiz ve Hooking Nedir?

Dinamik analiz, uygulamayı gerçek/sanal bir cihazda çalıştırırken davranışını inceler. Hooking, bir fonksiyonun çağrılmasını araya girerek yakalamak; argümanlarını, dönüş değerini görmek ve isterseniz değiştirmektir. Frida bunu, hedef sürece bir ajan (JavaScript ile yazılmış) enjekte ederek yapar. Bu teknik hem saldırı hem savunma tarafında kullanılır; biz savunma ve kendi kodunu anlama amacıyla ele alıyoruz.

[Resim: attachment.php?aid=221]

Lab Ortamı: Emülatör ve Kendi Uygulamanız

Güvenli ve yasal bir lab için:
  • Android Studio ile bir Android Emülatör (tercihen Google APIs imajı, root erişimi kolay olan) kurun.
  • Analiz edeceğiniz uygulama sizin yazdığınız basit bir test uygulaması olsun. OWASP'ın MASTG projesi, tam da bu amaç için savunmasız örnek uygulamalar (MAS Test Apps) sağlar.
  • Asla Play Store'dan indirdiğiniz üçüncü taraf bir uygulamaya müdahale etmeyin.

Frida Kurulumu (Host ve Cihaz)

Frida iki parçadan oluşur: bilgisayarınızdaki komut satırı araçları ve cihazdaki frida-server. Resmi belgelere göre host tarafı:

Kod:
pip install frida-tools frida --version

frida-tools; frida, frida-ps, frida-trace gibi komutları içerir. Cihaz tarafı için cihazın mimarisine uygun frida-server sürümünü resmi GitHub sürümlerinden indirip (yalnızca kendi root'lu emülatörünüze) yükleyin:

Kod:
adb push frida-server /data/local/tmp/ adb shell "su -c 'chmod 755 /data/local/tmp/frida-server'" adb shell "su -c '/data/local/tmp/frida-server &'"

[Resim: attachment.php?aid=222]

Süreçleri Listeleme ve Bağlanma

frida-server çalışırken, USB üzerinden bağlı cihazdaki uygulamaları listeleyin. Resmi belgelere göre -U USB cihazını, -a yüklü uygulamaları, -i ise ek bilgiyi gösterir:

Kod:
frida-ps -U frida-ps -Uai

İkinci komut, yüklü uygulamaları paket adlarıyla birlikte listeler. Kendi test uygulamanızın paket adını (örneğin org.benim.lab) buradan not alın.

İlk Hook: Bir Fonksiyonu İzleme

Basit bir Frida ajanı JavaScript ile yazılır. Aşağıdaki script, kendi uygulamanızdaki bir Java metodunu yakalayıp argüman ve dönüş değerini yazdırır. Java.perform ve Java.use, Frida'nın resmi JavaScript API'sinin parçasıdır:

Kod:
// izle.js Java.perform(function () { var Hesap = Java.use("org.benim.lab.Hesaplayici"); Hesap.topla.implementation = function (a, b) { console.log("[+] topla cagrildi: a=" + a + " b=" + b); var sonuc = this.topla(a, b); console.log("[+] donen deger: " + sonuc); return sonuc; }; });

Scripti kendi uygulamanıza enjekte ederek çalıştırın:

Kod:
frida -U -l izle.js -f org.benim.lab

-f uygulamayı Frida'nın başlatmasını sağlar (spawn), böylece en baştan izlersiniz. Konsola, uygulama o metodu her çağırdığında argümanlar ve dönüş değeri düşer.

Örnek: Kendi Kök Kontrolünüzü Gözlemleme

Birçok uygulama cihazın root'lu olup olmadığını kontrol eder. Kendi lab uygulamanıza basit bir kök kontrolü fonksiyonu yazıp, Frida ile bu fonksiyonun ne döndürdüğünü gözlemleyin:

Kod:
// kok-gozlem.js Java.perform(function () { var G = Java.use("org.benim.lab.GuvenlikKontrol"); G.rootluMu.implementation = function () { var r = this.rootluMu(); console.log("[*] rootluMu() -> " + r); return r; // sadece gozlem; degeri degistirmiyoruz }; });

[Resim: attachment.php?aid=223]

Buradaki önemli savunma dersi: Dinamik analizle kök kontrolü gibi istemci tarafı korumaların değiştirilebildiğini görürsünüz. Bu yüzden güvenlik kararlarını yalnızca istemciye bırakmayın; kritik doğrulamaları sunucu tarafında da yapın. Kendi uygulamanızda bu zafiyeti görmek, onu nasıl sertleştireceğinizi öğretir.

İleri Seviye: Etik Sınırlar ve Savunma Dersleri

Frida çok güçlü bir araçtır ve bu güç sorumluluk getirir:
  • Yalnızca kendi uygulamalarınızda veya yazılı izinli (bug bounty kapsamı dahilinde) hedeflerde kullanın.
  • İstemci tarafı korumalar (kök tespiti, SSL pinning, kurcalama tespiti) saldırganı yavaşlatır ama tek başına yeterli değildir.
  • Savunma için: kritik iş mantığını ve yetkilendirmeyi sunucuda tutun, hassas verileri istemcide tutmayın, obfuscation ve bütünlük kontrolleri ekleyin.
  • Dinamik analiz bulgularınızı OWASP MASTG testleriyle eşleştirerek raporlayın.

Frida ayrıca iOS, Windows, Linux ve macOS süreçlerinde de çalışır; mantık her yerde aynıdır: çalışan koda araya girip davranışı gözlemlemek.

Sonuç

Frida, bir uygulamanın çalışırken gerçekte ne yaptığını görmenin en etkili yollarından biri. Kendi lab uygulamanızda frida-tools ve frida-server ile kurulum yapın, frida-ps ile süreçleri bulun, basit bir Java.perform hook'u ile fonksiyonları izleyin ve istemci tarafı korumaların neden tek başına yetmediğini kendi gözünüzle görün. Bu bilgiyi yalnızca kendi kodunuzu güçlendirmek için kullanın. Siz Frida ile hangi senaryoları test ettiniz? Yorumlarda paylaşın.

Kaynakça
Yasal Uyarı

Frida ve dinamik analiz teknikleri yalnızca kendinize ait uygulamalar, kendi cihazınız veya sahibinden yazılı izin aldığınız (ör. bug bounty kapsamındaki) hedefler üzerinde kullanılmalıdır. Başkasına ait uygulama veya cihazlara izinsiz müdahale, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suça yol açar. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

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