Wazuh ve Suricata birlikte kullanıldığında uç nokta telemetrisi ile ağ trafiği görünürlüğünü tek bir açık kaynak SOC laboratuvarında birleştirebilir. Wazuh; ajan, sunucu, indexer ve dashboard bileşenleriyle dosya bütünlüğü, güvenlik yapılandırması, günlük analizi ve alarm yönetimi sağlar. Suricata ise ağ paketlerini inceleyerek IDS/IPS kuralları, protokol kayıtları ve akış telemetrisi üretir.

Bu rehber, ev laboratuvarı veya küçük bir test ağı için Wazuh single-node mimarisini, Suricata'nın EVE JSON çıktısını, Wazuh log collector entegrasyonunu, özel decoder ve kural mantığını, yanlış pozitif azaltmayı ve güvenli üretim geçişini anlatır. Amaç saldırı yapmak değil; kendi yetkili ağınızdaki sinyalleri güvenilir biçimde toplamak ve olayları doğrulamaktır.

Mimari: hangi bileşen ne yapar?

Wazuh merkezi tarafta üç ana bileşen kullanır: Wazuh server olayları alır ve kurallarla analiz eder; Wazuh indexer alarmları saklar ve aramaya açar; Wazuh dashboard görselleştirme ve yönetim arayüzüdür. Uç noktalardaki Wazuh agent ise işletim sistemi günlüklerini, dosya bütünlüğü değişikliklerini ve güvenlik telemetrisini merkezi sunucuya gönderir.

Suricata ağ sensörü olarak seçilen arayüzde trafiği inceler. HTTP, TLS, DNS, SSH, flow ve alert gibi olayları eve.json dosyasına JSON satırları halinde yazabilir. Wazuh agent bu dosyayı okur, olayları manager'a iletir ve yerleşik ya da özel kurallarla alarma dönüştürür.

BileşenGörevTipik veri
SuricataAğ trafiği analizialert, dns, http, tls, flow, fileinfo
Wazuh agentYerel toplama ve iletimeve.json, auth.log, syslog, FIM
Wazuh serverDecode, kural ve korelasyonnormalized event ve alert
Wazuh indexerArama ve saklamawazuh-alerts indeksleri
Wazuh dashboardİnceleme ve görselleştirmedashboard, discover, rule görünümü


Laboratuvar topolojisi

En sade kurulumda üç mantıksal rol yeterlidir:


  • Wazuh sunucusu: Manager, indexer ve dashboard'u tek Linux makinede veya resmi single-node Docker bileşimiyle çalıştırır.
  • Suricata sensörü: Ubuntu tabanlı bir VM veya fiziksel sistemde ağ trafiğini görür ve Wazuh agent barındırır.
  • Test istemcisi: Yalnız yetkili laboratuvar trafiği üretir; DNS, HTTP ve TLS olaylarıyla veri hattı doğrulanır.



Sensörün göremediği trafik analiz edilemez. Sanal ortamda port mirroring, Linux bridge veya hypervisor sanal anahtar ayarı; fiziksel ağda ise yönetilebilir switch SPAN/TAP kullanımı gerekebilir. Sensörü inline IPS olarak başlatmak yerine önce pasif IDS biçiminde çalıştırmak daha güvenlidir.

Kaynak gereksinimleri

Wazuh'un resmi Docker belgesi single-node dağıtım için en az 4 CPU çekirdeği önerir. Indexer belgesi, tek indexer düğümü için minimum 4 GB RAM ve 2 CPU; önerilen olarak 16 GB RAM ve 8 CPU verir. Küçük laboratuvarda tüm bileşenler aynı makinede çalışacağı için 8 GB RAM pratik alt sınır, 12-16 GB daha rahat bir başlangıçtır.

Disk ihtiyacı olay hacmi ve saklama süresine bağlıdır. Suricata'da yalnız alert kaydı yerine dns, http, tls ve flow olaylarının tamamı açılırsa günlük veri hızla büyür. Laboratuvara başlamadan önce beklenen events-per-second değeri, indeks rotasyonu ve saklama günü belirlenmelidir.

