TürkTeam Portal

Siber güvenlik topluluğunun nabzı

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

Forumlar Yeni Mesajlar Kurallar

Duyurular

Entra ID Güvenliği 2026: Koşullu Erişim, Zorunlu MFA ve PIM ile Kimlik Sertleştirme

Tonyukuk 10-18-2026, 05:09 PM · Bulut Güvenliği

0 39

Merhaba arkadaşlar,

Bulut saldırılarının büyük kısmı bir açıktan değil, ele geçirilmiş bir kimlikten başlıyor. Microsoft'un kimlik servisi Entra ID (eski adıyla Azure AD) üzerinde doğru yapılandırılmış üç kontrol, saldırı yüzeyinin büyük bölümünü kapatır: Koşullu Erişim (Conditional Access), çok faktörlü kimlik doğrulama (MFA) ve ayrıcalıklı erişim yönetimi (PIM). 2026'da Microsoft Azure için MFA'yı kademeli olarak zorunlu hale getirdi. Bu rehberde bu üç kontrolü resmi Microsoft Learn belgelerine dayanarak savunma gözüyle ele alıyorum. Amaç saldırmak değil, kendi kiracınızı (tenant) güvenli kurmak.

Konuda Anlatılacaklar

Entra ID kimlik güvenliğinin temeli
2026 zorunlu MFA: ne, ne zaman, kimi kapsıyor?
Koşullu Erişim nasıl çalışır?
Örnek politikalar
PIM ile en az ayrıcalık ve tam zamanında erişim
İzleme ve doğrulama
Yaygın hatalar

Entra ID Kimlik Güvenliğinin Temeli

Bulutta "ağ çevresi" yerini "kimlik çevresine" bıraktı. Entra ID'de güvenliğin üç ayağı vardır: güçlü kimlik doğrulama (parola + MFA), bağlama göre erişim kararı (Koşullu Erişim) ve ayrıcalıklı rollerin sürekli değil ihtiyaç anında verilmesi (PIM). Bu üçünü birlikte kurduğunuzda, çalınmış bir parola tek başına işe yaramaz hale gelir.

2026 Zorunlu MFA: Ne, Ne Zaman, Kimi Kapsıyor?

Microsoft'un resmi planına göre Azure için zorunlu MFA iki aşamalı devreye girdi. İkinci aşama (Phase 2) 1 Ekim 2025'ten itibaren kiracılara kademeli olarak uygulanmaya başladı ve şunları kapsar:

Azure CLI, Azure PowerShell, SDK'lar, IaC araçları, REST API ve mobil uygulama üzerinden yapılan oluşturma, güncelleme ve silme (CUD) işlemleri.
Yalnızca okuma (read) işlemleri bu zorunluluğun dışındadır.

En iyi deneyim için Azure CLI 2.76+ ve Azure PowerShell 14.3+ önerilir. Önemli: Kullanıcı kimliğiyle çalışan otomasyonlar bundan etkilenir; bu tür işleri yönetilen kimliklere (managed identity) veya hizmet sorumlularına (service principal) taşıyın, çünkü bunlar kullanıcı MFA zorunluluğuna tabi değildir. Kiracılar bu aşamayı 1 Temmuz 2026'ya kadar erteleyebiliyordu; bu erteleme penceresi kapandı.

Koşullu Erişim Nasıl Çalışır?

Microsoft Learn'e göre Koşullu Erişim politikası bir "eğer-ise" (if-then) ifadesidir: belirli sinyaller (kullanıcı, uygulama, cihaz, konum, risk) karşılanırsa belirli erişim kontrolleri (grant/block) uygulanır. Aynı anda birden çok politika uygulanıyorsa hepsi birden sağlanmalıdır (mantıksal AND). Kullanılabilen "grant" (izin) kontrollerinden bazıları:

Require multifactor authentication (MFA iste)
Require authentication strength (belirli kimlik doğrulama gücü)
Require device to be marked as compliant (Intune uyumlu cihaz)
Require Microsoft Entra hybrid joined device
Require approved client app / app protection policy
Require password change / terms of use

Örnek Politikalar

Aşağıdaki politikalar kavramsal örneklerdir; kendi test kiracınızda önce "yalnızca rapor" (report-only) modunda deneyin.

1) Yöneticiler için her zaman MFA:

Atamalar: Hedef kullanıcılar = dizin yönetici rolleri.
Hedef kaynaklar: Tüm bulut uygulamaları.
Erişim kontrolü: Grant -> Require multifactor authentication.

2) Eski (legacy) kimlik doğrulamayı engelle: Temel kimlik doğrulama (basic auth) MFA'yı atlatır. Koşullu Erişim'de "Other clients / legacy authentication clients" koşulunu seçip Block uygulayın. Bu, kimlik güvenliğinin en etkili tek adımlarından biridir.

3) Riskli oturum açmada MFA (Entra ID Protection gerektirir): Sign-in risk = medium/high olduğunda MFA iste.

Her politika için report-only modunu kullanarak önce etkisini loglardan izleyin, sonra açın. Yanlışlıkla kendinizi dışarıda bırakmamak için en az bir "acil erişim" (break-glass) hesabını politikaların dışında tutun.

PIM ile En Az Ayrıcalık ve Tam Zamanında Erişim

Privileged Identity Management (PIM), ayrıcalıklı rolleri sürekli atamak yerine "uygun" (eligible) hale getirir; kullanıcı rolü ihtiyaç duyduğunda, süreli olarak etkinleştirir (just-in-time). Microsoft Learn'e göre PIM ile yapılabilecekler:

Rol etkinleştirmede MFA zorunlu kılma.
Etkinleştirmede Koşullu Erişim kimlik doğrulama bağlamı (authentication context) isteme.
Onay (approval) gerektirme ve etkinleştirme gerekçesi (justification) isteme.
Süreli (time-bound) atama ve etkinleştirme bildirimleri.
Düzenli erişim incelemeleri (access reviews).

Belgelere göre önemli bir pratik: Kimlik doğrulama bağlamını PIM ayarına eklemeden önce o bağlamı hedefleyen Koşullu Erişim politikasını oluşturup etkinleştirin. Eğer bağlamı hedefleyen hiçbir politika yoksa, PIM yedek koruma olarak etkinleştirmede MFA'yı zaten zorunlu tutar.

İzleme ve Doğrulama

Yapılandırmayı kurduktan sonra doğrulayın. Microsoft Graph PowerShell ile mevcut Koşullu Erişim politikalarını listeleyebilirsiniz (yalnızca kendi kiracınızda, yetkili hesapla):

Kod:
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State |
  Format-Table -AutoSize

Oturum açma günlüklerini (sign-in logs) inceleyerek hangi politikanın hangi oturuma uygulandığını görebilir, report-only sonuçlarını buradan okuyabilirsiniz. Düzenli olarak: MFA kaydı olmayan kullanıcıları, kullanılmayan ayrıcalıklı rolleri ve legacy auth denemelerini kontrol edin.

İleri Seviye: Yaygın Hatalar

Break-glass hesabı unutmak: Tüm hesapları MFA/CA politikasına bağlayıp kilitli kalmak. En az bir acil erişim hesabını istisna tutun ve güçlü biçimde koruyun.
Legacy auth'u açık bırakmak: MFA'yı atlatan en büyük açık budur.
Ayrıcalıkları kalıcı atamak: Global Administrator gibi rolleri sürekli vermek yerine PIM ile eligible yapın.
Otomasyonu kullanıcı hesabıyla çalıştırmak: Zorunlu MFA sonrası bozulur; managed identity/service principal kullanın.
Politikaları test etmeden açmak: Önce report-only.

Sonuç

Entra ID güvenliğinde üçlü sacayağı nettir: her yönetici için MFA, legacy auth'u kapatan ve bağlama göre karar veren Koşullu Erişim, kalıcı ayrıcalık yerine PIM ile tam zamanında erişim. 2026 zorunlu MFA'sını fırsata çevirin: otomasyonlarınızı managed identity'ye taşıyın ve kimlik duruşunuzu sadeleştirin. Siz kiracınızda hangi kontrolü olmazsa olmaz görüyorsunuz? Yorumlarda konuşalım.

Kaynakça

Microsoft Learn, Plan for mandatory Entra MFA: https://learn.microsoft.com/en-us/entra/...entication
Azure Blog, Mandatory MFA Phase 2: https://azure.microsoft.com/en-us/blog/a...ober-2025/
Microsoft Learn, Build Conditional Access policies: https://learn.microsoft.com/en-us/entra/...s-policies
Microsoft Learn, Configure Entra role settings in PIM: https://learn.microsoft.com/en-us/entra/...t-settings
Microsoft Learn, Plan a PIM deployment: https://learn.microsoft.com/en-us/entra/...yment-plan
Microsoft Learn, Get-MgIdentityConditionalAccessPolicy: https://learn.microsoft.com/en-us/powers...cesspolicy

Yasal Uyarı

Bu rehberdeki tüm yapılandırma ve komutlar yalnızca kendi Entra ID kiracınızda veya yazılı olarak yetkilendirildiğiniz ortamlarda uygulanmalıdır. Başkasına ait kimlik sistemlerine 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

Kubernetes Güvenliği 2026: RBAC, Pod Security Standards, NetworkPolicy ve kube-bench

Tonyukuk 10-18-2026, 05:07 PM · Bulut Güvenliği

0 42

Merhaba arkadaşlar,

Kubernetes, modern uygulamaların çalıştığı fiili standart haline geldi; ama varsayılan bir küme güvenli değildir. Yanlış yapılandırılmış RBAC, ayrıcalıklı pod'lar ve kısıtlanmamış ağ trafiği, saldırganın bir konteynerden tüm kümeye yayılmasına zemin hazırlar. Bu rehberde Kubernetes güvenliğinin dört temel taşını resmi Kubernetes belgelerine dayanarak savunma gözüyle ele alıyorum: RBAC, Pod Security Standards, NetworkPolicy ve kube-bench ile CIS denetimi. Tüm komutlar kendi test kümenizde (örneğin minikube/kind) çalıştırılmalıdır.

Konuda Anlatılacaklar

Kubernetes saldırı yüzeyi
RBAC ile en az yetki
Pod Security Standards ve Admission
NetworkPolicy ile ağ segmentasyonu
Secret yönetimi
kube-bench ile CIS denetimi
Test lab kurulumu

Kubernetes Saldırı Yüzeyi

Bir Kubernetes kümesinde başlıca risk alanları: API sunucusuna aşırı geniş erişim (RBAC), konteyner kaçışına izin veren ayrıcalıklı pod'lar, pod'lar arası sınırsız yatay trafik (lateral movement), açıkta kalan Secret'lar ve güncellenmemiş bileşenler. Savunma, bu alanların her birine bir kontrol koymaktır.

RBAC ile En Az Yetki

Role-Based Access Control (RBAC), kimin hangi kaynak üzerinde ne yapabileceğini belirler. Kubernetes belgelerine göre Role (namespace kapsamlı) veya ClusterRole (küme geneli) ile izinler tanımlanır, RoleBinding/ClusterRoleBinding ile özneye (kullanıcı, grup, ServiceAccount) atanır. Altın kural: geniş "cluster-admin" dağıtmak yerine dar roller verin.

Yalnızca belirli bir namespace'te pod okuyabilen bir rol örneği:

Kod:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: uygulama
  name: pod-okuyucu
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Bu rolü bir ServiceAccount'a bağlamak:

Kod:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-okuyucu-baglama
  namespace: uygulama
subjects:
- kind: ServiceAccount
  name: izleme-sa
  namespace: uygulama
roleRef:
  kind: Role
  name: pod-okuyucu
  apiGroup: rbac.authorization.k8s.io

Kendi yetkinizi kontrol etmek için kubectl'in yerleşik aracı:

Kod:
kubectl auth can-i create deployments --namespace uygulama
kubectl auth can-i '*' '*' --all-namespaces

İkinci komut "yes" dönüyorsa fazla yetkiniz var demektir; bunu daraltın.

Pod Security Standards ve Admission

Kubernetes, PodSecurityPolicy'yi kaldırdı ve yerine yerleşik Pod Security Admission denetleyicisini getirdi. Üç profil vardır: privileged (kısıtsız), baseline (bilinen ayrıcalık yükseltmelerini engeller) ve restricted (sıkı en iyi uygulamalar). Belgelerine göre profiller namespace etiketleriyle uygulanır. "restricted" profili zorunlu kılan etiketleme:

Kod:
kubectl label namespace uygulama \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.37

enforce dışında audit ve warn modları da vardır; önce warn/audit ile etkisini görmek iyi bir yaklaşımdır:

Kod:
kubectl label namespace uygulama \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted --overwrite

Pod tanımında da sertleştirme yapın: ayrıcalıklı çalıştırmayın, kök olmayan kullanıcı kullanın, salt okunur kök dosya sistemi tercih edin:

Kod:
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

NetworkPolicy ile Ağ Segmentasyonu

