GSoc: Integrate Suricata to Cloudstack

[btzq]

Summary

Currently, Cloudstack only has ACLs (in Advanced Networks) that acts a layer of securing access to the networks (VPCs). However, these only operate in the Layer 3 and 4 of OSI Layer.

In todays day and age, where Cybersecurity threats become more advanced, complex and operate in Layer 7 OSI layer, there needs to be a way for Cloudstack to allow its own tenants to implement its own form of mature cybersecurity solution.

The problem all this while is that if a user is using a VPC or L2 Networks, 3rd party firewalls such as PFsense, FortinetVM Firewall etc cant be implemented effectively due to a lack of being able to set static routes that stays with the VR after it is recreated. There are other limitations that im not fully aware of.

There needs to be a better option for users of cloudstack to implement a deeper form of cybersecurity to protect their workloads.

Feature Request for GSoC 2025

This feature request is to integrate Suricata into Cloudstacks VPC.

Link to Suricata: https://suricata.io/

Suricata is an open source Intrusion Detection System (IDS) and Intrusion Prevention System (IPS). It is under the GPLv2 license, and is widely used. In fact, it is used by AWS to power its 'AWS Network Firewall' service.

Suricata supports the ability to be used in a form of 'Transparent Mode' which i believe is called 'Inline IPS Mode', or Bridged Mode. That way, there, there should be ideally no complex routing logic required (i hope) to implement Suricata, as the VMs will not know it exists.

By integrating Suricata in a 'Transparent Mode', it is able to run as an IPS and filter/block traffic based on the rules. And, each tenant, having set up the suricata themselves, can benefit from implementing their own rules.

Benefits To Cloudstack

• Allows Cloudstack Users to achieve a form of Layer 7 security for their VPCs
• If deployed on each VPC (VR), then suricata rules can be configured (self serviced) to apply only to their desired network without affecting other tenants (If cloud operator implements suricata on shared internet, it may negatively impact the tenants as some rules may not be suitable for specific tenants).
• If deployed in Transparent mode, there should not be a need for complex routing.
• Free Open source tool which can benefit the entire community, and increase the value proposition of Cloudstack.
• Leverage on Suricata Features such as IDS alerts, traffic inspection etc.

Expected Deliverables

• Suricata Inline (Bridge) Mode Implementation - Implementation of Suricata running inline on the Virtual Router (VR) in bridge mode, ensuring Layer 7 traffic inspection without altering the existing routing configuration.

• CloudStack UI/API Enhancements - Extend the CloudStack UI and API to allow tenants to manage their Suricata configurations, including uploading custom rules, enabling or disabling rule sets, and viewing logs/alerts.

• Configuration Persistence Mechanism - Ensure that Suricata configurations and rules persist through VR upgrades or recreations, maintaining seamless, uninterrupted security coverage for tenant workloads

Expected Outcomes

Improved security offering in Cloudstack that allows users to benefit from Layer 7 filtering capabilities using open source solutions

[Imvedansh]

@btzq @DaanHoogland I’ve been exploring CloudStack’s networking capabilities and came across the idea of integrating Layer 7 security tools like Suricata into the VPC stack. Given Suricata’s capabilities as an IDS/IPS—particularly its inline (transparent) mode—it seems like a powerful way to enhance per-tenant security in CloudStack environments.

Has there been any prior work or discussion in the community regarding such an integration? If the idea is still open, I’d be very interested in contributing to this feature

[Imvedansh]

I'm drafting the proposal. Where can I share it for your feedback? Please respond at your convenience.
This project is very much needed

[btzq]

Hey @Imvedansh , thanks for contributing to this! Im not a developer myself but im more or less familiar with Cloudstack from an admin perspective.

I strongly agree with you that Suricata in transparent mode is a no brainer, and would greatly benefit the Cloudstack Project, especially when users have their own VPCs provided by the Virtual Router.

How did you have in mind to integrate it? I remember Suricata needed quite a number of vCPUs to process traffic efficiently, which would be a problem for the VR, as its already struggling from performance issues. So, i am thinking if its better to have suricata deployed as a separate VMs? If Cloudstack has the ability for user defined static routes, i think users can pretty much set this up themselves with some additional effort.

