Project

General

Profile

Actions

Feature #120

closed

Capture full session on alert

Added by Dave Smith about 14 years ago. Updated almost 2 years 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 (2 open4 closed)

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

Updated by Will Metcalf about 14 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 almost 13 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 over 11 years ago

  • Target version set to TBD
Actions #4

Updated by Brian Keefer over 9 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 over 8 years ago

  • Assignee changed from Anonymous to Mathew Oldham
Actions #6

Updated by Victor Julien over 6 years ago

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

Updated by Victor Julien over 5 years ago

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

Updated by Victor Julien over 5 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 about 5 years ago

  • Assignee set to Community Ticket
Actions #10

Updated by Andreas Herz over 4 years ago

  • Related to Task #2219: Save pcap only if alert added
Actions #11

Updated by Andreas Herz over 4 years ago

Add a global rule tag keyword

Actions #12

Updated by Victor Julien over 4 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 over 4 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 over 3 years ago

  • Status changed from New to In Review
  • Assignee changed from Community Ticket to Scott Jordan
  • Target version changed from TBD to 7.0.0-beta1
Actions #15

Updated by Jason Ish over 3 years ago

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

Updated by Jason Ish about 2 years ago

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

Updated by Chatak Kumar about 2 years 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 almost 2 years ago

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

Updated by Victor Julien almost 2 years 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