FIELD NOTES / 01

When SysWarden
meets BunkerWeb.

Web protection. Host defense.
A shared approach to defense in depth.

BunkerWebAPPLICATION PROTECTION
SysWarden conceptual architecture with observation, policy decisions, nftables enforcement and evidence.

DISTINCT LAYERS. A CONNECTED DEFENSE.

01

Two projects. A shared purpose.

Security becomes more useful when good tools can work together. That is the idea behind our work with BunkerWeb: connect web application protection with Linux host defense. Two French open-source projects, complementary responsibilities and a shared ambition: make defense in depth practical, understandable and open to inspection.

If you run an internet-facing service, you know the routine. A suspicious request appears, a rule fires, and someone needs to understand what happened next. Was the source blocked? For how long? Which system owns the decision? Our work starts with those ordinary questions, because they matter when you are operating a real service.

02

Web protection meets host defense.

BunkerWeb is an open-source web application firewall built on NGINX. As an in-band reverse proxy, it inspects requests on their way to an application and applies web-focused protections. Its plugin system makes connections with other tools possible. Explore the implementation in the BunkerWeb GitHub repository.

SysWarden brings out-of-band log analysis and host signals to the picture, without adding another HTTP proxy. Its validated decisions are enforced through nftables in the Linux networking stack. Out-of-band describes the analysis path; the resulting firewall rules still act on live traffic. This distinction matters when explaining how the two layers work.

03

In-band + out-of-band: defense in depth.

BunkerWeb can examine application context that a network firewall does not see. SysWarden can turn a validated handoff into host-level enforcement. Together, these distinct controls support defense in depth: a web-facing layer and a host layer with clear responsibilities. Neither makes the other unnecessary, and neither replaces patching, access control or monitoring.

THE CONNECTION, EXPLAINED

Two layers. Clear responsibilities.

IN-BAND Application request path
01ClientWeb request
02BunkerWebInspect and protect
03ApplicationAllowed request
OUT-OF-BAND Detection handoff and policy control
SIGNALBunkerWeb pluginTemporary ban request
TRUSTHTTPS APIAuthentication + validation
DECISIONSysWardenOwnership + expiration
ENFORCEMENTnftablesLinux host firewall
Conceptual control flow, not packet ordering. SysWarden analyzes signals outside the HTTP proxy path; nftables enforces validated policy on live network traffic. Version-specific prerequisites apply.

04

A small bridge with clear boundaries.

The documented plugin boundary uses SysWarden's authenticated HTTPS HA API to submit temporary bans from BunkerWeb. The plugin does not need to edit SysWarden configuration files or execute its local commands. That separation keeps the integration contract explicit and makes it easier to reason about what a remote component is allowed to do.

A useful handoff carries more than an IP address. Duration, source ownership and validation matter too. In the documented contract, removing one producer's claim does not automatically remove another producer's reason for keeping an address blocked. This is an important operational detail: cleanup should remove the state an integration owns, without silently undoing someone else's protection.

05

Designed for the person on call.

For me, the most valuable outcome is a system that an operator can explain. A diagram should help answer a simple question: where does this decision come from? Configuration should make the trust boundary visible. Logs should help distinguish an observation from an action that actually reached the firewall. Those details deserve as much attention as the headline feature.

On the SysWarden side, our work has covered authenticated API boundaries, source-owned bans, expiration, cleanup and versioned operator guidance. Linux laboratory work also examines recovery and firewall behavior. A successful API call is only part of that story: we need to know what was retained, what was removed and what the kernel actually enforced. Qualification remains a separate, evidence-based decision.

06

The people behind the connection.

Open source is also about the people who take time to make their projects work well together. I would like to thank the whole BunkerWeb team, with a special mention for Florian Pitance , Théophile Diot and Alexandre Agasseau . It is a pleasure to build this connection with people who care about useful, accessible security tooling.

What I appreciate about this collaboration is the conversation around the code. Different projects bring different constraints, and an integrator's question can reveal an assumption worth revisiting. Public documentation and review give those lessons somewhere to live, and let operators help improve the result.

07

Building the next chapter, in the open.

At the time of writing, v4.04.3 remains SysWarden's qualified stable release, while the v4.10.0 source candidate is still under qualification. The integration guide is version-specific; it does not certify every plugin combination or the successor HA v2 runtime. Check the compatibility notes before deployment. This article presents the collaboration and architecture, rather than a blanket production-readiness claim.

The direction is clear: make web protection and host defense easier to operate together, with evidence that people can inspect. We will keep sharing the engineering decisions, practical lessons and release progress here. If you use BunkerWeb, maintain Linux systems or enjoy working on open-source security, bring your questions and use cases. The next useful improvement may start with exactly that conversation.

KEEP EXPLORING

From the article to the code.

← Back to the blog