Wazuh ile SIEM/XDR: Ticari Ürünlere Bakmadan Önce Neden Bunu Değerlendirmelisiniz

Son birkaç yıldır önümüze gelen her güvenlik projesinde aynı soruyla karşılaşıyoruz: "SIEM'e ihtiyacımız var ama bütçemiz Splunk veya QRadar'a yetmiyor, ne yapalım?" Bu soruyu duyduğumda artık tereddütsüz Wazuh'u masaya koyuyorum. Açık kaynak olması cazip geliyor ama asıl mesele bu değil — mesele, Wazuh'un artık sadece bir log toplayıcı değil, gerçek anlamda bir XDR platformu haline gelmiş olması.

Wazuh'un kökleri OSSEC'e, yani klasik bir host tabanlı saldırı tespit sistemine (HIDS) dayanıyor. Ama yıllar içinde Elastic Stack'in güvenlik yeteneklerinin de ötesine geçerek bağımsız bir SIEM/XDR çözümüne evrildi. Geleneksel SIEM'lerin çoğu pasif kalır: log toplar, indeksler, analiz eder ve size bir uyarı ekranı sunar. Wazuh ise uç noktalara kurduğu hafif ajanlar sayesinde dosya bütünlüğü izleme, güvenlik yapılandırma değerlendirmesi, zafiyet tespiti ve otomatik yanıt gibi proaktif mekanizmaları tek bir çatı altında topluyor. Bu, saha tarafında farklı ürünleri birbirine yamamak zorunda kalmadan tek bir ajan ve tek bir panelden tam görünürlük elde etmeniz anlamına geliyor.

Mimarinin Dört Ayağı

Wazuh'u anlamanın en pratik yolu dört bileşenini ayrı ayrı ele almak: Ajan, Sunucu (Manager), İndeksleyici (Indexer) ve Gösterge Paneli (Dashboard). Bu yapı, veri toplama, işleme, depolama ve görselleştirme katmanlarını birbirinden ayırıyor ama son derece iyi senkronize çalışıyor — ve bu ayrım sayesinde sistem hem yatayda hem dikeyde rahatça ölçeklenebiliyor.

Ajan tarafı C ile yazılmış, minimum kaynak tüketen bir uygulama. Logcollector modülü syslog ve Windows Event Log gibi kaynakları okurken, Syscheck (FIM) kritik dosyaların ve registry anahtarlarının hash değerlerini (MD5, SHA-1, SHA-256) izliyor. Syscollector donanım, işletim sistemi paketleri, açık portlar ve çalışan süreçleri periyodik tarayarak sunucudaki zafiyet tespiti modülüne veri besliyor. SCA modülü ise CIS gibi sıkılaştırma standartlarına uyumu denetliyor. Ajan, kayıt (enrollment) için 1515/TCP üzerinden TLS kullanıyor, kayıt sonrası olay iletimi ise 1514/TCP üzerinden AES-256 ile şifreleniyor. Binlerce ajanı merkezi konfigürasyonla tek noktadan yönetebilmek, saha operasyonunda gerçekten fark yaratan bir özellik.

Sunucu tarafında asıl karar mekanizması wazuh-analysisd daemon'u. Loglar önce dekoderlerden geçip yapılandırılmış veriye dönüşüyor, ardından kurallar motoruyla eşleştiriliyor. Belirli bir eşiği (genelde seviye 3 ve üstü) geçen her eşleşme bir uyarıya dönüşüyor ve Filebeat servisi bu uyarıları İndeksleyiciye taşıyor.

İndeksleyici, OpenSearch tabanlı, verileri JSON dokümanları olarak saklayan bir arama motoru. wazuh-alerts-, wazuh-archives-, wazuh-monitoring-* ve wazuh-statistics-* gibi ayrı indeks kalıpları kullanılıyor. Arşiv modu (wazuh-archives-*) açıldığında kural tetiklesin tetiklemesin tüm ham olaylar indeksleniyor — adli inceleme için değerli ama depolamayı ciddi şekilde şişiriyor, bunu her projede müşteriye ayrıca anlatmak gerekiyor.

