Selamlar,
Açık kaynak zafiyet tarayıcı denince akla hâlâ OpenVAS geliyor; proje bugün Greenbone Community Edition / GVM çatısı altında. Bu yazıda ev labımda GVM'i ayağa kaldırıp ilk izinli taramayı çalıştırma ve raporu okuma notlarımı paylaşıyorum. Hedef yalnızca kendi VM'lerim.
Mimariyi kısaca tanıyın
- gvmd: yönetici daemon
- ospd-openvas: tarayıcı sarmalayıcı
- openvas-scanner: asıl motor
- gsad: web arayüzü (Greenbone Security Assistant)
- Feed'ler: NVT, SCAP, CERT — kalite bunların güncelliğine bağlı
Kurulum (Docker ile pratik yol)
Resmi Greenbone community container dokümantasyonunu takip etmek, kaynak derlemekten çok daha az acılı. Labımda docker compose ile ayağa kaldırdım; ilk feed senkronu uzun sürer (saat düzeyinde olabilir). Sabır şart.
Kod:
# Örnek: feed durumunu kontrol (kuruluma göre komut değişir)
docker compose ps
# Web arayüzü genelde https://localhost:9392İlk hedef ve görev
- Configuration > Targets: lab IP veya CIDR (ör. 10.10.10.0/28)
- Credentials (opsiyonel): SSH/SMB kimliği verirseniz authenticated scan derinleşir
- Tasks > New Task: tarama profili seçin
- Full and fast: günlük lab için dengeli
- Discovery: yalnızca keşif
- Full and very deep: uzun ve gürültülü; bilinçli kullanın
Raporu okumak
Sonuçlarda CVSS skoru, QOD (Quality of Detection) ve CVE listesi gelir. Pratik filtrelerim:
- Önce QOD'u yüksek + CVSS kritik/high olanlar
- Sonra "False Positive" işaretleme disiplini (yoksa bir sonraki taramada aynı gürültü)
- CVE'yi NVD ve üretici bülteniyle doğrula; tarayıcı yanlış pozitif üretebilir
- Authenticated bulgular (eksik yama, zayıf cipher) genelde daha aksiyoneldir
CLI ile hızlı bakış
Ortamınıza göre gvm-cli / omp benzeri araçlarla görev başlatılabilir. Önemli olan otomasyonda kimlik bilgilerini düz metin dosyada bırakmamaktır.
Sınırlar: tarayıcı pentest değildir
GVM bilinen imzaları arar. İş mantığı açıkları, zincirleme exploit, fiziksel güvenlik bu aracın işi değildir. Raporu "otomatik bulgu listesi" olarak görün; pentest metodolojisinin keşif/zafiyet analizi aşamasına girdi sağlar.
Performans ipuçları
- Feed güncellemesini geceye bırakın
- Eşzamanlı hedef sayısını lab kaynaklarına göre sınırlayın
- Firewall'da tarayıcı IP'sini allowlist'e almak (izinli pentestte) yanlış pozitif düşürür
Kaynaklar
- Greenbone Community Documentation
- OpenVAS / GVM GitHub org
- NIST NVD (CVE doğrulama)
Siz feed senkronunda en çok hangi adımda takıldınız? Container log'unda gördüğünüz tipik hataları da yazabilirsiniz.
Authenticated scan değeri
Kimliksiz tarama çoğunlukla sürüm ve port bulur. SSH/WinRM/SMB hesabı verdiğinizde eksik yama, yerel kullanıcı politikası, zayıf servis yapılandırması çıkar. Labda ayrı bir "scanner" hesabı açın; domain admin vermeyin. Başarıyla giriş yapılamazsa rapor "auth failed" diye yalan yanlış critical üretmesin diye görev logunu kontrol edin.
Raporu iş biletleme
CSV/XML dışa aktarıp her kritik CVE için: varlık sahibi, yama penceresi, geçici mitigeasyon (WAF imzası, port kapatma). Tarayıcı skoru tek başına öncelik değildir; internete açık + exploit public ise yukarı çekin.
Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.
Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.
Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.
Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.
Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.
Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.
Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.
Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.
Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.
Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.
Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.
Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.
Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.
Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.
Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.