Suricata timestamps are +2 hours relative to their corresponding Zeek events about build-suricata

[alfred-landrum]

FYI, I reproduced this on my Windows 10 laptop as well.

[philrz]

I've managed to reproduce this on something other than someone's personal Windows 10 laptop. 😉

It looks like the secret ingredient may be timezone settings. I spun up a Windows 2016 Server VM in Google Cloud. I installed the Brim-rc-v0.20.0-suricata20.exe artifact and imported the wrccdc pcap. All the Suricata alerts were within the pcap's time range as reflected in the picker.

However, that's when I noticed the timezone on the VM was at its default of UTC.

I then set the timezone to Pacific and redid the import, and now the alerts were outside the default range, and I had to once again change the picker settings to Whole Space to get them.

I was then able to change the timezone back to UTC and repro the problem yet again. Interestingly, from what I can tell, the delta doesn't seem to change based on which timezone I've selected, as I saw the same +2 hour difference if I changed to Eastern timezone.

[philrz]

I've now been able to narrow this down to a general Suricata problem.

On a scratch Windows 2016 VM in Google Cloud, I installed https://nmap.org/npcap/dist/npcap-1.00.exe and then https://www.openinfosecfoundation.org/download/windows/Suricata-6.0.0-beta1-1-64bit.msi. Using that same wrccdc.pcap, I test via:

"\Program Files\Suricata\suricata.exe" -r wrccdc.pcap

When my system timezone is set to default UTC, the timestamp of the top event in eve.json is 2018-03-23T19:58:22.647908+0000. If I paste that into the ISO8601 box at https://www.timestamp-converter.com/, it translates to:

Date (UTC)	Mar 23, 2018, 8:58:22 PM

Then when my system timezone is set to Pacific, the timestamp of the top event in eve.json is 2018-03-23T12:58:22.647908-0900. Pasted into that tool, it translates to:

Date (UTC)	Mar 23, 2018, 10:58:22 PM

While baselining in Suricata v5.0.3 I ran into the bug discussed at https://forum.suricata.io/t/eve-json-windows-timestamp-field-has-eastern-daylight-time-appended-to-timestamp/197 which leads to the change at OISF/suricata@bbdc118#diff-d8eecda9235371babc2890abb8415eeb9310a124444ea5189aa39e36025bbff9, which seems suspicious since it involves mucking with timestamps specifically on Windows, and this problem involves timestamps and we're only seeing it on Windows. @henridf is looking closer at that code.

[philrz]

I've opened an issue with Suricata https://redmine.openinfosecfoundation.org/issues/4183 in the event they figure it out before we do.

[henridf]

fixed with brimdata/suricata#2

[philrz]

Verified with draft Brim artifact rc-v0.20.0-suricatav5.0.3-brimpre1 that includes the fixed Suricata build. Now when I import the wrccdc pcap, the Suricata alerts are immediately visible as part of the time range that's been set based on the pcap.

If I isolate and group the events without changing the time range, I see the diverse set.

If I select "Whole Space" in the picker, the numbers remain the same, as we would expect.

Thanks @henridf!