Wazuh - Open Source XDR. Open Source SIEM

Linux-haladó

Wazuh - Open Source XDR. Open Source SIEM

Van valakinek vele tapasztalata Win kliens és szerver környezetben?
Köszi.

  • 1690 megtekintés

( zeller | 2023. 09. 04., h – 23:06 )

Van... Érdemes átgondolni, hogy a logokat milyen formában és tartalommal akarod hosszabb távon tárolni/elrakni, mert szép, hogy a szerver oldalon van a "dúsítás", de onnantól az már egy bővített, nem az eredeti formátumban létező adathalmaz, és ha infót keresel egy probléma kapcsán, akkor annak a tartalma kevésbé lesz alkalmas szakmai fórumokon, gyártói oldalakon történő keresgélésre.

Tudom... Nem véletlenül etetik nagyon sok helyen a "hagyományos" (központi syslog/loggyűjtő) forrásból ezt a csodát: a logok gyűjtése, napi-heti időtávnál hosszabb tárolása központi log szerveren, elemzése, adatdúsítás utáni vizsgálgatása meg egy másikon, ahol csak korlátozott időre visszamenőleg kell tárolni az adatokat.

( zrubi v | 2023. 09. 05., k – 10:48 )

Érdekesen hangzik, megérne egy 'kipróbálást'.

A dokumentációját hirtelen átnézve nem igazán derül ki mire képes valójában, mennyire skálázható és egyátalán miféle logokat képes értelmezni by defult.

 

Ha lenne egy kis időm kipróbálni.... én QRadarral tudnám összevetni, mert azzal dolgozok napi szinten 10+ éve.

Ott a legnagyobb kihívás a mindenféle logok egységes adatbázisba gereblyézése. 

Ezután lehet correlációs mókákat végezni - mert ugye remélhetőleg nem egy szál log alapján akarnak alareteket generálni. :)

Utána jön az, hogy ebből mennyit (Event Per Second) képes 'benyelni' és hogyan skálázódik ha már nem elég alá egy vas...

zrubi.hu

Az első benyomások:

- a dashboard, és úgy általában az UI 'szép' és kényelmesnek tűnik - hogy mennyire praktikus, az persze csak valós használat közben derül ki.

 

Mivel SIEM-nek (azaz Security Information and Event Management) hívja magát, első sorban az érdekelt, hogy hogyan jutnak bele a security eventek, vagyis a 'logok'.

A dokumentációja szerint ez kizárólag az agent-en keresztül történik, de van némi (nem túl egyértelmű) utalás arra, hogy direktben is fogad(hat) syslog eventeket. Így aztán először megnéztem mit is csinál az agent:

Ami egyből feltűnt, hogy nem teljesen saját agent-ről van szó, az OSSEC megoldását használják.

A wazuh-agent teszt (CentOS-8) gépre telepítése után a beérkező event-ekben gyanús volt, hogy file neveket írt forrásként...

Egy kicsit mélyebbre ásva ki is derült, hogy valóban ez történik a wazuh-agent file-okat olvasgat fel:

- /var/log/audit/audit.log

- /var/log/messages

- /var/log/secure

- /var/log/maillog

és ezek tartalmát küldi el a wazuh-manager-nek! :(

Ez a módszer már 20 éve is csak workaround-nak volt elfogadható olyan gagyi alkalmazások esetén, amik nem tudták/akarták értelmesebb csatornákra küldeni logjaikat. Manapság ez már teljesen rossz megközelítés, hiszen minden Linux disztribúció rég átállt systemd-journald-re.

Tehát, a logok eredeti és egyetlen megbízható forrása a journald. Minden más - beleértve a fent megnevezett log file-okat - kizárólag egy kevésbé hiteles másolat, amit tipikusan valamelyik syslog agent irkálja. Mert ugye a jurnald térhódítása előtt a syslog számított az iparági standard-nak Linux/Unix rendszereken, így minden disztribúcióban biztosan volt egy előre felkonfigurált agent, ami ha mást nem is csinált, de helyi fájlokba írkálta a syslog socket-re érkező eventeket. Ezek az agent-ek haladtak a korral, és ma már nem csak a syslog socket-re érkező de a journald-be érkező logokat is képesek input-ként kezelni - beleértve ezek biztoságos továbbítását egy remote syslog szerverre, pl egy SIEM-be :)

 