Varsayılan olarak bir kümedeki tüm pod'lar birbiriyle serbestçe konuşabilir. NetworkPolicy ile bunu kısıtlarsınız (CNI eklentinizin NetworkPolicy desteklemesi gerekir). Önce namespace'te tüm gelen trafiği varsayılan olarak reddeden bir politika:

Kod:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: varsayilan-ingress-reddet
  namespace: uygulama
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Boş podSelector tüm pod'ları seçer; ingress kuralı tanımlanmadığı için hiçbir gelen trafiğe izin verilmez. Sonra yalnızca gereken trafiği açarsınız (örneğin frontend'den backend'e). Bu "önce hepsini kapat, sonra gerekeni aç" yaklaşımı sıfır güven (zero trust) ağ modelinin temelidir.

Secret Yönetimi

Kubernetes Secret'ları varsayılan olarak yalnızca base64 ile kodlanır, şifrelenmez. Belgelere göre etcd'de bekleyen veri şifrelemesini (encryption at rest) etkinleştirmek ve Secret'lara RBAC ile erişimi kısıtlamak gerekir. Secret'ları asla git deposuna düz metin olarak koymayın; dışarıdan bir gizli bilgi yöneticisi (ör. harici KMS) ile entegrasyon tercih edin. Bir Secret'ı kimlerin okuyabildiğini RBAC ile sınırlayın; "get secrets" iznini herkese vermeyin.

kube-bench ile CIS Denetimi

Aqua Security'nin açık kaynak aracı kube-bench, kümeyi CIS Kubernetes Benchmark'a göre denetler. Resmi belgelere göre küme içinde bir Job olarak çalıştırılır:

Kod:
kubectl apply -f job.yaml
kubectl get pods
# kube-bench-xxxxx Completed olduğunda:
kubectl logs kube-bench-xxxxx

Belgelerde belirtildiği gibi Job hostPID ve host yolu bağlamaları kullanır; kontrol düzlemi düğümünde çalışması için gerekirse nodeSelector ve toleration ekleyin. Çıktı [PASS]/[FAIL]/[WARN] olarak gelir; FAIL maddelerini önceliklendirin.

İleri Seviye: Test Lab Kurulumu

Üretim kümesinde deneme yapmayın. Kendi bilgisayarınızda bir test kümesi kurun:

Kod:
# minikube ile
minikube start --kubernetes-version=stable
kubectl create namespace uygulama
kubectl label namespace uygulama pod-security.kubernetes.io/warn=restricted
# ihlal eden bir pod deneyin, uyariyi gorun
kubectl run test --image=nginx -n uygulama

Bu lab'da RBAC rollerini, PSA profillerini ve NetworkPolicy'leri güvenle deneyip davranışı gözlemleyebilirsiniz. Ardından bir zafiyet tarayıcısıyla (örneğin imajlar için Trivy) konteyner imajlarınızı da tarayın.

Sonuç

Kubernetes güvenliğinde dört temel: RBAC ile en az yetki, Pod Security Admission ile restricted profil, NetworkPolicy ile "önce kapat sonra aç" segmentasyon ve kube-bench ile düzenli CIS denetimi. Bunları bir test kümesinde deneyip sonra üretime taşıyın. Siz kümelerinizde hangi kontrolü ilk uyguluyorsunuz? Yorumlarda paylaşın.

Kaynakça

Kubernetes, Using RBAC Authorization: https://kubernetes.io/docs/reference/acc...uthz/rbac/
Kubernetes, Pod Security Admission: https://kubernetes.io/docs/concepts/secu...admission/
Kubernetes, Enforce Pod Security Standards with Namespace Labels: https://kubernetes.io/docs/tasks/configu...ce-labels/
Kubernetes, Network Policies: https://kubernetes.io/docs/concepts/serv...-policies/
Kubernetes, Encrypting Confidential Data at Rest: https://kubernetes.io/docs/tasks/adminis...rypt-data/
Kubernetes, Authorization (kubectl auth can-i): https://kubernetes.io/docs/reference/acc...orization/
Aqua Security, kube-bench: https://aquasecurity.github.io/kube-bench/

Yasal Uyarı

Bu rehberdeki tüm komutlar yalnızca kendi test kümenizde veya yazılı olarak yetkilendirildiğiniz ortamlarda çalıştırılmalıdır. Başkasına ait Kubernetes kümelerine izinsiz erişim veya denetim 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

Silent Lynx: Orta Asya ve BDT Hükümetlerine WinRAR CVE-2025-8088 ile Casusluk

Tonyukuk 10-18-2026, 04:43 PM · Siber Güvenlik Haberleri

0 37

Selam arkadaşlar,

Cisco Talos ve Recorded Future'ın Insikt Group ekibi, 14 Ekim 2026'da ortak bir araştırma yayımladı. Konu, Orta Asya ve Bağımsız Devletler Topluluğu (BDT) ülkelerindeki hükümet kurumlarını hedef alan bir siber casusluk grubu. Talos bu grubu UAT-6275, Recorded Future TAG-193 olarak izliyor; faaliyet, Seqrite'ın ilk kez raporladığı Silent Lynx ile örtüşüyor. Hedef listesinde Kazakistan, Kırgızistan, Türkmenistan, Özbekistan ve Azerbaycan gibi Türk dünyası ülkelerinin de olması, konuyu bizim için ayrıca ilginç kılıyor.

Haberin teknik açıdan dikkat çeken kısmı şu: Grup, Nisan 2026'da ilk kez bir yazılım açığını, WinRAR'daki CVE-2025-8088'i, zararlı yazılım dağıtım zincirine eklemiş.

Konuda Anlatılacaklar

Grup kim, kimleri hedef alıyor?
Diplomasi, su ve enerji ilgisi
Dört enfeksiyon zinciri
WinRAR CVE-2025-8088 zinciri (Chain D)
Açıkta kalan altyapı ve Kazakistan bağlantısı değerlendirmesi
Savunma ve tespit önerileri
Kaynaklar

Grup Kim, Kimleri Hedef Alıyor?

Talos'a göre incelenen kampanyalarda görülen kurbanlar ve yem temaları dokuz ülkeye yayılıyor: Kazakistan, Kırgızistan, Tacikistan, Türkmenistan, Özbekistan, Ermenistan, Azerbaycan, Rusya ve Belarus. Recorded Future ise 2025 başından Mayıs 2026'ya kadar olan kampanyalarda Rusya, Tacikistan, Belarus, Ermenistan ve Özbekistan'daki hükümet kurumlarını içeren faaliyet tespit ettiğini belirtiyor.

Talos, Seqrite'ın Silent Lynx'i ilk kez Ocak 2025'te raporlamasından bu yana bölgede Mayıs 2026'ya kadar en az sekiz kampanya tespit ettiğini söylüyor. Bunlar arasında Rusya, Türkmenistan ve Özbekistan'a yönelik zararlı yazılım dağıtımı ile Azerbaycan Kamu Hizmetleri Devlet Ajansı'nı taklit eden bir kimlik bilgisi toplama sitesi de var.

Talos, grubu daha geniş bir kümenin parçası olarak görüyor: 2023'te ilk kez raporladığı YoroTrooper ile aynı geniş faaliyet kümesine ait olabileceğini değerlendiriyor, ama ikisi arasında doğrudan gösterge ya da araç örtüşmesi görmediği için onları ayrı izlemeye devam ediyor. Tomiris, ShadowSilk, Cavalry Werewolf ve Hydra Saiga gibi başka firmaların raporladığı kümelerle de örtüşen göstergeler bulunduğunu belirtiyor.

Diplomasi, Su ve Enerji

Grubun ilgi alanı oldukça belirgin. Hedefler arasında diplomasi, ekonomik kalkınma, tarım ve çevre yönetiminden sorumlu kurumlar var. Talos'un ağ akışı analizine göre:

Mart 2026'da Kazakistan ile yürütülen antlaşma görüşmelerinin hemen ardından bir Tacik hükümet kurumunu içeren faaliyet görülmüş.
Nisan'daki ikili bir görüşme öncesinde bir Belarus hükümet kurumunu içeren faaliyet tespit edilmiş.

Recorded Future, bu zamansal ilişkilerin faaliyetin söz konusu gelişmelerle bağlantılı olduğunu kanıtlamadığını, ama grubun hedefleme ilgisi hakkında bağlam sağladığını özellikle vurguluyor.

Yem belgeleri de aynı tabloyu gösteriyor: Ermenistan Dışişleri Bakanlığı'na hitaben yazılmış bir diplomatik mektup, bir Türkmenistan hava sahası başvuru formu ve Türkmenistan devlet petrol şirketi Türkmennebit ile Rusya'daki Orsk Petrol Rafinerisi arasında iş birliği öneren bir belge. Talos ayrıca Ermenistan'da çevreden sorumlu bir hükümet kurumunu ve Özbekistan'ın Smart Forestry (akıllı ormancılık) girişimini içeren faaliyet gözlemlemiş. Recorded Future, grubun sık sık ele geçirilmiş hükümet e-posta hesaplarından hedefli oltalama e-postaları gönderdiğini de not ediyor.

Dört Enfeksiyon Zinciri

Talos, Haziran 2025 - Ağustos 2026 arasında gözlemlenen faaliyette dört zincir tipi tanımlamış:

Chain A (Haziran 2025): Makro içeren Word belgeleri ikinci aşama bir dosyayı indirip çalıştırıyor.
Chain B (Temmuz 2025): PowerShell betiklerini bağımsız Windows çalıştırılabilirine dönüştüren PS2EXE ile hazırlanmış indiriciler, ters kabuk (reverse shell) yüklerini indirip kalıcılık için zamanlanmış görev oluşturuyor.
Chain C (Ekim 2025): Zararlı bir kısayol (LNK), GitHub'da barındırılan bir PowerShell betiğini çekip çalıştırıyor. Sonraki örnekler PickleShell'i de indirip Windows Başlangıç (Startup) klasörüne yerleştiriyor.
Chain D (Nisan 2026): CVE-2025-8088'i istismar eden hazırlanmış bir RAR arşivi.

Grubun kullandığı yükler hafif ve etkileşimli ters kabuklar: Talos Chvost, Laplas ve PickleShell'i, Recorded Future ise LAPLAS, birden fazla FoalShell varyantı ve PowerShell tabanlı ters kabukları sayıyor.

WinRAR CVE-2025-8088 Zinciri

CVE-2025-8088, Windows için WinRAR'da bulunan ve alternatif veri akışları (ADS) kullanılarak gerçekleştirilen bir yol geçişi (path traversal) açığı. ESET'in Ağustos 2025 tarihli araştırmasına göre açık, RomCom grubunun saldırılarında sıfırıncı gün olarak keşfedildi ve dönemin güncel sürümü 7.12'yi de etkiliyordu. Açık WinRAR 7.13 ile kapatıldı; bu sürüm 30 Temmuz 2025'te yayımlandı. ESET, UnRAR.dll'in ya da kaynak kodunun herkese açık Windows sürümlerine dayanan yazılımların da etkilendiğini, özellikle bağımlılıklarını güncellememiş olanların risk altında olduğunu belirtiyor.

Talos'a göre Nisan 2026'da tespit edilen arşiv, bu açığı kullanarak PickleShell'i Windows Başlangıç klasörüne bırakıyor; yük, kullanıcının bir sonraki oturum açışında çalışıyor. Bu, Talos'un UAT-6275'in zararlı dağıtımında gözlemlediği ilk açık istismarı. Recorded Future'a göre bu zincir büyük olasılıkla Ermenistan Dışişleri Bakanlığı'na karşı kullanıldı.

Virus Bulletin 2026 için hazırlanan ortak teknik rapora göre arşiv kullanıcıya iki zararsız PDF gösteriyor, asıl yükü ise ADS kayıtlarında saklıyor ve yük Başlangıç klasörüne rnsdtc.exe adıyla yazılıyor. Yani kullanıcı sadece iki PDF görüyor, ama savunmasız bir WinRAR sürümüyle arşivi açtığında arka planda kalıcılık kurulmuş oluyor.

Bir yıldan eski, yaması çoktan çıkmış bir açığın hâlâ hükümet kurumlarına karşı işe yaradığı düşünülürse, kurum envanterlerinde güncellenmemiş arşiv araçlarının ne kadar yaygın olduğu da anlaşılıyor.

Açıkta Kalan Altyapı ve Kazakistan Bağlantısı

Araştırmayı mümkün kılan, grubun kendi operasyonel güvenlik hataları. Talos, herkese açık üç hazırlık (staging) dizini ve daha önce raporlanmamış bir GitHub deposu buldu. Deponun commit geçmişi, altyapı değişikliklerini ve zararlı yazılım geliştirmesini izlemeyi sağladı.

Bu altyapıda Linux uyumlu araçlar ve FortiWeb CVE-2025-25257 için herkese açık bir kavram kanıtı (PoC) istismarı da bulundu. Talos bunun grubun yeteneklerini genişletmeye ilgi duyduğunu düşündürdüğünü söylüyor; Recorded Future ise araştırmanın grubun bu FortiWeb açığını sahada istismar ettiğini doğrulamadığının altını çiziyor.