Wazuh single-node kurulumu

Wazuh resmi belgeleri hızlı kurulum, bileşen bazlı kurulum ve Docker seçenekleri sunar. Docker kullanan ekipler güncel resmi etiketi Wazuh dokümanından doğrulamalıdır; eski bir blogdaki sürüm numarasını üretime kopyalamayın.

Tipik laboratuvar akışı şöyledir:

CODE TERMINAL
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.7
cd wazuh-docker/single-node
docker compose -f generate-indexer-certs.yml run --rm generator
docker compose up -d
docker compose ps


Sürüm etiketi bu yazının hazırlandığı sıradaki resmi doküman örneğidir. Kurulumdan önce Wazuh'un güncel kararlı sürümünü ve upgrade notlarını kontrol edin. Docker, yapılandırmayı dinamik olarak yeniden yüklemediği için manager veya indexer ayarı değiştirildiğinde ilgili bileşenin kontrollü biçimde yeniden başlatılması gerekebilir.

Dashboard ilk açılışta self-signed sertifika kullanabilir. Sertifika uyarısını üretim alışkanlığı haline getirmeyin; laboratuvar dışında kurumsal CA veya güvenilir sertifika zinciri kullanın. Varsayılan parolaları ilk girişte değiştirin ve dashboard'u doğrudan internete açmayın.

Suricata kurulumu ve arayüz seçimi

Ubuntu üzerinde resmi OISF kararlı deposu kullanılabilir:

CODE TERMINAL
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update
sudo apt install suricata -y
suricata --build-info
ip -br link


Arayüz adını tahmin etmeyin. ip -br link çıktısıyla trafiği gerçekten gören arayüzü belirleyin. Netplan, NetworkManager, sanal switch ve promiscuous mode ayarları topolojiye göre değişebilir.

Suricata yapılandırmasında HOME_NET yalnız laboratuvarın korunan ağlarını kapsamalıdır. Çok geniş HOME_NET gürültüyü artırır; çok dar değer ise gerçek iç ağ trafiğini dış ağ gibi sınıflandırır.

CODE TERMINAL
vars:
  address-groups:
    HOME_NET: "[192.168.50.0/24]"
    EXTERNAL_NET: "!$HOME_NET"


Yapılandırma değişikliğinden sonra servis yeniden başlatılmadan önce dosya doğrulanmalıdır:

CODE TERMINAL
sudo suricata -T -c /etc/suricata/suricata.yaml -v
sudo systemctl restart suricata
sudo systemctl status suricata --no-pager


EVE JSON neden merkezde?

EVE JSON, Suricata'nın farklı olay türlerini yapılandırılmış JSON olarak tek akışta sunar. Her satırda zaman damgası, flow_id, kaynak ve hedef adresleri, portlar, protokol ve event_type gibi ortak alanlar bulunabilir. Alert olayları ayrıca signature, category, severity ve rule ID bilgisi taşır.

Laboratuvar için dengeli bir başlangıç:

CODE TERMINAL
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      types:
        - alert
        - dns
        - http
        - tls
        - flow
        - fileinfo


HTTP body veya tam dosya içeriği gibi hassas ve yüksek hacimli seçenekler varsayılan olarak açılmamalıdır. URL, hostname, kullanıcı aracısı ve TLS SNI bile kişisel ya da ticari hassas veri olabilir. Toplama amacı, erişim rolü ve saklama süresi belgelenmelidir.

Suricata kural güncellemesi

Suricata paketleri genellikle suricata-update aracını içerir. Kural kaynağını ve etkin dosyayı doğruladıktan sonra güncelleme yapılabilir:

CODE TERMINAL
sudo suricata-update
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl reload suricata


Reload desteği dağıtım ve çalışma kipine göre değişebilir; başarısız olursa kontrollü restart planı uygulayın. Kural güncellemesini doğrudan engelleme kipindeki üretim sensörüne vermeden önce staging sensöründe performans ve yanlış pozitif testi yapılmalıdır.

Wazuh agent kurulumu

