Wazuh’ta log ve alarm sorunları: adım adım teşhis

Wazuh agent’ın Active görünmesi, beklediğiniz logun toplandığını veya dashboard’da alarm olarak gösterileceğini kanıtlamaz. Bağlantı kurulmuş olabilir; ancak yanlış kaynak izleniyor, olay bir kuralla eşleşmiyor, alarm eşiğinin altında kalıyor veya indeksleme aşamasında sorun yaşanıyor olabilir.

Bu yüzden ilk adım bütün servisleri yeniden başlatmak değil, tek bir yeni olayı kaynağından dashboard’a kadar takip etmektir.

Önce sorunun hangi aşamada olduğunu belirleyin

Standart alarm akışı şöyledir:

Kaynak log
  → Agent / Logcollector
  → Manager / decoder ve kurallar
  → alerts.json
  → Filebeat
  → Wazuh Indexer
  → Dashboard

Resmî alarm yönetimi belgesine göre, üretilen alarmlar varsayılan olarak alerts.json dosyasına yazılır ve Filebeat tarafından indeksleyiciye aktarılır.

Arşivleme kapalıysa archives.json dosyasının bulunmaması, olayın Manager’a ulaşmadığını göstermez.

Başlamadan önce agent kimliğini, olay saatini ve ilgili makineyi not edin. Dağıtık kurulumda olayı işleyen Manager düğümünü belirleyin. Log örneklerindeki kullanıcı, müşteri ve gizli bilgileri dışarıya paylaşmadan önce temizleyin.

1. Kaynak sistem gerçekten yeni log üretiyor mu?

Kontrolün yapılacağı yer: İzlenen makine, yani agent’ın kurulu olduğu sistem.

Önce Wazuh’tan bağımsız olarak beklenen olayın oluştuğunu doğrulayın. Örneğin SSH olayları için:

sudo journalctl -u ssh.service -u sshd.service --since "15 minutes ago" --no-pager -o short-iso

Beklenen sonuç, araştırdığınız zaman aralığındaki gerçek SSH kayıtlarıdır. Çıktı yoksa hemen Wazuh’u suçlamayın: hizmet farklı bir birim adıyla çalışıyor veya farklı kaynağa yazıyor olabilir.

Dosya tabanlı loglama kullanılıyorsa dağıtım adından hareketle kesin yol varsaymayın:

Örneğin, dosya mevcutsa:

sudo tail -n 30 /var/log/auth.log

Kaynakta yeni kayıt yoksa önce uygulamanın log seviyesini ve log yönlendirmesini düzeltin. Var olmayan bir dosyayı agent yapılandırmasına eklemek çözüm değildir.

Ayrıca eski bir satırın bulunması, agent’ın onu yeniden okuyacağı anlamına gelmez. Wazuh’un only-future-events davranışını dikkate alın; kontrol için yapılandırma uygulandıktan sonra oluşmuş yeni bir olay kullanın.

2. Agent doğru kaynağı topluyor mu?

Kontrolün yapılacağı yer: Agent makinesi.

Yerel yapılandırma dosyası:

/var/ossec/etc/ossec.conf

Dosya tabanlı örnek, yalnız gerçekten bu dosyaya yazılan sistemler için anlamlıdır:

<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
</localfile>

Journal kaynağında ise location ve log_format değerlerinin ikisi de journald olmalıdır. Şunları kontrol edin:

• Filtredeki hizmet adı gerçek journal kaydıyla uyuşuyor mu?
• ssh.service beklenirken kayıt sshd.service altında mı geliyor?
• Bir öncelik filtresi aradığınız olayı dışarıda mı bırakıyor?
• Dosya yolu, izinler veya rotasyon sonrası dosya durumu değişmiş mi?
• Aynı olay hem dosyadan hem journal’dan gereksiz yere toplanıyor mu?

Önemli journal ayrıntısı: Güncel localfile belgesinde, en az bir filtreli journald bloğu varsa filtresiz blokların yok sayıldığı belirtiliyor. Bu nedenle “bir tane de filtresiz blok ekleyeyim” yaklaşımı beklediğiniz sonucu vermeyebilir.

