Exoledge Edge¶

Edge security for European web applications. Web application firewall, bot management and DDoS absorption in front of your origins, hosted in the European Union, reversible by design.

This guide is for the people who operate the service: platform engineers, security teams and managed service providers running customer sites behind Exoledge.

1. What Exoledge does¶

Every request to a protected domain reaches an Exoledge edge node before it reaches your server. The edge terminates TLS, identifies the client, applies your security policy, and only then forwards the request to an origin you control.

What that gives you:

A web application firewall built on the OWASP Core Rule Set, tuned per domain rather than per platform.
Bot management that keeps automated traffic away from your application without blocking real users: proof of work, a self-hosted challenge, or a hard refusal.
Network reputation so that traffic from known hostile networks is priced in before it reaches your application.
Caching in front of the origins, with purge on demand.
Load balancing across several origins, with health taken from Kubernetes itself.
Full visibility: every decision is logged with the address, the path, the reason and a request identifier.

Exoledge runs on Talos Linux and Kubernetes, on European infrastructure, using open components you can audit and replace. Nothing about the platform locks your traffic in: an origin stays a plain HTTP server, and the day you leave, you point DNS back and keep your system.

2. The concepts¶

Organization. The tenant boundary. Every domain, account, list and log line belongs to one organization, and nothing crosses that boundary. A provider running several customers gives each one its own organization.

Domain. The name users type. Declaring a domain in the console is what makes Exoledge answer for it, and what makes it request a certificate.

Origin. The server that actually serves the application. An origin is a hostname and a port. A domain can have several, weighted.

Edge policy. The set of decisions taken for a domain: which firewall families are active, how aggressive the rule engine is, which addresses are exempt, how hard the challenge is.

Pass. A short-lived signed cookie proving that this client already solved the challenge. It avoids asking the same visitor to solve it again on every page.

3. How a request is handled¶

The order matters, because it explains most of what you will observe in the logs.

TLS termination. The certificate for the domain is presented. Exoledge never forwards plaintext to you.
Domain resolution. The Host header is matched to a declared domain. An unknown host is refused before anything else happens.
Allowlists. Payment provider callbacks, search engine crawlers and repository webhooks are recognised first. They are never challenged and never blocked, because a challenge on a payment callback means a failed payment.
Lists and reputation. Addresses on your blocklists, Tor exit nodes, public proxies and VPNs, and networks with a bad reputation are scored. A high enough score refuses the request, or prices it into a harder challenge.
Sensitive paths. Requests for .env, .git, database dumps and common admin panels are refused before the rule engine runs. They are cheap to identify and never legitimate.
The rule engine. OWASP CRS evaluates the request: injection, traversal, command execution, protocol violations. The paranoia level and the anomaly threshold decide how much evidence is needed before a request is refused.
The challenge decision. If the client is not clearly legitimate, the edge decides: give a proof of work, give the interactive challenge, or drop. A valid pass skips this step.
The origin. The request is forwarded to a healthy origin, with the client's real address in the standard forwarding headers.
The cache. When caching is enabled for the domain, a response served from cache never reaches the origin at all.

4. Putting a domain behind Exoledge¶

Declare the domain in the console, with its origin (hostname and port).
Point DNS at the edge: an A record on the domain name towards the edge address.
Wait for the certificate. Exoledge requests it automatically and serves the domain over HTTPS as soon as it is issued. Nothing to install on your side.
Watch the logs for a day, in observation mode. Nothing is blocked. You see what the policy would have done.
Turn filtering on when the volume of what would have been blocked matches your expectations.

Observation mode is the recommended way to start. It answers the only question that matters before enabling a firewall: what would it have done to my legitimate traffic.

5. The web application firewall¶

The firewall is Coraza running the OWASP Core Rule Set. Three things are yours to decide, per domain:

Which families are active. Signature filtering, sensitive files, path traversal, SQL injection and cross-site scripting, WordPress scanning, backdoor attempts, admin interface probing, technology probing. Each one can be turned off for a domain, for instance because the application legitimately uses paths that look like probes.

How strict the engine is. The paranoia level runs from 1 to 4. Level 1 catches the obvious and keeps false positives low. Level 4 assumes an application that never receives unusual input. Most sites belong at 1 or 2, and the right way to move up is to raise the level in observation mode and read the logs.

How much evidence is needed. The anomaly threshold is the score a request must reach before it is refused. Lower means stricter.

Exemptions close the loop: an address, a path prefix, or a rule identifier can be excluded when you know a legitimate flow trips a rule. An exemption should be narrow and documented, otherwise it becomes a hole.

6. Bot management¶

Not every automated client is hostile, and no firewall can decide alone. Exoledge separates three outcomes:

Proof of work. The default. The client performs a small computation before entering. Real browsers do it without noticing, cheap botnets cannot afford it at volume, and no human is asked anything.

Interactive challenge. For clients that cannot compute: a page with a single question, served by Exoledge itself, with no third-party script and no external dependency.

