Quote:
|
Does this have any impact on my system's security and/or reliability whether at the client or server level ?
|
Setting the time-of-day incorrectly means to have the wrong timezone setting or being off by some minutes or hours. This can certainly confuse anyone reading logs that use timestamps -- especially when comparing logs from one machine, with another machine when conducting root cause analysis. When recovering data in filesystems by timestamp, this could introduce integrity problems -- using the wrong backup for recovery, as an example.
The only security issue I could think of with an incorrect timestamp are when security systems use timestamps as part of the operational schema. Kerberos tickets used for authentication and authorization are timestamped and require participating systems to keep clocks in sync within specific tolerances.
If a time-of-day clock is malfunctioning, this means that all timestamps are untrustworthy -- this means that timestamps in logs, file metadata, authentication and authorization systems will be adversely affected.
If a system clock (time-of-day, msec or sec counter) is malfuctioning it might possibley weaking an encryption schema that uses clocks for key management. Weakened semantic security will occur if multi-use keys are not replaced within appropriate traffic windows. I don't know if any implementations use clocks rather than message counters...but the possibility exists..