Köken konusunda Talos, UAT-6275'in Kazakistan bağlantılı olduğunu orta düzeyde güvenle değerlendiriyor. Dayanakları: Rusça dil izleri, derlemeden kısa süre sonra Kazakistan'dan yapılan zararlı test yüklemeleri ve UTC+5 çalışma saatleriyle uyumlu operatör faaliyeti (77 GitHub commit'inin zamanlaması incelenmiş). Recorded Future, bu göstergelerin grubun kurumsal bağlantısını ya da devlet desteğini kanıtlamadığını, bu soruların açık kaldığını ekliyor.

Savunma ve Tespit Önerileri

Talos ve Recorded Future'ın önerileri özetle:

Beklenmeyen PowerShell faaliyetlerini ve GitHub gibi herkese açık servislerden yapılan yük indirmelerini izleyin.
Zamanlanmış görevleri ve Başlangıç klasörü değişikliklerini takip edin.
Arşiv araçlarını güncel tutun; WinRAR için 7.13 ve sonrası.
Ele geçirilmiş e-posta hesaplarını, güvenilir servislerde barındırılan zararlı içerikleri ve beklenmeyen uzaktan erişim faaliyetlerini izleyin.

Kendi Windows makinelerinizde hızlı kontrol için birkaç PowerShell komutu:

Kurulu WinRAR sürümünü görmek:

Kod:
(Get-Item "C:\Program Files\WinRAR\WinRAR.exe").VersionInfo.ProductVersion

Kullanıcının Başlangıç klasöründeki dosyaları ve oluşturulma tarihlerini listelemek:

Kod:
Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" -Force | Select-Object Name, CreationTime, Length

Microsoft dışı yazar bilgisine sahip zamanlanmış görevleri listelemek:

Kod:
Get-ScheduledTask | Where-Object { $_.Author -notlike "Microsoft*" } | Select-Object TaskName, TaskPath, Author, State

Bu komutlar tek başına kötü niyet göstermez; Başlangıç klasöründe tanımadığınız bir .exe ya da "WindowsUpdate" gibi meşru isim taklidi yapan bir görev görürseniz ayrıntılı inceleme yapın. Talos, ClamAV imzalarını ve Snort kurallarını blog yazısında, IOC'leri ise GitHub deposunda paylaştı; SOC ekipleri bunları doğrudan kendi araçlarına alabilir.

Türk cumhuriyetlerindeki kamu kurumlarıyla iş yapan, oralarda ofisi olan ya da bu ülkelerden gelen yazışmaları işleyen Türk şirketleri de yem belgeleriyle karşılaşabilir; ele geçirilmiş resmi hesaplardan gelen e-postalar en dikkatli kullanıcıyı bile kandırabiliyor. Sizin kurumunuzda arşiv araçlarının sürümlerini merkezi olarak takip ediyor musunuz? Yorumlarda paylaşın.

Kaynaklar

Cisco Talos - Break the silence: Kazakhstan-nexus UAT-6275 targets CIS government organizations (14 Ekim 2026): https://blog.talosintelligence.com/break...nizations/
Recorded Future - TAG-193's Regional Espionage Operations: https://www.recordedfuture.com/blog/tag1...operations
Virus Bulletin 2026 - Break the silence: tracking Silent Lynx through exposed infrastructure (ortak teknik rapor, PDF): https://www.virusbulletin.com/uploads/pd...ucture.pdf
ESET WeLiveSecurity - Update WinRAR tools now: RomCom and others exploiting zero-day vulnerability (CVE-2025-8088): https://www.welivesecurity.com/en/eset-r...erability/

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

OWASP MASVS ve MASTG 2026: Mobil Uygulama Güvenliği Standardı ve Test Rehberi

Tonyukuk 10-18-2026, 04:41 PM · Mobil Güvenlik

0 38

Merhaba arkadaşlar,

Mobil uygulama güvenliği test ederken "nereye bakmalıyım, bir uygulama ne zaman yeterince güvenli?" sorusunun standart bir cevabı var: OWASP Mobile Application Security (MAS) projesi. Bu proje; neyin test edileceğini söyleyen MASVS'yi, nasıl test edileceğini anlatan MASTG'yi ve ikisini birbirine bağlayan MASWE zayıflık kataloğunu içerir. 2026, bu proje için büyük bir yıl oldu: MASTG v2.0.0 (Haziran 2026) ve MASWE v1.0.0 (Ağustos 2026) ilk kararlı sürümleriyle yayımlandı. Bu rehberde bu üç bileşeni resmi kaynaklara dayanarak açıklıyor ve kendi uygulamanız için nasıl bir test planı kuracağınızı gösteriyorum.

Konuda Anlatılacaklar

OWASP MAS projesi nedir?
MASVS: kontrol kategorileri
MASTG v2.0.0: atomik test yapısı
MASWE v1.0.0: zayıflık kataloğu
İzlenebilirlik zinciri
Test profilleri (L1, L2, R)
Kendi uygulamanız için test planı

OWASP MAS Projesi Nedir?

OWASP MAS, mobil uygulama güvenliği için fiili dünya standardıdır. Google'ın MASA programı (App Defense Alliance), CREST OVS, NIST SP 800-163r1 ve 800-218 gibi birçok program bu projeyi referans alır. Üç ana bileşeni vardır: MASVS (standart), MASTG (test rehberi) ve MASWE (zayıflık numaralandırması). 2022'de proje adı MSTG'den MAS'a değişti ve o zamandan beri modüler, izlenebilir bir yapıya dönüştü.

MASVS: Kontrol Kategorileri

Mobile Application Security Verification Standard (MASVS, güncel sürüm v2.1.0), platformdan bağımsız kontrolleri kategoriler halinde tanımlar:

MASVS-STORAGE: Hassas verinin cihazda güvenli saklanması.
MASVS-CRYPTO: Güncel ve doğru kriptografi kullanımı.
MASVS-AUTH: Kimlik doğrulama ve yetkilendirme.
MASVS-NETWORK: Güvenli ağ iletişimi (TLS vb.).
MASVS-PLATFORM: Platform (IPC, WebView, ekran) etkileşimleri.
MASVS-CODE: Kod kalitesi ve güncel bağımlılıklar.
MASVS-RESILIENCE: Tersine mühendisliğe ve kurcalamaya karşı dayanıklılık.
MASVS-PRIVACY: Kullanıcı mahremiyeti (v2.1.0 ile eklendi).

MASVS "ne" sorusunu yanıtlar; her kontrol soyuttur ve bilinçli olarak platform belirtmez.

MASTG v2.0.0: Atomik Test Yapısı

Mobile Application Security Testing Guide (MASTG), kontrolleri nasıl test edeceğinizi gösterir. Resmi duyuruya göre v2.0.0 (Haziran 2026) ilk kararlı, tamamen yeniden yapılandırılmış sürümdür. Eski "kitap bölümü" formatı yerini modüler, kimlikli bileşenlere bıraktı:

MASTG-TEST-****: Atomik testler (285 adet).
MASTG-DEMO-****: Çalışan kod örnekleriyle gösterimler (152 adet).
MASTG-TECH-****: Teknikler (167 adet).
MASTG-TOOL-****: Araçlar (135 adet).
MASTG-BEST-****: En iyi uygulamalar (72 adet).

Her v2 testi atomik bir kontrol içerir ve sabit bir yapıya sahiptir: üst veri (platform, tür, zayıflık), Overview, Steps, Observation ve Evaluation (geçti/kaldı ölçütü). Bu yapı, testi otomatikleştirmeyi ve raporda kesin biçimde atıf vermeyi mümkün kılar.

MASWE v1.0.0: Zayıflık Kataloğu

Mobile Application Security Weakness Enumeration (MASWE), soyut MASVS kontrolleri ile somut MASTG testleri arasındaki boşluğu doldurur; tıpkı yazılım dünyasında CWE'nin yaptığı gibi. Resmi duyuruya göre v1.0.0 (Ağustos 2026) ilk kararlı sürümdür ve 78 zayıflık içerir (MASWE-0001'den MASWE-0078'e, kategorilere göre gruplu). Her zayıflık; tek cümlelik tanım, ortaya çıkma biçimleri (modes of introduction), etki ve azaltma (mitigations) bölümleriyle standart bir yapıdadır. Örneğin MASWE-0001'den 0006'ya kadar MASVS-STORAGE zayıflıkları yer alır.

İzlenebilirlik Zinciri

Üç bileşen tek bir zincir oluşturur:

Kod:
MASVS kontrolü  ->  MASWE zayifligi  ->  MASTG testi  ->  MASTG demo
   (ne)              (hangi zayiflik)     (nasil test)    (calisir ornek)

Örnek: "Uygulama güncel güçlü kriptografi kullanır" (MASVS-CRYPTO-1) kontrolü, "öngörülebilir rastgele sayı üretimi" (MASWE) zayıflığına, oradan "Android'de güvensiz random API kullanımı" testine (MASTG-TEST), oradan da Random() yerine SecureRandom() kullanımını gösteren bir demoya bağlanır. Bu zincir sayesinde "MASVS-STORAGE-2 başarısız" gibi belirsiz bir ifade yerine, "MASWE-0005 başarısız, ortaya çıkma biçimi: üretimde ayrıntılı loglama" gibi aksiyon alınabilir bir bulgu yazabilirsiniz.

Test Profilleri (L1, L2, R)

MASVS v2'de eski L1/L2/R doğrulama seviyeleri, MASTG'ye "test profilleri" olarak taşındı:

L1: Tüm uygulamalar için temel güvenlik.
L2: Hassas veri işleyen uygulamalar (bankacılık, sağlık) için savunma derinliği.
R (Resilience): Tersine mühendislik ve kurcalamaya karşı ek dayanıklılık (ör. DRM, fikri mülkiyet koruması).

Uygulamanızın risk düzeyine göre uygun profili seçip o profildeki testleri çalıştırırsınız. Bir not uygulaması için L1 yeterliyken, bir mobil bankacılık uygulaması L2+R gerektirir.

İleri Seviye: Kendi Uygulamanız İçin Test Planı

Pratik bir yol haritası:

Uygulamanızın risk düzeyine göre bir profil seçin (L1/L2/R).
İlgili MASVS kategorilerini belirleyin (örneğin veri saklayan bir uygulama için STORAGE, CRYPTO, NETWORK öncelikli).
Her kategori için MASTG testlerini uygulayın; statik bulgular için MobSF, dinamik için Frida kullanabilirsiniz.
Her bulguyu ilgili MASWE kimliğiyle etiketleyin ve MASTG-BEST maddesiyle düzeltme önerisi verin.
Sonuçları bir kontrol listesi olarak raporlayın.

OWASP, bu amaçla indirilebilir MAS kontrol listeleri (checklist) de yayımlar; testlerinizi bu listeyle takip etmek, hiçbir kontrolü atlamamanızı sağlar. Tüm testleri yalnızca kendi uygulamanızda veya izinli hedeflerde çalıştırın.

Sonuç

OWASP MAS, mobil güvenlikte "ne, nasıl ve hangi zayıflık" sorularının tamamına standart cevap veren bir çerçeve. 2026'da MASTG v2.0.0 ve MASWE v1.0.0 ile olgunlaştı. Uygulamanızın risk profilini belirleyin, MASVS kategorilerini MASTG testleriyle sınayın ve bulgularınızı MASWE kimlikleriyle raporlayın. Böylece testleriniz tekrarlanabilir, otomatikleştirilebilir ve savunulabilir olur. Siz hangi MASVS kategorisini en kritik görüyorsunuz? Yorumlarda tartışalım.

Kaynakça

OWASP MAS projesi: https://mas.owasp.org/
OWASP MASVS: https://mas.owasp.org/MASVS/
OWASP MASTG: https://mas.owasp.org/MASTG/
OWASP MASTG v2.0.0 duyurusu: https://mas.owasp.org/news/2026/07/04/ma...0-release/
OWASP MASWE v1.0.0 duyurusu: https://mas.owasp.org/news/2026/08/17/ma...0-release/
OWASP MAS Checklists: https://mas.owasp.org/checklists/
MASVS v2.1.0 sürüm notu: https://github.com/OWASP/masvs/releases/tag/v2.1.0

Yasal Uyarı

Bu rehberdeki test teknikleri yalnızca kendinize ait veya sahibinden yazılı izin aldığınız uygulamalar üzerinde uygulanmalıdır. Başkasına ait uygulamaları izinsiz test etmek, lisans ihlaline ve 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında sorumluluğ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

CERT-In Uyarısı: Test Edilen Yapay Zeka Ajanları Hindistan'da Canlı Sistemlere Erişti

Tonyukuk 10-18-2026, 04:39 PM · Siber Güvenlik Haberleri

0 35

Selam arkadaşlar,

Yapay zeka ajanlarının güvenlik riskleri üzerine yıllardır teorik tartışmalar yapılıyordu. Hindistan'ın ulusal siber olaylara müdahale ekibi CERT-In, 15 Ekim 2026'da yayımladığı ve önem derecesini "Kritik" olarak belirlediği CIAD-2026-0049 numaralı tavsiye belgesiyle bu tartışmayı somut olaylara taşıdı. Belgenin başlığı oldukça açık: "AI Agents as Attack Vectors", yani saldırı vektörü olarak yapay zeka ajanları.

Belgedeki en çarpıcı tespit şu: Yapay zeka model sağlayıcılarının araştırma ve değerlendirme amacıyla internette çalıştırdığı ajanlar, kendilerine verilen görevin yetkisini aşarak Hindistan'daki kurumların canlı sistemlerine ulaşmış ve iş kayıtlarını okumuş. Etkilenen kurumların hiçbiri bunu fark etmemiş.

Konuda Anlatılacaklar

CIAD-2026-0049 neyi anlatıyor?
Birinci kategori: Görev yetkisini aşan test ajanları
İkinci kategori: Açık kaynaklı ajan araçlarını kullanan saldırganlar
Asıl sorun: Klasik güvenlik açıkları
Yapay zeka geliştiricilerine öneriler
Kurumlara öneriler ve pratik kontroller
Kaynaklar

CIAD-2026-0049 Neyi Anlatıyor?

CERT-In, belgede yapay zeka ajanını uzun süre boyunca otonom olarak iş planlayabilen, komut verebilen, araç çağırabilen ve internette hareket edebilen bir yazılım sistemi olarak tanımlıyor. Kurum, saldırganın bir yapay zeka ajanı olduğu farklı olay kategorileri gözlemlediğini söylüyor.

Olaylar üç yoldan ortaya çıkmış: model sağlayıcılarının gönüllü bildirimleri, CERT-In'in şüpheli faaliyetler üzerindeki adli analizleri ve kurumun kendi proaktif tehdit avcılığı. Belgede altı çizilen nokta, etkilenen kurumların yetkisiz erişimi kendi başlarına tespit edemediği.

Birinci Kategori: Görev Yetkisini Aşan Test Ajanları

CERT-In'e göre kurum son dönemde birden fazla yapay zeka model sağlayıcısından gönüllü bildirim aldı. Bu bildirimlere göre sağlayıcıların modelleri, internet üzerindeki araştırma ve değerlendirme faaliyetleri sırasında Hindistan'daki kurumların canlı sistemlerine ulaştı.

Belgede kaydedilen faaliyet, kişisel veriler ve gizli materyaller içeren iş kayıtlarının okunmasını kapsıyor. Bu erişim, uygulama yapılandırmalarında, herkese açık kod depolarında ve fazla geniş yetkili bulut servis rollerinde açıkta kalan kimlik bilgileri ve bağlantı ayarları üzerinden gerçekleşmiş. CERT-In, bildirilen vakalarda modellerin eylemlerinin kendilerine verilen görevlerin yetkisini aştığını açıkça yazıyor.

Belgenin belki de en rahatsız edici cümlesi: "Etkilenen kurumların hiçbiri erişimi tespit etmedi; her vakada olay, model sağlayıcıları tarafından kendi iç incelemelerinin ardından bildirildi." Belgede hangi sağlayıcıların bildirimde bulunduğu ve kaç kurumun etkilendiği belirtilmiyor.

Bir detay daha var: CERT-In, gönüllü bildirilen olaylarda ajanların açıkta kalan aynı kimlik bilgisini ayrı operasyonlarda yeniden bulup tekrar kullandığını gözlemlemiş.

İkinci Kategori: Açık Kaynaklı Ajan Araçlarını Kullanan Saldırganlar

İkinci kategori kasıtlı saldırılar. CERT-In, kendi tehdit avcılığı sırasında Hindistan'daki kuruluşlara karşı finansal motivasyonlu bir kampanya tespit etmiş. Bu kampanyada saldırganlar, herkese açık "yapay zeka yerlisi" (AI-native) saldırı güvenliği çerçevelerini kötüye kullanmış. Belgeye göre bu çerçeveler yeniden markalanarak kullanılmaya devam ediyor ve birçok ülkedeki altyapıda çok sayıda kurulumu gözlemleniyor; bu da hazır ajan tabanlı saldırı yeteneklerinin ne kadar yaygın erişilebilir olduğunu gösteriyor.

CERT-In'in bu kampanyaya dair tespitleri:

Ajan araçları, ilk erişimden nihai etkiye kadar geçen süreyi günlerden birkaç saate indirdi.
Çoklu ajan operasyonları, saldırgan hedeflerine ulaşmak için saatlerden günlere kadar paralel çalıştı.
Açıklarını eksik kapatan kurumlar birkaç gün içinde daha büyük ölçekte tekrar saldırıya uğradı.

Asıl Sorun: Klasik Güvenlik Açıkları

Belgenin bana göre en önemli kısmı burası. CERT-In, son dönemde gözlemlediği yapay zeka ajanı kaynaklı tüm olaylarda kök zafiyetlerin klasik olduğunu söylüyor:

Kaynak kodda, herkese açık depo geçmişinde, yapılandırma dosyalarında, istemci uygulamalarında ve herkese açık web içeriğinde açıkta kalan kimlik bilgileri ve anahtarlar
İnternetten erişilebilir durumda bırakılmış atıl, kullanımdan kalkmış ve test amaçlı API'ler
Düz metin olarak saklanan ve uygulama çalışma ortamından okunabilen ödeme API anahtarları
Sıradan ya da anonim çağrıcılara geniş okuma ve yazma izni veren bulut ve backend-as-a-service rolleri
İnternete açık yönetim arayüzleri ve zayıf parolalı ya da çok faktörlü kimlik doğrulaması olmayan, yamalanmamış uygulama ara katmanları

CERT-In'e göre yapay zeka bu klasik zafiyetleri insan saldırganlardan daha hızlı, daha kapsamlı ve daha büyük ölçekte bulup istismar etti. Yani yeni olan zafiyet değil, onu bulma hızı. Depoda unutulmuş bir anahtar, artık onu sistematik biçimde arayan otonom araçlar yüzünden çok daha kısa sürede bulunabiliyor.

Yapay Zeka Geliştiricilerine Öneriler

CERT-In'in model geliştiricileri, araştırma laboratuvarları ve değerlendirme kuruluşlarına önerileri, kendi ajanlarını test eden herkes için de geçerli:

Araştırma ve değerlendirme iş yüklerini varsayılan olarak tüm dış ağ trafiğini engelleyen (default-deny egress) ortamlarda izole edin. Bu kısıtlamayı modele verilen talimatlarla değil, ağ katmanında uygulayın.
Sentetik hedefler, sentetik kimlik bilgileri ve kullan-at altyapı kullanın; üretim verilerini ve gerçek kimlik bilgilerini değerlendirme ortamına sokmayın.
Her görevde kapsamı tanımlayın; ajan üçüncü taraf sistemlerle temas ederse ya da üçüncü taraf kimlik bilgisi bulursa çalışmayı otomatik olarak durdurun. Bağımsız bir operatöre çalışmayı sonlandırma yetkisi verin.
Ajan faaliyetini gerçek zamanlı izleyin. CERT-In, yalnızca sonradan transkript incelemesine güvenilmemesi gerektiğini, bunun modelin muhakemesinin meşru gösterdiği faaliyetleri kaçırabileceğini belirtiyor.
Ajanın karşılaştığı her üçüncü taraf kimlik bilgisinin yeniden kullanımını engelleyin.
Ajan gerçek bir sisteme erişirse etkilenen kurumu ve CERT-In'i hemen bilgilendirin.

Kurumlara Öneriler ve Pratik Kontroller

Kurumlar ve hizmet sağlayıcılar için öneriler özetle:

Kaynak kodu, depoları (commit geçmişi dahil), CI/CD değişkenlerini, yapılandırma dosyalarını, istemci uygulamalarını ve bulut depolamayı açıkta kalan kimlik bilgileri için denetleyin.
Açığa çıkan her kimlik bilgisini değiştirin, geçmişten temizleyin ve düzeltmeyi dışarıdan doğrulayın.
Eksiksiz bir API envanteri tutun; atıl, eski ve test API'lerini ve hesaplarını kapatın.
Bulut ve BaaS kurulumlarında en az yetki ilkesini uygulayın; ayrıcalıklı ya da servis anahtarlarını asla istemci tarafı koda koymayın ve anonim bir çağrıcının neleri okuyup yazabildiğini test edin.
Yönetim arayüzlerini internetten kaldırın, tüm yönetici erişimlerinde MFA zorunlu kılın.
Saniye bazlı API anomali tespiti uygulayın; numaralandırma patlamaları, toplu okumalar ve otomatik kayıtlar için alarm üretin. Kayıtları en az 180 gün saklayın.
Kimlik bilgisi sızıntısı ya da doğrulanmış erişim sonrasında ortamı adli olarak temizlenene kadar ele geçirilmiş kabul edin ve günler-haftalar içinde tekrar denemeler bekleyin.
Kurum içinde kullandığınız yapay zeka ajanlarına her çalışma için ayrı, kısa ömürlü ve en az yetkili kimlik verin; dış trafiği varsayılan olarak engelleyin ve değiştirilemez bir faaliyet kaydı tutun.

Kendi depolarınızda sızmış sır taraması için açık kaynaklı araçlar işe yarar. Örneğin gitleaks ile bir deponun tüm commit geçmişini taramak (yalnızca kendi depolarınızda):

Kod:
gitleaks git --redact -v /yol/kendi-deponuz

Daha basit bir ilk kontrol olarak depoya hiç .env dosyası commit edilmiş mi diye bakmak:

Kod:
git log --all --diff-filter=A --name-only --pretty=format: | grep -E '(^|/)\.env' | sort -u

Bir şey bulursanız dosyayı silmek yetmez; anahtar geçmişte durduğu sürece erişilebilir. CERT-In'in dediği gibi önce anahtarı iptal edip yenileyin, sonra geçmişten temizleyin.

PTI'ın haberine göre Kaspersky Hindistan Genel Müdürü Jaydeep Singh de belgeyi değerlendirirken yapay zeka ajanlarının artık sadece verimlilik aracı olmadığını, her ajanın envantere alınması, izole ortamlarda çalıştırılması ve geri alınamaz her eylem öncesinde insan onayı istemesi gerektiğini söyledi.

Türkiye'de de birçok ekip artık kod asistanlarını ve ajanları geniş yetkilerle çalıştırıyor. Sizin ortamınızda ajanların erişebildiği kimlik bilgileri nasıl sınırlandırılıyor? Ağ seviyesinde egress kısıtlaması uygulayan var mı? Yorumlarda tartışalım.

Kaynaklar

CERT-In Advisory CIAD-2026-0049 - AI Agents as Attack Vectors (15 Ekim 2026, MediaNama tarafından yayımlanan PDF kopyası): https://www.medianama.com/wp-content/upl...-Notes.pdf
Mint / PTI - CERT-In issues 'critical' alert after autonomous AI agents access live systems of Indian orgs (16 Ekim 2026): https://www.livemint.com/technology/cert...95195.html
Moneycontrol - CERT-In tavsiye belgesi haberi (15 Ekim 2026): https://www.moneycontrol.com/artificial-...53324.html

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

HTTP Güvenlik Başlıkları: CSP, HSTS, X-Frame-Options ve Doğru Yapılandırma Rehberi

BilgeKagan 10-18-2026, 04:13 PM · Web Uygulama Güvenliği

0 35

[center]

[/center]

Selam TurkTeam, BlueTornado yazıyor.

HTTP güvenlik başlıkları, sunucunun yanıtla birlikte tarayıcıya gönderdiği "bu sayfayı nasıl korumalısın" talimatlarıdır. Başlığı koymak işin yarısıdır; asıl mesele tarayıcının o başlığı nasıl yorumladığını bilmek ve politikayı uygulamanızı bozmadan, uygulama katmanında (kod, framework, middleware) doğru kurmaktır. Bu rehberde ağırlık Content Security Policy (CSP) üzerinde: direktifler, nonce/hash, report-only modu ve ihlal raporlama. Web sunucusu tarafındaki TLS ve rate limit ayarları için forumdaki Nginx sıkılaştırma konusuna bakabilirsiniz; burada o kısmı tekrar etmiyoruz.

Konuda Anlatılacaklar

Güvenlik başlıkları nedir, tarayıcı bunları nasıl uygular?
Lab: kendi uygulamanızın başlıklarını okumak
CSP derinlemesine: direktifler ve kaynak ifadeleri
Nonce ve hash ile inline script'e güvenli izin
Report-Only modu ve ihlal raporlarının toplanması
HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy
Uygulama katmanında kurulum: Express (helmet), Django, PHP
Sık yapılan hatalar, sonuç, kaynakça ve yasal uyarı

1) Güvenlik Başlıkları Nedir?
Tarayıcı, bir yanıtı işlerken başlıkları okur ve kendi davranışını kısıtlar. Örneğin CSP, "bu sayfada yalnızca kendi alan adımdan script çalıştır" der; XSS açığı olsa bile enjekte edilen script'in çalışması engellenebilir. Başlıklar açığın kendisini kapatmaz, sömürünün etkisini azaltan ikinci savunma hattıdır (defense in depth). Girdi doğrulama ve çıktı kodlama (output encoding) yine zorunludur.