Merkezi yapılandırmayı unutmayın

Agent bir gruptan yapılandırma alıyorsa yalnız yerel dosyaya bakmak yeterli değildir. Manager üzerindeki ilgili grubun agent.conf dosyasını da inceleyin.

Merkezi yapılandırma belgesi, yerel ve paylaşılan ayarların birleştirildiğini açıklar. Manager’da, örnek agent kimliğini kendi kimliğinizle değiştirerek senkronizasyonu kontrol edebilirsiniz:

sudo /var/ossec/bin/agent_groups -S -i 001

Beklenen sonuç grubun senkronize olmasıdır. Senkronizasyon, ayarın semantik olarak doğru olduğunu değil, dağıtıldığını gösterir.

Değişiklik yapacaksanız

Önce değiştireceğiniz makinede yapılandırmanın yedeğini alın:

BACKUP="/var/ossec/etc/ossec.conf.before-logcheck.$(date +%Y%m%dT%H%M%S)"
sudo cp -a /var/ossec/etc/ossec.conf "$BACKUP"

Logcollector yapılandırmasını kontrol edin:

sudo /var/ossec/bin/wazuh-logcollector -t

Bu, Logcollector yapılandırma testidir; uçtan uca veri akışını doğrulamaz.

Yerel ayarın uygulanması için agent’ı yeniden başlatacaksanız kısa izleme kesintisini planlayın. Hatalı yapılandırmayla devam etmeyin. Merkezi değişikliklerde ayrıca dağıtım ve yeniden yükleme durumunu kontrol edin.

sudo systemctl restart wazuh-agent

Ardından yeni bir kaynak olay oluşturup tekrar kontrol edin.

3. Bağlantı var mı; olay Manager’a ulaşıyor mu?

Kontrolün yapılacağı yer: Manager.

sudo /var/ossec/bin/agent_control -l

Active durumu agent’ın Manager’a bağlı olduğunu belirtir. Ancak araştırdığınız kaynağın toplandığının kanıtı değildir.

İlgili agent ve Manager üzerindeki iç çalışma günlüklerini ayrı ayrı inceleyin:

sudo tail -n 100 /var/ossec/logs/ossec.log

Bu dosya uygulamanızın ham olay arşivi değil, Wazuh’un kendi çalışma günlüğüdür. Okuma, bağlantı, kimlik doğrulama ve kuyruk hataları açısından değerlendirin.

Agent bağlantısı gerçekten sorunluysa adres, port ve protokolü karşılaştırın. Güncel belgelerde varsayılan veri iletişimi 1514/TCP, enrollment ise 1515/TCP olarak ayrılır. Enrollment başarısı, veri kanalının sağlıklı olduğunun yerine geçmez. Sorunu çözmek için yönetim portlarını internete açmayın. Kaynak

Gerekirse kısa süreli ham olay incelemesi

Her gelen olay alarm üretmediğinden, yalnız alerts.json dosyasında arama yapmak yeterli olmayabilir.

Wazuh arşivleri varsayılan olarak kapalıdır. Arşivleme açıksa olayın ayırt edici metnini şu dosyada arayın:

sudo grep -F -- 'AYIRT_EDICI_METIN' /var/ossec/logs/archives/archives.json

Metni gerçek olaydan seçin; bulunan kaydın agent kimliğini ve zamanını da kontrol edin.

Risk: logall_json yalnız seçtiğiniz agent’ı değil, ilgili Manager’ın aldığı olayları arşivleyebilir. Disk tüketimini ve hassas veri saklamayı artırır. Kapasite ve değişiklik onayı olmadan açmayın.

Geçici arşivleme gerekiyorsa:

1. Mevcut ayarı ve yapılandırma yedeğini kaydedin.

2. Boş alanı kontrol edin: df -h /var/ossec.

3. Mevcut <global> bölümündeki logall_json değerini geçici olarak değiştirin:

   <logall_json>yes</logall_json>
   

4. Manager’da yapılandırmayı kontrol edin:

   sudo /var/ossec/bin/wazuh-analysisd -t
   

5. Planlı kısa kesinti kapsamında, test başarılıysa Manager’ı yeniden başlatın:

   sudo systemctl restart wazuh-manager
   