Tehát ez a szipiszupi wazuh-agent, balga módon a syslog-agent által kiírt file-okat olvasgatja, és küldi tovább, ami semmiképp sem elfogadható módszer. Security szempontból pedig egyszerűen nevetséges.

Ki is próbáltam gyorsan: leállítottam a syslog-agent-et, és lám az wazuh-agent vidáman közli, hogy semmi sem történik a host-on, és minden szép zöld vele kapcsolatban :)

 

Arról nem is beszélve, hogy ezen fájlok tartalmát könnyedén lehet helyben módosítani... és hát ugye pontosan emiatt lenne értelme a remote-logging-nak úgy általában. :)

 

Linux Audit/OS log gyűjtés - broken by design. :(

zrubi.hu

Nem tudom pontosan hogy csinálja, de ez az eredmény:

Sep 11 07:56:59 centos-8.zrubi.lan systemd[1]: systemd-journald.service: Main process exited, code=killed, status=9/KILL
Sep 11 07:56:59 centos-8.zrubi.lan journalctl[24008]: Failed to kill journal service: No main process to kill
Sep 11 07:56:59 centos-8.zrubi.lan systemd[1]: systemd-journald.service: Failed with result 'signal'.

 

És persze újra is indul azonnal:

Sep 11 07:56:59 centos-8.zrubi.lan systemd[1]: Started Journal Service.
Sep 11 07:56:59 centos-8.zrubi.lan systemd[1]: Starting Flush Journal to Persistent Storage...
Sep 11 07:56:59 centos-8.zrubi.lan systemd[1]: Started Flush Journal to Persistent Storage.

zrubi.hu

Nekem úgy tűnik, hogy remote syslog serverből is lehet tolni bele a logokat: https://documentation.wazuh.com/current/user-manual/capabilities/log-da… és van Kubernetes támogatás is, bár ott sajnos csak Docker integrációt találtam ami azért elég problémás.

Elasticsearch van mögötte úgyhogy az index, shard, ILM meg ilyen alap kifejezésekkel meg kell ismerkedni, mert ilyen "security" rendszernél azért az ciki ha megáll az adatnegyűjtés (vagy bármi).

 

Nekem úgy tűnik, hogy remote syslog serverből is lehet tolni bele a logokat: https://documentation.wazuh.com/current/user-manual/capabilities/log-da…

Igen, ez lesz a kovetkező amit megnézek, de:

- a wazuh-agent mellett ez nem tudom mennyire működik, nélküle meg a többi fícsör veszik oda, amiért kár lenne

- a doksi szerint igen limitáltak a konfigurációs lehetőségek, pl hol van a TLS??!

Az eddigiek alapján úgy tűnik maga a wazuh-agent is TLS syslog-on küldi az eventeket a remote:1514-es portjára.

Ezek alapján nekem úgy néz ki újra feltalálták a kereket, csak az övék kicsit szögletes még(?)

Az pl egy elfogadható workaround lenne, ha az event küldéssel részével egyátalán nem foglalkozna a wazuh-agent, henem mellette fel lehetne konfigurálni egy normális syslog-agentet...

 

szerintem.

zrubi.hu

Az eddigiek alapján úgy tűnik maga a wazuh-agent is TLS syslog-on küldi az eventeket a remote:1514-es portjára.

Nem, ez bizony nem TLS syslog, hanem valami saját megoldás, AES titkosítással, UDP-n keresztül:

https://wazuh.com/blog/benefits-of-using-aes-in-our-communications/

 

Ez akár még lehet jó is :)  - de a gyakorlat azt mutatja, hogy amint valaki saját titkosításosdiba kezd, annak könnyen/hamar beletörik a bicskája.

Én egészen biztosan a standard TLS csatornán csinálnék bármilyen titkos kommunikációt, de biztos maradi vagyok - és lehet hogy már öreg is :D

 

