Suricata

Ofer Dagan wrote:

Hi all,

Currently the pcap-log feature, when configured with `conditional: alerts`, only records the "golden packet" that triggered the alert. For analysis and forensic purposes, it would be valuable to also capture surrounding packets for context.

This is not currently the case, the way it is done is that Suricata write all packets that are linked to stream and that are not yet inspected and then it starts to write to disk all packets belonging to the flow. So I will be happy to see how you just have the "golden packet" in all cases. But there is a known and sadly common case where this is happening: if you have short flow and signature only matching on application layer then as Suricata is using different buffers for application layer (than streaming one), the result is that you may have the flow all gone, streaming already all gone when the detection on application layer is processed.

Proposed Enhancement:
Add configurable context packet capture with two new options:
- `context-packets-before: N` - capture N packets before the alert packet
- `context-packets-after: N` - capture N packets after the alert packet

That looks just optimal but I fear about development complexity and performance impact. But I would love to be proven wrong.

Use Case:
This is essential for incident analysis where investigators need to see the complete flow context around an alert, not just the triggering packet. This helps understand attack patterns, data exfiltration, and protocol-level behavior.

Implementation Notes:
- Only applies to conditional logging modes (`alerts`/`tag`), not `all`
- "Before" packets stored in circular buffer during normal operation
- "After" packets tracked per-flow after alert triggers
- Maintains existing performance characteristics when context is disabled

The company I work for has a critical need for this feature and we're ready to invest development time. If there's no availability in the near term, I'm prepared to develop and maintain this feature myself, following project guidelines.

I'd appreciate feedback on the approach and any guidance on implementation preferences.

Thanks for the quick response!

But there is a known and sadly common case where this is happening: if you have short flow and signature only matching on application layer then as Suricata is using different buffers for application layer (than streaming one), the result is that you may have the flow all gone, streaming already all gone when the detection on application layer is processed.

This is very possible that what happened to me was the issue you mentioned in the beginning (the signature only on the application layer).

I'm finishing up the implementation and will open a PR so you can see for yourself the complexity it adds. I think it's relatively fine and can bring a lot of value.
Regarding the performance, how can I test it? I don't add much logic so I actually doubt it will hurt performance but for sure we should test it.