Network architecture
Your traffic and our control plane never share a path
Filtering happens on an upstream scrubbing network. UMBREN's control plane tells that network what to protect and how, and reads back what it measured. It carries none of your traffic.
Traffic path and control plane
Two systems with one narrow connection between them
The traffic path moves packets. The control plane moves decisions. Configuration and policy go up to the scrubbing network and telemetry comes back down. Customer traffic never crosses.
Traffic path
Traffic for your service arrives at a protected address on an upstream scrubbing network. Attack traffic is filtered there, according to the policy deployed for your endpoint. What remains is delivered to your origin: your server, on your address.
Control plane
The dashboard and API, and behind them onboarding, ownership verification, policy, provisioning and the audit log. The control plane reaches scrubbing networks through provider adapters. No customer packet passes through it.
Provider-adapter model
Scrubbing providers connect through one common contract
UMBREN integrates upstream scrubbing providers through adapters. Every adapter implements the same contract, so the rest of the product does not depend on how any one provider works.
- 01
Capability discovery
What a provider can protect: protocols, ports, regions and profiles. Validation checks an endpoint against this before anything is reserved.
- 02
Endpoint reservation
Reserving a protected address for an endpoint. Capacity is confirmed by a reservation, not by an assumption.
- 03
Origin and port configuration
Telling the provider where clean traffic goes: the verified origin address, the protocol and the ports.
- 04
Policy deployment
Carrying a policy version that is in enforce mode to the provider that will apply it.
- 05
Telemetry and incident retrieval
Reading back what the provider measured: bandwidth, packet rate, protocol distribution, allowed versus mitigated, and incidents.
- 06
Health monitoring
Checking the health of the provider and of what is deployed on it, and recording when a check fails.
- 07
Reconciliation
Comparing the configuration UMBREN intends with the configuration the provider actually holds, so that drift is found.
- 08
Safe rollback
Returning to an earlier known configuration when a deployment or a health check fails.
- 09
Credential rotation
Replacing the credentials UMBREN holds for a provider as a routine operation, not an emergency one.
Not tied to one vendor
Onboarding, policy and visibility are written against the contract, not against a provider. A provider is connected by implementing the contract.
Simulated providers are labelled
In evaluation environments an endpoint may be staged on a simulated provider. It is labelled “simulated” everywhere it appears, and it never counts as protected.
Failure behaviour
A control-plane outage does not disable deployed protection
Deployed protection does not depend on our website being up. More generally, each failure has a defined result, and that result is the cautious one.
This describes how the product is designed to behave. It is not an uptime commitment, and UMBREN does not publish one.
- The dashboard or API is unavailable
- Protection that is already deployed keeps running. It lives on the scrubbing network, not in the control plane. Policy changes and new telemetry wait until the control plane is back.
- An automated onboarding step fails
- The endpoint moves to FAILED. Retry returns it to the last stable checkpoint. It does not start again from the beginning, and it does not skip a check.
- A health check fails during mitigation
- With rollback on health failure enabled, as it is by default, mitigation is rolled back.
- An attack ends
- Automatically applied rules expire at the end of their time to live. The incident resolves once traffic has stayed normal for the quiet period.
- An administrative hold is lifted
- The endpoint returns to a stable checkpoint. An endpoint that was active must be authorized again. It never resumes straight to ACTIVE.
- A gate stops holding before activation
- Every gate is checked again at the moment of activation. If one no longer holds, activation does not happen. There is no override.
Clean-traffic delivery
What reaches your origin, and from where
After filtering, legitimate traffic is delivered from the scrubbing network to your origin. Your origin has to be ready to receive it, and you are the one who confirms that it is.
- The origin stays where it is. Your server keeps its address. UMBREN does not host your service or move it.
- Consider closing the direct path. An origin that still answers the whole Internet on the same port can be attacked directly. Once your users reach you through the protected address, consider accepting the service port only from the delivery ranges.
- The origin address is kept out of notifications. Origin addresses are never included in webhook payloads.
Delivery ranges are shown to you
The endpoint page lists the delivery ranges that clean traffic for the endpoint will come from.
You prepare the firewall and routing
Your origin must accept clean traffic from those ranges. You confirm that it does, and that confirmation is one of the activation gates.
The staged path is tested
With the protected address reserved and the origin configured, the provider tests the staged path to your origin. No user traffic moves during staging or testing.
Activation is authorized
When every gate holds, a member of your team with activation rights types the endpoint name to approve the change. Only then does traffic move to the protected address.
Design decision
Why packets are not scrubbed in the web and API tier
The control plane is a web application and an API. It is built for correctness, access control and audit. It is not built to absorb a flood, and it is never asked to.
Volume belongs at the edge
Scrubbing takes network capacity and a position in front of the target. Upstream scrubbing networks are built for that. An application server is not.
Separate failure domains
A flood aimed at your service never passes through the systems that hold your account, your policies and your audit log. A fault in those systems does not sit in the path of your packets.
A smaller target
The web tier handles sign-in, configuration and records. Keeping packet processing out of it keeps it simple enough to reason about and to secure.
The verification step follows the same principle in the other direction. UMBREN never connects to, scans or probes your origin. The verification agent makes a single outbound HTTPS request from your server, and UMBREN compares the address it arrives from with the address you registered. See umbren-agent verify in the documentation.
Bring your infrastructure under protection
Create an account, register an endpoint and verify ownership. Protection is activated only after every check has passed and you have authorized the change.