AIX event date/time issue
|Article:TECH176447|||||Created: 2011-12-07|||||Updated: 2012-05-31|||||Article URL http://www.symantec.com/docs/TECH176447|
The post and event time stamps [hour, minutes, and year] gathered in a .csv file show a year well into the future. However, the getagentinfo captured does not reflect this issue.
Some records that indicate that the btmp collector’s read offset appears to be off by some fixed number of bytes in (at least some of) the records w/ bad event dates. We can deduce that these are off by 2 bytes by looking at the event details field. The Username: field is ‘ fee’ but should be ‘coffee’, the Port: is ‘h’ but should be ‘ssh’, etc.
Version 18.104.22.1687 AIX 5L
AIX rcscsp13 2 5 000097984C00
AIX rcscsp10 2 5 000D0D9F4C00
SCSP version=5.2.0 build.number=537
The event data provided from the SCSP database revealed that the data the SCSP IDS daemon read in from the file was a few bytes off. This is the actual reason of the invalid time stamps in the database. This issue would subsequently correct itself by a reboot of the system, restart of the IDS daemon or rotation of BTMP file on the system.
A possible reason for this issue is that the IDS daemon started at the time the BTMP file was active and IDS daemon started reading from an incomplete record offset within BTMP file.
BTMP file is a binary file containing fix records of login failure records. IDS daemon upon start up would seek to the end of the file and wait for new entries to become available. If the file was active during the seeking to the end, we would end up reading from an incorrect offset. Since time stamp set in event time field comes from BTMP record, it ended up with invalid time stamps; in this case, the time was far into the future.
Workaround: reboot the system.
This issue is addressed in SCSP 5.2 RU8 MP4
Symantec added sanity checks on event timestamps and removes any events with a date > 6 months different from current date. This attempt is made to recover from bad records by resetting the file pointer to the end of the file.
Article URL http://www.symantec.com/docs/TECH176447