Wrong time
-
did you change your timezone since the system was last booted? that's generally where you get a discrepancy in time like that, processes don't pick up the new timezone until they're restarted.
-
-
Might I suggest, some feedback for users so they know when the fw needs to be rebooted. Other products tell the user when to reboot (or reload their desktop program) for settings to take effect.
There is a chance some changes to the fw which require a reboot might be exploitable now or in the future.
-
I had the same problem a few days ago (pfsense indicating a time of 15:00 instead of 13:00 in the logs. I noticed that trying to solve openvpn connection)
I did "ntpdate ntp.belnet.be" in the console to fix both problems.
-
ntpdate does no help :(
BTW, time in the console is incorrect (+1H).
Will try to change the timezone later and see if it's related to particular TZ or not. -
Changed TZ to Europe/Minsk (the same TZ as Moscow, GMT+3), rebooted.
Current date/time Wed Jan 21 19:30:38 MSK 2015
checking log - all good:
Jan 21 19:29:52 php-fpm[62125]: /index.php: Successful login for user 'admin'Changed TZ to Europe/Moscow, rebooted.
Current date/time Wed Jan 21 19:37:54 MSK 2015
checking log - time is wrong:
Jan 21 20:37:38 php-fpm[62912]: /index.php: Successful login for user 'admin' -
do those tz have different daylight saving settings?
-
do those tz have different daylight saving settings?
Both [should] have no DST. For Moscow DST was eliminated last year, not sure it was properly reflected in the router configuration.
-
There is a chance some changes to the fw which require a reboot might be exploitable now or in the future.
Changes that require a reboot to apply are few and far between and should always prompt as such. I can't think of any that don't, outside of if you want everything on the configured timezone post-change. There are 0 of them that "might be exploitable". Timezone changes have no relevance to security, simply a matter of which timezone processes are using for their time, which might be a different offset in that circumstance. They're still using the same clock as everything else.
Both [should] have no DST. For Moscow DST was eliminated last year, not sure it was properly reflected in the router configuration.
What we include there is the stock tzdata from FreeBSD 10.1, which should be accurate for all timezone changes up through a couple months ago. That's where I'd start looking though, search if anyone's seen issues with that timezone.
-
Time zone mismatches can cause problems with other systems or flag up alerts, less so with Windows as it doesnt record time properly in the first place which is why you'll never see windows being used in High Frequency Trading platforms which rely on fractions of a second to carry out trades, but even this years leap second will cause some problems if the programmers are not aware of it.
