Choose the timestamp field in the Logstash configuration

[Salam Salam]

Hi Dears.

In previous question in this group: https://groups.google.com/g/wazuh/c/yI7OZVEchs8

You instruct the person to follow:  https://github.com/wazuh/wazuh/blob/master/extensions/logstash/01-wazuh-remote.conf#L32 in order to choose the timestamp field in the Logstash configuration.

Unfortunately the link isn't working now. Could you please tell me how to choose the timestamp field in the Logstash configuration and where is  the location of this Logstash configuration file.

Many thanks in advance.

Regards,

[Alejandro Ruiz Gonzalez]

Hello,

You can change the timezone that Kibana uses to show the timestamp. For that, you can go to the left side of the browser, open Management and then go to Advanced settings and search for timezone. This will show the dateFormat:tz setting, where you can choose your desired timezone to match your Wazuh instance. Click on the Save button to apply your changes.

Restart Kibana and your Wazuh manager and this should be enough to change the timestamp field on your Kibana instance to match your Wazuh alerts. 

Maybe you will need to refresh your cache too.

Let us know if you have more questions.

[Salam Salam]

Thank you dear for your replay.

Could you please provide me with more details to solve this issue.

Hereunder, the snapshot of  Advanced settings R --> timezone.

Waiting your kind feedback.

Best Regards,

[Alejandro Ruiz Gonzalez]

Hello,

I will send you the steps to be followed with a photo to guide you.

1.Open the main menu, then click Stack Management > Advanced Settings.

2.Scroll or search for the setting you want to modify.

3. Enter a new value for dateFormat:tz

4. Click Save changes.

You will need to choose the dateFormat that you want or select the Browser option and then the time will synchronize with your device and you will need to refresh the cache of the browser too.

Let me know if that was useful to you and don't hesitate to contact me if you have further questions.

[Salam Salam]

Dear,

Thank you for your answers.

For more explanation, In Wazuh manager I configured the collection of log data from files by editing ossec.conf  to