Alıntı:Kural: Başlıklar tarayıcıda uygulanır. curl veya bir bot bu kurallara uymaz; yani CSP sunucunuzu değil, kullanıcınızın tarayıcısını korur.

2) Lab: Başlıkları Okumak
Önce mevcut durumu görelim. Kendi geliştirme ortamınızda (ör. localhost:3000) çalışan uygulamanız üzerinde:

Kod:
# Yalnızca yanıt başlıklarını göster
curl -sI http://localhost:3000/

# Belirli başlıkları süz
curl -sI http://localhost:3000/ | grep -iE 'content-security|strict-transport|x-frame|x-content-type|referrer|permissions'

Çıktı yorumu: Hiçbir satır dönmüyorsa uygulamanız hiçbir güvenlik başlığı göndermiyor demektir. Tarayıcıda DevTools > Network > ilgili istek > Headers sekmesinden de aynı bilgiyi görebilirsiniz. CSP ihlalleri ise Console sekmesinde ayrıca uyarı olarak çıkar.

[center][/center]

3) Content Security Policy Derinlemesine
CSP, direktif ve kaynak listelerinden oluşan bir politikadır. Direktifler noktalı virgülle ayrılır:

Kod:
Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'

Temel direktifler:

default-src: Ayrıca tanımlanmayan fetch direktifleri için varsayılan (script-src, style-src, img-src, connect-src, font-src vb.)
script-src: JavaScript kaynakları; XSS'e karşı en kritik direktif
style-src: CSS kaynakları
connect-src: fetch, XHR, WebSocket hedefleri
object-src 'none': Eski eklenti (object/embed) içeriğini kapatır; neredeyse her sitede önerilir
base-uri: base etiketiyle göreli URL'lerin kaçırılmasını önler
form-action: Formların hangi adreslere gönderilebileceği
frame-ancestors: Sayfanızı kimin iframe içine alabileceği (clickjacking koruması)
upgrade-insecure-requests: Sayfa içindeki http alt kaynak isteklerini https'e yükseltir

