[Snort-users] Logging to tcpdump file and d/b

roman at ...438... roman at ...438...
Mon Mar 5 10:12:37 EST 2001

(I have not confirmed at the source level, but I suspect the following
may be happening)

TCPDump correctly stores the timestamp of a packet.  However, 
the timestamp generated by the DB-plug-in is actually not
the absolute time that the packet was read off the wire.  Rather 
this timestamp reflects when Snort detected/received it.  When 
Snort is used to read the packets directly off the wire, these two 
times are potentially off by only several milliseconds.  However,
when packets are replayed, the latency between the packets being
on the wire and being read by Snort can be significantly longer.
Thus, as slaves to the underlying database, analysis tools may 
be providing skewed results on alert arrival time.


> I have a 1.7 sensor logging to tcpdump, syslog and mysql/acid
> (I know it's not efficient - it's in test)
> In checking through some alerts I replayed the binary file back 
> through snort and tcpdump,
> (grepping for the source address seen in acid) it didn't show
> anything for that address. (I also used vi on the output and
> paged through looking by date/time)
> So, I see the alert in syslog and acid with same date/time but
> not in the binary file.
> The binary file has plenty of entries for the last several days.
> Any ideas?
> Steve
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users

This message was sent using Voicenet WebMail.

More information about the Snort-users mailing list