Client Syslog Information in GUI

[Scott Regnier]

I am here becasue our company management wanted a SEIM type product.  One main item out of that was to have saved logs that could be used for remediation of incidents.  Looking at the various options and related costs we decided to see what we could do for "free".  So two of us ended looking at OSSEC and ELK.  I checked out OSSEC and after setting it up in a virtual test environment, it didn't provide what we needed, so I looked like Wazuh we be better.  I'm having issues with how to collect Syslog information from various clientless devices and could use some more explanation on how to make it work.

So using a single CentOS 7.6 virtual machine, I've followed the installation guide to install Wazuh Server, Elastic Stack, and Wazuh agents on several Windows servers.

I did NOT do any of these optional steps:

Elasticsearch tuning

Transform your data with Logstash

Insert a Wazuh API entry automatically

Configure an Elasticsearch Cluster

I'm collecting information from the Windows even logs from my Windows servers. 
   Will ALL the events be recorded in the Archives?

I've set the LOGALL option to  "yes" in the ossec.conf with hopes I will record all the log information so it  can be searched with Elastic Stack.

I've read that the above option will record the log information even if there isn't a decoder/ruleset for it, therefore I haven't made a custom decoder.

However, I noticed a cisco customer decoder sample given on the mailing list, which makes me wonder if I still need it.

   Do I need to have a custom decoder to get all the traffic from my syslog from Cisco?

I expect to be able to view information in the GUI collected by the Wazuh client and clientless syslog methods, but don't see any info for the syslog.

  Where do I go in the GUI to display the Syslog information so I know that I'm capturing it?

[Jose Miguel Mallorquin]

Hello Scott,

first of all, thank you very much for your interest in Wazuh.

As you properly mentioned, Wazuh Manager has the capability to collect Syslog events from remote devices (agentless servers, firewalls, routers, switches, printers, etc.) and parse them by using the Decoders and Rules, generating the corresponding alerts when needed. The detailed information can be found here.

You just need to edit the Manager's /var/ossec/etc/ossec.conf file to add the following section:

  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <allowed-ips>192.168.2.0/24</allowed-ips>
    <protocol>udp</protocol>
  </remote>

You can add more than one IP addresses or networks whose syslog will be accepted by Wazuh, just adding consecutive <allowed-ips> lines like above.

Once the Remote syslog collection is enabled and the remote devices are forwarding their events to the Wazuh Manager IP, you can check the incoming syslog by using, for example, the following command:

tcpdump -i any port 514 -AA

Also, as you enabled the <logall> option in the ossec.conf file, Wazuh Manager will store all of the received events at:

/var/ossec/logs/alerts/alerts.log

Then, if the current Decoders and Rules are ready to analyze the incoming events from your devices, an alert will be sent to Kibana at the end of the chain. You can see the alerts in the Kibana GUI -> Discover tab at the lateral menu.

To parse any log in Wazuh Manager, you can use the following tool:

/var/ossec/bin/ossec-logtest

Just paste the full log and press Enter. You will see if a existing Decoder extracts the fields contained in the log and if a Rule triggers the corresponding alert.

Otherwise, if the default Ruleset of Wazuh doesn't contemplate a specific syslog type, it is very common to create custom Decoders and Rules: custom rules and decoders.

Regarding the Windows event logs, our recommendation is to install the Wazuh Agent software on the required server. It is quite easy to install and manage, and the resources consumption is really low. The Agents will send their events to the Wazuh Manager in which they are regiestered. The Manager is plently ready to parse the main three Windows events channels: System, Application and Security.

Every event received by Wazuh Manager will be stored at /var/ossec/logs/archives/archives.log and archives.json and the generated alerts will be stored at /var/ossec/logs/alerts/alerts.json and alerts.log files.

If your server doesn't have a big disk storage, it is not recommendable to leave <logall> enabled, as it can hugely grow depending on the events per second it receives.

I hope this helps. Don't hesitate to ask us for further information.

Kind regards,

Jose M.

[Scott Regnier]

[Scott Regnier]

Jose, Thanks for the information.  

I already had the ossec.conf updated with the <remote> information.
Running the tcpdump test we confirmed data was reaching the wazuh server from our cisco switch.

We also verified that a record was written to archives.log.

Using ossec-logtest showed that there was no matching decoder.  Hmmm.  I wonder why.

We followed the installation guide from the Web site so we have the default decoders.

In the /var/ossec/ruleset/decoders/0065-cisco-ios_decoders.xml we have...

 <!--
   - Sequence number, date (preceded by * or . or nothing) and hour
   - 1348: .Jun 12 18:22:22 UTC: %SYS-5-CONFIG_I:
   - 1348: *Jun 12 18:22:22 UTC: %SYS-5-CONFIG_I:
   - 1348: Jun 12 18:22:22 UTC: %SYS-5-CONFIG_I:
   - 681: Aug 17 17:41:24.776 AEST: %SEC-6-IPACCESSLOGS:
 -->

 <decoder name="cisco-ios">
   <prematch>^\d+:\s+\p*\w+\s+\d+\s+\S+\s+\w+:\s+%</prematch>
 </decoder>