Hard refusal. For traffic that has no reason to exist: hostile networks, addresses already condemned by your own policy.

A client that succeeds receives a pass, valid for thirty minutes by default, so the cost is paid once and not on every page.

Under pressure. When a domain receives significantly more traffic than its own history, the edge raises the price instead of tightening the rules: the proof of work gets harder and the pass gets shorter. This is automatic, and it is measured against the hourly average of the last thirty days at the same hour, not against a number picked in advance. A sudden legitimate campaign is not an attack: the hostile share has to be there too. You can force the level for thirty minutes when you know something the history does not, then let it fall back to measurement.

7. Lists and reputation¶

Two mechanisms, deliberately separate.

Your lists. Addresses and networks you add or remove yourself. They are yours, they take effect immediately, and they are the only ones you need to explain to a customer.

Platform lists. Tor exit nodes, public proxies and VPNs, networks belonging to bulletproof hosters, and networks with a bad reputation. They are refreshed every hour from public sources, and they are never trusted alone: each one carries a weight, and the total score decides between refusing, challenging and letting through.

Every request also carries what the platform knows about the address: the network operator, the country, and whether the network is residential, mobile, hosting or anonymising. The console shows it next to the log line, so a decision can be explained to a customer without a separate lookup.

One deliberate exception: bulletproof hosting is refused on the strength of that list alone. A network that exists to host abuse does not get the benefit of the doubt.

8. Load balancing¶

A domain can point at several origins. Each origin carries a weight, and traffic is distributed accordingly; weights are useful for progressive migrations and canary deployments as much as for capacity.

Health is not guessed. It comes from the orchestrator: an origin that stops reporting ready endpoints stops receiving traffic, and comes back when it reports again. A failing origin does not take the domain down with it.

When a domain has no healthy origin, Exoledge serves a maintenance page with a proper status code and a retry hint, and says nothing about the software behind it.

9. Cache¶

Caching is enabled per domain. When it is on, a response can be served without touching the origin, which is what turns a slow page into a fast one under load.

Two rules worth knowing:

The cache is shared, not private. A response cached for one visitor can be served to another. Pages that depend on a cookie or a session must not be cached, and the default configuration does not cache them.
Purge is explicit. You can purge a given URL from the console, and the purge takes effect immediately across the cache. Purging by tag is not supported: the request is refused rather than silently ignored, because a purge that does nothing is worse than no purge at all.

10. Logs, metrics and observation mode¶

Every request produces a log line: timestamp, address, method, path, status, duration, the decision taken, the reason, and a request identifier.

From the console you can:

Filter by domain, address, path, decision and time.
Follow the stream live while you work.
Search by request identifier when a customer sends you a screenshot.
Read the request fingerprint: a stable identifier of the client's HTTP behaviour, computed by Exoledge, that groups requests coming from the same tool.

The dashboard aggregates the same data: requests, refusals, latency, top paths, response codes, and the share of traffic that was challenged.

Observation mode is a console-wide switch. Nothing is blocked, nothing is challenged: the edge decides and writes down what it would have done. It is the right mode for a first week, and the right mode to prepare a policy change.

11. Accounts, roles and audit¶

Three roles:

Owner: everything, including deleting the organization.
Admin: domains, policies, accounts. Not the organization itself.
Viewer: read-only, including logs.

Passwords are twelve characters minimum. Sessions are cookies, HttpOnly, Secure, and every state-changing call requires an anti-replay token.

Every administrative action is written to an audit log: who changed what, on which domain, when.

12. API¶

Everything the console does, the API does. It is a REST API under /api/v1, authenticated by the session cookie plus the anti-replay header, documented with OpenAPI 3.1.

Typical uses: declaring domains from your own provisioning, pushing lists from your inventory, exporting logs to your SIEM, or driving the observation mode from a change management tool.

13. Current limitations¶

Stated plainly, because a platform that hides them is worse than one that does not have them:

One edge node in the current deployment. The architecture separates control plane and data plane, but the proof of concept runs a single node. Multi-node distribution is designed and not yet deployed in production.
No anycast. Traffic reaches the edge through DNS, not through a global routing announcement.
No transport-layer protection yet. The firewall and the bot management work on HTTP. TCP and UDP protection is on the roadmap, not in the product.
Purge by tag is refused, not implemented.
One function is recorded and not applied: the "Known attackers" list, which would block addresses seen in exploitation campaigns. No feed backs it yet, so its state says applied: false instead of pretending to protect.
One panel is greyed: the numeric thresholds of the under-pressure mode, which the console does not expose yet. It is shown disabled with the reason, rather than filled with invented numbers.

14. Getting help¶

For anything operational, the console keeps the evidence: the request identifier, the log line, the decision and the reason. Send those, and the answer is usually immediate.

Exoledge is operated from France, on European infrastructure, with open components. Your traffic stays yours: the platform forwards it, decides about it, and gives it back the day you ask.