Read what protects you.

The core of Ardarik is published under AGPL-3.0 at launch, so anyone can read the code that decides about your traffic. Until then, this page shows how it is built and how it is tested.

A gateway that works on its own.

The core is not a trial version. It is a gateway in its own right, without the paid edition. It receives each request, reads forms, JSON, XML and uploads, and checks them with the OWASP Core Rule Set, the public rules that recognise common attacks. For each application and each path, it records what it would stop, or stops it. It keeps an event log, checks its configuration before every reload, and has a console for one administrator. It has no licence check: nothing in it waits to be unlocked.

The engine is our own.

The Core Rule Set was written for a library in C++, a language in which one mistake in handling memory can become a way in for an attacker. Embedding that library would bring back the risk a gateway written in Rust is meant to remove. So the rule engine, the parsers and the detectors are our own, in Rust. Our port of the detector for injected database commands and scripts gives the same answers as the original on all 167,646 of its samples.

4,502 pass. 2 fail.

The Core Rule Set comes with its own tests: requests, each with the answer the rules must give. On Ardarik’s engine, 4,502 give that answer and 2 do not. Another 53 never reach a rule: Ardarik reads requests more strictly and refuses them first. The numbers, how they are counted and the attacks it does not stop yet are written down beside the code, and published with it at launch.

It reads like the server behind it.

An attack slips through when the gateway reads a request one way and the application behind it reads it another. So the way Ardarik reads a request is tested against how the software behind gateways reads it: Tomcat, Spring, PHP, Node.js, Django, Go and others. Where two of them would read the content of a request differently, Ardarik does not guess which one you run. It refuses the request.

A bad request gets an answer, not a crash.

A gateway that falls over takes your applications offline with it. So the build refuses code in the path of a request that could stop the program instead of answering, and code that switches off Rust’s memory checks. Every pattern it searches a request for runs in time that grows only with the size of the request, so no request can be shaped to keep it searching.

Tested by attacking it.

Before security code is written, the attacks it must withstand are written down. Its review is an attack on the built program, and every finding becomes a test. Every night, nine parts of the core are fed malformed input at random, to find what breaks. Where our own tests got past it, the changelog says so, and what was done about it.

Few dependencies, all checked.

Every outside library is code you run without having written it. So each one the core uses has its reason written down: what it does, and why we do not write it ourselves. Only permissive licences, such as MIT and Apache-2.0, are allowed. On every change, the build checks each library’s licence, its known security advisories and where it comes from.

Anyone may read it. Nobody may close it.

The core is published under AGPL-3.0 at launch, so anyone can read it, audit it, run it and change it. Cloo GmbH also offers it under a commercial licence.

The licence keeps it open: nobody can take the core, extend it and sell it as a closed product. A licence for the Enterprise edition adds the learned profile, which learns each of your applications from its own traffic. It is counted per instance.

See pricing

Questions are welcome.

Talk to us Read the source