Closed marc-gr closed 3 years ago
Pinging @elastic/siem (Team:SIEM)
This issue came up recently on Discuss, with a user providing a workaround: https://discuss.elastic.co/t/filebeat-using-fortinet-module-tz-issue/251518/10
Pinging @elastic/security-external-integrations (Team:Security-External Integrations)
This is a possible workaround but what we really want is related to these 2 issues:
https://github.com/elastic/beats/pull/20273
Important to mention here is that this can happen only with older Fortinet Firmwares. Here was a discussion around this topic:
https://github.com/elastic/beats/issues/19010#issuecomment-643247437
For consistency, it could be interesting to do what we do in other modules with similar problematics:
event.timezone
and another one without event.timezone
(as here in the nginx module).event.timezone
is set with add_locale
(as here), and can be also set, or overriden by the user by setting event.timezone
with the add_fields
processor.Just a note, you can use eventtime as a UTC time that matches the date time fields. Why not use that time?
In your example above:
date=2020-07-20 time=08:29:08
eventtime=1595226548 == Monday, July 20, 2020 6:29:08 AM
Thoughts?
Would this be something related? https://github.com/elastic/beats/issues/11273
Would this be something related? https://github.com/elastic/beats/issues/11273
No, I don't think so.
Describe the enhancement:
Some fortinet logs do not have a
tz
field to set the timezone from, now we are defaulting to UTC for this, but would be desirable to set a fallback default timezone if this happens.Describe a specific use case for the enhancement or feature:
When we have a log like
we want to be able to define which timezone it is other than UTC
cc\ @P1llus