Extend Suricata support

[0xThiebaut]

Extend Suricata support in OPNsense to increase the monitoring capabilities (e.g., integrate with Malcolm)

Features:

• Extend support for EVE log, supporting all available protocols (RDP, DNS, ...).
• Add support for PCAP logs.

Subsequent changes:

• Update configuration template to align with Suricata 7.0.8 (e.g., add new fields such as ja4).
• Disable stats.log (stats can be enabled in EVE).
• Add migration logic.

[0xThiebaut]

Thanks for the reviews so far!

I get that every help or label string I change bounces the translations of other languages, which we typically want to avoid. However I believe the benefit of properly (re)naming the options and help messages will benefit the users on the long run as the current strings are not consistent and occasionally obscure or incorrectly translated (e.g., Output TLS transaction where the session [...] is translated to French as Exit a TLS transaction where a session [...]).

I'd love to refactor the IDS UI strings to have them be consistent and helpful for the users (instead of requiring them to find the equivalent features in the Suricata documentation). I'd obviously be happy to perform the French translations on any bumped string.

[Monviech]

If you limit this PR only to the new functionality you want to add it will be simpler to review.

If you want to change existing language strings it could be in a separate PR after this one.

[0xThiebaut]

Thanks for the feedback; I rolled-back any rewording not related to the new features.

[Monviech]

Just asking but isn't there a way to add the new features that you need inline without needing a migration or altering existing options? That would make reviewing far easier and we could still move settings around later.

Migrations are always a risk due to possible impacts on existing installations.

[0xThiebaut]

We definitely could add it without a migration; I focused on having a reasonable code-base with pleasant UI but if avoiding a migration is a priority I can add the new features without requiring a migration.

Could you confirm you'd prefer this? This would involve having a drop-down for new protocol types (e.g.,DNS) while retaining check boxes for already-supported log types (i.e., HTTP & TLS).

This wouldn't be consistent but would avoid the need for a migration.

[Monviech]

I prefer not having a migration here.

@fichtner whats your opinion?

[fichtner]

We don't have this policy in place (yet) but it would be a very good idea to either only introduce new changes or only move existing data, but not both in the same PR. This is beneficial in reducing risk of regression and considering backporting. On top of that suricata.yaml has broken a few times already so you have that risk as well on top.

[0xThiebaut]

Alright, with that guideline I'll make the necessary modifications to have this PR introduce the required functionality without it involving a migration.

I'll leave the refactoring for better UX for a later time.

[Monviech]

Is it really necessary to alter the model like that? Can't we go for a minimal impact approach first?