Feature #7786
openEnhance --pcap-file-delete to Conditionally Delete PCAPs Based on Alerts
Description
Hello Suricata Team,
I would like to suggest a new feature that enhances the functionality of the `--pcap-file-delete` command-line option.
Use Case
In my organization, we analyze a high volume of pcap files that are constantly coming in. When an alert is raised, we need to keep the corresponding pcap for further analysis. The current challenge is that we must keep all pcaps around until we can confirm whether an alert was generated for them, which quickly exhausts our in-memory storage.
This feature would allow us to clear storage much faster by automatically deleting pcaps that do not trigger alerts.
I initially explored using the pcap-log feature to solve this, but that approach has its own challenges, as detailed in this ticket: https://redmine.openinfosecfoundation.org/issues/7785
Suggested Implementation
To maintain a clean command-line interface, this feature could be controlled by a new configuration option in suricata.yaml that modifies the behaviour of the existing `--pcap-file-delete` flag:
pcap-file:
# ... existing options
# If true, --pcap-file-delete will only remove pcaps that have
# generated no alerts.
delete-no-alerts-only: false
I would be happy to implement this feature myself to help move it forward. I believe it would also be a great introductory issue for a first-time contributor like myself to get more familiar with the Suricata development process.
Updated by Ofer Dagan 5 days ago
What do you mean with integrating with our pcap-log? It should have no affect on the pcap-log output.
Each packet now holds a pointer (p->pcap_v.shared) to its reader-thread’s PcapFileSharedVars, letting Detect threads atomically bump alerts_total (a new counter); we snapshot that counter at file open and compare at file close — if the delta is zero, the pcap raised no alerts. What do you think about this solution?
Updated by Ofer Dagan 5 days ago
I've opened a PR with the suggested solution - https://github.com/OISF/suricata/pull/13528
Let me know if you want me to implement it in a different way.
Updated by Jason Ish 5 days ago
Ofer Dagan wrote in #note-3:
What do you mean with integrating with our
pcap-log? It should have no affect on thepcap-logoutput.
Each packet now holds a pointer (p->pcap_v.shared) to its reader-thread’sPcapFileSharedVars, letting Detect threads atomically bump alerts_total (a new counter); we snapshot that counter at file open and compare at file close — if the delta is zero, the pcap raised no alerts. What do you think about this solution?
Sorry, I jumped here right after reading #7785 and read this feature all wrong.