6. Yeni olayı tekrar üretin, arşivde arayın ve disk büyümesini izleyin.

7. İnceleme bitince önceki ayara dönün; değişikliği yine kontrollü uygulayın.

Bu işlem arşivlerin dashboard’da otomatik görünmesini sağlamaz. Bunun için ayrıca arşiv indeksleme yapılandırması gerekir. Teşhis amacıyla bütün ham olayları indekslemek zorunda değilsiniz.

4. Olay neden alarm üretmiyor?

Kontrolün yapılacağı yer: Manager.

Manager’a ulaştığını doğruladığınız olayın gerçek log içeriğini kural motorunda inceleyin:

sudo /var/ossec/bin/wazuh-logtest

Arşivden alıyorsanız bütün JSON kaydını değil, olayın full_log içeriğini kullanın.

Resmî test aracında şu bilgileri arayın:

• Hangi decoder eşleşti?
• Beklenen alanlar ayrıştırıldı mı?
• Hangi kural eşleşti?
• Kuralın seviyesi ne?
• Kural tek olay mı, zaman içinde birden fazla olay mı bekliyor?

wazuh-logtest, agent → Filebeat → dashboard hattının testi değildir. Örnek bir metnin decoder ve kurallarla nasıl değerlendirildiğini gösterir.

Varsayılan log_alert_level değeri 3’tür. Olayın bir kuralla eşleşmesi, mutlaka görünür alarm oluşturacağı anlamına gelmez. Eşik, bastırma ve korelasyon koşullarını birlikte değerlendirin.

Alarm üretmesi beklenen yeni olayı dosyada arayın:

sudo grep -F -- 'AYIRT_EDICI_METIN' /var/ossec/logs/alerts/alerts.json

Burada yoksa Filebeat’i düzeltmeye çalışmadan önce Manager aşamasında kalın.

Ayrıca jsonout_output ayarını kontrol edin. Bu çıktı kapalıysa standart kurulumda Filebeat’in okuyacağı JSON alarm dosyası güncellenmez.

Özel kural gerekiyorsa paketle gelen kuralları doğrudan değiştirmeyin. Yerel kural dosyalarını kullanın; hem eşleşmesi gereken hem eşleşmemesi gereken örnekleri test edin. Bütün logları görmek için genel alarm eşiğini düşünmeden düşürmeyin.

Ayarlar doğru görünmesine rağmen alarm üretimi durmuşsa disk, kuyruklar ve sürüm notları da araştırılmalıdır. Örneğin 4.14.8 sürüm notlarında, Active Response kuyruğu dolduğunda alarm üretimini durduran bir analysisd kilitlenmesinin düzeltildiği belirtilir. Bu, her benzer belirtinin aynı kök nedenden kaynaklandığını göstermez.

5. Alarm dosyada var, indekste yok mu?

Kontrolün yapılacağı yer: Alarmı üreten Manager ile ilişkili Filebeat makinesi.

sudo systemctl status filebeat --no-pager
sudo filebeat test output
sudo journalctl -u filebeat --since "15 minutes ago" --no-pager

Wazuh’un dashboard sorun giderme belgesi, filebeat test output kontrolünü önerir.

Beklenen sonuç bağlantı, TLS ve sunucuyla iletişim testlerinin başarılı olmasıdır. Başarısızsa:

• DNS veya bağlantı hatasında hedef adresi ve ağ erişimini;
• TLS hatasında CA zincirini, sertifika adını ve geçerliliğini;
• kimlik doğrulama/yetki hatasında ilgili servis hesabını;
• indeksleme hatasında disk, indeks ve kayıt işleme hatalarını inceleyin.

TLS doğrulamasını kapatmak veya servis hesaplarını varsayılan parolalara döndürmek kalıcı çözüm değildir.

Bağlantı testinin başarılı olması da belirli alarmın indekslendiğini kanıtlamaz. Filebeat’in doğru alarm dosyasını okuduğunu ve olayın gerçekten indekslendiğini ayrıca doğrulayın.

6. İndekste var ama dashboard’da görünmüyor mu?