Suricata sensörü üzerinde Wazuh agent kurulur ve manager adresine kaydedilir. Paket komutu işletim sistemi ve Wazuh sürümüne göre değiştiği için resmi Wazuh agent belgesindeki güncel depo adımları kullanılmalıdır. Kurulumdan sonra agent'ın manager ile bağlantısı doğrulanır:

CODE TERMINAL
sudo systemctl enable --now wazuh-agent
sudo systemctl status wazuh-agent --no-pager
sudo tail -n 50 /var/ossec/logs/ossec.log


Agent bağlantısı yokken eve.json toplamayı ayarlamak merkezi görünürlük sağlamaz. Önce dashboard'da sensörün active olduğu, ardından sıradan sistem günlüklerinin ulaştığı doğrulanmalıdır.

Wazuh'a eve.json ekleme

Suricata sensöründeki /var/ossec/etc/ossec.conf dosyasına JSON biçimli localfile tanımı eklenir:

CODE TERMINAL
<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>


Dosya yolu Suricata yapılandırmanızla aynı olmalıdır. Ardından Wazuh agent yapılandırması test edilir ve servis yeniden başlatılır:

CODE TERMINAL
sudo /var/ossec/bin/wazuh-control restart
sudo tail -f /var/ossec/logs/ossec.log


Agent kullanıcısının eve.json dosyasını okuyabilmesi gerekir. Herkese okuma izni vermek kolay ama kötü bir çözümdür. Dosya grubu, ACL veya log collector için en az ayrıcalıklı okuma yetkisi kullanılmalıdır. Logrotate sonrasında izinlerin korunacağı da test edilmelidir.

Veri hattını güvenli test etme

En iyi ilk test, kendi yetkili ağınızda zararsız ve beklenen protokol trafiği üretmektir. Bir DNS sorgusu, HTTPS bağlantısı ve laboratuvar web sunucusuna istek gönderin. Önce Suricata eve.json dosyasında olayın bulunduğunu, sonra Wazuh manager arşivinde ve dashboard'da göründüğünü doğrulayın.

CODE TERMINAL
sudo jq -c 'select(.event_type=="dns")' /var/log/suricata/eve.json | tail
sudo jq -c 'select(.event_type=="tls")' /var/log/suricata/eve.json | tail


Test için üçüncü taraf sistemleri taramayın ve herkese açık saldırı payload'ları göndermeyin. Laboratuvar veri hattını doğrulamak için normal protokol olayları yeterlidir. IDS alarmı gerekiyorsa Suricata belgelerindeki kontrollü test kuralını yalnız size ait IP'ler arasında kullanın.

Wazuh kural hiyerarşisi

Wazuh, decoder aşamasında ham olayı alanlara ayırır; rule aşamasında bu alanları eşleştirip seviye, grup ve açıklama üretir. JSON decoder eve.json alanlarını okuyabildiği için çoğu Suricata olayı için sıfırdan decoder yazmak gerekmez. Önce dashboard'da data.suricata veya ilgili JSON alanlarının nasıl adlandırıldığını gözlemleyin.

Özel kurallar /var/ossec/etc/rules/local_rules.xml altında tutulabilir. Yerleşik rule ID alanıyla çakışmamak için özel aralık kullanın. Örnek, yalnız yapıyı göstermek içindir:

CODE TERMINAL
<group name="suricata,network_ids,">
  <rule id="100500" level="8">
    <field name="event_type">alert</field>
    <field name="alert.severity">1</field>
    <description>Suricata yüksek önem alarmı: $(alert.signature)</description>
    <options>no_full_log</options>
  </rule>
</group>


Gerçek Wazuh alan yolu sürüme ve decoder sonucuna göre değişebilir. Kuralı kaydetmeden önce wazuh-logtest ile gerçek bir örnek olay üzerinde doğrulayın:

CODE TERMINAL
sudo /var/ossec/bin/wazuh-logtest


Bir kuralın eşleşmesi onun kaliteli olduğu anlamına gelmez. Alarm açıklaması olay bağlamını taşımalı, seviye gerçek riske göre seçilmeli ve aynı flow için yüzlerce kopya üretmemelidir.

Yanlış pozitif azaltma

