Re: [security-onion] Sguil vs packet captures, not live traffic

[Scott Runnels]

Richard, 

Have you had any luck using tcpreplay to feed the data through all of SecurityOnion's components in one go?  

v/r

Scott Runnels

On Thu, Jan 17, 2013 at 9:07 AM, Richard Bejtlich <taose...@gmail.com> wrote:

I was wondering if anyone had recommendations for ways to run Sguil (and its various components) against a packet capture, rather than solely on a live interface?

Many of the tools shipped with Security Onion support reading from a packet capture, as do individual Sguil components (Snort or Suricata, SANCP, etc.) However, with Sguil, it's not apparent how to get all of the components to work against a packet capture such that the results appear in the console as one might like to see.

Any advice?

Thank you,

Richard

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To post to this group, send email to securit...@googlegroups.com.
To unsubscribe from this group, send email to security-onio...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion?hl=en-US.

[Heine Lysemose]

Hi

I think it's the other way around.

It's not the tools to replay pcaps that the problem (tcpreplay, snort, netsniff-ng, bro etc.). It's the tools that reads the traffic... I think that the capturing tool will always use the current system time when capturing the traffic.

I'm I way off?

/Lysemose

On Thu, Jan 17, 2013 at 6:23 PM, Richard Bejtlich <taose...@gmail.com> wrote:

Hi Scott,

Tcpreplay is an option, but the result is the data in Sguil, etc., reflects the timestamps at the time of replay -- not those from the original trace.

Sincerely,

Richard

[Jon Schipp]

Indeed. Libpcap based tools (Wireshark, tcpdump, snort etc.) receive the
timestamp from libpcap, which, in turn, receives it from the network system
in the OS. This is usually sometime _after_ the network device receives the
packet since many non-specialized cards do not support hardware time stamping.

When a tool receives the replayed packets, the timestamps on the packets
_received_ (from replaying interface) will "reflect the timestamps at the
time of replay" and not of the timestamps of the original trace.

This was just a misunderstanding :)