OBIE · Open Ban Intelligence Exchange
OBIE is a leaderless mesh where defenders exchange signed attacker signals, so that collective defence stops requiring a central authority anyone has to trust. Servers warn each other about attackers. Each server still decides for itself what to block.
Read the spec and try to break it
No tokens. No coin. Incentives come from mutual defence, not speculation.
signed report
signed · ed25519 · verified
01The problem
Defensive intelligence is concentrated in a handful of vendors. Their outage is your outage.
Any server on the internet is probed all day by automated tools that guess passwords and look for weak spots. The same addresses attack thousands of servers. Yet each server has to learn about an attacker the hard way: by being attacked.
The usual shortcut is a threat feed: a list of known bad addresses that one provider collects and hands out. That helps, but it moves the problem instead of solving it.
Good feeds often cost money. Small operators, who need help most, go without.
You cannot see why an address is on the list. You have to trust the provider.
If the provider has an outage, makes a mistake or is compromised, everyone who relies on it is affected at once.
OBIE takes a different route: servers share what they have seen directly with each other, every report can be checked, and nobody in the middle decides for you.
Read the full reasoning in the whitepaper02How it works
OBIE runs as a small program next to the tools you already use. Here is what happens when one server sees an attack, as designed for version 0.1.
A tool that already watches your logs spots an attack. The first one OBIE is being built for is Fail2Ban, a widely used program that notices repeated failed logins.
Your server writes a short report about the attacking address and signs it with its own key. The signature is a digital seal: anyone can check who wrote the report and that nobody changed it. Your logs and your users’ data stay at home.
The report goes to other OBIE servers, called peers. In version 0.1 you choose these peers yourself, and you decide how much you trust each one.
No report is an order. Every server weighs what it receives by how much it trusts the sender. By default it only acts when at least two trusted sources report the same address (your own server counts as one) and their combined confidence is high enough.
Addresses you must never block, such as your office network or your own gateways, go on a safety list (an allowlist). No report can override it.
When the rules are met, the server blocks the address in its firewall for a limited time. The block ends on its own, so a mistake does not last forever.
This is the version 0.1 design. Which steps already run in the code is listed under Status.
A short story with three OBIE servers, two attackers and one troublemaker. Step through it at your own pace and watch each server decide for itself.
Illustration: made-up servers and example addresses, not live data from the network.
Here, a server blocks an address when the reports it trusts reach a combined score of 1.2, its threshold, from at least two reporters, its quorum. The federation guide suggests this for three to five servers; out of the box the threshold is 1.8. A Fail2Ban report has a confidence of 0.8. These servers block in their firewalls; a new server only watches (observe mode) until its operator switches blocking on.
Three servers, each run by a different operator: a web shop (A), a university lab (B) and a homelab (C). They connect directly, with no central server. Each lists how much it trusts the others, from 0 to 1.
Planned Peers are added by hand today. Finding them automatically is planned.
A password-guessing bot works through server after server and starts with A. A’s own log watcher (such as Fail2Ban) blocks it at once: A needs nobody’s permission to protect itself. A colleague’s mistyped passwords get an office address blocked too.
A sends B and C a short report: the address, what it did, how often and a fingerprint of the evidence. The logs themselves stay on A. A’s digital signature proves to B and C that the report is A’s.
B and C record A’s reports but do not block. Each scores a report: its trust in the sender times how sure the sender is. One report stays below each server’s bar, and each wants two independent reporters.
Why One mistaken or compromised server must never get an address blocked everywhere. The office address shows why.
Next the bot tries B. B’s own detection catches it, and B blocks it at once. Its own report and A’s earlier one agree: two trusted voices.
B shares its signed report with A and C. Together with A’s, two independent, trusted reports now pass C’s bar, so C blocks the bot. When the bot knocks on C minutes later, it is turned away at the door.
Planned Today the quorum counts servers, not organisations. Checking that reporters come from different networks is planned.
A web scanner probes C and nowhere else. C blocks it and reports it. A and B only watch: one reporter is not enough for them, and each weighs C by its own trust. Each server decides for itself.
An unknown participant floods the servers with reports to get the shop’s payment service blocked. Nobody trusts it, so its reports weigh 0, however many it sends. And the service is on A’s safety list: never blocked, whatever anyone reports.
Planned Trust that grows or shrinks with a peer’s track record is planned. Today each operator sets the numbers.
A learns the office address is a colleague’s shared connection and withdraws its report with a signed revocation. A unblocks it; B and C drop it automatically. Blocks also end on their own: the scanner’s one-hour block has run out.
Planned A way for the owner of a blocked address to appeal is planned.
Shared intelligence, sovereign enforcement: servers warn each other early, and every server still decides for itself what to block.
03Principles
Ten principles, and the first is: evidence above authority.
Trust comes from data you can check, not from a badge. Every report is signed, so you always know who sent it.
Your server makes its own decisions. Reports from others are advice, never orders.
There is no central server that can switch OBIE off or tell everyone what to block.
Servers share attacker addresses. They never share your users’ identities or your raw logs.
There is no coin and nothing to trade. You take part because shared defence protects you too.
If it can’t be deployed by a competent engineer in a weekend, it’s research, not production.
04Status
Version 0.1 is being built in the open. There is no running public mesh yet, and OBIE is not ready to protect production servers. Here is what the code does today and what comes next.
What version 0.1 can and cannot do yet, and what it needs
Follow the progress on GitHub05Get started
OBIE is built for engineers who run their own Linux servers. You need Go 1.26 or newer to build it.
Build the node from source. One command produces two programs in ./bin: obied, the node, and obiectl, the tool to control it.
make buildStart in observe-only mode, the default. Once decisions land, the node will record what it would block but block nothing, so you can check its judgement first.
./bin/obied --config /etc/obie/obie.yamlList the peers you trust, and how much, in the configuration file. Once blocking lands, switch to enforce mode when you are confident.
./bin/obiectl --socket /run/obie/obie.sock peersVersion 0.1 is still in development. Until decisions and blocking land (see Status), a node connects to its peers and stores reports, but decides and blocks nothing.
Example configuration with every option
06Founder
Founder of OBIE · Software architect · Managing director, Cloudwerks Technology GmbH
Markus Niewerth has been building software systems that reduce complexity for 15 years. As founder of Cloudwerks Technology GmbH he designs and builds its products himself, among them QuickSelect, Krisis and OBIE, and works in parallel as a software architect on automotive platforms (software-defined vehicle, Android Automotive OS). He started OBIE after evaluating crowd-sourced security SDKs for a project and running into what he calls the centralization trap.
Proposals drawn from OBIE’s principles. Suggest your own topic in the form below.
07Contact
For talks, workshops, interviews, research collaborations and other questions about OBIE. Your message goes directly to Markus Niewerth.
Prefer to ask in public? Open an issue on GitHub08FAQ
Yes. The code and the specification are open source under the MIT licence. There are no tokens and no coin.
Not on its own. As designed for version 0.1, your server only acts on reports from sources you chose to trust, by default only when at least two of them report the same address (your own server counts as one) with enough combined confidence, and never against your safety list. Reports about private and internal network addresses are rejected outright. Peers you trust could still agree on a wrong report, which is why you choose them carefully and can start in observe-only mode. Trust that is earned automatically is planned.
Once sharing is built (in progress for version 0.1), only signed reports in the format the specification defines: the attacking address, the attacked service, how many events were seen, a reason code, whether a honeypot saw it, the suggested action, a confidence value and how long the action should last. Optional are a fingerprint of the log lines, which proves what you saw without revealing it, codes for the attack technique (MITRE ATT&CK IDs) and the number of your network (its ASN). A server can also withdraw its own report with a signed revocation that carries a reason code. The format has no room for logs, user names, passwords or free text. Like any network connection, your peers see your server’s address and its public OBIE ID.
Fail2Ban is the first detector OBIE is being built to work with. A server does not need its own detector to act on reports from peers it trusts. Support for other sources, such as honeypots (decoy servers that attract attackers), is planned.
No. Version 0.1 is in development in the open. Today a node runs, has its own identity, connects to the peers you list and stores reports. Detection, decisions and blocking are still being built. Please do not rely on it to protect production servers yet.
No. Servers connect directly to each other. There is no central server, no account and no kill switch.
OBIE is developed in the open on GitHub, with a public specification and MIT-licensed code. The company that initiated it is named in the footer, and the founder section above introduces the person who started it. Anyone can read the code, report problems and contribute.