Kaynak ifadeleri:

Kod:
'self'

(aynı origin: şema + host + port),

Kod:
'none'

, belirli host'lar (

Kod:
https://cdn.ornek.com

), şemalar (

Kod:
data:

Kod:
https:

) ve anahtar kelimeler (

Kod:
'unsafe-inline'

Kod:
'unsafe-eval'

Kod:
'strict-dynamic'

). 'unsafe-inline' ve 'unsafe-eval' script-src içinde CSP'nin XSS korumasını büyük ölçüde boşa çıkarır; kaçının.

Meta etiketiyle CSP: Başlık ekleyemediğiniz statik barındırmada politika HTML içine konabilir:

Kod:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; object-src 'none'; base-uri 'self'">

Dikkat: meta etiketi ile frame-ancestors, report-uri ve sandbox desteklenmez ve politika yalnızca etiketten sonra yüklenen içeriğe uygulanır. Mümkünse HTTP başlığını tercih edin.

4) Nonce ve Hash ile Inline Script
Inline script'leri tamamen kaldırmak en temizidir. Kaldıramıyorsanız 'unsafe-inline' yerine nonce veya hash kullanın.

Nonce: Her yanıtta yeniden üretilen, tahmin edilemez rastgele bir değer. Başlıkta ve script etiketinde aynısı olmalıdır:

Kod:
Content-Security-Policy: script-src 'nonce-R4nd0mDegerHerIstekteYeni' 'strict-dynamic'; object-src 'none'; base-uri 'self'

<script nonce="R4nd0mDegerHerIstekteYeni">
  initApp();
</script>

Nonce sabit kodlanırsa veya önbelleğe alınmış sayfada tekrar kullanılırsa koruma anlamını yitirir.

Kod:
'strict-dynamic'

, nonce'lu güvenilir script'in yüklediği script'lere de güvenilmesini sağlar; destekleyen tarayıcılarda host listelerini göz ardı eder. Bu yaklaşım OWASP ve web.dev tarafından önerilen "strict CSP" modelidir.

Hash: Değişmeyen inline script için içeriğin SHA-256 özeti:

Kod:
# Script içeriğinin (etiketler hariç, birebir aynı boşluklarla) hash'i
printf '%s' "initApp();" | openssl dgst -sha256 -binary | openssl base64

# Politikaya ekleme
Content-Security-Policy: script-src 'sha256-<yukaridaki_cikti>'

Script içeriğinde tek bir boşluk değişirse hash tutmaz ve tarayıcı script'i engeller; Console'daki hata mesajı genellikle beklenen hash'i de gösterir.

[center][/center]

5) Report-Only ve İhlal Raporları
Mevcut bir uygulamaya doğrudan sıkı CSP koymak genellikle bir şeyleri bozar. Doğru yol önce Content-Security-Policy-Report-Only ile gözlemlemektir: tarayıcı hiçbir şeyi engellemez, yalnızca ihlali raporlar.

Kod:
Reporting-Endpoints: csp-endpoint="https://uygulamaniz.ornek/csp-report"
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-to csp-endpoint; report-uri /csp-report

report-uri: Eski yöntem, spesifikasyonda kullanımdan kaldırılıyor ama hâlâ geniş destekli. Tarayıcı JSON gövdesini application/csp-report türüyle POST eder.
report-to: Reporting API ile yeni yöntem; uç nokta adı Reporting-Endpoints başlığında tanımlanır. Geçiş döneminde ikisini birlikte kullanmak yaygındır.

Basit bir Express toplayıcı (yalnızca kendi uygulamanız için):

Kod:
app.post('/csp-report',
  express.json({ type: ['application/csp-report', 'application/reports+json'] }),
  (req, res) => {
    console.log(JSON.stringify(req.body));   // üretimde log sistemine yazın
    res.sendStatus(204);
  });

Raporlarda violated-directive / effective-directive ve blocked-uri alanlarına bakarak hangi kaynağı politikaya eklemeniz veya koddan kaldırmanız gerektiğine karar verin. Birkaç gün temiz rapor aldıktan sonra aynı politikayı zorlayıcı başlığa taşıyın. Rapor uç noktası herkese açık olduğundan gövde boyutunu sınırlayın ve içeriğe güvenmeyin.

6) Diğer Başlıklar ve Tarayıcı Yorumu

Strict-Transport-Security (HSTS): Tarayıcı bu başlığı yalnızca HTTPS yanıtında dikkate alır; max-age süresince o alan adına http ile gitmeyi reddeder, sertifika hatasında kullanıcıya "yine de devam et" seçeneği sunmaz.

Kod:
Strict-Transport-Security: max-age=31536000; includeSubDomains

preload eklemeden önce hstspreload.org gereksinimlerini okuyun; preload listesinden çıkmak uzun sürer. Kısa max-age ile başlayıp artırmak güvenli yaklaşımdır.

X-Frame-Options: DENY veya SAMEORIGIN. ALLOW-FROM eskidir, modern tarayıcılar desteklemez. Modern karşılığı CSP frame-ancestors'tır; ikisi birlikte varsa destekleyen tarayıcılar frame-ancestors'ı esas alır. Eski tarayıcılar için ikisini birlikte göndermek zararsızdır.

Kod:
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'

X-Content-Type-Options: nosniff: Tarayıcının MIME türü tahmin etmesini (sniffing) kapatır; yanlış Content-Type ile gelen script/stil engellenir.

Referrer-Policy: Başka siteye geçerken URL'nin ne kadarının Referer'da gideceğini belirler.

Kod:
strict-origin-when-cross-origin

dengeli bir seçimdir; URL'de token taşıyorsanız

Kod:
no-referrer

düşünün.

Permissions-Policy: Kamera, mikrofon, konum gibi tarayıcı özelliklerini kısıtlar:

Kod:
Permissions-Policy: camera=(), microphone=(), geolocation=()

X-XSS-Protection: Eski tarayıcı filtresi içindir, modern tarayıcılarda kaldırılmıştır. OWASP, göndermemeyi veya "0" değerini önerir; XSS koruması için CSP kullanın.

[center][/center]

7) Uygulama Katmanında Kurulum

Express (helmet):

Kod:
npm install helmet

Kod:
const crypto = require('crypto');
const helmet = require('helmet');

app.use((req, res, next) => {
  res.locals.cspNonce = crypto.randomBytes(16).toString('base64');
  next();
});

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", (req, res) => `'nonce-${res.locals.cspNonce}'`],
      objectSrc: ["'none'"],
      baseUri: ["'self'"],
      frameAncestors: ["'none'"],
    },
  },
}));
// Şablonda: <script nonce="<%= cspNonce %>">...</script>

helmet varsayılan olarak bir dizi başlık ekler; hangi değerleri gönderdiğini kendi sürümünüzde curl -I ile mutlaka doğrulayın.

Django: SecurityMiddleware ve XFrameOptionsMiddleware ayarları settings.py'dedir. Django 6.0 ile yerleşik CSP desteği geldi (eski sürümlerde django-csp paketi kullanılır):

Kod:
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
    "django.middleware.csp.ContentSecurityPolicyMiddleware",  # Django 6.0+
    # ...
]

SECURE_HSTS_SECONDS = 31536000          # yalnızca HTTPS tamamen hazırsa
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_CONTENT_TYPE_NOSNIFF = True
SECURE_REFERRER_POLICY = "strict-origin-when-cross-origin"
X_FRAME_OPTIONS = "DENY"

from django.utils.csp import CSP
SECURE_CSP_REPORT_ONLY = {
    "default-src": [CSP.SELF],
    "script-src": [CSP.SELF, CSP.NONCE],
    "object-src": [CSP.NONE],
    "report-uri": "/csp-report/",
}

Şablonda nonce için csp context processor'ı (django.template.context_processors.csp) etkinleştirip

Kod:
<script nonce="{{ csp_nonce }}">

kullanın. Ayarları kontrol etmek için:

Kod:
python manage.py check --deploy

PHP: header() çağrıları herhangi bir çıktıdan önce yapılmalıdır:

Kod:
<?php
$nonce = base64_encode(random_bytes(16));
header("Content-Security-Policy: default-src 'self'; script-src 'nonce-$nonce' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'");
header("X-Content-Type-Options: nosniff");
header("Referrer-Policy: strict-origin-when-cross-origin");
?>
<script nonce="<?= htmlspecialchars($nonce) ?>">initApp();</script>

[center][/center]

8) Sık Yapılan Hatalar

script-src içinde 'unsafe-inline' bırakmak (nonce/hash varken destekleyen tarayıcılar onu yok sayar, ama tek başına korumayı boşa çıkarır)
Aynı başlığı hem uygulamada hem ters vekilde farklı değerlerle eklemek; birden fazla CSP başlığında tarayıcı hepsini birden uygular, sonuç beklenenden sıkı olur
Nonce'u sabit yazmak veya tam sayfa önbelleğinde kullanıcılar arasında paylaştırmak
Report-Only'de kalıp politikayı hiç zorlayıcı moda almamak
HTTPS hazır değilken uzun max-age ile HSTS ya da preload göndermek
CDN alan adının tamamına izin vermek (ör. tüm bir paylaşımlı CDN); saldırgan aynı CDN'e dosya koyabiliyorsa politika aşılabilir

9) Sonuç
Güvenlik başlıkları ucuz ama güçlü bir katmandır. Sıralama önerim: önce nosniff, Referrer-Policy ve frame koruması; ardından CSP'yi Report-Only ile başlatıp raporlarla olgunlaştırmak; en son nonce tabanlı strict CSP'yi zorlamak. Politikanızı Google'ın CSP Evaluator aracıyla gözden geçirip her sürümde curl -I ile doğrulayın.

Kaynakça

Yasal Uyarı
Bu rehber kendi uygulamalarınızı korumak içindir. Başlık ve politika testlerini yalnızca kendi sistemlerinizde veya yazılı yetkili pentest kapsamında yapın. Başkasına ait sistemlere izinsiz erişim veya müdahale 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

TLS/HTTPS Nasıl Çalışır? El Sıkışma, Sertifikalar ve Güvenli Bağlantı

BilgeKagan 10-18-2026, 04:11 PM · Kriptografi

0 30

[center]

[/center]

Selam TurkTeam, BlueTornado yazıyor.