Unless, you wanted Suricata to be part of the VR? (Just like how HA Proxy is part of the VR), so that its more automated?

[Imvedansh]

Hey @btzq ,
Yes, I agree — the best approach would be to deploy Suricata as a dedicated VM, rather than embedding it in the VR, especially since IPS/IDS workloads are resource-intensive and could negatively impact VR performance.

Here’s how I envision the high-level setup:

1)Provision a VM within CloudStack with sufficient CPU and memory resources.
2)Install a Linux OS on the VM and set up Suricata.
3)Update Suricata rules to match the tenant's security requirements.
4)Deploy Suricata in inline (transparent bridge) mode — effectively bridging traffic between the VR and the instance network.
5)Configure two NICs on the Suricata VM:
->One connected to the upstream (northbound) side (VR/public/internet).
->One connected to the downstream (southbound) side (tenant VM subnet).
6)Enable IP forwarding and bridging on the Suricata VM to allow seamless traffic flow.

For logging and alerting, tenants can integrate Suricata with their own SIEM solutions using Suricata's EVE JSON output or socket API.
..

However, as far as I understand, CloudStack does not currently support native, persistent, tenant-defined static routes inside VPCs. This presents a key challenge:

->If the VR is rebooted or re-deployed (due to scaling, upgrade, or failure recovery), any manually configured static routes
(used to steer traffic through the Suricata VM) will be lost.
->This means that while Suricata as a middlebox VM works in principle, the setup is fragile and depends on:
-Manually re-adding static routes after every VR recreation, or
-Automating the process using cloud-init, userdata, or an external automation script.

Now,
To make this more robust, we could explore a solution to implement persistent, user-defined static routing inside a VPC, possibly by extending the VR’s functionality.
This could either:

• Be scoped as a separate feature (or project) to enable route persistence per tenant, or
• Be considered as an extension of this project, making Suricata-as-a-Service inside CloudStack VPCs more reliable and easier
  to adopt.
• That said, designing and implementing a persistent static routing mechanism inside CloudStack would likely involve
  significant development effort and may need deeper discussion with the community regarding scope, feasibility, and design.

Please let me know your thoughts and any question about this.

[Imvedansh]

@btzq If we come to a decision, I can share my proposal with you so you can provide your insights. Also, could you please share your email so I can reach out to you directly?.

[btzq]

@Imvedansh , your proposal above actually opens alot of doors, not just to Suricata.

If Suricata is able to be implemented based on your suggestion, other Virtual Network Appliances such as Layer 7 VM Firewalls (Fortinet VM) and many other can be added while using a VPC. This is something we've needed for a long time!.

I actually started a discussion here:

#9158
#9424

But if remember correctly, there was a video by Shapeblue mentioning about enhancing VPC to support User Defined Static Routes? @weizhouapache did i remember that correctly?

As for the proposal, sure id love to help bounce some ideas, but im more of the admin side of cloudstack, not a programmer. The benefit of having the discussion here is that @weizhouapache @DaanHoogland and others could chip in too!

[Imvedansh]

@btzq @DaanHoogland @weizhouapache

Hi,

I think we can adopt the approach where all conditional traffic from the Virtual Router (VR) is forwarded to a dedicated IDS/IPS VM. Additionally, we could build a unified UI within the VR to allow users to define conditions for traffic forwarding.

As far as I know, you prefer Suricata—an open-source IDS/IPS licensed under GPLv2. It offers a solid, cost-effective alternative to vendor solutions like FortiGate or Palo Alto, which involve significant licensing costs.

That said, I’d appreciate some clarity on what exactly I should propose in the GSoC proposal. Should I proceed with this broader approach, or would you suggest any refinements or alternative directions that I can incorporate?

[btzq]

@Imvedansh , although suricata is a great open source solution, i think we shouldnt limit it strictly to suricata. We should allow basically any network appliance to be used.

VNFs are already supported in cloudstack. What it doesnt have is the ability to place it before the VR and set static routes. Thats where the user defined static routes come in to play.