Suricata + Wazuh entegrasyonunda en yaygın hata, tüm IDS uyarılarını aynı yüksek seviyeye çıkarmaktır. İmza severity değeri tek başına iş etkisini bilmez. Hedefin kritikliği, internetten erişilebilirlik, bağlantının başarılı olup olmadığı ve aynı kaynaktan tekrar sayısı gibi bağlamlar eklenmelidir.


  • Önce gözlem modunda bir baseline dönemi oluşturun.
  • En çok alarm üreten ilk 20 imzayı kaynak, hedef ve hizmete göre inceleyin.
  • Kurala değil, belirli yanlış pozitif bağlamına istisna yazın.
  • Geniş IP veya imza kapatma yerine mümkün olan en dar koşulu kullanın.
  • İstisnaya sahip, gerekçe, oluşturma tarihi ve gözden geçirme tarihi ekleyin.
  • Kural güncellemesinden sonra alarm hacmi ve CPU kullanımını karşılaştırın.



Bir güvenlik imzasını yalnız “çok alarm üretiyor” diye kapatmak görünürlük kaybıdır. Önce trafiğin neden oluştuğunu ve meşru uygulamanın daha doğru yapılandırılıp yapılandırılamayacağını araştırın.

Flow ID ile olay korelasyonu

Suricata aynı bağlantıya ait alert, dns, http, tls ve flow olaylarında ortak flow_id kullanabilir. Wazuh tarafında bu alan saklandığında analist bir alarmdan aynı akışın protokol bağlamına geçebilir. Bu, imzanın gerçekten başarılı bir oturumla mı yoksa yalnız başarısız bir denemeyle mi ilişkili olduğunu anlamayı kolaylaştırır.

Korelasyonda şu sorular sorulmalıdır:


  1. Alarmdan önce aynı flow_id için DNS veya TLS olayı var mı?
  2. Hedef hizmet gerçekten yanıt vermiş mi?
  3. Kaynak IP aynı zaman aralığında başka hedeflere de erişmiş mi?
  4. Uç noktadaki Wazuh agent aynı dakikalarda süreç, kullanıcı veya dosya değişikliği görmüş mü?
  5. İmza alarmından sonra dış bağlantı ya da yeni kalıcılık sinyali oluşmuş mu?



Bu yaklaşım ağ alarmını tek başına kanıt olarak değil, uç nokta ve kimlik telemetrisiyle zenginleştirilecek bir başlangıç sinyali olarak ele alır.

Dashboard ve indeks yönetimi

Wazuh indexer alarm indekslerini yakın gerçek zamanlı arama için saklar. Dashboard'da Discover görünümüyle rule.id, agent.name, source.ip, destination.ip, event_type, alert.signature ve flow_id alanları incelenebilir. Alan adları ortamınızdaki gerçek belge şemasından seçilmelidir.

Saklama süresi belirlenmeden tüm ağ olaylarını sonsuza kadar tutmak disk tüketimini kontrolsüz artırır. Alert olayları daha uzun, düşük değerli flow kayıtları daha kısa saklanabilir. Hukuki ve kurumsal gereksinimler ayrı değerlendirilmelidir.

Veri sınıfıÖnerilen yaklaşım
Yüksek önem alertUzun saklama, olay kaydıyla ilişkilendirme
DNS ve TLS metadataAmaçla sınırlı saklama, erişim kontrolü
HTTP metadataKişisel veri ve token riski için alan incelemesi
FlowHacme göre kısa veya orta saklama
Ham paketVarsayılan kapalı; yalnız yetkili olay prosedürü


Performans ve paket kaybı

Suricata işlem kapasitesini aşarsa paket kaybı yaşanabilir ve görünürlük sessizce azalır. capture.kernel_drops, packet loss, CPU, bellek ve eve.json yazma gecikmesi izlenmelidir. Wazuh agent kuyruğu veya manager giriş kapasitesi de ayrı darboğaz olabilir.