Gösterge Paneli ise OpenSearch Dashboards üzerine kurulu, arka planda iki ayrı bağlantı kullanıyor: görselleştirme için İndeksleyiciye (9200/TCP) doğrudan sorgu, yönetimsel işlemler için ise Sunucunun sunduğu RESTful API'ye (55000/TCP) JWT tabanlı çağrılar. Bu API sayesinde Python, Ansible veya PowerShell ile platformu tamamen uzaktan yönetebiliyorsunuz.

Ajansız İzleme ve Bulut Entegrasyonu

Ajan kurulamayan cihazlar için — yönlendiriciler, switch'ler, güvenlik duvarları — Wazuh syslog üzerinden (514/UDP veya TCP) doğrudan log kabul ediyor ve bu veriler ajandan gelenlerle aynı dekoder/kural zincirinden geçiyor. SSH tabanlı ajansız modül ise uzak cihazlara periyodik bağlanıp komut çalıştırabiliyor veya dosya bütünlük kontrolü yapabiliyor.

Bulut tarafında "Wodle" adı verilen Python tabanlı entegrasyon betikleri devreye giriyor. AWS'de CloudTrail loglarının S3'e düşmesi ve aws-s3 wodle modülünün bu kovaya periyodik erişip verileri çekmesi tipik bir senaryo. Azure ve Office 365 entegrasyonlarında ise azure-logs ve office365 modülleri, Entra ID oturum açma loglarını ve Graph API verilerini kullanarak imkansız seyahat (impossible travel) gibi kimlik odaklı saldırıları yakalayabiliyor. Kamu ve savunma sektöründe çalışırken bu tarz kimlik tabanlı tespitlerin klasik ağ tabanlı tespitlerden çok daha kritik hale geldiğini görüyorum.

Dağıtım Modelleri: Ölçeğe Göre Doğru Mimariyi Seçmek

Sahada en sık yapılan hata, ajan sayısına bakmadan mimariyi seçmek. Üç temel model var:

Hepsi Bir Arada (All-in-One): Sunucu, İndeksleyici ve Panel tek makinede. 50-100 ajana kadar PoC veya test ortamları için uygun, ama tek nokta hata riski taşıdığı için üretimde önermiyorum.

Tekli Düğüm Dağıtık: Bileşenler ayrı sunuculara kurulur ama kümeleme yok. 100-500 ajan arası orta ölçekli üretim için makul bir denge — bileşenler bağımsız ölçeklenebiliyor ama donanım arızasına karşı hâlâ savunmasız.

Çoklu Düğüm Kümesi: Yüzlerce-binlerce ajan ve yüksek erişilebilirlik gerektiren ortamlar için zorunlu. Burada bir "Master" düğüm konfigürasyonu tutarken çok sayıda "Worker" düğüm asıl işi yapıyor ve yük dengeleyici trafiği Worker'lara dağıtıyor. Önemli bir kısıt: Wazuh gerçek çoklu-master mimarisini desteklemiyor. Master çevrimdışı kaldığında log analizi devam eder ama konfigürasyon değişikliği yapamazsınız — bunu proje planlamasında mutlaka hesaba katmak gerekiyor.

Büyük holding yapılarında veya birden fazla veri merkezine sahip kurumlarda "Çoklu Saha" mimarisi devreye giriyor. Her coğrafi bölge kendi yerel sunucu ve indeksleyici kümesine sahip oluyor, ajanlar sadece yerel sunuculara rapor gönderiyor ve böylece WAN üzerindeki darboğaz tamamen ortadan kalkıyor. Sahalar arası indeks verisi felaket kurtarma senaryoları için arka planda çapraz kopyalanıyor, merkezi bir panel de her iki sahaya aynı anda bağlanarak tek noktadan yönetim sağlıyor.

Kural Yazımı ve Aktif Yanıt