Ugyanitt kiderül, hogy ezen kívül csak clear-text syslog (tehát titkosítatlan) receiver tud lenni, ami 2023-ban eléggé szarul hangzik egy SIEM rendszer esetében.

 

Szóval számomra itt ért véget a tesztelés, mert hiába szép és jó a dashboard, meg jó kis ELK stack van mögötte, ha koncepcionálisan rossz a leg alapvetőbb része...

 

Persze, ez továbbra is csak magánvélemény  - és lehet csak én vagyok helikopter :)

zrubi.hu

Ezután lehet correlációs mókákat végezni - mert ugye remélhetőleg nem egy szál log alapján akarnak alareteket generálni. :)

Csak nem hagyott nyugodni, és ezt a részét is megvizsgáltam kicsit:

Van neki egy 'decoder' része - ami tulajdonképpen egy parser, ez bogarássza ki az event payload-ból a benne 'elrejtett' adatokat. - regex segítségével, ami várhatóan nem is gyors, és nem is túl hatékony módszer.

Ennél tulajdonképpen a syslog-ng önmagában is többre képes, cserébe a wazuh sok előre elkészített decoder-t tartalmaz...

Ennek a QRadar megfelelője a DSM, ahol a regex csak a végső univerzális megoldás, ha nem áll rendelkezésre jobb/gyorsabb parszolási lehetőség...

 

Rule-ok terén hasonló a két rendszer, mindegyikben lehet a payload-ra is matchelni (ami persze lassúú) vagy a már kiparszolt adatok  (Custom Properties in QRadar) alapján matchelni egy - vagy több - event-re, és ennek eredménye alapján alertet (Offense in QRadar) generál.

 

A 'default' rule-okból itt is elég sok van - de hogy mennyire hasznosak a gyakorlatban az nyilván nem derül ki egy ilyen 'tesztelés' alatt.

QRadar esetében ezek leginkább példák, éles felhasználásra - módosítás nélkül - nem igazán valók.

 

A fő különbség - ami igen jelentős - az event pipeline-ban rejlik, ami QRadar esetén akár külön appliance-okra is tehető (többek között) terhelés elosztás és skálázhatóság végett.

Persze, már az erőforrás igényük sem összehasonlítható, egy QRadar 'All in One' meg sem nyikkan 32G RAM alatt, amíg a Wazuh-nak a 8Gb is  'elég'. Kérdés persze, hogy mire, hiszen QRadar esetén akár 5000 EPS-ről is beszélhetünk, több száz Log Source mellet, míg a wazuh oldala 100 agent-et említ, ami nyilván nem egy enterprise környezet....

(a wazuh architektúra doksik szerint ez is skálázható, de erről még csak számokat sem látni, így elképzelni sem tudom mit jelent ez a gyakorlatban)

zrubi.hu

( soproni v | 2023. 09. 25., h – 09:37 )

Köszi mindenkinek, még én is tesztelgetem.

# RHE, Rocky, NethServer, MBP14

( Honkydoo v | 2025. 06. 10., k – 10:53 )

Szerkesztve: 2025. 06. 10., k – 10:55

Sziasztok!

 

Van ezzel a termékkel konkrét tapasztalat?

 

Mivel ingyenes, ezért alternatíva lehet olyan cégeknek, akiknek nincs pénze pl QRadarra, de szeretnének SIEM-et...

 

Persze ez csak akkor érdekes, ha tényleg használható ez a termék.

 

Szóval próbálta már valaki éles környezetben?

 

Szerk.:

Esetleg mint log gyűjtő, mennyire alkalmas a graylog kiváltására?

Nálunk van egy kb. 70 klienssel, megy (miután kapott elég ramot :))

Pushoveren keresztül reportolta ami engem érdekel, aztán ntfy-on keresztül (miután a pushover nem csípte a sok üzit és letiltotta a picsába :)).

Ami nem tetszik, hogy olyan alap dolgok, hogy átnevezek egy klienst kb. impossible mission és , hogy a Debian/Ubuntu vulnerability detection nagyon off mintha nem számolná bele a debian security patcheket és szimpla verziószám alapján dobja, hogy vulnerable. 

Ami tetszik , hogy többet látok mint amit eddig láttam és legalább egy helyen. :)