VMesxi decoder and rule

283 views
Skip to first unread message

Aung Pyae

unread,
Apr 5, 2022, 6:13:31 AM4/5/22
to Wazuh mailing list
Hi Wazuh Team, 

I have forwarded syslogs from esxi and got 

CMD//

tcpdump -i any udp port 514 and src  172.xx.xx.xxx 

Result logs
09:48:48.171110 IP 172.xx.xx.xxx > wazuh-manager.syslog: SYSLOG user.info, length: 391
09:48:48.171650 IP  172.xx.xx.xxx   > wazuh-manager.syslog: SYSLOG user.info, length: 204
09:48:48.860201 IP  172.xx.xx.xxx    > wazuh-manager.syslog: SYSLOG user.info, length: 336
09:48:48.860430 IP  172.xx.xx.xxx   > wazuh-manager.syslog: SYSLOG user.info, length: 201
09:48:49.866161 IP  172.xx.xx.xxx    > wazuh-manager.syslog: SYSLOG user.info, length: 336
09:48:49.866379 IP 172. 172.xx.xx.xxx    > wazuh-manager.syslog: SYSLOG user.info, length: 201

Kibana logs
Apr 5, 2022 @ 15:45:33.117
location:172.xxxxxxxxx input.type:log agent.name:wazuh-manager agent.id:000 manager.name:wazuh-manager rule.firedtimes:1 rule.mail:false rule.level:5 rule.pci_dss:10.2.4, 10.2.5 rule.hipaa:164.312.b rule.tsc:CC6.1, CC6.8, CC7.2, CC7.3 rule.description:syslog: User authentication failure. rule.groups:syslog, access_control, authentication_failed rule.id:2501 rule.nist_800_53:AU.14, AC.7 rule.gpg13:7.8 rule.gdpr:IV_35.7.d, IV_32.2 id:1649150133.69760859


Please provide decoder and rule format if available.

Thanks 

vmwaelog.txt

Jonathan Martín Valera

unread,
Apr 5, 2022, 7:16:44 AM4/5/22
to Wazuh mailing list

Hi,

First of all, I am going to share with you some useful references for the creation of decoders and rules:

To create the decoders you have to see if the log has a fixed structure or can be variable, in which case you will probably have to create several decoders for those cases.

I am going to give you an example with the following log:

1 2022-04-05T10:08:30.949693+00:00 photon-machine vpxd 3963 - -  -->    startVClockTime = (vim.vslm.VClockInfo)

If we try this log in the /var/ossec/bin/wazuh-logtest tool, we see that there is no decoder for it:

1 2022-04-05T10:08:30.949693+00:00 photon-machine vpxd 3963 - -  -->    startVClockTime = (vim.vslm.VClockInfo)

**Phase 1: Completed pre-decoding.
    full event: '1 2022-04-05T10:08:30.949693+00:00 photon-machine vpxd 3963 - -  -->    startVClockTime = (vim.vslm.VClockInfo)'

**Phase 2: Completed decoding.
    No decoder matched.

I am going to assume that to identify this type of logs, the header will be the following:

1 2022-04-05T10:08:30.949693+00:00 photon-machine vpxd 3963 - -  -->

and the content:

startVClockTime = (vim.vslm.VClockInfo)

Therefore, I am going to create and add the following decoder to /var/ossec/etc/decoders/local_decoder.xml.

<decoder name="esxi-generic">
  <prematch type="pcre2">\d \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d+.\d{2}:\d{2} photon-machine vpxd \d+ - -  --\>\s*</prematch>
</decoder>

<decoder name="esxi-start">
  <parent>esxi-generic</parent>
  <regex>startVClockTime = \((\.*)\)</regex>
  <order>start_v_clock_time</order>
</decoder>

If I wanted to generate an alert when such decoded field has value vim.vslm.VClockInfo, then I would create and add the following rule in /var/ossec/etc/rules/local_rules.xml:

<rule id="100050" level="3">
  <decoded_as>esxi-generic</decoded_as>
  <field name="start_v_clock_time">vim.vslm.VClockInfo</field>
  <description>vim.vslm.VClockInfo started!</description>
</rule>

If we try to test again the same log in the /var/ossec/bin/wazuh-logtest tool, we can see as it is now decoded and the alert would be generated for the mentioned use case:

**Phase 1: Completed pre-decoding.
    full event: '1 2022-04-05T10:08:30.949693+00:00 photon-machine vpxd 3963 - -  -->    startVClockTime = (vim.vslm.VClockInfo)'

**Phase 2: Completed decoding.
    name: 'esxi-generic'
    start_v_clock_time: 'vim.vslm.VClockInfo'

**Phase 3: Completed filtering (rules).
    id: '100050'
    level: '3'
    description: 'vim.vslm.VClockInfo started!'
    groups: '['local', 'syslog', 'sshd']'
    firedtimes: '1'
    mail: 'False'
**Alert to be generated.

If we want to apply these changes, we must restart the wazuh-manager:

systemctl restart wazuh-manager

I hope you find this information useful.

Best regards.

Reply all
Reply to author
Forward
0 new messages