Kurumsal iç ağlarda zafiyet yönetimi çoğu zaman iki uçtan birine savrulur. Ya kapsamlı taramalar nadiren yapılır ve sonuçlar haftalarca işlenmeden kalır, ya da çok sık tarama yapılıp gürültü seviyesi ekiplerin güvenini düşürür. Nuclei bu dengeyi kurmak için iyi bir araçtır; çünkü doğrulanabilir şablon yaklaşımıyla hedefi belli, düşük maliyetli ve otomasyona uygun kontroller üretir.
Nuclei’yi neden iç ağ için düşünmeli?
Nuclei genelde internet yüzeyi taramalarında anılır, fakat iç varlıklar için de güçlüdür. Özellikle şu senaryolarda değer üretir:
- Yönetim panellerinde unutulmuş varsayılan yollar
- Açık versiyon bilgisinden doğrulanabilen zafiyetler
- Kurumsal standart dışı başlık veya konfigürasyon eksikleri
- Bilinen middleware ve ajan yüzeyleri
Burada ana fikir, her portu körlemesine denemek değil; envanteri bilinen servis sınıflarına göre anlamlı şablon setleriyle doğrulamaktır.
Hedef listesi nasıl hazırlanmalı?
En sağlıklı model, hedefleri CMDB veya servis envanterinden beslemektir. En azından şu alanlar olmalı:
- Varlık adı
- IP veya FQDN
- Servis tipi
- Ortam sınıfı
- Sahip ekip
Bu veri sayesinde Nuclei şablonlarını tüm ağa aynı şekilde değil, servis profiline göre uygulayabilirsiniz.
Örnek hedef dosyası:
https://grafana.internal.example.com
https://vault.internal.example.com
https://jenkins.internal.example.comTemel tarama komutu:
nuclei -l targets.txt -tags exposures,misconfig,default-login -severity medium,high,critical -jsonl -o findings.jsonlGürültüyü nasıl azaltırsınız?
Asıl farkı burada yaratırsınız. İç ağda sürekli doğrulama kurarken şu filtreler önemlidir:
- Şablonları servis sınıfına göre ayırmak
- Düşük değerli bilgi bulgularını varsayılan olarak dışarıda bırakmak
- Bakım penceresi dışındaki agresif kontrolleri kapatmak
- Aynı bulguyu tekrar tekrar ticket’a dönüştürmemek
Pratikte çoğu ekip için günlük hafif tarama, haftalık derin taramadan daha sürdürülebilir sonuç verir.
Operasyon akışına nasıl bağlanır?
En kötü kullanım, JSON çıktısını üretip kimsenin bakmadığı bir klasöre bırakmaktır. Benim önerdiğim akış şöyledir:
- Nuclei çıktısını
jsonlolarak üretin - Aynı bulgunun açık kaydı varsa yeniden açmayın
- Sahip ekibi varlık envanterinden eşleyin
- Sadece doğrulanmış orta ve üzeri bulguları ticket’a dönüştürün
- Kritik bulgular için kısa SLA ve yeniden doğrulama çalıştırın
Bu model, zafiyet yönetimini rapor üretiminden çıkarıp kapanabilir operasyon işine dönüştürür.
Örnek zamanlama
Basit bir cron yaklaşımı yeterli olabilir:
15 2 * * * nuclei -l /srv/nuclei/targets.txt \
-tags exposures,misconfig,default-login \
-severity medium,high,critical \
-jsonl -o /srv/nuclei/out/findings-$(date +\%F).jsonlBu komutun ardından küçük bir ayrıştırıcı ile bulguları normalize edip mevcut ticket sistemiyle eşleştirebilirsiniz.
En sık yapılan hata
Şablon deposunun tamamını hiçbir filtre olmadan iç ağa koşturmak sık görülen hatadır. Böyle yapıldığında hem gereksiz gürültü oluşur hem de bazı ekipler taramayı saldırı gibi algılar. Başlangıç için daha dar ama güvenilir bir şablon seti seçmek, sisteme güven oluştuğunda kapsamı büyütmek daha doğrudur.
Sonuç
Nuclei ile iç varlıklarda sürekli zafiyet doğrulama, iç ağ güvenliğini dönemsel tarama raporlarından çıkarıp yaşayan bir kontrol katmanına dönüştürür. Hedef envanteri, sınıflandırılmış şablon seti ve tekrarları azaltan ticket akışı birlikte kurulduğunda hem gürültü azalır hem de gerçekten kapanan bulgu oranı yükselir. Sağlam zafiyet yönetimi, en çok bulgu üreten değil; en tutarlı doğrulama döngüsünü kuran sistemdir.