Time error in Wazuh Dashboard

[ShtrudelMan]

Good afternoon!!!
I reread your posts above, but I was not helped by the answers you gave to a colleague's question.
My time zone is UTC+3h.
My settings are as follows:
admin@Wazuh-Server:~$ sudo timedatectl status
               Local time: Sat 2024-04-27 17:48:23 MSK
           Universal time: Sat 2024-04-27 14:48:23 UTC
                 RTC time: Sat 2024-04-27 14:48:23 UTC
                Time zone: Europe/Moscow (MSK, +0300)
System clock synchronized: yes
              NTP service: n/a
          RTC in local TZ: no

But for some reason time is different in components. 

As you can see in the screenshots. Time is different everywhere in different panels.
Under ideal conditions. It is required, of course, that when I log in with my computer in different time zones, the whole system displays events in the time zone in which I am present, except of course the logs that relate to the server.

For some reason on some panels the time is UTC+6 and my time is UTC+3.
What are my settings in “Menu”->“Stack Management”->“Advanced Settings”:
1. Day of week = Monday
2. Timezone for date formatting = Browser
3. Formatting locale = Russian

[Juan Antonio Garcia Ruiz]

Hello, I'm Juan from the Wazuh team, pleased to assist you.

I've been trying to replicate the error by changing the time zone and observing the results, but I can't replicate the error. Could you tell me the operating system, Wazuh version, and browser version you are using?

Thank you very much for your patience, I await your response to continue as soon as possible.

[ShtrudelMan]

Good afternoon, Juan!
I am using Wazuh version 4.7.3 rev.02 for all components.
Wazuh is installed locally on a Linux Debian 11 server.
The browser version used to connect to Wazuh Dashboard = Google Chrome (Version 124.0.6367.119 (Official Build), (64 bit)) installed on my Windows 10 workstation.
Release: Windows 10 Pro
Version: 21H2
OS build: 19044.3086
Interaction: Windows Feature Experience Pack 1000.19041.1000.0
My time zone = UTC+3 Moscow

понедельник, 29 апреля 2024 г. в 17:48:31 UTC+3, Juan Antonio Garcia Ruiz:

[Juan Antonio Garcia Ruiz]

Good morning and sorry for the delay in response.

Just a question, have you restarted the server once you have set the timezone for the server storing the Wazuh manager / Filebeat?
This may be happening because of the processes not taking the host timezone until they are restarted, also, depending on the log, ingestion time is used for the alerts

Let me know, regards.

[ShtrudelMan]

       Good afternoon
       Glad you are responding to this problem!
       Currently, all Wazuh components are installed on one server - these are the components Wazuh Manager, Wazuh Dashboard, Wazuh Indexer, and including Filebeat.

       Currently, when installing Debian 11 OS on my server, I indicated the current system time for my region.

       Here are my settings and the current status of the time service:

• root@Wazuh-Server:/home/admin# timedatectl status
•                 Local time: Tue 2024-05-07 15:16:16 MSK
•             Universal time: Tue 2024-05-07 12:16:16 UTC
•                   RTC time: Tue 2024-05-07 12:16:16

•                  Time zone: Europe/Moscow (MSK, +0300)
• System clock synchronized: yes
•                NTP service: n/a
•            RTC in local TZ: no

       Perhaps the problem, of course, is that I have not updated the test server to the latest versions of packages for Debian 11 for a long time, since this is very critical for the entire system to work stably for a long time.

       I'll try the task of including the "deb.debian.org" repository in "APT EDIT-SOURCES". I will update the system packages for Debian 11. And then I will inform you about this additionally!

       I am also interested in your answer, which you indicated that depending on the logs received, the time for receiving events from the logs is indicated for them. But if for some third-party systems I can still understand this nuance, then for Wazuh daemons and even more so for system logs, in my opinion, this is critical when the time of receiving logs goes several hours ahead of the real current time.

       Once again I will duplicate the settings in Wazuh “Menu” -> “Stack Management” -> “Advanced Settings”:

1. Day of week = Monday

1. Time zone for date formatting = Browser
2. Formatting locale = Russian

вторник, 7 мая 2024 г. в 11:52:33 UTC+3, Juan Antonio Garcia Ruiz:

[Juan Antonio Garcia Ruiz]

Good morning, I'm interested in knowing if you've updated the Debian version?
And if so, does the issue still persist?


Thank you very much, and I'm looking forward to your response."

[ShtrudelMan]

Currently my infrastructure looks like this:
1) Server with Wazuh components:

• root@WazSIEM:~# neofetch
  • OS: Debian GNU/Linux 11 (bullseye) x86_64
  • Host: KVM/QEMU (Standard PC (i440FX + PIIX, 1996) pc-i440fx-8.1)
  • Kernel: 5.10.0-28-amd64
  • Shell: bash 5.1.4

2) Agents:

• root@Deb11EOS:~# neofetch
  • OS: Debian GNU/Linux 12 (bookworm) x86_64
  • Host: KVM/QEMU (Standard PC (i440FX + PIIX, 1996) pc-i440fx-8.1)
  • Kernel: 6.1.0-21-amd64
  • Shell: bash 5.2.15

Look!
I have agents on Fedora 39 and Debian 12. My server is on Debian 11.
I am attaching screenshots where you can see the difference.

Look!
I have agents on Fedora 39 and Debian 12. My server is on Debian 11.
I am attaching screenshots where you can see the difference.
They show that time is moving forward on some dies in the Wazuh control panel.
Basically, they do not affect the work in any way! Security events are displayed based on the time the browser is being used.
But at the same time, in the Wazuh Dashboard -> Management -> Logs section, log entries are displayed indicating the time that is moving forward. I have attached these screenshots below. These logs are written on the Wazuh server side. The server has the correct time zone and the correct time. But the logs have different recording times, and for some reason they rush forward. This can be confusing when working. It is not clear what and when the process occurred in the system.

пятница, 10 мая 2024 г. в 09:23:44 UTC+3, Juan Antonio Garcia Ruiz:

[Juan Antonio Garcia Ruiz]

Good morning ShtrudelMan, after a small investigation I have found that the issue arises from a different API response. 

This will be fixed in future versions. 

Thank you very much for your contribution.

[ShtrudelMan]

Great!
How can I find out when these kinds of bugs will be fixed?

среда, 15 мая 2024 г. в 12:18:37 UTC+3, Juan Antonio Garcia Ruiz: