Introducing Suricatavel: Governance platform for Suricata

Community Announcements
1

Hi everyone !

Today I would like to introduce Suricatavel, a tool to manage a distributed fleet of Suricata sensors without “fumbling with cables”, but in a clear, measurable and repeatable operation, which should ease managing it at scale by reinforcing consistency and reducing configuration drifting.

This solution is based on 3 pillars:

  • Automated lifecycle
    • Leveraging Ansible, we intend to reduce time to detection for new nodes, from initial provisioning to atomic ruleset management, all from the same web interface.
    • Rule management is conveyed from feeds to automatic deployment on each node through configurable policies.
  • High-performance ingestion
    • Prepared for high throughput of events, we offer an inhouse-built logging agent, which guarantees correct behaviour even during saturation peaks.
    • For enterprise-level loads, we baked in Apache Kafka integration (“at-least-once” delivery), for deployments that need even more delivery performance.
    • Our ingestion pipeline relies on Laravel Octane to handle massive eve.json event streams with low latency.
  • Actionable intelligence and response
    • Enrichment providers bring automatic metadata decoration vía known services such as AbuseIPDB, MaxMind’s GeoIP, URLHaus, Shodan, VirusTotal and WHOIS.
    • A dedicated query engine delivers results in nearly instantaneous time (sub-second), helping analysts investigations and correlations.
    • Firewall integrations with popular products like OPNSense, pfSense or even OpenWRT allow the user to rapidly block an attacker from within the web interface.

This project is under active development, so stay tuned to find out news to come !

Poke around the demo and explore what else Suricatavel has to offer: https://demo.suricatavel.org

Get your nose into the docs: https://docs.suricatavel.org

2

Is this a commercial offering?
Is there an open source project?

Having built a similar system around ansible I was curious to explore your art and look for opportunities to make a meaningful contribution but alas I seem to be blocked by cloudflare regardless of browser, JS support, tracking cookie acceptance, or geo (tried north and south america).

3

It’s not a commercial offering at this stage, but it’s also not open source.

Suricatavel is source-available: the code can be downloaded and used freely for personal, research, and evaluation purposes. Commercial use would currently require a separate license.

Right now I’m keeping development centralized while the project evolves, but I’m very interested in feedback from the community, will consider open-sourcing it in the future.

Now, I’ve checked Cloudflare to relax security a bit, please try again and feel free to reach me directly to get this access issue sorted out :slight_smile:

4

Interesting direction.

We already operate Aegis in our environment, and we have also implemented DNS control through Cloudflare Zero Trust using DoH/Gateway-based enforcement. In practice, that gives us centralized DNS policy control, category-based filtering, and a cleaner way to standardize protection across distributed users and sites.

So I’m looking at Suricatavel from the standpoint of an existing production environment where core security controls and operational workflows are already in place, rather than from a greenfield deployment.

The three pillars you highlight — lifecycle automation, high-throughput ingestion, and integrated response — are absolutely the right areas to focus on for distributed Suricata operations. The main question for teams like ours is how Suricatavel differentiates itself operationally from a stack that already combines Aegis, centralized policy enforcement, and established automation.

What would be especially valuable to see is:

  • how policy-based rule deployment is governed across larger sensor fleets,

  • how the ingestion layer behaves under sustained load and degraded conditions,

  • how much operational visibility and auditability exist around automated changes,

  • and how the response model integrates with existing DNS/security enforcement layers already in production.

Promising concept overall. For mature environments, adoption will likely depend on whether the platform can demonstrate measurable gains in consistency, scalability, and response efficiency beyond what is already achievable with a well-integrated internal stack.

image
image2504×1191 364 KB

1 Like
5

Thanks for the detailed feedback — this is exactly the kind of perspective I was hoping to get.

Your setup with Aegis is actually a very good example of the kind of environment where Suricatavel would need to fit. It provides a SOC-style architecture, aggregating multiple layers (DNS, Suricata, Zeek, WAF, etc.) into a centralized event stream and orchestration layer, so our goal wouldn’t be to replace that, but to complement it -specifically at the Suricata layer-.

The way I see Suricatavel fitting into a stack like yours is as a dedicated operational layer for Suricata itself, sitting alongside Aegis rather than competing with it. Following your key points:

  • Lifecycle & fleet management: Suricatavel is targeted to manage Suricata sensors at scale — consistent rule deployment, configuration versioning consistence and controlled rollouts across distributed nodes, even updating Suricata version.

  • Ingestion shaping before aggregation: instead of replacing Aegis’ unified event bus, Suricatavel can act upstream — handling high-throughput EVE streams, filtering/enriching events, and making this avabilable through API to feed existing pipelines.

  • Response integration, not duplication: in an environment already using DNS enforcement or automated blocking, the idea is for Suricatavel to trigger those existing controls (via APIs, workflows or direct ingtegrations, etc.), not replicate them. As of now, we can trigger actions through policies, so we could explore on that direction.

