[Snort-users] Snort/Postgresql: invalid timestamps on alpha and sparc with dormant Y2K
vlast at ...2411...
Thu Jun 28 11:53:13 EDT 2001
Looking for directions on how to start handle the following
We have ACID/POSTGRESQL running on Alpha (RedHat 6.2).
The first SNORT sensor was installed on the same Alpha accessing it as
localhost. The second SNORT sensor was installed on a INTEL-based PC
accessing the POSTGRESQL remotely.
The remote SNORT sensor was logging everything perfectly from the very
The local SNORT sensor produced "invalid" timestamps for any alerts logged in
to the database but scans. Portscan plug-in logged correct timestamps.
Trying to find the cause we discover that alpha "hwclock --debug" command
displays the following date "101/06/28" instead of "2001/06/28". Although it
is definitely a dormant Y2K, kernel somehow handled it until now and all
other applications (a lot of them :-) on the host runs without problem.
Plain "hwclock" command produces correct date and BIOS clock syncronises
correctly with system clock etc.
Now we put a third SNORT sensor on sparc (RedHat 6.2) :-).
The POSTGRESQL refuses to accept logs at all from this sensors with the
Jun 27 18:20:13 192.168.1.1 snort: database: postgresql_error: ERROR: Bad
timestamp external representation '???????-???????-??????? ???????'
We run "hwclock --debug" on sparc and got the same year "101" instead "2001"
Now, the question - whose fault it is?
Is it hardware problem and can be solved only with BIOS upgrade?
Or it is a POSTGRESQL bug ( I searched their bug-lists and found a lot of
staff related to the same timestamp error produced by other applications) ?
Or it is a SNORT problem which can not handle this Y2K quirk of alpha/sparc
while other applications knows how to bypass it?
IndiVisual Learning, Inc.
23 Empire Drive,
St. Paul, MN 55103
More information about the Snort-users