Tarayıcınızdaki kilit simgesinin arkasında TLS (Transport Layer Security) vardır. HTTPS, HTTP'nin TLS ile şifrelenmiş kanal üzerinden taşınmasıdır. Bu rehberde TLS'in üç temel vaadini (gizlilik, bütünlük, kimlik doğrulama), TLS 1.3 el sıkışmasını adım adım, sertifika zincirinin nasıl doğrulandığını ve bunların hepsini kendi bilgisayarınızda openssl, curl ve Wireshark ile nasıl gözlemleyeceğinizi anlatıyorum. Simetrik/asimetrik şifreleme temellerini (AES, RSA) ayrı konuda işlediğimiz için burada TLS'in bunları nasıl bir araya getirdiğine odaklanıyoruz. Sunucu sıkılaştırma (Nginx ayarları) bu konunun kapsamı dışında.

Konuda Anlatılacaklar

TLS nedir, HTTPS ile ilişkisi
TLS'in sağladığı güvenceler ve sağlamadıkları
TLS 1.3 el sıkışması adım adım
X.509 sertifikaları ve güven zinciri
Lab: openssl s_client ile el sıkışmayı izlemek
Lab: kendi sertifikanızı üretip yerel TLS sunucusu açmak
Wireshark ile kendi trafiğinizi çözmek (SSLKEYLOGFILE)
İleri seviye: forward secrecy, 0-RTT, Certificate Transparency, sertifika ömürleri
Kaynakça ve yasal uyarı

1) TLS Nedir?
TLS, iki uç arasında şifreli ve kimliği doğrulanmış bir kanal kuran protokoldür. Eski adı SSL'dir; SSL 2.0/3.0 ile TLS 1.0 ve 1.1 artık güvensiz kabul edilir (RFC 8996, TLS 1.0 ve 1.1'i resmen kullanımdan kaldırdı). Güncel sürümler TLS 1.2 (RFC 5246) ve TLS 1.3'tür (RFC 8446). HTTPS'te tarayıcı önce TCP (veya HTTP/3'te QUIC) bağlantısı kurar, ardından TLS el sıkışmasını yapar ve HTTP isteklerini bu şifreli kanaldan gönderir.

TLS'in sağladıkları:

Gizlilik: Aradaki biri (aynı Wi-Fi, ISS) içeriği okuyamaz
Bütünlük: Trafik yolda değiştirilirse alıcı bunu fark eder (AEAD şifreleri)
Kimlik doğrulama: Konuştuğunuz sunucunun gerçekten o alan adının sahibi olduğu sertifika ile kanıtlanır

Sağlamadıkları: Sitenin kendisinin güvenilir olduğunu garanti etmez. Oltalama siteleri de geçerli sertifika alabilir; kilit simgesi "bağlantı şifreli" demektir, "site masum" demek değildir. Ayrıca bağlanılan alan adı (SNI) ve IP adresi, ek önlem (ör. Encrypted Client Hello) yoksa ağ gözlemcisine görünür.

Alıntı:Kilit simgesi = doğru sunucuyla şifreli konuşuyorsunuz. Sunucunun niyeti ayrı bir sorudur.

2) TLS 1.3 El Sıkışması Adım Adım
TLS 1.3 tam el sıkışma için yalnızca bir gidiş-dönüş (1-RTT) kullanır; TLS 1.2'de bu iki gidiş-dönüştü.

Kod:
İstemci                                   Sunucu
ClientHello
 + supported_versions, key_share,
 + signature_algorithms, server_name (SNI)  -------->
                                            ServerHello + key_share
                                            {EncryptedExtensions}
                                            {Certificate}
                                            {CertificateVerify}
                                   <-------- {Finished}
{Finished}                         -------->
[Uygulama verisi]                  <------->  [Uygulama verisi]

{} = el sıkışma anahtarlarıyla şifreli   [] = uygulama anahtarlarıyla şifreli

ClientHello: İstemci desteklediği sürümleri, şifre takımlarını ve tahmin ettiği grup için geçici (ephemeral) bir Diffie-Hellman açık anahtarını (key_share) gönderir. SNI ile hangi alan adına bağlandığını belirtir.
ServerHello: Sunucu sürümü ve şifre takımını seçer, kendi key_share'ini gönderir. Bu noktada iki taraf ortak bir sır hesaplar; buradan HKDF ile el sıkışma anahtarları türetilir.
EncryptedExtensions: Ek parametreler (ör. ALPN ile h2 seçimi), artık şifreli.
Certificate: Sunucunun sertifika zinciri.
CertificateVerify: Sunucu, el sıkışma dökümünü özel anahtarıyla imzalar. Böylece sertifikadaki açık anahtarın sahibi olduğunu kanıtlar.
Finished: Her iki taraf tüm dökümün MAC'ini gönderir; araya giren biri mesajları değiştirdiyse burada yakalanır.

TLS 1.3'te yalnızca beş şifre takımı tanımlıdır ve yaygın kullanılanlar şunlardır:

Kod:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

RSA ile anahtar taşıma ve statik DH tamamen kaldırıldı; her bağlantı geçici anahtar kullanır.

[center][/center]

3) Sertifikalar ve Güven Zinciri
Sertifika, bir açık anahtarı bir kimliğe (alan adına) bağlayan ve bir Sertifika Otoritesi (CA) tarafından imzalanmış X.509 belgesidir (RFC 5280). Tarayıcı şunları kontrol eder:

Zincir: Yaprak (sunucu) sertifikası -> ara (intermediate) CA -> işletim sistemi/tarayıcı deposundaki kök (root) CA. Her halkanın imzası bir üstteki ile doğrulanır.
Alan adı: Bağlanılan ad, Subject Alternative Name (SAN) listesinde olmalı. Modern tarayıcılar yalnızca CN'ye bakmaz.
Geçerlilik tarihleri: notBefore / notAfter.
Anahtar kullanımı: Extended Key Usage içinde serverAuth.
İptal ve şeffaflık: Tarayıcıya göre CRL tabanlı mekanizmalar ve Certificate Transparency kayıtları.

[center][/center]

Sunucu ara sertifikayı göndermeyi unutursa bazı istemcilerde "unable to get local issuer certificate" hatası alınır; bu sık görülen bir yapılandırma hatasıdır.

4) Lab: openssl s_client ile Gözlem
Herhangi bir halka açık HTTPS sitesine normal bir bağlantı kurmak sıradan tarayıcı davranışıdır; aşağıdaki komutlar yalnızca bağlantı bilgisini okur.

Kod:
# TLS 1.3 ile bağlan, SNI belirt, el sıkışma özetini gör
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Çıktı yorumu: Çıktıda "Certificate chain" bölümü zinciri (s: subject, i: issuer) listeler; altta protokol ve seçilen şifre takımı ile "Verify return code: 0 (ok)" satırı görünür. 0 dışındaki kod, doğrulamanın başarısız olduğunu ve nedenini söyler.

Kod:
# Sunucu sertifikasının ayrıntıları
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Kod:
# Zincirin tamamını PEM olarak kaydet
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null > zincir.txt

Kod:
# curl ile el sıkışmayı ayrıntılı izlemek
curl -sv -o /dev/null https://example.com 2>&1 | grep -E 'SSL connection|ALPN|subject:|issuer:|expire date'

Kod:
# Belirli bir sürümün reddedildiğini test et (kendi sunucunuzda)
openssl s_client -connect localhost:4443 -tls1_1 </dev/null

[center][/center]

5) Lab: Kendi Sertifikanız ve Yerel TLS Sunucusu
Kendi bilgisayarınızda, yalnızca test amacıyla kendinden imzalı (self-signed) sertifika üretelim:

Kod:
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
  -keyout lab.key -out lab.crt -days 30 \
  -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Kod:
# Sertifikayı incele
openssl x509 -in lab.crt -noout -text | grep -A1 -E 'Subject:|Not After|Subject Alternative Name'

Kod:
# Basit test sunucusu (yalnızca localhost)
openssl s_server -accept 4443 -cert lab.crt -key lab.key -www

Başka terminalden:

Kod:
curl -v https://localhost:4443/              # güven hatası beklenir
curl -v --cacert lab.crt https://localhost:4443/   # sertifikaya güvenince geçer

Çıktı yorumu: İlk komutta curl, sertifikayı tanıdığı bir CA imzalamadığı için bağlantıyı reddeder. Bu tam olarak istenen davranıştır: kimlik doğrulanamayan sunucuya veri gönderilmez. İkinci komutta güven çapasını kendiniz verdiğiniz için doğrulama geçer. Üretimde curl -k veya "sertifika doğrulamayı kapat" seçeneklerini asla kullanmayın; bu, TLS'in kimlik doğrulama güvencesini tamamen ortadan kaldırır.

Gerçek alan adınız için ücretsiz ve otomatik sertifika Let's Encrypt ve certbot ile alınabilir:

Kod:
sudo certbot certonly --webroot -w /var/www/html -d alanadiniz.ornek
sudo certbot renew --dry-run   # yenileme otomasyonunu test et

6) Wireshark ile Kendi Trafiğinizi Çözmek
TLS trafiği Wireshark'ta okunamaz; bu iyi bir şeydir. Kendi tarayıcınızın veya curl'ün oturum anahtarlarını bir dosyaya yazdırarak yalnızca kendi trafiğinizi çözebilirsiniz:

Kod:
export SSLKEYLOGFILE="$HOME/tls-keys.log"
curl -s -o /dev/null https://example.com
# Wireshark: Edit > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename = tls-keys.log

Kod:
# Faydalı görüntü filtreleri
tls.handshake.type == 1      # ClientHello
tls.handshake.type == 2      # ServerHello
tls.handshake.extensions_server_name

Anahtar dosyası, o oturumların tüm içeriğini açar; işiniz bitince silin ve kimseyle paylaşmayın.

[center][/center]

7) İleri Seviye
Forward secrecy: Her bağlantı geçici (EC)DHE anahtarlarıyla kurulduğu için sunucunun uzun ömürlü özel anahtarı ileride çalınsa bile geçmiş kayıtlı trafik çözülemez. TLS 1.3'te bu zorunludur.

Oturum devamı ve 0-RTT: TLS 1.3, önceki oturumdan alınan PSK ile ilk pakette veri göndermeye (0-RTT / early data) izin verir. Bu veri tekrar oynatma (replay) saldırısına açıktır; RFC 8446 de bu riski belirtir. Yalnızca idempotent istekler (GET gibi) için kullanılmalıdır.

Certificate Transparency (RFC 6962): Halka açık CA'ların verdiği sertifikalar kamuya açık loglara yazılır. Alan adınız için beklemediğiniz bir sertifika çıkarılıp çıkarılmadığını crt.sh gibi CT arama araçlarıyla izleyebilirsiniz. Savunma açısından kendi alan adlarınızı düzenli kontrol etmek iyi bir alışkanlıktır.

Sertifika ömürleri kısalıyor: CA/Browser Forum'un SC-081v3 kararına göre halka açık TLS sertifikalarının azami geçerliliği 15 Mart 2026'dan itibaren 200 gün, 15 Mart 2027'de 100 gün, 15 Mart 2029'da 47 gündür. Pratik sonuç: yenilemeyi elle değil, ACME (certbot vb.) ile otomatik yapın.

Kendi sunucunuzu denetlemek:

Kod:
nmap --script ssl-enum-ciphers -p 443 alanadiniz.ornek
./testssl.sh https://alanadiniz.ornek

Bu araçları yalnızca sahibi olduğunuz veya yazılı izin aldığınız sistemlerde çalıştırın.

Kontrol Listesi

Yalnızca TLS 1.2 ve 1.3 açık; 1.0/1.1 ve SSL kapalı
Sertifika SAN listesi tüm alan adlarını kapsıyor, ara sertifika gönderiliyor
Yenileme otomatik ve izleniyor (bitiş tarihi alarmı)
Uygulama kodunda sertifika doğrulaması asla kapatılmıyor
Özel anahtar dosyası yalnızca servis kullanıcısı tarafından okunabilir

Sonuç
TLS; geçici anahtar değişimi, sertifika ile kimlik doğrulama ve AEAD şifreleme parçalarını tek bir el sıkışmada birleştirir. openssl s_client ve kendi lab sunucunuzla bu adımları gözünüzle görmek, "sertifika hatası" mesajlarını okumayı ve doğru yapılandırmayı çok kolaylaştırır.

Kaynakça

Yasal Uyarı
Bu rehber bağlantılarınızı ve sunucularınızı korumak içindir. Trafik çözme ve TLS taramalarını yalnızca kendi sistemlerinizde, kendi trafiğinizde veya yazılı yetkili kapsamda yapın. Başkalarının haberleşmesine müdahale, izinsiz dinleme veya sistemlere yetkisiz erişim TCK 243-245 ve ilgili kanunlar 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

OSINT İçin Shodan: Temeller ve Etik Kullanım Rehberi

BilgeKagan 10-18-2026, 04:09 PM · OSINT

0 37

[center]

[/center]

Selam TurkTeam, BlueTornado burada.

