Bevezetés

Egy ügyfél Wazuh környezetében az Office365 Dashboard egyik napról a másikra megszűnt új eseményeket megjeleníteni.

A felhasználók azt látták, hogy az utolsó Office365 esemény több napja érkezett, ezért első ránézésre úgy tűnt, hogy az Office365 integráció leállt vagy a Microsoft API-val van probléma.

A valóság azonban egészen más volt.

A teljes hibakeresés során kiderült, hogy az Office365 integráció végig hibátlanul működött, a probléma valójában az OpenSearch shard limit elérésére vezethető vissza.

Ebben a cikkben lépésről lépésre végigmegyünk a teljes vizsgálati folyamaton.

A probléma

A Dashboard nem mutatott új Office365 eseményeket.

Az utolsó látható esemény több nappal korábbi volt.

A felhasználók számára úgy tűnt, hogy:

Office365 integráció nem működik

A cél az volt, hogy meghatározzuk, pontosan melyik komponensnél akad el az adatfolyam.

Az adat útja

A hibakeresés során mindig érdemes végigkövetni az adat teljes útját:

Microsoft 365
↓
Office365 API
↓
Wazuh Office365 Module
↓
alerts.json
↓
Filebeat
↓
OpenSearch
↓
Dashboard

A feladat az volt, hogy megtaláljuk, melyik ponton szakad meg a lánc.

1. lépés – Office365 modul ellenőrzése

Elsőként bekapcsoltuk a részletes naplózást.

nano /var/ossec/etc/local_internal_options.conf

Tartalom:

wazuh_modules.debug=2

Majd:

systemctl restart wazuh-manager

A naplók figyelése:

tail -f /var/ossec/logs/ossec.log | grep office365

A logban megjelentek:

Office 365 API access token URL
Office 365 API subscription URL
Office 365 API content blobs URL
Bookmark updated

Ez bizonyította, hogy:

Azure hitelesítés működik
API token létrejön
Microsoft válaszol
A Wazuh modul fut

2. lépés – Bookmark fájlok ellenőrzése

Az Office365 integráció állapotát tároló fájlok:

ls -lah /var/ossec/var/wodles/office365-*

Megjelentek az összes előfizetéshez tartozó bookmark fájlok:

Audit.Exchange
Audit.General
Audit.SharePoint
Audit.AzureActiveDirectory
DLP.All

Ez azt jelezte, hogy a modul működik.

3. lépés – Kényszerített újraszinkronizálás

A bookmark fájlok törlésével teljes újraszinkronizálást indítottunk.

rm -f /var/ossec/var/wodles/office365-*
systemctl restart wazuh-manager

A rendszer újra létrehozta a fájlokat.

Ez kizárta a sérült bookmark állapot lehetőségét.

4. lépés – Tényleg érkeznek események?

Megnéztük küld-e a modul eseményeket:

grep -i "Sending Office365 log" /var/ossec/logs/ossec.log

A naplóban ilyen sorok jelentek meg:

DEBUG: Sending Office365 log

Ez azt jelentette:

Microsoft API → OK
Wazuh Office365 Module → OK

5. lépés – Generálódik-e alert?

Következő ellenőrzés:

grep -i office365 /var/ossec/logs/alerts/alerts.json | tail

Friss Office365 események jelentek meg.

Példa:

{
  "data": {
    "integration": "office365"
  }
}

Ekkor már tudtuk:

Office365 API → OK
Module → OK
Rules → OK
alerts.json → OK

A hiba máshol van.

6. lépés – OpenSearch vizsgálata

Lekérdeztük a legfrissebb Office365 eseményt:

curl -k -u admin:admin \
"https://INDEXER:9200/wazuh-alerts-*/_search?q=data.integration:office365&size=1&sort=@timestamp:desc&pretty"

Meglepő eredmény:

A lekérdezés több nappal korábbi eseményt adott vissza.

Miközben az alerts.json már friss eseményeket tartalmazott.

Ez kulcsfontosságú felismerés volt:

alerts.json → friss
OpenSearch → régi

A probléma az indexelési oldalon van.

7. lépés – Filebeat vizsgálata

A Filebeat futott:

systemctl status filebeat

Ezután megnéztük a naplókat:

journalctl -u filebeat -n 100

Itt jelent meg a valódi hiba:

this cluster currently has [1000]/[1000] maximum shards open

A valódi ok

Az OpenSearch elérte a maximális shard limitet.

Ennek következménye:

Új index nem jöhet létre
↓
Filebeat nem tud indexelni
↓
Dashboard nem mutat adatot

Miközben:

Office365 működik
Wazuh működik

Azonnali javítás

A shard limit ideiglenes emelése:

curl -k -u admin:admin -X PUT \
"https://INDEXER:9200/_cluster/settings" \
-H 'Content-Type: application/json' \
-d '{
  "persistent": {
    "cluster.max_shards_per_node": "2000"
  }
}'

Majd:

systemctl restart filebeat

Az Office365 események azonnal megjelentek.

Miért telt be a shard limit?

A vizsgálat során kiderült, hogy több száz napi index létezett.

Sok közülük:

0 dokumentumot tartalmazott

de mégis:

3 primary shardot foglalt

Ez rendkívül pazarló konfiguráció volt.

Régi indexek törlése

A régi indexek eltávolítása:

curl -k -u admin:admin -X DELETE \
"https://INDEXER:9200/wazuh-alerts-4.x-2024.*"

curl -k -u admin:admin -X DELETE \
"https://INDEXER:9200/wazuh-alerts-4.x-2025.*"

A shard szám jelentősen csökkent.

Új indexek optimalizálása

A Wazuh template alapértelmezés szerint:

"number_of_shards": "3"

értékkel hozta létre az új indexeket.

Single-node környezetben ezt módosítottuk:

"number_of_shards": "1"

értékre.

Ellenőrzés:

curl -k -u admin:admin \
"https://INDEXER:9200/_template/wazuh?pretty" | grep number_of_shards

Eredmény:

"number_of_shards": "1"

Retention ellenőrzése

A rendszerben már létezett egy 90 napos törlési szabály.

Ellenőrzés:

curl -k -u admin:admin \
"https://INDEXER:9200/_plugins/_ism/policies/wazuh-alert-retention-policy?pretty"

A policy:

90 nap után automatikusan törli
a wazuh-alerts-* indexeket

Végső eredmény

A rendszer stabil állapotba került.

✅ Office365 Dashboard működik

✅ Office365 események érkeznek

✅ OpenSearch indexel

✅ 90 napos retention aktív

✅ Az új indexek már csak 1 sharddal jönnek létre

✅ A shard terhelés több mint 50%-kal csökkent

Tanulság

Amikor egy Dashboard nem mutat adatot, nem szabad rögtön az integrációt hibáztatni.

A helyes hibakeresési módszer:

API
↓
Collector
↓
Alert
↓
Indexer
↓
Dashboard

Ebben az esetben az Office365 integráció végig hibátlanul működött.

A valódi probléma egy OpenSearch kapacitáskorlát volt, amely megakadályozta az új indexek létrejöttét.

A strukturált hibakeresés végül néhány perc alatt elvezetett a valódi okhoz és a tartós megoldáshoz.

Wazuh Office 365 Dashboard üres – hiba megoldás