So the scope of this proposal should be to enhance cloudstack to allow VNF to transparently route traffic to the virtual router using user defined static routes, on a per vpc basis. Its also important that cloud operators shouldnt need to get involved in this setup as much as possible. It should be self serviced.

[Imvedansh]

@btzq I agree ,we shouldn’t limit ourselves to just Suricata.
Based on our discussion and my understanding, here’s a draft of the problem statement and objective. Could you please review and confirm if you're aligned with this? Once approved, I’ll move forward with drafting and submitting the proposal.

Problem Statement
While CloudStack supports Virtual Network Functions (VNFs), it currently lacks native support for transparently inserting VNFs before the Virtual Router (VR) in the traffic flow. This limitation hinders advanced use cases such as traffic inspection, monitoring, and policy enforcement using custom appliances or third-party IDS/IPS systems.

Objective
Enhance CloudStack’s VPC networking model to allow users to insert a VNF transparently before the VR, ensuring traffic flows through the VNF first and then to the VR. This should be achieved using user-defined static routes, and designed to be self-serviceable by tenants (wherever feasible), reducing dependency on operator-level configuration.

[weizhouapache]

But if remember correctly, there was a video by Shapeblue mentioning about enhancing VPC to support User Defined Static Routes? @weizhouapache did i remember that correctly?

Hi @btzq @Imvedansh

Yes, we have implememted thje enhancement as part of a new feature
https://cwiki.apache.org/confluence/display/CLOUDSTACK/VPN+solutions+for+SDN+networks

We have not created a PR yet.

[Imvedansh]

@weizhouapache @btzq Thanks for sharing the VPN solution link. I believe it aligns with the goal of enabling user-defined static routes, which is part of the problem we’re addressing.

However, the solution described in the link doesn’t appear to cover transparent insertion of IDS/IPS (like Suricata) . It seems more aligned with general routing, rather than deep packet inspection or advanced security use cases.

What’s your advice? Should I proceed with the proposal for transparent VNF insertion (with IDS/IPS focus), or do you feel this requirement is already addressed and no longer needed?

Looking forward to your thoughts.

[Imvedansh]

So I did a little more digging, it does not comprehensively solve IPS/IDS issue,Scope for it persistent, what i can do is propose accordingly . If Topic is still up for Gsoc,

[weizhouapache]

@weizhouapache @btzq Thanks for sharing the VPN solution link. I believe it aligns with the goal of enabling user-defined static routes, which is part of the problem we’re addressing.

Yes, the link is linked to the user-defined static routes.
It might be helpful for the integration of Suricata.

However, the solution described in the link doesn’t appear to cover transparent insertion of IDS/IPS (like Suricata) . It seems more aligned with general routing, rather than deep packet inspection or advanced security use cases.

What’s your advice? Should I proceed with the proposal for transparent VNF insertion (with IDS/IPS focus), or do you feel this requirement is already addressed and no longer needed?

Looking forward to your thoughts.

I suggest you to do some proof of concept, and share the diagram with more setings like

• gateway/source nat
• routing and routes
• incoming/outgoing traffic flows

[btzq]

@Imvedansh im all for continuing this enhancement to support VNF in transparent mode before the VR. This will greatly address the needs of many enterprise companies. Just a quick look online and youll see loads of creative cyberattacks evolving daily.

How should we continue this?

@Imvedansh if youd like, i can send the draw.io which i used to draw the diagrams in #9424. You got an email?

We could bounce some ideas there too

[Imvedansh]

Thanks @btzq really glad to hear your support for continuing this enhancement! I completely agree — with the rise of sophisticated cyberattacks, having a transparent VNF before the VR could be a game-changer for enterprise-grade security use cases.

Yes, I’d love to see the draw.io diagrams you mentioned from #9424 — that would really help me visualize the architecture better. You can send them over to [email protected] .
Happy to collaborate and bounce ideas over email too!

Looking forward to it!

[DaanHoogland]

@Imvedansh @btzq , you triggered an issue from project management perspective: "Suricata—an open-source IDS/IPS licensed under GPLv2". This could be possible if we allow for a separate installation, but not if we (have to) call any libraries distributed under gplv2. The licensing is incompatible (see https://www.apache.org/licenses/GPL-compatibility.html)

please keep this in mind in your design.