Wazuh - Decentral Log analyser - Syslog Concentrator/Forwarder - with Windows using NXLOG

[LukasO]

Dear Community,

to clarify the Subject: I am learning about Wazuh while building a decentralized log analysis platform for any (remote) log source (Win,Lin,Hardware).
The target network infrastructure/design paradigm restricts point to point communication: Agents are not usable, Wazuh cannot reach the log sourcesm log sources canot contact Wazuh.
The concept is:
Logsource "Syslog-MSG" -> (chain)  Log Concentrator/Forwarder "Syslog-MSG" -> Wazuh

I would like to detail and share my implementation and I am asking for a bit of review, additional general ideas, and pointers things I have messed up.

So, first I made Wazuh understand my forwarded syslog messages, the Decoder for my logformat:

<!-- 1 YYYY-MM-DDTHH:MM:SS+HH:MM <Source IPv4> <progam_name> - - - <MESSAGE> -->
<decoder name="SyslogConcentrator">
    <type>syslog</type>
    <prematch>^\d\s\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d\p\d\d:\d\d\s</prematch>
</decoder>

<!-- Common: origin ip, program_name (or other origin identifier) -->
<decoder name="SyslogConcentrator">
    <parent>SyslogConcentrator</parent>
    <regex offset="after_parent">(\d+.\d+.\d+.\d+)\s(\S+)</regex>
    <order>location, program_name</order>
</decoder>

That should fit all messages a typical linux OS forwards. Also already built-in rules should match, should they?

