Feature #120
closedCapture full session on alert
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.
WM Updated by Will Metcalf about 16 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
VJ Updated by Victor Julien about 15 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.
VJ Updated by Victor Julien almost 14 years ago
- Target version set to TBD
BK Updated by Brian Keefer over 11 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.
VJ Updated by Victor Julien over 10 years ago
- Assignee changed from Anonymous to Mathew Oldham
VJ Updated by Victor Julien over 8 years ago
- Related to Task #2309: SuriCon 2017 brainstorm added
VJ Updated by Victor Julien over 7 years ago
- Assignee changed from Mathew Oldham to Anonymous
- Effort set to high
- Difficulty set to medium
VJ Updated by Victor Julien over 7 years ago
- Related to Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires added
AH Updated by Andreas Herz about 7 years ago
- Assignee set to Community Ticket
AH Updated by Andreas Herz over 6 years ago
- Related to Task #2219: Save pcap only if alert added
AH Updated by Andreas Herz over 6 years ago
Add a global rule tag keyword
VJ Updated by Victor Julien over 6 years ago
- Related to deleted (Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires)
VJ Updated by Victor Julien over 6 years ago
- Has duplicate Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires added
VJ Updated by Victor Julien over 5 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
JI Updated by Jason Ish over 5 years ago
- Related to Task #4097: Suricon 2020 brainstorm added
JI Updated by Jason Ish about 4 years ago
- Related to Bug #5189: Suricata alerts pcap issue added
CK Updated by Chatak Kumar about 4 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.
JI Updated by Jason Ish almost 4 years ago
- Related to Bug #5374: pcap-log: breaking change in file names added
VJ Updated by Victor Julien almost 4 years ago
- Status changed from In Review to Closed
- Priority changed from Low to Normal
- Effort deleted (
high) - Difficulty deleted (
medium)