Feature #120
closed
Capture full session on alert
Added by Dave Smith about 14 years ago.
Updated almost 2 years ago.
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.
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
- 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.
- Target version set to TBD
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.
- Assignee changed from Anonymous to Mathew Oldham
- Related to Task #2309: SuriCon 2017 brainstorm added
- Assignee changed from Mathew Oldham to Anonymous
- Effort set to high
- Difficulty set to medium
- Related to Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires added
- Assignee set to Community Ticket
- Related to Task #2219: Save pcap only if alert added
Add a global rule tag keyword
- Related to deleted (Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires)
- Has duplicate Feature #385: Configuration option to log all known (pcap) data for a stream when an alert fires added
- 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
- Related to Task #4097: Suricon 2020 brainstorm added
- Related to Bug #5189: Suricata alerts pcap issue added
- Related to Bug #5374: pcap-log: breaking change in file names added
- Status changed from In Review to Closed
- Priority changed from Low to Normal
- Effort deleted (
high)
- Difficulty deleted (
medium)
Also available in: Atom
PDF