SELinux Firewall

Web application and API protection

SELinux Firewall is our Sovereign Fortress High Assurance WAAP engineering project. Web Application and API Protection (WAAP) brings together web application firewall (WAF) functionality, API protection, bot and automation controls, and application-layer traffic limits to protect web applications and APIs.

Built on the shared Sovereign Fortress architecture, the platform combines SELinux-enforced access controls, process isolation and restricted privileges. Its components operate with the resource access and communication paths required for their responsibilities, helping limit the consequences of a compromise.

What does WAAP bring together?

WAAP brings web application protection, API security, bot protection and application-layer DDoS controls into a coordinated approach. The aim is to protect the application across these related forms of abuse, with controls selected for its traffic and requirements.

Beyond signature-based protection

Known attack signatures remain useful, but signature matching alone cannot cover the range of abuse facing an application. An automated client may repeatedly target a costly endpoint with individually ordinary requests. Examining request content is one part of understanding that traffic.

SELinux Firewall, our High Assurance WAAP, combines ML-based application inspection, behavioural and automation signals, IP reputation and explicit risk policy. ML inspection evaluates application input; behavioural signals contribute context about client activity; reputation provides additional security information. These methods have different roles and complement configured rules and access controls.

The aim is to assess both a request and the relevant context around it, then apply an action under the application’s policy. Depending on the enabled controls and route, that action may be to allow, block, rate-limit or require a challenge. The signals, decisions and enforcement article explains how these responsibilities fit together.

Flexible deployment. A consistent security architecture.

Sovereign Fortress / High Assurance WAAP

How the protection layers work together

Application traffic passes through the gateway. ML inspection and route controls operate in the request path; reputation and behavioural signals inform risk evaluation. The gateway applies the configured action.

Public trafficVisitors & API clients

↓ HTTPS traffic

Traffic enforcementApplication gateway

Allow · block · challenge

ML Inspection Engine
Rules, route controls and authentication

↓ Configured routes

Protected servicesApplications & APIs

Security inputs → risk evaluationReputation, behaviour & risk

Collected reputation, behaviour and bot signals inform the local risk service. Scoped decisions and shared state support gateway enforcement.

Operational evidenceEvents & metrics

The event pipeline forwards signals to risk evaluation and can deliver events to monitoring or SIEM systems. Metrics support investigation and validation.

Runtime boundaries: SELinux Type Enforcement, Linux namespaces and restricted Linux capabilities.

Application traffic controls

The platform combines a reverse proxy and application inspection with policy-driven access controls. Its application security work covers:

• Inspection of web requests for attack patterns and anomalous input.
• Request and connection limits to control abusive traffic.
• Bot and automation signals, with our own CAPTCHA challenge service where enabled by deployment policy.
• Route-specific authentication and access controls.
• Security events that support investigation and policy tuning.

Request and connection limits help manage abusive traffic at the application layer. They form part of a deployment’s availability controls alongside capacity planning and upstream network DDoS protection; gateway limits cannot prevent an attack from exhausting the network link before traffic reaches the platform.

The configured policy determines how controls are applied to each application. A signal, an enforcement decision and the resulting action have distinct roles; detection alone is not treated as proof that a request was blocked.

From security signals to enforcement

The platform separates application inspection, risk evaluation and traffic enforcement. Our locally operated ML Inspection Engine provides ML-based application inspection. IP reputation, behavioural observations and automation signals add context about the client and its activity.

A local risk decision service evaluates the relevant signals under configured policy. Shared decision state makes the current outcome available to the application gateway, which applies the configured controls and actions. The policy defines the scope and lifetime of a decision, including how unavailable or expired information is handled.

An event collection and forwarding pipeline carries security signals to risk evaluation and can send events to configured monitoring or SIEM systems. Request-path inspection and asynchronous signal processing have distinct roles and timing. Events and metrics help connect an observation, the resulting decision and the action actually applied. The technical architecture article describes the components behind these responsibilities.

Web and API traffic

The traffic scope is HTTP/HTTPS, including HTTP/2, and application integrations that use WebSocket or gRPC through the gateway. Routing a protocol and inspecting all of its application messages are different capabilities. Inspection coverage and limits must be established for the particular route, payload and configured controls.

API protection is defined for each route: permitted methods, authentication and access requirements, request limits and supported payload inspection. That scope must follow the application’s actual interfaces and enabled controls. WAAP brings these responsibilities together with WAF, bot and application availability controls; the label alone does not establish a particular feature set.

TLS handling and upstream connections form part of the deployment configuration. They are selected alongside application requirements and the trust boundaries between the gateway and its backends.

Protecting the protection platform

Application inspection protects the traffic path; the security platform also needs protection against compromise of its own components. SELinux Type Enforcement constrains each service’s access to resources. Linux namespaces separate selected resource views, while restricted Linux capabilities limit privileged operations. The runtime services operate in confined process domains, with permissions matched to their responsibilities. Network separation and restricted communication provide complementary boundaries.

Administrative configuration, request processing and security event handling receive only the access they need. The Sovereign Fortress architecture explains this confinement foundation, while Protecting the WAF Itself examines its application to the gateway platform.

This separation supports a practical question: if one component fails or is compromised, what other resources can it reach?

Network separation from the host

The WAAP runtime services share a dedicated Linux network namespace, separated from the host’s network stack. macvlan interfaces provide the required network connections, while Virtual Routing and Forwarding (VRF) separates routing domains. Runtime services therefore do not automatically share the host’s interfaces, routing tables or loopback services.

Explicit communication rules constrain access to application backends and operational services. Service-bound nftables policies restrict locally generated connections using service identity and permitted source/destination relationships, including where components share the runtime network namespace.

Network reachability becomes a reviewed part of each service’s authority, alongside its SELinux permissions and restricted capabilities. Protecting the WAF Itself explains the mechanisms and how to verify the boundary.

Controlled configuration and validation

The engineering workflow uses Git-managed configuration, compilation and validation before deployment. Changes can be reviewed in relation to the intended routes, enabled controls and supported runtime capabilities.

Deterministic validation checks defined outcomes, including client responses and whether a request reached the backend. Security testing and operational observation complement these checks. They provide evidence for a particular version and configuration, rather than a universal protection guarantee.

Security and integration capabilities

The platform’s supported controls cover identity, application inspection, traffic handling and AI service integration. They are selected and configured for each application’s requirements through the reviewed deployment policy.

Operational visibility

Security events and metrics support investigation, tuning and follow-up. The aim is to connect a request and its signals to the configured action, while keeping operational decisions under the deployment’s control.

The scope of a deployment should identify the protected applications, enabled controls, inspection coverage and validation results. Contact us to discuss those requirements and the engineering work involved.