Task #2693
Updated by Jason Ish 2 months ago
This request came up at Suricon2018, but has come up before. The idea is to turn much of Suricata into a library that can be reused in other tools.
The first step would be to define some of the use cases we'd like to initially support so that an API could be designed for that.
Goals for 8.0:
- Allow a library user to replicate the Suricata application by exposing all functions needed by the current SuricataMain, or refactoring to allow this.
- Given replication of Suricata, allow the library user to register custom capture modes and output callbacks
- Allow the user to bring their own threads
General library challenges given we've been an application for so long:
- Command line parsing should be opt-in
- Loading the configuration file should be opt-in
- Registering signal handlers should be opt-in, but the functionality they provide should be exposed to the library user can easily call them
- A library should never fatal exit outside of extreme conditions, instead error codes must be ripple back to where the library user can decide what to do
- Global state should be non-existent. One could imagine where a user might want to have a "handle" on multiple discrete Suricata instances.
Future goals:
- Remove global state
- Improve developer experience. I imagine an interface where you bootstrap a Suricata "engine" and feed your own packets into
- Refactor modules to make them more usable outside the scope of Suricata? What modules would make sense here? Capture methods, just to get packets. Flow, to defrag, or TCP re-assembly if you already have your own packets.
Scope:
- Initially, the should be limited to code that Suricata uses itself. That is, Suricata the application is a user of the library. If Suricata the application does not use a module, it should be looked at closely if it belongs in the library, mainly for scope, QA, and support reasons.