[Snort-users] simultaneous snort and tcpdump
roesch at ...1935...
Thu Sep 26 18:30:04 EDT 2002
You should use tags to record follow-on traffic. Traffic preceding the
event is a lot harder, we'd have to have some sort of packet buffering
mechanism that could keep the packets around for a relatively long period of
time and then you'd have to search that buffer in the event of a detection.
We could do something like a ring buffer that just overwrites its tail over
time without getting too crazy, but it'd be best to multi-thread it so that
packet acquisition could continue while Snort does its job. Searching the
whole buffer to dump packets that precede the event traffic is potentially a
very slow process, which could lead to issues. Additionally, the amount of
traffic buffered before the event couldn't be guaranteed, so you could never
guarantee that you'd get the 10 packets before the event.
So that's the scoop. If anyone wants to tackle the hard end of the problem
I'd be interested in seeing the solution you come up with. Tagging is in
the "Writing Rules" document at snort.org, if you have any problems using
them, let me know.
On 9/26/02 4:47 PM, "Carl Gibbons" <cgibbons at ...6953...> wrote:
> Okay, here's an example of what I'd like: for every snort alert,
> don't just save (into mmdd at ...3818...) the packet that caused
> the alert, but also save the ten preceeding and ten succeeding
> packets between the same hosts.
> This is why I am running tcpdump and snort simultaneously. My
> question remains. Sorry, Jason, but your "RTFM" suggestion
> to craft a clever snort rule doesn't help. - Carl
> On Sun, 22 Sep 2002, Jason wrote:
>> create a rule that matches the other interesting traffic.
>> look at the docs for creating rules on snort.org
>> Carl Gibbons wrote:
>>> Thanks, Bennett and Gary.
>>> I was needlessly complicating matters. Perhaps I still am: one
>>> reason I want simultaneous snort/tcpdump is that "snort -b" only
>>> seems to record packets on which it finds a rule match, and I want
>>> to record other traffic as well. Perhaps there's an elegant,
>>> efficient way to do so with a single snort process? - Carl
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> Snort-users list archive:
Martin Roesch - Founder/CTO Sourcefire Inc. - (410) 290-1616
Sourcefire: Professional Snort Sensor and Management Console appliances
roesch at ...1935... - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
More information about the Snort-users