Kontrolün yapılacağı yer: Yetkili dashboard oturumu / Indexer sorgusu.

Dev Tools erişiminiz varsa aşağıdaki salt okunur sorguyla başlayabilirsiniz. 001 ve AYIRT_EDICI_METIN değerlerini kendi olayınıza göre değiştirin:

GET /wazuh-alerts-*/_search
{
  "size": 5,
  "query": {
    "bool": {
      "filter": [
        { "term": { "agent.id": "001" } },
        { "range": { "timestamp": { "gte": "now-30m" } } }
      ],
      "must": [
        { "match_phrase": { "full_log": "AYIRT_EDICI_METIN" } }
      ]
    }
  }
}

Bu örnek OpenSearch Search API yapısını kullanır. Olayınızda full_log saklanmıyorsa sorguyu mevcut alanlara uyarlayın.

Beklenen sonuç, ilgili olayın hits.hits içinde bulunmasıdır. Sonuç yoksa önce agent kimliğini, aranan metni ve zaman aralığını doğrulayın. Saat farkı veya hatalı filtreyi veri kaybı sanmayın.

Olay indekste bulunduğunda dashboard tarafında şunları kontrol edin:

• Alarm verileri için doğru indeks deseni seçili mi?
• Zaman aralığı olay saatini kapsıyor mu?
• Agent, kural seviyesi veya kayıtlı sorgu filtresi olayı dışlıyor mu?
• Kullanıcı ilgili indeksi okumaya yetkili mi?
• Doğru görünüm ve gerekiyorsa tenant seçili mi?

wazuh-alerts-* ile wazuh-archives-* aynı veri kümesi değildir. Alarm üretmeyen bir ham olayın alarm ekranında görünmesini beklemeyin.

Bu aşamada indeks silmek, yeniden indeksleme başlatmak veya güvenlik yapılandırmasını sıfırlamak ilk müdahale olmamalıdır.

7. Düzeltmeyi aynı olayla doğrulayın ve geçici ayarları geri alın

Başarı ölçütü yalnız servislerin running olması değildir.

Alarm üretmesi beklenen, kontrollü ve yeni bir olay için şu zinciri doğrulayın:

1. Kaynak sistemde oluştu.
2. Doğru agent ve kaynak üzerinden toplandı.
3. Beklenen decoder/kural tarafından işlendi.
4. Manager’ın alerts.json dosyasına yazıldı.
5. İndekste bulundu.
6. Yetkili kullanıcı tarafından dashboard’da görüntülendi.

Aynı olayın agent kimliğini, zamanını ve ayırt edici alanlarını aşamalar arasında karşılaştırın. Rastgele SSH parola denemeleri veya üretim servislerini durdurmak yerine, onaylı test makinesi ve güvenli bir test senaryosu kullanın.

İşlem sonunda:

• Geçici arşiv ayarını önceki durumuna döndürün.
• Eklediğiniz test kuralı ve kaynaklarını kontrollü kaldırın.
• Değişiklik başarısızsa ilgili yedeği geri yükleyip yapılandırmayı yeniden doğrulayın.
• Oluşan teşhis kayıtlarını kurumun saklama ve erişim politikasına göre yönetin.
• Bulguyu, yapılan değişikliği ve kabul testinin sonucunu kaydedin.

Özet: “Agent bağlı ama log gelmiyor” tek bir hata değildir. Kaynak logu, toplanan olayı, üretilen alarmı ve indekslenmiş kaydı ayrı ayrı kanıtladığınızda sorunun yeri daralır; gereksiz ve riskli değişikliklerden kaçınırsınız.

Kurumsal ortamınızda bu kontrolleri kaynak envanteri, kabul testleri ve işletim sorumluluklarıyla birlikte ele almak için Mono’nun Wazuh kurulum ve operasyon desteğini inceleyebilirsiniz.

Kaynaklar

• Wazuh — Log toplama yapılandırması
• Wazuh — Olay arşivleme
• Wazuh — Alarm yönetimi
• Wazuh — Decoder ve kural testi
• Wazuh — Dashboard sorun giderme
• Wazuh — 4.14.8 sürüm notları