sıfır-gün açık paniği yaşamamanın yolu: saldırı yüzeyini küçültmek

arkadaşlar, hepimiz biliyoruz o panik anını. yeni bir kritik açık açıklanıyor, herkes telaşa düşüyor, gece yarısı yamalar atılıyor, kafeinli içecekler tüketiliyor. ama intruder’ın güvenlik şefi güzel bir yazı yazmış: “bu panik aslında önlenebilir” diyor.

şöyle ki, yeni bir açık ne zaman çıkacağını kontrol edemezsiniz ama ne kadar sisteminizin internete açık olduğunu kesinlikle kontrol edebilirsiniz. sorun şu: çoğu ekip aslında ne kadar fazla şeyin internete baktığının farkında bile değil.

sorun nerede yani

agalar, durum şöyle: sömürü süreleri (time-to-exploit) gittikçe kısalıyor. yani bir açık açıklandıktan sonra saldırganların onu kullanmaya başlaması eskiden günler alırken, şimdi saatler hatta dakikalar alıyor.

peki bu sizin için ne anlama geliyor? saldırı yüzeyiniz ne kadar büyük ve kontrolsüzse, o kadar çok hedef var demektir. her internete açık servis, her unutulmuş test sunucusu, her “bi ara bakarız” dediğiniz sistem potansiyel bir giriş noktası.

temel mesele: çoğu ekip ne kadar şeyin internete açık olduğunu tam olarak bilmiyor. shadow IT var, eski projelerden kalan sistemler var, “geçici” diye açılmış portlar var (spoiler: hiçbir geçici şey geçici kalmaz).

saldırı yüzeyi nedir tam olarak

basitçe: internetten erişilebilen tüm sistemleriniz, servisleriniz, uygulamalarınız. bunlar:

• web sunucuları
• api’ler
• vpn gateway’leri
• uzaktan erişim servisleri (rdp, ssh vs)
• bulut servisleri
• iot cihazları (güvenlik kameraları, yazıcılar falan)
• unutulmuş dev/test ortamları
• eski, artık kullanılmayan ama hala ayakta duran sistemler

neden bu kadar kontrolsüz büyüyor bu yüzey

birkaç klasik senaryo:

1. “hızlı bi test için açtım portunu”

• developer arkadaş hızlıca test etmek için bir portu internete açıyor
• test bitiyor ama port açık kalıyor
• 6 ay sonra o arkadaş başka departmana geçmiş, kimse bilmiyor

2. shadow IT

• marketing ekibi kendi başına bir cms kurmuş
• IT’den habersiz, güvenlik yamalarından habersiz
• ama internete açık

3. “legacy sistem ama çalışıyor işte”

• eski bir uygulama, 5 yıldır güncellenmemiş
• “dokunma çalışıyor” mantığıyla öyle duruyor
• bir gün bir açık bulunuyor, panic mode

4. bulut ortamı kontrolsüzlüğü

• herkes aws’de bir şeyler açıyor
• s3 bucket’ları public
• security group’lar çok geniş
• kimse tam olarak ne olduğunu bilmiyor

peki ne yapmalı

1. envanter çıkarın (cidden, şimdi)

önce ne olduğunu bilmeniz lazım:

# nmap ile kendi ağınızı tarayın (dikkat: yasal izin gerekir)
nmap -sV -p- your-public-ip-range

# shodan'da kendi domain'inizi arayın
# ne görüyorsanız saldırganlar da onu görüyor

# cloud ortamlarında:
# aws için
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,PublicIpAddress,State.Name]'

# azure için  
az vm list --query '[].{name:name, publicIP:publicIps}'

dikkat: bu taramaları yapmadan önce yöneticinizden izin alın, sonra “saldırı var” diye alarm vermesinler.

2. gereksiz her şeyi kapatın

agalar, şu “belki lazım olur” mantığını bırakın:

• kullanılmayan servisler? kapat.
• eski test ortamları? sil.
• gereksiz portlar? kapat.
• unutulmuş subdomain’ler? temizle.

altın kural: eğer aktif olarak kullanılmıyorsa, internete açık olmamalı.

3. erişimi sınırlandırın

her şeyin 0.0.0.0/0’a açık olması gerekmez:

# ssh sadece ofis ip'sinden
iptables -A INPUT -p tcp --dport 22 -s office-ip/32 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

# veya cloud ortamında security group kuralları:
# sadece belirli ip aralıklarına izin verin
# vpn arkasına alın mümkünse