...which we believe should match our syslog record.

Here is the record I used to test.
 
 002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown

Can you explain why that doesn't match the decoder?

On Wednesday, September 11, 2019 at 2:44:39 PM UTC-5, Scott Regnier wrote:

[Jose Miguel Mallorquin]

Hello Scott,

thanks for the feedback. It seems we are very close to getting it.

If we compare the log samples in the current 0065-cisco-ios_decoders.xml file of the default Ruleset with your Syslog record, we can see a tiny difference: space+TIMEZONE

   681: Aug 17 17:41:24.776 AEST: %SEC-6-IPACCESSLOGS: <any_event_information>

002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown

So, the original decoder cisco-ios would need to be edited to delete these expressions: \s+\w+

The proper way to create that custom Decoder, following our Documentation, is to copy the original one and paste it in /var/ossec/etc/decoders/local_decoder.xml. Then, edit it like below:

<!--

002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown

-->

<decoder name="custom_cisco-ios">
    <prematch>^\d+:\s+\p*\w+\s+\d+\s+\S+:\s+%</prematch>
</decoder>
<!-- Cisco IOS
  - Extracts the ID of cisco ios messages IF NOT IDS/ACL log.
  -->
<decoder name="custom_cisco-ios-default">
  <parent>custom_cisco-ios</parent>
  <regex>(%\w+-\d-\w+):</regex>
  <order>id</order>
</decoder>

Save the changes and restart the wazuh-manager service.

Once it's done, the ossec-logtest tool will show the following output when using the log sample you provided:

[root@wazuh-manager-3-9-ip9 ~]# /var/ossec/bin/ossec-logtest
2019/09/13 01:55:24 ossec-testrule: INFO: Started (pid: 4571).
ossec-testrule: Type one log per line.

002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown

**Phase 1: Completed pre-decoding.
       full event: '002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown'
       timestamp: '(null)'
       hostname: 'wazuh-manager-3-9-ip9'
       program_name: '(null)'
       log: '002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown'

**Phase 2: Completed decoding.
       decoder: 'custom_cisco-ios'
       id: '%PARSER-5-CFGLOG_LOGGEDCMD'

We can see the Phase 1 and Phase 2 are completed. And the decoder used is now our custom_cisco-ios.


If you wanted to extract any other field in addition to the "id" (e.g. the "user" or the "command"), you can follow the instructions to edit the regular expression in the custom child decoder custom_cisco-ios-default. and add the corresponding field name between the <order></order> tag. See also Dynamic fields.

On the other hand, we need to create a custom Rule to trigger the alerts based on the information extracted with the custom Decoder. You can copy the default rule, which is the rule id="4715" and paste it in /var/ossec/etc/rules/local_rules.xml

It will look like below (modify the level or description values to your choice):

<group name="syslog,cisco_ios,">
  <rule id="100002" level="0">
    <decoded_as>custom_cisco-ios</decoded_as>
    <description>Grouping of Cisco IOS rules.</description>
  </rule>
  <rule id="100003" level="3">
    <if_sid>100002</if_sid>
    <id>-5-</id>
    <description>Cisco IOS notification message.</description>
  </rule>
</group>

And, finally, here is the result parsing your Syslog record:

[root@wazuh-manager-3-9-ip9 ~]# /var/ossec/bin/ossec-logtest
2019/09/13 02:05:36 ossec-testrule: INFO: Started (pid: 5105).
ossec-testrule: Type one log per line.

002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown

**Phase 1: Completed pre-decoding.
       full event: '002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown'
       timestamp: '(null)'
       hostname: 'wazuh-manager-3-9-ip9'
       program_name: '(null)'
       log: '002115: Sep 12 14:18:13.783: %PARSER-5-CFGLOG_LOGGEDCMD: User:mnadella  logged command:no shutdown'

**Phase 2: Completed decoding.
       decoder: 'custom_cisco-ios'
       id: '%PARSER-5-CFGLOG_LOGGEDCMD'

**Phase 3: Completed filtering (rules).
       Rule id: '100003'
       Level: '3'
       Description: 'Cisco IOS notification message.'
**Alert to be generated.

After restarting the wazuh-manager service, you can check the output of /var/ossec/logs/alerts/alerts.json and alerts.log and, in the end, if the entire data flow in your environment is working as expected, you should have those Cisco IOS alerts in the Kibana GUI.

I hope it helped.

Regards,

Jose M.