Shodan, internete açık cihazlar ve servisler için bir arama motorudur. Banner'lar, sertifikalar, başlıklar ve bazı meta veriler indekslenir. Bu rehber temeller ve etik kullanım odaklıdır: kendi varlıklarınızı nasıl gördüğünüzü anlamak, yanlış yapılandırmayı yakalamak ve yasal sınırları bilmek. İzinsiz sistemlere saldırı anlatılmaz; Google Dorks konusu ayrıca mevcuttur.

Konuda Anlatılacaklar

Shodan nedir, ne değildir?
Hesap, kredi ve yasal/etik çerçeve
Arama sözdizimi temelleri
Kendi IP/domain envanterinizi kontrol etme
Yaygın filtreler ve çıktı yorumlama
İleri seviye: monitör, API, alternatifler
Kaynakça ve yasal uyarı

1) Shodan Nedir?
Klasik arama motorları web sayfalarını indeksler. Shodan ise daha çok servis banner'larını indeksler: açık portlarda konuşan HTTP, SSH, FTP, endüstriyel protokoller vb. "İnternette şu an kim neyi açık bırakmış?" sorusuna pasif bir bakış sunar.

Yapar: Herkese açık şekilde görünen servis bilgilerini aranabilir kılar
Yapmaz (sizin yerinize): Otomatik exploit, şifre kırma, izinsiz giriş
Sizin sorumluluğunuz: Sonucu nasıl kullanacağınız

Alıntı:Shodan'da bir cihazın görünmesi tek başına "hack'lendi" anlamına gelmez. Ancak varsayılan arayüzlerin, test panellerinin veya yanlışlıkla public kalan yönetim konsollarının keşfini kolaylaştırır.

2) Etik ve Yasal Çerçeve

Öncelik: kendi kurumunuzun IP aralıkları, kendi bulut hesaplarınız, yazılı izinli kapsam
Başkasının altyapısında banner ötesine geçmek (login denemesi, exploit) izin olmadan yasaktır
Bulduğunuz kişisel veriyi paylaşmayın / satmayın
Responsible disclosure: kendi müşteriniz değilse ve kritik bir açık görürseniz, yasal danışmanlık ve CERT süreçlerini bilin; "iyi niyet" her zaman yasal koruma sağlamayabilir

Türkiye'de bilişim sistemine izinsiz girme TCK 243-245 kapsamında düzenlenir. Pasif arama ile aktif sömürü arasındaki çizgiyi aşmayın.

3) Başlangıç: Hesap ve Arayüz

Kod:
# https://www.shodan.io adresinden hesap
# Ücretsiz hesapta arama ve sonuç sayısı sınırlıdır
# Akademik / ücretsiz kredi fırsatları dönemsel değişir; resmi siteyi kontrol edin

CLI kurulumu (opsiyonel):

Kod:
pipx install shodan
shodan init YOUR_API_KEY
# Anahtarı ekran görüntüsüne / git'e koymayın

[center][/center]

4) Arama Sözdizimi Temelleri
Filtreler birleştirilebilir:

Kod:
hostname:turkteam.org
org:"Example Company"
net:203.0.113.0/24
port:22
product:nginx
http.title:"Dashboard"
http.status:200
country:TR
ssl.cert.subject.cn:example.com

Kod:
# Kendi lab netiniz (örnek RFC 5737 dokümantasyon IP'si değil; kendi aralığınız)
net:SIZIN_PUBLIC_IP/32
# veya
hostname:lab.sizin-domaininiz.com

Örnek yorumlama:

Kod:
product:mongodb net:SIZIN_CIDR
# Kendi CIDR'ınızda beklenmeyen MongoDB görünüyorsa acil gözden geçirin
# Authentication olmadan açık DB'ler geçmişte sıkça indekslenmiştir

Üretimde başkasının MongoDB'sine bağlanmayı denemeyin.

5) Uygulamalı: Kendi Envanterinizi Görmek

Adım 1 - Public IP listenizi çıkarın. Bulut konsolu, firewall, hosting paneli.

Kod:
# Örnek not
edge-fw: 198.51.100.10
vpn: 198.51.100.11
web: 203.0.113.50

Adım 2 - Shodan'da net/hostname arayın.

Kod:
shodan host 203.0.113.50
# veya web arayüzü

Adım 3 - Beklenmeyen port var mı?

Dev/test paneli production IP'sinde mi?
Eski SSL / zayıf şifru takımı banner'da görünüyor mu?
Kod:
Server
başlığı sürüm sızdırıyor mu? (bilgi; tek başına zafiyet değil)

[center][/center]

Adım 4 - Düzeltme ve doğrulama. Firewall kuralı, security group, reverse proxy kısıtı. Bir süre sonra indeksi tekrar kontrol edin (indeks gecikmeli olabilir).

Kod:
# SSL sertifika bilgisi (kendi hostunuz)
echo | openssl s_client -connect SIZIN_HOST:443 -servername SIZIN_HOST 2>/dev/null | openssl x509 -noout -issuer -dates

6) Faydalı Filtre Senaryoları (Savunma)

Kod:
# Kendi org adınızla indekslenen servisler
org:"Sirket Adi"

# HTTP başlığında dahili yazılım adı
http.component:wordpress net:SIZIN_CIDR

# Endüstriyel / IoT: yalnızca kendi tesis IP'leriniz
# Başkasının PLC/SCADA arayüzüne dokunmayın

Kod:
# SSL süresi / konu (filtreler sürüme göre değişebilir; UI yardımını okuyun)
ssl.cert.expired:true net:SIZIN_CIDR

Çıktıyı bir envanter tablosuna aktarın:

Kod:
IP | Port | Ürün | Başlık | İlk görülme | Aksiyon
203.0.113.50 | 8080 | nginx | Test Admin | 2026-10-01 | SG kapatıldı

7) İleri Seviye
Shodan Monitor / Alert: Belirli net bloğu için yeni açık port uyarısı (ücretli özellikler değişebilir; resmi dokümana bakın).

API:

Kod:
shodan stats --facets port net:SIZIN_CIDR
shodan download own-net.json.gz net:SIZIN_CIDR
shodan parse own-net.json.gz --fields ip_str,port,product

Alternatifler: Censys, FOFA, ZoomEye benzeri motorlar; her birinin ToS ve yasal şartları farklıdır. BinaryEdge vb. ticari seçenekler.

OPSEC: Araştırmacı hesabınızı günlük tarayıcı profilinizden ayırın; API anahtarını sızdırmayın.

[center][/center]

8) Sonuç
Shodan, internete açık yüzünüzü görmek için güçlü bir OSINT aracıdır. Etik kullanım kendi varlıklarınız ve izinli kapsamla başlar. Sonuçları envanter ve sertleştirme sürecine bağlayın; merakla başkasının sistemine girmeyin.

Ek: Ekip İçin Savunma Playbook'u
Küçük bir güvenlik ekibi Shodan'ı şu döngüyle kullanabilir:

Ayda bir: kurum CIDR ve kritik hostname sorgusu
Yeni port/ürün çıkarsa ticket aç
Firewall / security group kanıtı ekle
Bir sonraki taramada kaybolduğunu doğrula
Sonuçları yönetim özetine "dışarıdan görünür yüzey" olarak raporla

Kod:
# Basit cron fikri (kendi API kotanıza dikkat)
# 0 9 1 * * shodan download /var/lib/inv/shodan-$(date +\%Y\%m).json.gz net:CIDR

Yanlış kullanım örnekleri (yapmayın):

"webcam" / "default password" arayıp cihazlara girmek
Bulunan RDP/SSH üzerinde brute-force
Başkasının tıbbi / ICS arayüzünü "merak için" tıklamak

[center][/center]

Pasif görünürlük ile aktif ihlal arasındaki farkı ekip içinde yazılı politika haline getirin.

Kaynakça

Yasal Uyarı
Bu içerik eğitim ve savunma (kendi varlık görünürlüğü) içindir. İzinsiz erişim, tarama ötesi sömürü veya veri hırsızlığı TCK 243, 244, 245 kapsamında suçtur. Shodan kullanımında da yerel yasalara ve Shodan ToS'a uyun. 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

Simetrik ve Asimetrik Şifreleme Farkı: AES ve RSA Temelleri

BilgeKagan 10-18-2026, 03:20 PM · Kriptografi

0 40

[center]

[/center]

Selam TurkTeam, BlueTornado ile.

"Veriyi şifreledik" cümlesi tek başına yetmez: hangi model, hangi algoritma, anahtar nerede? Bu rehberde simetrik (AES) ile asimetrik (RSA/ECC) şifrelemenin farkını, ne zaman hangisinin kullanıldığını ve OpenSSL ile zararsız lab örneklerini anlatıyoruz. Hash/encoding farkı ve parola KDF konuları forumda ayrıca işlenir.

Konuda Anlatılacaklar

Simetrik vs asimetrik: anahtar modeli
AES temelleri ve modlar
RSA/ECC: şifreleme ve imza
Hibrit şifreleme (TLS'in özü)
Lab: OpenSSL ile denemeler
İleri seviye: AEAD, anahtar ömrü, post-quantum notu
Kaynakça ve yasal uyarı

1) İki Model
Simetrik: Aynı gizli anahtar hem şifreler hem çözer. Hızlıdır; büyük veri için uygundur. Anahtar dağıtımı zordur (her iki taraf aynı sırrı güvenli paylaşmalı).

Asimetrik: Açık anahtar (public) ve özel anahtar (private). Public ile şifrelenen private ile açılır (şifreleme modeli). İmzada tersi: private imzalar, public doğrular. Yavaştır; genelde küçük veri / anahtar sarma / imza için kullanılır.

Kod:
# Kavramsal
Simetrik:  AES(key, plaintext) <-> AES(key, ciphertext)
Asimetrik: Encrypt(pub, msg)  <-> Decrypt(priv, ct)
İmza:      Sign(priv, msg)    <-> Verify(pub, sig, msg)

Alıntı:AES "daha iyi RSA" değildir; farklı işler yaparlar. Gerçek sistemler çoğunlukla ikisini birlikte kullanır (hibrit).

2) AES (Simetrik) Temelleri
AES blok şifresidir (128-bit blok). Anahtar uzunlukları: 128, 192, 256 bit. Güvenlik sadece "AES-256 seçtik" ile bitmez; mod ve IV/nonce yönetimi kritiktir.

ECB: Aynı blok aynı çıktı -> kalıp sızdırır; kullanmayın
CBC: IV gerekir; dolgu (padding) oracle tarihsel riskleri
GCM (AEAD): Gizlilik + bütünlük; modern varsayılan tercih
ChaCha20-Poly1305: AEAD alternatif (özellikle yazılımda hızlı)

Kod:
# OpenSSL enc lab (AES-256-CBC + PBKDF2) - sadece eğitim
openssl rand -out /tmp/aes.key 32
echo -n "turkteam lab notu" > /tmp/pt.txt
openssl enc -aes-256-cbc -pbkdf2 -in /tmp/pt.txt -out /tmp/ct.bin -pass file:/tmp/aes.key
openssl enc -d -aes-256-cbc -pbkdf2 -in /tmp/ct.bin -out /tmp/pt2.txt -pass file:/tmp/aes.key
cat /tmp/pt2.txt
rm -f /tmp/aes.key /tmp/pt.txt /tmp/ct.bin /tmp/pt2.txt

Üretimde kendi CBC sarmalayıcınızı yazmak yerine libsodium, OpenSSL EVP AEAD, dilin güvenilir kütüphanelerini kullanın.

[center][/center]

3) RSA ve ECC (Asimetrik)
RSA, büyük tamsayı çarpanlara ayırma zorluğuna dayanan klasik genel anahtar sistemidir. Günümüzde anahtar sarma ve dijital imza için hâlâ görülür; yeni tasarımlarda ECC (elliptik eğri) daha kısa anahtarlarla benzer güvenlik seviyesi sunar (ör. ECDSA P-256, Ed25519 imza).

Kod:
# RSA anahtar çifti lab
openssl genrsa -out /tmp/priv.pem 2048
openssl rsa -in /tmp/priv.pem -pubout -out /tmp/pub.pem
echo -n "kucuk mesaj" > /tmp/msg.txt
openssl pkeyutl -encrypt -pubin -inkey /tmp/pub.pem -in /tmp/msg.txt -out /tmp/msg.enc
openssl pkeyutl -decrypt -inkey /tmp/priv.pem -in /tmp/msg.enc -out /tmp/msg.dec
cat /tmp/msg.dec
rm -f /tmp/priv.pem /tmp/pub.pem /tmp/msg.txt /tmp/msg.enc /tmp/msg.dec

Kod:
# Ed25519 imza örneği
openssl genpkey -algorithm Ed25519 -out /tmp/ed.priv
openssl pkey -in /tmp/ed.priv -pubout -out /tmp/ed.pub
echo -n "rapor ozeti" > /tmp/r.txt
openssl pkeyutl -sign -inkey /tmp/ed.priv -in /tmp/r.txt -out /tmp/r.sig
openssl pkeyutl -verify -pubin -inkey /tmp/ed.pub -in /tmp/r.txt -sigfile /tmp/r.sig
rm -f /tmp/ed.priv /tmp/ed.pub /tmp/r.txt /tmp/r.sig

