Hi,
You can find the events of the agents in the directory /var/ossec/logs/archives
. Here you can find two types of files:
archives.log: Contains the events received in plain text format
archives.json: Contains the events received in plain JSON format
It is important to note that by default event storage is not enabled, since if the manager receives many events per second, the size of these files could increase considerably in a short time.
In case you want to enable this feature, you can do it by editing the file /var/ossec/etc/ossec.conf
and in the global section you will find this:
<logall>no</logall>
<logall_json>no</logall_json>
Reference: https://documentation.wazuh.com/4.0/user-manual/reference/ossec-conf/global.html#logall
All you have to do is change one of these values to yes
and restart the manager. Then all the events received by the manager will be stored in the directory described above and in the file that you have specified in the config (archives.log
if <logall>
enabled or archives.json
if <logall_json>
enabled).
It is possible to activate both simultaneously, but it may not make much sense, since it is the same information in a different format, and it can consume a lot of disk space unnecessarily.
This option (store events in the file) is usually used temporarily for debugging purposes. Remember to deactivate it when you no longer need it.
I hope this information is helpful to you.
Best regards.
Hi,
Indeed, if you enter the entire event in ossec-logtest
, the events will not be decoded or generate alerts (in debugging mode).
This is because the events stored in archives.*
contain a series of headers (extra information) added to the original event sent by the agent. An event will match a decoder or rule as long as it matches the original sent by the agent.
What you have to do is to enter the event without the corresponding headers in the ossec-logtest
tool.
For example, imagine that from the archives.log
I take the following event:
2020 Dec 07 15:40:16 (xxxxxxxxxx1) any->\aem\logpath\logs\access.log 07.12.2020 15:40:32.058 *INFO* [qtp305148339-1116906] access.log 11.11.111.11 - anonymous 07/Dec/2020:15:40:32 +0100 GET /url/random HTTP/1.1 200 2"
Then the event without headers would be (this is the one to be entered in the ossec-logtest
tool):
\aem\logpath\logs\access.log 07.12.2020 15:40:32.058 *INFO* [qtp305148339-1116906] access.log 11.11.111.11 - anonymous 07/Dec/2020:15:40:32 +0100 GET /url/random HTTP/1.1 200 2"
I just have another thread here https://groups.google.com/g/wazuh/c/vOOhiQ2TGjM with a user where I explain all this. Please take a look because it can be quite useful for you.
Hi,
It seems I made a mistake in the example I told you, it should be the following:
From
2021 Feb 10 05:13:37 wazuhtestng03->/var/log/messages Feb 10 05:13:36 wazuhtestng03 audispd: node=wazuhtestng03 type=EXECVE msg=audit(1612934016.634:27477): argc=4 a0="grep" a1="--color=auto" a2="10.248.15.57" a3="archives.log"
To
Feb 10 05:13:36 wazuhtestng03 audispd: node=wazuhtestng03 type=EXECVE msg=audit(1612934016.634:27477): argc=4 a0="grep" a1="--color=auto" a2="10.248.15.57" a3="archives.log"
If we enter this log in ossec-logtest
, we can see how some of the logs are pre-decoded.
**Phase 1: Completed pre-decoding.
full event: 'Feb 10 05:13:36 wazuhtestng03 audispd: node=wazuhtestng03 type=EXECVE msg=audit(1612934016.634:27477): argc=4 a0="grep" a1="--color=auto" a2="10.248.15.57" a3="archives.log"'
timestamp: 'Feb 10 05:13:36'
hostname: 'wazuhtestng03'
program_name: 'audispd'
log: 'node=wazuhtestng03 type=EXECVE msg=audit(1612934016.634:27477): argc=4 a0="grep" a1="--color=auto" a2="10.248.15.57" a3="archives.log"'
**Phase 2: Completed decoding.
No decoder matched.
Next, what you need to do is to create a custom decoder for this case (In this case I have based the decoder for the program name audispd
, so it will work as long as the value of the pre-decoded program_name
field has this value)
Add the following decoder to /var/ossec/etc/decoders/local_decoder.xml
and reopen the ossec-logtest
tool to take into account the new changes.
<decoder name="my_custom_decoder">
<program_name>audispd</program_name>
<regex>node=(\.*) type=(\.*) argc=(\.*) a0=(\.*) a1=(\.*) a2=(\.*) a3=(\.*)</regex>
<order>node, type, argc, a0, a1, a2, a3</order>
</decoder>
The log should now be decoded correctly:
**Phase 1: Completed pre-decoding.
full event: 'Feb 10 05:13:36 wazuhtestng03 audispd: node=wazuhtestng03 type=EXECVE msg=audit(1612934016.634:27477): argc=4 a0="grep" a1="--color=auto" a2="10.248.15.57" a3="archives.log"'
timestamp: 'Feb 10 05:13:36'
hostname: 'wazuhtestng03'
program_name: 'audispd'
log: 'node=wazuhtestng03 type=EXECVE msg=audit(1612934016.634:27477): argc=4 a0="grep" a1="--color=auto" a2="10.248.15.57" a3="archives.log"'
**Phase 2: Completed decoding.
decoder: 'my_custom_decoder'
node: 'wazuhtestng03'
type: 'EXECVE msg=audit(1612934016.634:27477):'
argc: '4'
a0: '"grep"'
a1: '"--color=auto"'
a2: '"10.248.15.57"'
a3: '"archives.log"'
I hope you find it helpful.
Best regards.
Hi,
In the case of windows eventchannel and syscollector, internal decoders are used. These decoders as they are cannot be tested in the ossec-logtest
tool but you can make a workaround to test them. I could show you how to do it with a specific use case that you need, that is, some condition in that event that you want to generate an alert.
In the meantime, to give you an idea, these logs are parsed as JSON, so if you want to know which fields are decoded you can copy the json containing the event data.
For example, imagine you want to see the fields of the eventchannel event, for this you would use the following:
{"win":{"system":{"providerName":"Symantec AntiVirus","eventID":"7","level":"4","task":"0","keywords":"0x80000000000000","systemTime":"2021-02-10T08:24:36.000000000Z","eventRecordID":"89723","channel":"Application","computer":"WindowsJumphost.NEXTGEN.LOCAL","severityValue":"INFORMATION","message":"\" \r\n\r\nNew virus definition file loaded. Version: 210209023.\""},"eventdata":{"data":" New virus definition file loaded. Version: 210209023."}}}
The result would be:
**Phase 2: Completed decoding.
decoder: 'json'
win.system.providerName: 'Symantec AntiVirus'
win.system.eventID: '7'
win.system.level: '4'
win.system.task: '0'
win.system.keywords: '0x80000000000000'
win.system.systemTime: '2021-02-10T08:24:36.000000000Z'
win.system.eventRecordID: '89723'
win.system.channel: 'Application'
win.system.computer: 'WindowsJumphost.NEXTGEN.LOCAL'
win.system.severityValue: 'INFORMATION'
win.system.message: '"
New virus definition file loaded. Version: 210209023."'
win.eventdata.data: ' New virus definition file loaded. Version: 210209023.'
And in the case of syscollector event:
{"type":"network","ID":817290886,"timestamp":"2021/02/08 11:12:56","iface":{"name":"Ethernet","adapter":"Intel(R) 82599 Virtual Function","type":"ethernet","state":"up","MAC":"06:9C:AC:75:19:EC","MTU":1500,"tx_packets":877079,"rx_packets":958770,"tx_bytes":274964697,"rx_bytes":387703122,"tx_errors":0,"rx_errors":0,"tx_dropped":0,"rx_dropped":0,"IPv4":{"gateway":"10.248.15.1","metric":5,"DHCP":"enabled","address":["10.248.15.57"],"netmask":["255.255.255.0"],"broadcast":["10.248.15.255"]},"IPv6":{"DHCP":"enabled","address":["fe80::d58c:9c0f:ebcd:3e26"],"netmask":["ffff:ffff:ffff:ffff::"]}}}
**Phase 2: Completed decoding.
decoder: 'json'
type: 'network'
ID: '817290886'
timestamp: '2021/02/08 11:12:56'
iface.name: 'Ethernet'
iface.adapter: 'Intel(R) 82599 Virtual Function'
iface.type: 'ethernet'
iface.state: 'up'
iface.MAC: '06:9C:AC:75:19:EC'
iface.MTU: '1500'
iface.tx_packets: '877079'
iface.rx_packets: '958770'
iface.tx_bytes: '274964697'
iface.rx_bytes: '387703122'
iface.tx_errors: '0'
iface.rx_errors: '0'
iface.tx_dropped: '0'
iface.rx_dropped: '0'
iface.IPv4.gateway: '10.248.15.1'
iface.IPv4.metric: '5'
iface.IPv4.DHCP: 'enabled'
iface.IPv4.address: '["10.248.15.57"]'
iface.IPv4.netmask: '["255.255.255.0"]'
iface.IPv4.broadcast: '["10.248.15.255"]'
iface.IPv6.DHCP: 'enabled'
iface.IPv6.address: '["fe80::d58c:9c0f:ebcd:3e26"]'
iface.IPv6.netmask: '["ffff:ffff:ffff:ffff::"]'
As I said, this is only useful to have an idea about the decoded fields, but in case you want to create or test any related rule in the ossec-logtest
tool you would have to make a workaround (This will be further improved).
Do you have any concrete use case?
Best regards.