Suricata inline before the Apache CloudStack Virtual Router
Category: Public Cloud · For: operators of Apache CloudStack, KVM and virtual networks · Reading time: 9 min
At a glance
- We placed Suricata in the KVM bridge traffic path, before packets reach the Apache CloudStack Virtual Router.
- The mechanism covers all traffic passing through the protected bridge, and the rules currently operate in alerting mode.
- Queue state, traffic, telemetry and alerts are visible in monitoring, and failure behaviour is explicitly defined.
Apache CloudStack keeps the orchestration layer clearly separated from tenant networks. This is one of its greatest strengths, but it also leaves the operator with a deliberate choice of traffic inspection point. Protection placed too high in the stack sees only part of the communication. Protection placed too low makes hosts harder to operate and can complicate failure diagnosis.
At WebDisk, we chose a point between the physical uplink and the Virtual Router: the KVM bridge serving the public network. Suricata runs inline there, so each packet passes through the analysis engine before reaching the CloudStack virtual infrastructure. This keeps the solution close to the hypervisor, covers one clearly identified path and requires no changes to customer machines.
Where did we place traffic inspection?
In a typical CloudStack zone, the Virtual Router provides network services including NAT, routing and firewall rules. Traffic to that router passes through a Linux bridge on the KVM host. This bridge provides a place to add inspection while retaining the standard CloudStack model.
In practice, a rule in the bridge layer sends packets to an NFQUEUE queue. The Suricata process receives them, analyses them and returns a verdict to the network stack. CloudStack continues to manage the Virtual Router and tenant networks, while the protective layer remains the responsibility of the hypervisor operator.
This inspection point is attractive for three reasons. First, it covers traffic before the Virtual Router services process it. Second, it requires no agent in guest systems. Third, its scope can be tied to a specific bridge instead of capturing all host traffic.
How does inline mode differ from passive observation?
A passive sensor receives a copy of the traffic. It can detect and report events, but it is not in the packet path. It is useful for analysis, although its availability does not determine network availability.
An inline unit is part of the path. A packet enters the queue and returns to the bridge only after the process has handled it. This makes it possible to enforce verdicts, but requires much more careful management of the lifecycle, overload and process failures. Starting Suricata alone is not enough: resource limits, queue ownership checks, a watchdog, unambiguous cleanup and telemetry confirming that the path still works are all needed.
In our deployment, the passive service was disabled to prevent two competing observation models from running on the same host. The inline unit and its state monitor are the source of truth.
What does the solution's lifecycle look like?
Most of the work was not in the rule that directs traffic to NFQUEUE. What mattered was giving the engine a predictable lifecycle: from validating the configuration and taking ownership of the queue to safely removing the rule on shutdown.
The system unit has a limited CPU, memory and process budget. The monitor checks whether the queue listener exists, traffic counters are increasing, telemetry is fresh, and kernel or process drops have occurred. A degraded state is latched, so a brief event does not disappear simply because the next reading looks healthy.
Shutdown is just as important. The rule directing traffic to the queue must be removed when the process can no longer serve it. Otherwise, the operator may see an apparently healthy system service alongside a dead packet path. Cleanup therefore belongs to the same responsibility as startup.
What does alerting mode mean?
The engine has a detection ruleset loaded, but the active set contains no DROP rules. Each match produces an event, while the packet is not blocked on the basis of the signature. This is a deliberate operational configuration: we first establish a picture of real traffic and signal quality before enforcing a blocking policy.
Alerting mode does not change the fact that Suricata runs inline. Packets still pass through the queue and engine. The difference is in the verdict after analysis: the current rules observe and describe traffic rather than reject it.
This approach lets us assess false positives, load and protocol coverage using real traffic. A blocking rule can later be introduced as a separate, measurable change, with an owner, a rollback criterion and verification of its effect.
What do we see in monitoring?
The process being active would be too weak a piece of evidence on its own. Monitoring combines several independent signals:
- unit state and restart count — whether the process is running stably;
- presence of an NFQUEUE listener — whether the queue has a consumer;
- nftables rule counter — whether traffic is actually reaching the inspection point;
- pending packets and kernel/user drops — whether the queue is losing packets;
- telemetry freshness — whether the monitor is reporting the current state;
- alert and DROP rules — which enforcement mode is actually active;
- CPU and memory — whether protection stays within its assigned budget.
Four alerts group availability problems, data loss in the queue, degraded state and missing telemetry. The operator can therefore see both a process failure and a situation where the process exists but has stopped fulfilling its role.
What matters most to a CloudStack operator?
The first lesson is to protect a specific path rather than an abstract “host”. The public bridge is a boundary that can be described, measured and have its protection rolled back without touching tenant machines. Each host's topology must still be verified: device names and the way Virtual Routers are connected should not be taken on trust.
The second lesson concerns ownership. A single unit should be responsible for the nftables rule, the NFQUEUE listener, the Suricata process and cleanup. Separating these elements without a shared supervisor increases the risk that part of the path remains active after another part fails.
The third lesson is that observability is part of the security function. An increasing traffic counter, no drops, fresh telemetry and the expected rule count provide a much better picture than a single systemd status.
The fourth lesson is to state the boundaries explicitly. Analysing encrypted traffic does not expose application content without TLS termination. Protecting the public bridge does not automatically cover east-west traffic on other networks. Queue behaviour during a failure is an architectural choice, not something to leave to chance.
How can you start a similar deployment?
- Draw the actual packet path from the host interface to the Virtual Router.
- Select one bridge and verify its role by reading the configuration and counters.
- Run Suricata with a separate profile and a clearly defined queue.
- Bind the nftables rule, listener, monitor and cleanup into one lifecycle.
- Start with alerting rules and full observability.
- Only then use the data to consider blocking rules and their rollback criteria.
The public cs-public0 repository, released under Apache-2.0, contains a lifecycle controller, an Ansible role, Suricata configuration templates, example monitoring and tests. It can serve as a starting point for your own lab.
The reference variant covers forwarded IPv4 traffic on a selected bridge and rules in alert-only mode. It includes one demonstration signature; the operator supplies the full ruleset. Before deployment, verify the topology, systemd lifecycle and failure behaviour on the target KVM host as described in the repository documentation.
The Apache CloudStack documentation covers networking and traffic in the cloud and KVM host requirements. The official Suricata documentation explains inline IPS mode with NFQUEUE, while the nftables project describes bridge-layer filtering. These are standard components; the solution's value comes from combining them coherently and completing the operational work around them.
FAQ
Does Suricata replace the Apache CloudStack Virtual Router?
No. The Virtual Router continues to provide CloudStack network functions. Suricata is an additional inspection point in the KVM bridge path.
Do customer machines need an agent?
No. Inspection runs on the KVM host, before the Virtual Router, so guest machines require no changes.
Does the solution block detected threats?
The current configuration uses alerting rules. The inline architecture can enforce verdicts, but the active profile contains no DROP rules.
What happens when the Suricata process stops?
The lifecycle includes removing the rule that directs traffic to an unserved queue. The exact availability policy should be a deliberate operator decision and should be tested together with the shutdown procedure.
Can the solution see encrypted traffic?
It sees connection metadata and protocol characteristics available without decryption. HTTPS content remains encrypted unless TLS is terminated before the inspection point.
Can this pattern be used on other KVM hosts?
Yes, provided the operator first verifies the local topology, device names, resource budget and failure behaviour. The template should not assume that every host is identical.
What next?
If you operate Apache CloudStack on KVM, start with a diagram of the actual packet path and a set of signals that confirm the protection is working. We would be happy to compare experiences with NFQUEUE, Suricata and observability on CloudStack bridges — contact the WebDisk team. Learn more about our infrastructure on the WebDisk Cloud page.