[Snort-users] Snort/Postgresql: invalid timestamps on alpha and sparc with dormant Y2K

Vladimir Strezhnev 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 
beginning.
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 
following error: 
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?

-- 
VLAD STREZHNEV
System Engineer,
IndiVisual Learning, Inc.
23 Empire Drive,
St. Paul, MN 55103




More information about the Snort-users mailing list