Regarding performance: during development, the ingestion layer was battle-tested under sustained high event rates (thousands of events/sec) on limited hardware like a RaspberryPi 5, mainly to validate stability. That said, I fully agree that the real validation comes from production environments, where traffic patterns and failure modes are much more complex.

Finally, observability and auditability are core design goals. One of the problems we are trying to address is making the Suricata layer itself more transparent — what rules changed, how they were deployed, and how automated actions were triggered — especially when operating at scale.

So in short, as of now I don’t see Suricatavel as an alternative to Aegis, but as something that can tighten and add value to the Suricata layer inside an already working stack.

6

Thanks, that clarification helps.

I agree that Suricatavel makes more sense as a complementary Suricata operational layer rather than an Aegis replacement. In our case, Aegis already handles the broader SOC-style aggregation and orchestration, while DNS control and enforcement are also centralized through Cloudflare Zero Trust / DoH.

So the most valuable role for Suricatavel would be to strengthen the Suricata layer itself: rule lifecycle management, consistent configuration across sensors, controlled rollout, event filtering/enrichment before ingestion, and clear auditability for automated actions.

For response, I would prefer Suricatavel to trigger existing controls through APIs or policies instead of duplicating enforcement. For example, it could send enriched Suricata context into Aegis or trigger Cloudflare/Aegis workflows, while the actual blocking remains handled by the existing platform.

Overall, I think the direction is promising as long as Suricatavel remains focused on Suricata operations and integrates cleanly with platforms like Aegis, Cloudflare Zero Trust, SIEM, SOAR, or internal response systems.

7

That aligns very closely with the direction I’m trying to take.

One of the latest additions to Suricatavel is a feature called Policies (already available on demo) which is essentially intended to cover that “trigger existing controls instead of replacing them” model you described.

Policies allow defining conditions based on incoming events and then triggering actions when those conditions are met. For example:

  • receiving a Suricata alert with severity = 1

  • an IOC score signals a potential risk

Right now, the available actions are:

  • Jira ticket creation through Jira API

  • generic webhook execution with JSON payload delivery

Both actions support templating through Twig syntax, so users can dynamically build requests using event context and metadata before forwarding them to external systems.

The idea is precisely to avoid hardcoding enforcement logic into Suricatavel itself, and instead make it capable of integrating with already established platforms and workflows.

Your scenario with AEGIS SOC is particularly interesting in that regard. From what I understand, Aegis already acts as a centralized orchestration and aggregation layer, so I’d be interested to know more about its integration surface and automation model:

  • Does Aegis expose APIs or webhook ingestion endpoints suitable for this kind of event forwarding?

  • Are response workflows externally triggerable?

  • Would a templated webhook/Jira-style mechanism fit into how Aegis expects integrations to behave?

That would help me better understand whether the current Policies model aligns well with mature SOC-style environments like yours, or whether additional integration patterns would be needed :slight_smile:

8

Thanks Jorge, that makes sense.

Yes, this Policies model sounds aligned with how we would expect this kind of integration to work.

In our current architecture, Aegis acts as the central SOC orchestration and aggregation layer, so most response workflows are handled there rather than directly inside each detection component.

From an integration perspective, the ideal model would be for Suricatavel to forward enriched Suricata context into Aegis through API/webhook-style mechanisms. A templated JSON webhook would fit well, especially if the payload can include structured fields such as alert metadata, severity, source/destination, rule information, IOC score, sensor identity, policy/action ID, and enrichment results.

Suricatavel would not need to perform the final enforcement action itself. It could send the enriched event or trigger request to Aegis, and Aegis would then decide whether to involve Cloudflare Zero Trust, SIEM/SOAR workflows, ticketing, blocking, notification, or other internal response actions.

For us, the most important part is that Suricatavel remains focused on the Suricata operational layer: rule lifecycle management, configuration consistency, controlled rollout, event filtering/enrichment, auditability, and reliable forwarding. The actual enforcement and broader SOC automation should remain inside Aegis, where centralized policy, correlation, approval, and response logic already exist.

So yes, the current Policies direction looks like a good fit. The generic webhook with templated JSON is a strong starting point. Additional value would come from retry handling, delivery status, audit logs, payload validation, signed webhooks or shared-secret authentication, dry-run mode, and maybe predefined integration templates for platforms like Aegis, Cloudflare, SIEM, SOAR, or Jira.

Overall, I think this is the right approach: Suricatavel acts as a strong Suricata operations and integration layer, while mature SOC platforms like Aegis continue to handle orchestration, correlation, and enforcement.