Sorun görüldüğünde önce gereksiz EVE olay türlerini azaltın, ağ arayüzü offload ayarlarını ve capture threading modelini gözden geçirin, kural setini ihtiyaca göre daraltın ve sensöre yeterli CPU çekirdeği ayırın. Performans ayarı yaparken tespit kapsamını farkında olmadan düşürmediğinizi kontrollü trafikle doğrulayın.

Güvenli üretim geçişi

Laboratuvarın çalışması onu doğrudan üretime taşımak için yeterli değildir. Üretim tasarımı aşağıdaki kontrolleri içermelidir:


  • Wazuh manager, indexer ve dashboard için ayrı ağ segmenti
  • Güvenilir sertifikalar ve bileşenler arası TLS doğrulaması
  • Varsayılan hesapların kaldırılması veya parolalarının değiştirilmesi
  • Dashboard için MFA, rol tabanlı erişim ve IP kısıtı
  • Indexer yedekleme, snapshot ve geri yükleme testi
  • NTP senkronizasyonu ve doğru zaman dilimi
  • EVE dosyası, Wazuh kuyruğu ve indeks kapasitesi için sağlık alarmları
  • Kural ve istisnalar için sürüm kontrolü ve change süreci
  • Kişisel veri, erişim kaydı ve saklama politikası
  • Sensör arızasında görünürlük kaybını bildiren dış sağlık kontrolü



Sık yapılan hatalar

Yanlış arayüzü dinlemek: Suricata çalışır görünür ancak gerçek trafik eve.json'a düşmez. Arayüz ve mirror ayarı paket sayacıyla doğrulanmalıdır.

HOME_NET'i varsayılan bırakmak: Olay yönü ve imza bağlamı bozulur. Gerçek korunan CIDR'lar açıkça tanımlanmalıdır.

Tüm EVE türlerini açmak: Disk ve indexer hızla dolar. Toplama her zaman kullanım amacıyla eşleştirilmelidir.

Dosya izinlerini 777 yapmak: Kolaylık için hassas güvenlik günlüklerini herkese açar. Grup veya ACL ile en az ayrıcalık uygulanmalıdır.

Her alarmı kritik yapmak: Analist yorgunluğu oluşturur ve gerçek olayları gizler. Varlık bağlamı ve tekrar sayısı kullanılmalıdır.

Yalnız dashboard'a bakmak: Veri hattı koparsa sessizlik güvenlik gibi görünebilir. Sensör, agent, manager ve indexer sağlık sinyalleri dışarıdan izlenmelidir.

Kontrol listesi


  1. Wazuh bileşenleri sağlıklı ve dashboard yalnız güvenilir ağdan erişilebilir.
  2. Suricata doğru arayüzde paket görüyor ve eve.json düzenli büyüyor.
  3. HOME_NET laboratuvar CIDR'larıyla eşleşiyor.
  4. Wazuh agent manager'a bağlı ve eve.json dosyasını okuyabiliyor.
  5. DNS, TLS ve flow test olayları dashboard'da bulunabiliyor.
  6. Özel kural wazuh-logtest ile gerçek JSON örneğinde doğrulandı.
  7. Yanlış pozitif istisnaları dar, belgeli ve süreli.
  8. Disk, paket kaybı, queue ve indexer sağlığı izleniyor.
  9. Saklama ve erişim politikası hassas ağ metadata'sını kapsıyor.
  10. Yedekleme ve geri yükleme testi tamamlandı.



Sonuç

Wazuh ve Suricata, doğru kurulduğunda küçük bir laboratuvarda dahi uç nokta ve ağ görünürlüğünü bir araya getirir. Başarının ölçütü yalnız dashboard'da renkli grafik görmek değil; sensörden indexer'a kadar veri hattının doğrulanması, alarmın bağlamla zenginleştirilmesi ve sessiz veri kaybının izlenmesidir.

Önce pasif IDS, sınırlı EVE olay türleri ve gözlem odaklı Wazuh kurallarıyla başlayın. Trafik baseline'ı oluştukça kuralları daraltın, varlık kritikliğini ekleyin ve yalnız doğrulanmış kullanım senaryolarını üretime taşıyın.

Kaynaklar

TR Siber Ekibi Yazar · X
Kaynak bağlantısı ← Ana sayfaya dön