Dekoder-kural zinciri Wazuh'un gerçek zekası burada saklı. Ham bir log önce pre-decoding aşamasından geçip tarih, host adı, program adı gibi standart alanlara ayrılıyor, sonra özel XML dekoderler regex ile veriyi ayıklıyor. Performans için dekoderler parent-child hiyerarşisinde çalışıyor: önce program adına bakan bir "ebeveyn" dekoder eşleşiyor, ancak eşleşirse ilgili alt dekoderler devreye giriyor. Bu, gereksiz regex denemelerini önleyip CPU tasarrufu sağlıyor. Regex performansı açısından modern kural yazımında osregex yerine PCRE2 tercih etmek, özellikle IPv4/IPv6 doğrulama gibi karmaşık eşleştirmelerde ciddi fark yaratıyor.

Kurallar da aynı mantıkla zincirleniyor — <if_sid> veya <if_group> etiketleriyle bir kural yalnızca belirli bir ebeveyn kural tetiklendiyse çalışıyor. Örneğin "saniyede 10 başarısız SSH girişi" kuralı logun tamamını taramıyor, sadece "SSH girişi başarısız" kuralı (SID 5716) tetiklendiyse devreye giriyor. Özel kural ID'lerinin 100.000-1.000.000 aralığında tutulması, default kural setinin üzerine yazılmasını engelliyor. Yeni bir kuralı üretime almadan önce wazuh-logtest ile hangi dekoderden geçtiğini ve hangi kuralı tetiklediğini test etmek, saha tecrübesiyle söyleyebilirim ki gereksiz alarm trafiğinin önüne geçmenin en pratik yolu.

Aktif Yanıt modülü ise SIEM'in klasik "tespit et ve haber ver" misyonunu XDR'ın "tespit et ve anında engelle" vizyonuna taşıyan taraf. Bir fidye yazılımı senaryosunda süreç şöyle işliyor: FIM şüpheli bir dosya tespit ediyor, dosya hash'i VirusTotal gibi bir istihbarat kaynağına sorgulanıyor, zararlı olarak işaretlenirse wazuh-execd sunucudan ajana şifreli bir JSON payload gönderiyor, ajan bu komutu yorumlayıp önceden tanımlı bir script çalıştırıyor — iptables kurallarını değiştirerek cihazı ağdan izole etmek ya da dosyayı geri döndürülemez şekilde silmek gibi. Bütün bu zincir insan müdahalesi olmadan saniyeler içinde tamamlanıyor.

Uyumluluk, Zafiyet Tespiti ve Kapasite Planlama

Kurumsal projelerde regülasyon uyumluluğu çoğu zaman işin can alıcı kısmı oluyor. Wazuh her kuralı ilgili standardın maddesine etiketliyor — pci_dss_10.2.4 veya gdpr_IV_30 gibi. Bu sayede denetçinin "bana PCI DSS 10.2.4 ihlallerini göster" talebine panel üzerinden anında yanıt verebiliyorsunuz. Zafiyet tespiti tarafında ise Syscollector'ün topladığı paket envanteri, Wazuh'un kendi CTI veritabanındaki CVE beslemeleriyle (NVD, Canonical, RedHat, Microsoft) eşleştiriliyor ve yama yüklendiğinde durum otomatik "giderildi" olarak güncelleniyor.

Kapasite planlamasında en sık karıştırılan iki kavram EPS (saniyedeki olay) ve APS (saniyedeki uyarı). EPS, ajanlardan sunucuya gelen ham log hacmini ve dolayısıyla analysisd'in CPU ihtiyacını belirliyor — endüstri pratiği yaklaşık her 200 EPS için 1 vCPU. APS ise kuralları geçip alarma dönüşen olayların oranı ve asıl disk ihtiyacını bu belirliyor. İndeksleyici tarafında RAM'in yarısı JVM Heap'e ayrılıyor ama Java'nın sıkıştırılmış nesne göstergesi mimarisi bozulmasın diye bu değer asla 32 GB'ı geçmemeli. Depolama tarafında somut bir örnek vermek gerekirse: 500 iş istasyonu, 50 sunucu ve 20 ağ cihazından oluşan bir ortam 90 günde yaklaşık 1 TB, 180 günde 2 TB'a yakın uyarı verisi üretebiliyor; kümeye bir replika eklendiğinde bu rakam 4,3 TB'a, işletim sistemi I/O payı hesaba katıldığında yaklaşık 7 TB'a çıkıyor. Bu tarz hesapları projenin en başında yapmazsanız, altı ay sonra disk doluyor ve indeksleyici 500 hatası vermeye başlıyor.