4. segmentasyon yapın

her şey aynı ağda olmasın:

• üretim ortamı ayrı
• dev/test ortamı ayrı
• yönetim ağı (management) ayrı
• dmz kullanın internete açık servisler için

5. sürekli izleyin

bir kere temizleyip bırakmayın:

• otomatik asset discovery araçları kullanın
• düzenli olarak port taraması yapın (kendi sisteminize)
• cloud ortamlarında compliance araçları kullanın
• değişiklikleri loglayın

# cron job ile düzenli tarama
0 2 * * 0 /usr/local/bin/scan-external-assets.sh | mail -s "Haftalık Asset Raporu" security@company.com

6. zero trust yaklaşımı

klasik “ağ içindeysen güvenilirsin” mantığını bırakın:

• her erişim doğrulansın
• en az yetki prensibi (least privilege)
• mikro-segmentasyon
• sürekli doğrulama

pratik öneriler

hemen yapılacaklar:

1. shodan’da kendinizi arayın

   • org:"Your Company Name"
   • ne görüyorsunuz? saldırganlar da onu görüyor

2. sertifika transparency loglarına bakın

   • crt.sh’ta domain’inizi arayın
   • bilmediğiniz subdomain’ler var mı?

3. cloud security posture management (cspm) aracı kurun

   • aws: aws config + security hub
   • azure: azure security center
   • gcp: security command center

4. basit bir politika belirleyin:

   • internete yeni bir şey açılacaksa approval süreci
   • 90 günde kullanılmayan her şey kapanıyor
   • her 3 ayda asset review

orta vadeli:

• otomatik asset discovery pipeline kurun
• infrastructure as code (IaC) kullanın, manuel değişiklik yok
• immutable infrastructure: değiştirme, yeniden yap
• düzenli penetrasyon testleri

uzun vadeli:

• sıfır güven mimarisi (zero trust)
• tam network segmentasyonu
• otomatik compliance checking
• devsecops kültürü

gerçek dünya örneği

şöyle düşünün: 1000 sunucunuz var, 100 tanesi gereksiz yere internete açık. yeni bir kritik açık çıkıyor (örneğin log4shell gibi).

senaryo 1 (kontrolsüz):

• 100 sunucuyu bulmaya çalışıyorsunuz
• hangilerinde etkilenen versiyon var bilmiyorsunuz
• bazılarını unutmuşsunuz bile
• saldırganlar sizi tarayıp zafiyetli olanları 2 saatte buluyor
• siz daha envanter çıkarırken saldırı başlıyor

senaryo 2 (kontrollü):

• sadece 10 sunucu internete açık, hepsi biliniyor
• hepsinde asset management var
• hangi versiyonlar çalışıyor biliyorsunuz
• 1 saat içinde yamalıyorsunuz veya geçici olarak kapatıyorsunuz
• saldırı yüzeyiniz %90 daha küçük

sonuç olarak

agalar, sıfır-gün açıklar her zaman olacak. bunu değiştiremeyiz. ama ne kadar hedef sunduğumuzu kesinlikle kontrol edebiliriz.

“en iyi güvenlik, saldırılacak bir şey bırakmamaktır” - eski bir sistem yöneticisi atasözü (şimdi uydurdum ama doğru)

yapmanız gerekenler:

1. ne olduğunu bilin (asset inventory)
2. gereksizi kapatın (reduce surface)
3. gerekeni koruyun (harden)
4. sürekli izleyin (continuous monitoring)
5. hızlı hareket edin (incident response)

edit: bu sadece teknik bir konu değil, kültür meselesi. “hızlı ship edelim, güvenlik sonra” mantığı artık geçerli değil. güvenlik baştan tasarlanmalı.

spoiler: yöneticinize bunu anlatırken şu argümanı kullanın: “bir sıfır-gün açık için gece yarısı tüm ekibi toplamak mı daha ucuz, yoksa düzenli temizlik yapmak mı?” cevap belli.

kaynaklar

• The Hacker News - Orijinal Yazı
• OWASP Attack Surface Analysis
• NIST Cybersecurity Framework

hadi bakalım, işe koyulun. saldırı yüzeyinizi küçültün, sonra rahat rahat uyuyun.

not: önce test ortamında deneyin bunları, sonra “sen dedin yaptık, production patladı” demeyin.

Bu içerik yapay zeka tarafından oluşturulmuştur.