<localfile>

    <log_format>syslog</log_format>

    <location>/var/log/*</location>

</localfile>

 Logs files are put within the mentioned directory periodically, and parsed with Wazuh PAM decoder-Natively-

Lets say that we have the following log:

2021-07-27T22:00:01.669288+03:00 linux cron[235768]: pam_unix(crond:session): session opened for user root by (uid=0)

We can see the timestamp of the actual log is (2021-07-27T22:00:01) And the timestamp (when the log is loaded:predecoder) is Jul 28, 2021 @ 13:36:21.089

The conclusion: I need the predecoder.timestamp to be as the timestamp.

Best Regards,

[Alejandro Ruiz Gonzalez]

Hello,

I will explain to you what is exactly each field.

This is an example of an alert:

You can see there both fields, timestamp and predecoder.timestamp. The predecoder.timestamp is when the event has been generated and timestamp is when the Wazuh manager has received the log. We have other fields related to that like data.timestamp, this is when the Wazuh agent has received the log.

Let me know if that was useful to you and don't hesitate to contact me if you have any other questions.

[Salam Salam]

  Thank you dear for your explanation.

I know that wazuh by default  evaluate  the timestamp in any rule that uses time. Actually, I need from Wazuh to choose & evaluate predecoder.timestamp instead of timestamp in such rules.

For example, If I have a simple rule triggers an alert if  the log contains a time (predecoder.timestamp) between 6 pm - 8:30 am as follows:

<rule id="100127" level="10">

       <decoded_as>test</decoded_as>

       <time>6 pm - 8:30 am</time>

       <description>Login outside business hours.</description>

       <group>policy_violation</group>

</rule>

I need Wazuh  when it tests this mentioned time criteria to look at the time of  predecoder.timestamp  Not  the  timestamp  as the two samples

Jul 26 2021 01:42:30 host  123 -------------->      Triggers  alert here

Jul 26 2021 09:42:30 host 123   -------------->  Not triggers here

Other common  SSH brute-force attack correlation rule:

 <rule id="5710" level="5">

         <if_sid>5700</if_sid> 

        <match>illegal user|invalid user</match>

        <description>sshd: Attempt to login using a non-existent user</description> 

</rule>

----------------------------------------------------

  <rule id="5712" level="10" frequency="8" timeframe="120" ignore="60">

             <if_matched_sid>5710</if_matched_sid>

            <description>sshd: brute force trying to get access to the system. </description> 

           <same_source_ip /> 

</rule>

I also need here from rule 5712 to trigger an alert if there are 8 failed logins within two minutes -timeframe- by looking at the predecoder.timestamp of these logs regardless of timestamp.

Many thanks in advance.

Best Regards,

[Alejandro Ruiz Gonzalez]

Hello,

We are not able to modify the timestamp field to be evaluated as predecoder.timestamp. The predecoder.timestamp is a field that is added from a JSON. This is configured at the code and we can't modify it.

Regarding the rule, it should work with that:

 <rule id="5712" level="10" frequency="8" timeframe="120" ignore="60">

             <if_matched_sid>5710</if_matched_sid>

            <description>sshd: brute force trying to get access to the system. </description> 

           <same_source_ip /> 

</rule>

Let me know if you have further questions and don't hesitate to contact me If you have further questions.

[Salam Salam]

Thank you dear for your answer.

Regarding the mentioned rule, it didn't work also for the following scenario:

I edited ossec.conf file to instruct Wazuh to read SSH logs from a specific directory:

<localfile> /var/log/ssh_logs.log</localfile> 

 

Then, I put the following SSH logs into /var/log/ssh_logs.log (the logs isn’t coming from a direct SSH connection).

The predecoder.timestamp of these logs are scattered within two hours. Unfortunately, the rule triggers in spite of timeframe is more than 120 seconds as specified within the rule

 Aug 11 09:13:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

Aug 11 09:23:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

Aug 11 09:33:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

Aug 11 09:43:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

Aug 11 09:53:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

Aug 11 10:05:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

Aug 11 10:15:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

Aug 11 10:25:38 sshd[2983]: Failed password for root from 192.168.1.1 port 49229 ssh2

 

Please advise.

Best Regards,

[Alejandro Ruiz Gonzalez]

Hello,

To configure a <localfile>, you need to apply something similar to that configuration:

<localfile> 

   <log_format>syslog</log_format> 

   <location>/var/log/ssh_logs.log</location>

</localfile>

Then, regarding the rule, the logs you have sent me don't generate any alert with rule-5712, this rule triggers when rule 5710 has been triggered previously 8 times with an interval of 120 seconds. But the rule 5710 are not triggering with your logs, that rule look for illegal user|invalid user into your log.

Otherway, I have been testing your logs and I realised that the sshd decoder doesn't match with them, that is caused because you don't have a hostname at your logs, but we can modify the format of this logs adding a letter for example and that should fixed that problem. You can modify the previous configuration I have sent you with that one:

<localfile> 

   <log_format>syslog</log_format> 

   <location>/var/log/ssh_logs.log</location>

   <out_format>$(timestamp) x $(log)</out_format>

</localfile>

After applying that configuration you will need to restart your Wazuh manager.

I will send you a photo of the behaviour with the changes applied:

As you can see there, now when you receive multiple authentication failures the rule 5720 triggers and when authentication failure logs are less than 8 triggers the rule 5716.

Let me know if that information was useful to you and don't hesitate to contact me if you have further questions.

[Salam Salam]

Thank you dear for your reply.

However, is there any way to evaluate  predecoder.timestamp  of  interval of 120 seconds instead of timestamp interval.

Regards,

[Alejandro Ruiz Gonzalez]

Hello,

We are not able to modify the timestamp field to be evaluated as predecoder.timestamp. The predecoder.timestamp is a field that is added from a JSON. This is configured at the code and we can't modify it.

Let me know if that information was useful to you and don't hesitate to open a new thread if you have other questions.