Project

General

Profile

Feature #120

Capture full session on alert

Added by Dave Smith almost 10 years ago. Updated 4 months ago.

Status:
New
Priority:
Low
Target version:
Effort:
high
Difficulty:
medium
Label:

Description

On alert, snort either captures only the individual packet that hit on a rule, or 'n' number of packets thereafter that you specify with the tag keyword. Investigation of an alert is usually pretty hard with only that one packet, unless you happen to separately be saving all traffic on the wire to disk, and can go and retrieve the relevant pcap from elsewhere manually. Tagging will only get you packets after the alert - if your rule hits a few packets into the session, the previous packets are lost.

It would be great to have the capability to capture an entire session. I previously worked for a large multinational company that had a proprietary, in-house developed IDS that did this. Its engine held a rolling packet buffer of a couple hundred MB of of traffic from the wire that the engine could reach back into, to collect the beginning of the session, and it seemed to work quite well.


Related issues

Related to Support #2309: SuriCon 2017 brainstormNew12/01/2017Victor JulienActions
Related to Documentation #2219: Save pcap only if alertAssignedJason IshActions
Has duplicate Feature #385: Configuration option to log all known (pcap) data for a stream when an alert firesClosedCommunity TicketActions
#1

Updated by Will Metcalf almost 10 years ago

I really like this idea. Being multi-threaded it would be nice to have a pcap logging thread that supports file rotation similar to tsharks ring buffer or daemonlogger. Maybe we could even have multiple targets similar to time machine so that you could specify x mb to be written to mem (primary storage) and then have it migrated to disk (secondary) storage once you ran out of allocated space. Using this method may result in performing tasks such session extraction to be minimally invasive performance wise if you stick with the in mem buffer. It would also be nice to have flow stats as well similar to something like argus

#2

Updated by Victor Julien almost 9 years ago

  • Assignee set to Anonymous
  • Priority changed from Normal to Low

I like this idea as well, but I'm not convinced it should be part of Suricata. There are many tools that can log traffic (including Suricata in current git) and based on the alerts Suricata emits a 3rd party tool could easily extract that streams. Kind of like what Sguil does manually, but then in an automated way. My vote is to leave this to post-processing outside of Suricata.

#3

Updated by Victor Julien over 7 years ago

  • Target version set to TBD
#4

Updated by Brian Keefer over 5 years ago

Will Metcalf wrote:

I really like this idea. Being multi-threaded it would be nice to have a pcap logging thread that supports file rotation similar to tsharks ring buffer or daemonlogger. Maybe we could even have multiple targets similar to time machine so that you could specify x mb to be written to mem (primary storage) and then have it migrated to disk (secondary) storage once you ran out of allocated space. Using this method may result in performing tasks such session extraction to be minimally invasive performance wise if you stick with the in mem buffer. It would also be nice to have flow stats as well similar to something like argus

Yes to all of this. Critically though, like the original request says it's a must-have to log packets to PCAP from the stream that caused an alert. Working with barnyard2 to get this data is unwieldy. The great thing about Snort/Sourcefire is being able to use tcpdump & Wireshark to analyze payload of a stream that caused alert. Just being able to do that is bare minimum IMO.

#5

Updated by Victor Julien over 4 years ago

  • Assignee changed from Anonymous to Mathew Oldham
#6

Updated by Victor Julien about 2 years ago

#7

Updated by Victor Julien over 1 year ago

  • Assignee changed from Mathew Oldham to Anonymous
  • Effort set to high
  • Difficulty set to medium
#8

Updated by Victor Julien over 1 year ago

  • Related to Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires added
#9

Updated by Andreas Herz about 1 year ago

  • Assignee set to Community Ticket
#10

Updated by Andreas Herz 4 months ago

#11

Updated by Andreas Herz 4 months ago

Add a global rule tag keyword

#12

Updated by Victor Julien 4 months ago

  • Related to deleted (Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires)
#13

Updated by Victor Julien 4 months ago

  • Has duplicate Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires added

Also available in: Atom PDF