timezone settings - UTC is annoying
Jerry Shenk
somewhat annoying to constantly be doing date calculations in my
head. If I only have one sensor, is it really better to be running on
UTC time? This also makes it just that much more complicated to try
to explain to others.
Doug Burks
There are a few issues with timezones:
- Until recently, some timezones wouldn't run the daily disk purge
correctly. UTC forced the cronjob to run correctly keeping disks from
filling up. (This should no longer be an issue now that we've
de-coupled the purge from the daily restart and run the disk purge
every hour.)
- Time zones that have daylight saving time have a one-hour time warp
twice a year. This manifests itself in Sguil not being able to pull
transcripts for events within that one-hour time period. This is
avoided by using UTC, since there is no daylight saving time.
- Something similar can happen on a daily basis under certain
conditions. If there is a discrepancy between the OS timezone and the
Sguil UTC settings, then Sguil will be unable to pull transcripts for
events in a window of time around midnight coinciding with the
timezone's offset from UTC.
As you can see, using UTC avoids a lot of issues and is the
recommended setting. Feel free to experiment with timezones on your
installation and see if you can get consistent behavior.
Thanks,
Doug Burks
--
Doug Burks
SANS GSE and Community Instructor
Security Onion | http://securityonion.blogspot.com
President, Greater Augusta ISSA | http://augusta.issa.org
Jerry Shenk
Here's what I did so far:
dpkg-reconfigured tzdata - Changed from UTC to EST (America/New York)
edited /etc/nsm/ids-laptop-eth0/sensor.conf and changed the SENSOR_UTC
variable from "Y" to "N"
restarted nsm (service nsm restart)
4 hours later rebooted the whole box
At this point, things still aren't quite right. The date on the box
was correct after the dpkg-reconfigure procedure. Restarting nsm
caused some stuff to be correct and I'm not sure if rebooting the box
fixed anything.
The only only thing that's not sorking right at this point is the
snort events. They all come in with a timestamp that's 5 hours behind
(right now, EST is 10:14 and events show up as 05:14). That would
seem to indicate that some process is converting what it thinks is UTC
time to localtime. Squert however shows the "last event" as being 5
hours ago.
The real impetus behind my testing with this is that I have a guy who
wants an IDS and just knowing him, he's gonna have an issue with this
UTC thing. I may just end up explaining why UTC is best but he also
will have times when he will have to report to other people like the
owner of the company. I can just imagine that not going too well;)
In general, for a small network that only exists in a single timezone,
localtime just seems handier.
Paul Halliday
the gap. In its config file:
// Timezone offset. If you want UTC use the second option.
$offset = date("Z"); // Option #1: Local Time
//$offset = 0; // Option #2: UTC
if you have it set like this, and the systems php.ini contains a valid
timezone setting, something like:
date.timezone = Canada/Atlantic
it will apply the offset to any reports generated. As Doug mentioned
though, things get a little screwy during DST changes.
--
Paul Halliday
http://www.squertproject.org/
Jerry Shenk
back to UTC and change the sensor.conf file back to what it was
(SENSOR_UTC="Y"). At this point, the data is all stored in the sguil
database with UTC timestamps. Then squert can address the local time
issue when the data is viewed at the web server.
And, to get squert to make those conversions, it's config file needs
to be changed as you noted. Where is this config file? ..or what is
it's name? I can't find anything with in it.
Also, I understand that the date.timezone variable in /var/www/
squert/.glow needs to be set appropriately (America/New York for me).
I do understand that one a year there will be a gap in the events and
once a year there will be a really screwy overlap in events making any
analysis at those times a little more complicated.
Paul Halliday
> So, let me restat this - you think it would be best to put the machine
> back to UTC and change the sensor.conf file back to what it was
> (SENSOR_UTC="Y"). At this point, the data is all stored in the sguil
> database with UTC timestamps. Then squert can address the local time
> issue when the data is viewed at the web server.
Yup, for the reasons already mentioned. It is bad form to store time
stamps in local time. Let the apps do the conversion.
>
> And, to get squert to make those conversions, it's config file needs
> to be changed as you noted. Where is this config file? ..or what is
> it's name? I can't find anything with in it.
>
it should be in <path to squert>/.inc/config.php
> Also, I understand that the date.timezone variable in /var/www/
> squert/.glow needs to be set appropriately (America/New York for me).
.. no. You need to set this in php's .ini file. Look for php.ini. You
will need to restart the web server after the change.
>
> I do understand that one a year there will be a gap in the events and
> once a year there will be a really screwy overlap in events making any
> analysis at those times a little more complicated.
not if you stick to UTC :)
Jerry Shenk
the watch you wear on your arm? ...do you constantly do the math in
your head to convert the time from UTC to whatever your local timezone
is? Or, do you mean that you set everything to UTC, set the hardware
clock to UTC, etc. so that the time looks correct.
Doug Burks
Yes, the times on the events are UTC and I do the math to convert to
my local timezone. Personally, I'm more concerned about "did the box
get popped or not?" versus "when did the box get popped?".
Thanks,
Doug
--
Doug Burks
SANS GSE and Community Instructor
Security Onion | http://securityonion.blogspot.com
President, Greater Augusta ISSA | http://augusta.issa.org
Please vote for Security Onion for 2011 Toolsmith Tool of the Year! |
http://goo.gl/PwTDi