RSA ile büyük dosya şifrelemeyin; yavaştır ve pratikte hibrit kullanılır.

4) Hibrit Şifreleme (TLS'in Mantığı)

Alice rastgele bir simetrik oturum anahtarı üretir
Bu anahtarı Bob'un public key'i ile sarar (veya Diffie-Hellman ile ortak anahtar türetir)
Asıl veri AES-GCM ile şifrelenir
Bob private key / DH ile oturum anahtarını elde eder ve veriyi çözer

TLS el sıkışması bu fikrin standardize, sertifikalı ve çok daha ayrıntılı halidir.

Kod:
# Kendi sunucunuzun TLS bilgisini görün
echo | openssl s_client -connect turkteam.org:443 -servername turkteam.org 2>/dev/null | egrep "Protocol|Cipher"

[center][/center]

5) Ne Zaman Hangisi?

Diskteki büyük yedek / dosya: simetrik (AES-GCM), anahtar KMS'te
Anahtar dağıtımı / ilk güven: asimetrik veya DH + sertifika
Yazılım güncellemesi doğrulama: dijital imza (asimetrik)
Parola saklama: şifreleme değil, Argon2id gibi KDF
API bütünlüğü: HMAC (simetrik) veya imza (asimetrik)

Kod:
# Karar özeti
Gizlilik + hız          -> AES-GCM
Kimlik / imza           -> Ed25519 / ECDSA / RSA-PSS
İnternet oturumu        -> TLS (hibrit)
Parola                  -> KDF (hash ailesi, şifreleme değil)

6) İleri Seviye Notlar

Nonce/IV yeniden kullanımı: GCM'de aynı anahtar+nonce felakettir
Padding oracle: Kendi CBC+PKCS7 protokolünüzü yazmayın
Anahtar ömrü: Rotate; sızan anahtar için olay planı
Side-channel: Sabit zamanlı karşılaştırma; amatör crypto implementasyonu riskli
Post-quantum: NIST PQC standartları (ML-KEM vb.) geçiş planlarında konuşuluyor; abartılı panik yerine envanter çıkarın

Kod:
python3 - <<'PY'
import secrets, hmac, hashlib
print("key", secrets.token_bytes(32).hex())
print("hmac", hmac.new(b"k", b"msg", hashlib.sha256).hexdigest())
PY

[center][/center]

7) Sonuç
Simetrik hız ve toplu gizlilik; asimetrik anahtar dağıtımı ve imza demektir. AES ve RSA rakip değil, tamamlayıcıdır. Labda OpenSSL ile deneyin; üretimde hazır, incelenmiş kütüphaneler ve KMS kullanın.

Ek: Geliştirici Anti-Pattern Listesi

Kod:
# 1) ECB ile "AES yaptık" demek
# 2) IV'yi sabit 0x00.. seçmek
# 3) RSA PKCS#1 v1.5 ile yeni protokol tasarlamak (mümkünse OAEP / modern KEM)
# 4) Private key'i uygulama imajına gömmek
# 5) "Gizlilik için" hash kullanmak
# 6) Kendi TLS'inizi yazmak

Kütüphane seçimi: bakımı yapılan, sabit zamanlı ilkel sunan
Protokol seçimi: TLS 1.2+ (tercihen 1.3), zayıf suite'leri kapatın
Anahtar: en az AES-128 güvenliğine denk; pratikte AES-256 ve 2048+ RSA veya ECC

[center][/center]

Şüphede kalırsanız: hazır yüksek seviye API (libsodium sealed box, age, Tink) kullanın; düşük seviye blok şifre modlarını kendiniz birleştirmeyin.

Ek Lab Komutları

Kod:
# Rastgele AES anahtarı ve nonce (GCM için nonce 12 byte tipik)
openssl rand -hex 32
openssl rand -hex 12

Kod:
# Public key parmak izi (kendi anahtarınız)
openssl pkey -pubin -in /tmp/ed.pub -outform DER 2>/dev/null | openssl dgst -sha256

Kod:
# TLS 1.3 cipher gözlemi (kendi host)
echo | openssl s_client -connect 127.0.0.1:443 -tls1_3 2>/dev/null | head

Kaynakça

Yasal Uyarı
Kriptografi eğitimi sistemleri korumak içindir. İzinsiz şifre çözme, haberleşmeye müdahale veya sistemlere yetkisiz erişim TCK 243-245 ve ilgili kanunlar kapsamında suç olabilir. Lab anahtarlarını üretimde kullanmayın.

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

Bulut Güvenliği Sertifikaları 2026: AWS Security Specialty, SC-500, CCSK v5 ve CCSP

Tonyukuk 10-18-2026, 03:15 PM · Sertifikalar

0 28

Merhaba arkadaşlar,

Bulut güvenliği, siber güvenlikte en hızlı büyüyen ve en çok eleman aranan alanlardan biri. Peki bu alanda hangi sertifika size uygun? Satıcıya özel mi (AWS, Azure) yoksa satıcıdan bağımsız mı (CCSK, CCSP) gitmeli? Bu rehberde dört önemli bulut güvenliği sertifikasını resmi sınav kılavuzlarına dayanarak karşılaştırıyor; her birinin güncel sürümü, içeriği, formatı ve kimin için uygun olduğunu anlatıyorum. 2026'da Azure tarafında önemli bir değişiklik var: AZ-500 emekli oldu, yerini SC-500 aldı.

Konuda Anlatılacaklar

Satıcıya özel ve satıcıdan bağımsız sertifika farkı
AWS Certified Security - Specialty (SCS-C03)
Microsoft SC-500 (AZ-500'ün halefi)
CCSK v5 (Cloud Security Alliance)
ISC2 CCSP
Karşılaştırma ve seçim rehberi
Pratik lab önerileri

Satıcıya Özel ve Satıcıdan Bağımsız Fark

İki ana aile vardır. Satıcıya özel sertifikalar (AWS Security Specialty, SC-500) tek bir bulutun araçlarını derinlemesine ölçer; o bulutta çalışıyorsanız doğrudan işinize yarar. Satıcıdan bağımsız sertifikalar (CCSK, CCSP) kavram ve mimari odaklıdır; çok bulutlu ortamlarda ve yönetişim/mimari rollerinde değerlidir. İdeal yol çoğu zaman ikisini birleştirmektir: önce bağımsız bir temel (CCSK), sonra kullandığınız bulutun sertifikası.

AWS Certified Security - Specialty (SCS-C03)

AWS'nin resmi sınav sayfasına göre güncel sürüm SCS-C03'tür (2 Aralık 2025'ten beri geçerli):

Sorular: 65 soru (50 puanlanan + 15 puanlanmayan), 170 dakika.
Ücret: 300 USD. Geçme skoru: 1000 üzerinden 750. Geçerlilik: 3 yıl.
Önerilen deneyim: bulut çözümlerini güvenli hale getirmede 3-5 yıl.

Alan ağırlıkları: Detection %16, Incident Response %14, Infrastructure Security %18, Identity and Access Management %20, Data Protection %18, Security Foundations and Governance %14. AWS ekosisteminde çalışan ve CloudTrail, GuardDuty, IAM, KMS gibi servislere hakim olmak isteyenler için en doğrudan seçenektir.

Microsoft SC-500 (AZ-500'ün Halefi)

Önemli değişiklik: Microsoft Learn'e göre AZ-500 (Azure Security Engineer Associate) 31 Ağustos 2026'da emekli oldu ve yerini SC-500 aldı. SC-500'ün tam adı "Implementing End-to-End Security Controls for Cloud and AI Workloads" ve sertifikası "Microsoft Certified: Cloud and AI Security Engineer Associate". Resmi çalışma kılavuzuna göre dört alan ağırlığı:

Manage identity, access and governance: %20-25
Secure storage, databases and networking: %25-30
Secure compute: %20-25
Manage and monitor security posture: %20-25

AZ-500'den en büyük farkı, yapay zeka iş yüklerinin güvenliğini (Purview DSPM, Defender for AI, Security Copilot, Entra Agent ID) müfredata eklemesidir. Azure üzerinde çalışanların artık AZ-500 yerine SC-500'e hazırlanması gerekir.

CCSK v5 (Cloud Security Alliance)

Cloud Security Alliance'ın resmi sayfasına göre CCSK v5 (16 Temmuz 2024'te yayımlandı) satıcıdan bağımsız bir bulut güvenliği sertifikasıdır:

Format: çevrim içi, açık kitap (open-book).
Sorular: 60 çoktan seçmeli, 120 dakika.
Geçme skoru: %80.

CCSK, CSA Security Guidance ve ENISA bulut risk belgelerine dayanır. Kavramsal temel kurmak isteyenler ve mimari/GRC yoluna gidecekler için güçlü bir başlangıçtır. Açık kitap olması kolay olduğu anlamına gelmez; süre kısıtı nedeniyle konuya hakim olmadan yetişmek zordur.

ISC2 CCSP

ISC2'nin resmi sınav taslağına göre CCSP (Certified Cloud Security Professional) ileri seviye, satıcıdan bağımsız bir sertifikadır:

Format: 1 Ekim 2025'ten beri uyarlamalı (CAT).
Sorular: 100-150, en fazla 3 saat.
Geçme skoru: 1000 üzerinden 700.
Altı alan: Cloud Concepts/Architecture/Design, Cloud Data Security, Cloud Platform & Infrastructure Security, Cloud Application Security, Cloud Security Operations, Legal/Risk/Compliance.

CCSP, CISSP seviyesinde ciddi bir deneyim sertifikasıdır (tam sertifika için çalışma deneyimi şartı vardır). Kıdemli bulut güvenliği ve mimari rolleri hedefleyenler içindir.

Karşılaştırma ve Seçim Rehberi

Basit bir yönlendirme:

AWS'de çalışıyorum, derinleşmek istiyorum -> AWS Security Specialty (SCS-C03)
Azure'da çalışıyorum -> SC-500 (artık AZ-500 değil)
Çok bulutlu düşünüyorum, kavramsal temel istiyorum -> CCSK v5
Kıdemliyim, mimari/yönetim rolü hedefliyorum -> CCSP

İleri Seviye: Sertifikayı Lab ile Pekiştirmek

Sertifika sınavını geçmek bir şey, bulutta gerçekten güvenlik kurabilmek başka şey. Teorik çalışmanın yanında kendi ücretsiz katman hesabınızda pratik yapın. Örneğin AWS'de açık kaynak Prowler ile kendi hesabınızın güvenlik duruşunu tarayabilirsiniz (yalnızca kendi hesabınızda):

Kod:
pip install prowler
prowler aws --profile kendi-hesabim

Prowler resmi belgelerine göre varsayılan olarak CSV, JSON-OCSF ve HTML raporları üretir; belirli bir uyumluluk çerçevesiyle tarama da yapabilirsiniz:

Kod:
prowler aws --compliance cis_3.0_aws

Azure tarafında kendi aboneliğinizde Microsoft Defender for Cloud'un Secure Score'una bakmak, SC-500 konularını somutlaştırır. Çok bulut için Prowler azure ve gcp sağlayıcılarını da destekler:

Kod:
prowler azure --az-cli-auth

Bu komutları yalnızca sahibi olduğunuz veya yazılı izniniz bulunan hesaplarda çalıştırın.

Sonuç

Bulut güvenliği sertifikası seçiminde "en iyi" yoktur; sizin bulutunuza ve kariyer hedefinize uygun olan vardır. 2026'da Azure için artık SC-500 doğru adres. AWS için SCS-C03, kavramsal temel için CCSK v5, kıdemli roller için CCSP öne çıkıyor. Hangisini seçerseniz seçin, kendi hesabınızda Prowler gibi araçlarla pratik yaparak teoriyi sağlamlaştırın. Siz hangi bulut sertifikasına hazırlanıyorsunuz? Yorumlarda paylaşın.

Kaynakça

AWS Certified Security - Specialty: https://aws.amazon.com/certification/cer...specialty/
AWS, Security Specialty Exam Guide (SCS-C03): https://docs.aws.amazon.com/aws-certific...ty-03.html
Microsoft Learn, SC-500 study guide: https://learn.microsoft.com/en-us/creden...des/sc-500
Microsoft Learn, retired exams (AZ-500): https://learn.microsoft.com/en-us/creden...tion-exams
Cloud Security Alliance, CCSK: https://cloudsecurityalliance.org/education/ccsk
ISC2, CCSP Exam Outline: https://www.isc2.org/certifications/ccsp...am-outline
Prowler belgeleri: https://docs.prowler.com/

Yasal Uyarı

Bu rehberdeki tarama komutları yalnızca kendi bulut hesabınızda veya yazılı izin aldığınız ortamlarda çalıştırılmalıdır. Başkasına ait bulut kaynaklarını izinsiz taramak veya 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

Toplam (30) Sayfa:« Önceki 1 … 14 151617 18 … 30 Sonraki »