Sürekli büyüyen veriyi kontrol altında tutmak için İndeks Yaşam Döngüsü Yönetimi (ISM) politikaları zorunlu hale geliyor. Sıcak-ılık-soğuk katmanlama mantığıyla son 30 günlük veri yüksek performanslı disklerde replikalı tutulurken, daha eski veriler replikasız ve salt-okunur hale getiriliyor, saklama süresi dolan indeksler ise otomatik siliniyor.

Ticari Alternatiflere Kıyasla Nerede Duruyor

Splunk'ın günlük indekslenen gigabayt üzerinden fiyatlandırması, orta ölçekli bir kurumu (günde ~25 GB veri) yılda 45-100 bin dolar bandına taşıyabiliyor — ve hatalı yapılandırılmış tek bir DNS sunucusunun ürettiği fazla log, lisans bütçesini saatler içinde eritebiliyor. Microsoft Sentinel GB başına ücretlendiriliyor ama 90 günden uzun saklama için Log Analytics Workspace üzerinde öngörülemeyen ek maliyetler ortaya çıkıyor. Wazuh'ta ise ajan, EPS veya GB bazlı bir lisans kısıtlaması yok; asıl maliyet donanım ve platformu yönetecek yetkin personel.

Bunun karşılığında bazı yapısal sınırlamaları kabul etmek gerekiyor. Wazuh esasen uç nokta odaklı bir sistem olduğu için Kubernetes control plane loglarının derinlemesine incelenmesinde veya kompleks cloud-native ortamlarda amaca özel CSPM araçlarının gerisinde kalabiliyor. Sentinel veya Splunk'ın hazır yüzlerce konnektörüne karşılık, dış sistem entegrasyonları çoğunlukla Wodle betiklerinin elle uyarlanmasını gerektiriyor. Gerçek çoklu-master kümeleme eksikliği de bir düğüm çöktüğünde manuel müdahale ihtiyacını beraberinde getiriyor.

Uyarı Yorgunluğu ve Yapay Zeka Entegrasyonları

Her SOC ekibinin ortak derdi yanlış pozitifler ve uyarı yorgunluğu. Sürekli tetiklenen ama zararsız olduğu bilinen olayları (mesela onaylı bir zafiyet tarayıcısının ürettiği trafik) local_rules.xml içinde seviye 0'a çekerek susturmak, binlerce IP veya kullanıcıyı CDB Listeleri ile beyaz listeye almak, tuning sürecinin temel araçları.

Akademik tarafta ilginç gelişmeler var: kural bazlı eşik tespiti, günlere yayılan yavaş kaba kuvvet saldırıları gibi sinsi senaryolarda yetersiz kalabiliyor. "Smart-SIEM" adlı bir modelde, olaylara bağlam vektörü (son 30 olayın istatistiksel dağılımı) eklenerek LightGBM ve XGBoost ile %96,7 F1 skoru elde edilmiş — varsayılan kural motorunun tespit oranı %0 kalan bazı brute-force senaryolarını bu yaklaşım %100 doğrulukla yakalayabilmiş. Benzer şekilde LLM tabanlı çalışmalarda, Wazuh'tan çıkarılan verilerle olay çözümleme kodu %90 doğrulukla tahmin edilebilmiş. Bu araştırmalar henüz üretim ortamlarının standart parçası değil ama yönün nereye gittiğini gösteriyor: durum-bağımsız kural motorlarından, bağlamı hatırlayan ve öğrenen bir tespit katmanına doğru.

Sonuç olarak Wazuh, doğru boyutlandırıldığında ve dekoder/kural/ISM tarafında disiplinli yönetildiğinde, ticari SIEM'lerin astronomik lisans maliyetlerini ortadan kaldırırken uç nokta seviyesinde gerçek bir XDR deneyimi sunabiliyor. Bedeli ise mühendislik: kural yazımı, regex optimizasyonu ve küme stabilizasyonu gibi konularda kapalı kutu bir üründe olduğundan daha fazla iş yükünü kurum içinde taşımanız gerekiyor.