As for Windows, I am using NXlog (https://nxlog.co) to send Syslog UDP messages to my forwarder.
Now it gets a bit complicated, how can I use Wazuh's brilliant and plenty build-in rules to react my weird forwarded Windows syslog?

After digging trough 0575-win-base_rules.xml and 0580-win-security_rules.xml I understood that I need:
- a decoder named: "windows_eventchannel" with type "ossec", this decoder is nowhere to be found, so I expect some Agent Magic?
- the following fields parsed with correct data:
win.system.eventID
win.system.channel
win.system.severityValue
win.system.providerName
win.system.message

I have created a custom logformat on NXlog and matched the required fields to variables in NXlog:
Wazuh - Nxlog
win.system.channel $Channel
win.system.eventID $EventID
win.system.severityValue $EventType
win.system.providerName $SourceName

win.system.message $Message

Additionally, NXlog sends a fixed "facility" string "NXLOG" so I can regex for it and I used $Hostname and $Category to make the log more informative.

My nxlog is configured like this:

 Exec    to_syslog_ietf(); $raw_event = ' NXLOG'+\' Channel:'+$Channel+\' Domain:'+$Domain+\' EventID:'+$EventID+\ .....

Now the decoder, I have chosen to implement my own "windows_eventchannel" and I am using "sibling decoders" to parse the windows log:

<!-- 1 YYYY-MM-DDTHH:MM:SS+HH:MM <Source IPv4> NXLOG - - - <MESSAGE> -->
<decoder name="windows_eventchannel">
    <type>ossec</type>
    <prematch>^\d\s\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d\p\d\d:\d\d\s\.+NXLOG</prematch>
</decoder>

<!-- Common: origin ip -->
<decoder name="windows_eventchannel">
    <parent>windows_eventchannel</parent>
    <regex>\s(\d+.\d+.\d+.\d+)\sNXLOG</regex>
    <order>location</order>
</decoder>

<!-- Windows log: Event ID
Satisfies Wazuh build-in ruleset 0580-win-security_rules.xml
Wazuh: win.system.eventID
NXlog: $EventID
-->
<decoder name="windows_eventchannel">
    <parent>windows_eventchannel</parent>
    <regex>EventID:(\S+)\s</regex>
    <order>win.system.eventID</order>
</decoder>

There is a curious behavior: I need to place the more specific prematch decoder (for NXLOG) above the less specific (for syslog) otherwise detection fails.

This summarizes roughly 2 days of learning and testing. That curve was steep and I am still reading / watching youtube vids. What do you think?
Please share your knowledge and comments. Also if you require more info, feel free to answer here.

Cheers
Lukas

[Jose Camargo]

Hello Lukas,

thank you for using Wazuh!

To forward events from Wazuh using syslog, you can check how it is configured in this document: https://documentation.wazuh.com/current/user-manual/manager/manual-syslog-output.html

If you have some issues with your custom decoders, you can try testing them using Wazuh's own logtest tool as described here: https://documentation.wazuh.com/current/user-manual/capabilities/wazuh-logtest/how-it-works.html , there is a workaround to test Windows Events with the logtest tool, which is very well explained on the following Github Issue: https://github.com/wazuh/wazuh/issues/7651

Regarding Windows events,  there is no Windows Eventchannel XML decoder, as it is embedded inside Wazuh’s code. That is why you can’t find it along with the Wazuh installation files. If you know about the C language, you may want to take a look at this file where Eventchannel events are processed. For Windows events to be ingested, an agent has to be set to be able to use the default ruleset. For this case, if you want to get Windows events without an agent using NCLOG it won't work, you'll have to modify the whole existent ruleset (or create a custom one) to be able to match them, and unfortunately, because of how the windows_eventchannel decoders have been designed, it is not possible, currently, to create sibling decoders for it.

You can check some extra information on how Wazuh collects Windows events here: https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/how-to-collect-wlogs.html#how-to-collect-windows-logs

Please let me know if there's anything else I can help you with.

Regards,

Jose

[LukasO]

Thanks Jose,

your input is appreciated. However your first link details "syslog output", I have no current usecase to output from Wazuh. I see it as the "last-stop"/"dead-end" system. Are you hinting for me to use Wazuh as syslog forwarder/concentrator? A chain of Wazuhs?

I am using the logtest-tool heavily, the github link is a good hint to improve my testing! Thanks!

Now it gets interesting, I have not thought about the " windows_eventchannel" being in code rather than in config.
See, what I have implemented actually works! I am able to parse Windows eventlogs by "overloading" / "overriding" or "extending" the build-in "windows_eventchannel" decoder with my configured <decoder name="windows_eventchannel">. And I am matching against your ruleset (and extended it with my own custom rules) therefore I achieved my goal of not having to fork your ruleset or create my own for windows.

Can you tell me how far into "this should not work" or "this is unintended" or "future updates will make this impossible" or “this is an anomaly” territory I have wandered?

I personally think this is a feature, rather than a bug. In my mind I have “simply” added another source, or I have overridden the existing decoder by my own. I can share full configs if that helps.

Regards,
Lukas

[Jose Camargo]

Hi Lukas,

It's great to know that it's working! In reality, it's not a "this should not work" issue, as being an open-source software grants you the possibility of customizing it as you want, it's more a once you modify it (depending on the depth of the modification) we don't know how it will behave so it may be difficult to troubleshoot certain issues. But we will always try to help as much as we can.

Regarding the future updates, for now, we will continue working on Wazuh Dashboard - Wazuh Indexer separating ourselves from Kibana/Elastic/OpenSearch and possibly in the future also from Filebeat, but there's no specific time for this.

And regarding the syslog forwarding, it might be helpful, as you mentioned, to try to do a chain of Wazuhs, so can forward events from one to another, or from Wazuh to another tool, depending on your needs. If that is something that you want to do, I might have misunderstood you.

Please let me know if there's anything else I can help you with.

Regards,

Jose

[Oleksandr]

Hi Lukas,

I'm intrigued by your creative approach to Wazuh configuration and your use of the NXLog. While I understand if you prefer not to share your full configuration, I'd greatly appreciate any insights you're willing to provide. Your expertise could be valuable for the wider community.

среда, 28 декабря 2022 г. в 23:31:50 UTC+2, Jose Camargo:

[Lukas Orlowski]

Hello Oleksandr,

well, I would not necessarily call it "innovative". It is more a "no other option" approach.

Preface:
A segmented network (DMZs, Core(s), Management, ... ) , with mostly no direct communication between segments. However a log collection and forwarding infrastructure is established (syslog forwarders). A central syslog server exists on a MGMT network segment. Linux systems and (syslog capable) Hardware components

Challenges:
1. How to get Windows systems to use the existing infrastructure: Nxlog -> BSD syslog
2. How to consume the central syslog for a security function?

Why Wazuh is being considered?
It "understands" log sources already: e.g. identifies a successful or fail ssh login, the same for a Windows system as well as.
A lot of work is already done! The focus may now be in writing business case related alerting rules, not parsers for fundamental log events.

Challenge: Wazuh expects Windows logs coming from the agent, not syslog sources. My solution described in this thread was to write my own decoder "name=windows_eventchannel". Therefore overwriting/extending the existing decoder. I am still unsure if this is appropriate or will lead to incompatibilities in the future. Also, some predecoder/decoder statements are not available making rule writing uncomfortable.
I am looking forward to wazuh engine to address those issues.

Nothing of my general work done here is considered sensitive.
I can provide nxlog config snippets, syslog-ng forwarding config, and wazuh decoder or rules xmls. Don't expect anything groundbreaking. All is deliberately done with basic/existing functionality.

Let me know how I can help further.

Regards
Lukas



> Gesendet: Sonntag, den 02.06.2024 um 19:37 Uhr
> Von: Oleksandr <alex.j...@gmail.com>
> An: "Wazuh | Mailing List" <wa...@googlegroups.com>
> Betreff: Re: Wazuh - Decentral Log analyser - Syslog Concentrator/Forwarder - with Windows using NXLOG

> >>> <https://github.com/wazuh/wazuh/blob/master/src/logcollector/read_win_event_channel.c> where

> --
> You received this message because you are subscribed to a topic in the Google Groups "Wazuh | Mailing List" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/yDm-tYBH6gk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/2af6037c-afa0-48a7-93f6-084d130ced2en%40googlegroups.com.