Project

General

Profile

Actions

Feature #120

closed

Capture full session on alert

Added by Dave Smith over 12 years ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
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 6 (4 open2 closed)

Related to Task #2309: SuriCon 2017 brainstormAssignedVictor JulienActions
Related to Documentation #2219: Save pcap only if alertClosedActions
Related to Task #4097: Suricon 2020 brainstormAssignedVictor JulienActions
Related to Bug #5189: Suricata alerts pcap issue FeedbackChatak KumarActions
Related to Bug #5374: pcap-log: breaking change in file namesNewOISF DevActions
Has duplicate Feature #385: Configuration option to log all known (pcap) data for a stream when an alert firesClosedCommunity TicketActions
Actions #1

Updated by Will Metcalf over 12 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

Actions #2

Updated by Victor Julien over 11 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.

Actions #3

Updated by Victor Julien about 10 years ago

  • Target version set to TBD
Actions #4

Updated by Brian Keefer about 8 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.

Actions #5

Updated by Victor Julien almost 7 years ago

  • Assignee changed from Anonymous to Mathew Oldham
Actions #6

Updated by Victor Julien over 4 years ago

  • Related to Task #2309: SuriCon 2017 brainstorm added
Actions #7

Updated by Victor Julien about 4 years ago

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

Updated by Victor Julien about 4 years ago

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

Updated by Andreas Herz over 3 years ago

  • Assignee set to Community Ticket
Actions #10

Updated by Andreas Herz almost 3 years ago

Actions #11

Updated by Andreas Herz almost 3 years ago

Add a global rule tag keyword

Actions #12

Updated by Victor Julien almost 3 years ago

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

Updated by Victor Julien almost 3 years ago

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

Updated by Victor Julien almost 2 years ago

  • Status changed from New to In Review
  • Assignee changed from Community Ticket to Scott Jordan
  • Target version changed from TBD to 7.0rc1
Actions #15

Updated by Jason Ish over 1 year ago

  • Related to Task #4097: Suricon 2020 brainstorm added
Actions #16

Updated by Jason Ish 5 months ago

  • Related to Bug #5189: Suricata alerts pcap issue added
Actions #17

Updated by Chatak Kumar 5 months ago

Tried with latest version also https://github.com/OISF/suricata/pull/6941
But issue in packets formed by suricata alert pcap
I tried with this pcap https://www.malware-traffic-analysis.net/2021/07/14/index.html
Check http only in wireshark and compare with Suricata log.pcap . We can see Info/header is truncated which makes hard to understand.

Actions #18

Updated by Jason Ish 3 months ago

  • Related to Bug #5374: pcap-log: breaking change in file names added
Actions #19

Updated by Victor Julien 2 months ago

  • Status changed from In Review to Closed
  • Priority changed from Low to Normal
  • Effort deleted (high)
  • Difficulty deleted (medium)
Actions

Also available in: Atom PDF