Suricata: Add BPF filtering

[0xThiebaut]

Add support for BPF filtering.

This feature can be employed to avoid amplification if Suricata logs are exported (for example, using #8450).

[AdSchellevis]

@0xThiebaut I'm not sure about this to be be honest, bpf filters are highly sensitive and influence which traffic will be evaluated at all (not only the information feed). When trying to reduce the logging feed, it might be better to filter the input of the receiving end or the mechanism used to ship it somewhere.

[0xThiebaut]

@AdSchellevis I realize BPF filters are sensitive (hence the field flagged as advanced) but they play an important role in avoiding noise and amplifications generated by log and PCAP transports. The long-term goal I want to achieve is to permit using OPNsense as a proper network sensor to provide functionality close to CISA's Malcolm which ships Suricata events and PCAPs (something I plan on PR'ing soon).

Without a BPF filter, any PCAP shipped to a secondary appliance will be recorded and shipped in a continuous loop.

In Malcolm as well, their sensors recommend using a BPF filter to avoid "loops" where we record the sensor's own communications.

A similar pattern (not yet amplifying) can be observed when using opnsense/plugins#4591 to ship Suricata events, where a "quiet" appliance will still record its own reporting traffic in a loop.

Without a BPF filter, local PCAP processing will be required to filter out reporting traffic, which results in a DIY BPF filter.

[AdSchellevis]

flagging a field as advanced won't stop users from offering faulty input I'm afraid. From their command line setup I understand why they opt for bpf filters, in reality on our end this will cause a maintenance nightmare. Logically, I would expect you can filter these events also out from your logging pipeline, in which case you would move the issue to a more logical place.

[0xThiebaut]

I admit I didn't take the support nightmare into account. On the other hand, moving the logic to after the capture can introduce some additional challenges where either the filtering logic will need to happen on the OPNsense appliance or appliances fetching the PCAPs (e.g., scp) will need to execute some remote filtering.

Would an acceptable compromise be to have the user provide an IPPortField and, in the configuration, convert this into a BPF filter we control? This would remove the risk associated with bad BPF expressions while still allowing proper filtering on capture-level.

[AdSchellevis]

I'm not sure, but also doubt a bit why filtering within filebeat (the linked PR) would be problematic.

[0xThiebaut]

Hi @AdSchellevis , apologies for not being clear. Exporting the logs (e.g., through Filebeat) generates noise but no amplification. However, when relying on the Suricata PCAP feature (#8450), exporting those could generate amplification, which is typically prevented through a BPF filter.

[AdSchellevis]

@0xThiebaut you are aware that we already have an included packet capture in OPNsense? I'm not sure this is a direction we should be heading as it will lead to a lot more work and regressions later

[0xThiebaut]

@AdSchellevis I'm aware of Diagnostics: Packet capture, but unless I am mistaken this is not something designed to run continuously (rotating files, capture across reboots, ...)?

[L1ghtn1ng]

@0xThiebaut what ad is saying is there is an option in the ui for suricata in the suricata settings page where you can enable pcap output that is just a checkbox. I have this enabled myself so I think that is what ad means?

[L1ghtn1ng]

It's in the advanced menu of suricata and it's called log package payload

[AdSchellevis]

@AdSchellevis I'm aware of Diagnostics: Packet capture, but unless I am mistaken this is not something designed to run continuously (rotating files, capture across reboots, ...)?

Continuously running shouldn't be an issue, but it's designed to inspect targeted traffic indeed. Knowing the work needed to make that feature useable, I'm pretty sure I don't want to redo that again. Adding a flag in suricata is the easy part. If people want to use pcaps with suricata, custom includes should likely work.

[0xThiebaut]

It's in the advanced menu of suricata and it's called log package payload

@L1ghtn1ng Unless I am mistaken, that feature is only for payloads matching rules; It doesn't cover full and continuous PCAP logging.

Continuously running shouldn't be an issue, but it's designed to inspect targeted traffic indeed. [...] Adding a flag in suricata is the easy part. If people want to use pcaps with suricata, custom includes should likely work.

@AdSchellevis I might be trying to solve an issue in the incorrect place. If I want full continuous packet capture of OPNsense traffic (including WireGuard -> OPNsense -> WireGuard), what would the recommended setup be?

Most solutions I can think of are "custom" and not persisted within the OPNsense configuration.

PS: Your patience is much appreciated!

[AdSchellevis]

@0xThiebaut I expect you can add a persistent custom configuration for captures using the instructions described here https://docs.opnsense.org/manual/ips.html#advanced-configuration. I'm not saying suricata isn't the right tool for the job, just that functionality (partially) overlaps with what we are already offering, it also will need a lot of work to bring it to a functional state where you don't need the console to use it, which is a maintenance burden we are not willing to take.

Extending the current packet capture option to fit your use-case might be easier, but also brings quite some work (and/or guidance) which won't fit our community support time.

[0xThiebaut]

Thanks for the transparency! I'll close the related PRs and will consider using a custom plugin or working on extending the current capture functionality.