OBIE · Open Ban Intelligence Exchange
OBIE ist ein Mesh ohne zentrale Leitung, in dem Verteidiger signierte Hinweise auf Angreifer austauschen. So braucht gemeinsame Abwehr keine zentrale Instanz mehr, der alle vertrauen müssen. Server warnen einander vor Angreifern. Jeder Server entscheidet weiterhin selbst, was er sperrt.
Die Spezifikation lesen und versuchen, sie zu knacken
Keine Tokens. Keine Kryptowährung. Der Anreiz ist gegenseitige Abwehr, nicht Spekulation.
signierte Meldung
signiert · ed25519 · geprüft
01Problem
Das Wissen zur Abwehr liegt bei einer Handvoll Anbieter. Deren Ausfall ist Ihr Ausfall.
Jeder Server im Internet wird den ganzen Tag von automatisierten Programmen abgetastet, die Passwörter erraten und nach Schwachstellen suchen. Dieselben Adressen greifen Tausende Server an. Trotzdem muss jeder Server einen Angreifer auf die harte Tour kennenlernen: indem er angegriffen wird.
Die übliche Abkürzung ist ein sogenannter Threat-Feed: eine Liste bekannter schädlicher Adressen, die ein Anbieter sammelt und verteilt. Das hilft, verschiebt das Problem aber nur, statt es zu lösen.
Gute Feeds kosten oft Geld. Kleine Betreiber, die Hilfe am dringendsten brauchen, gehen leer aus.
Sie sehen nicht, warum eine Adresse auf der Liste steht. Sie müssen dem Anbieter vertrauen.
Hat der Anbieter eine Störung, macht er einen Fehler oder wird er kompromittiert, sind alle, die sich auf ihn verlassen, gleichzeitig betroffen.
OBIE geht einen anderen Weg: Server teilen ihre Beobachtungen direkt miteinander, jede Meldung lässt sich prüfen, und niemand in der Mitte entscheidet für Sie.
Die ganze Begründung im Whitepaper lesen02Funktionsweise
OBIE läuft als kleines Programm neben den Werkzeugen, die Sie schon nutzen. Hier sehen Sie, was in Version 0.1 passiert, wenn ein Server einen Angriff bemerkt.
Ein Werkzeug, das Ihre Logdateien bereits überwacht, bemerkt einen Angriff. Das erste, mit dem OBIE zusammenarbeitet, ist Fail2Ban, ein weit verbreitetes Programm, das wiederholte fehlgeschlagene Anmeldungen erkennt.
Ihr Server schreibt eine kurze Meldung über die angreifende Adresse und signiert sie mit seinem eigenen Schlüssel. Die Signatur ist ein digitales Siegel: Jeder kann prüfen, wer die Meldung geschrieben hat und dass niemand sie verändert hat. Ihre Logs und die Daten Ihrer Nutzer bleiben bei Ihnen.
Die Meldung geht an andere OBIE-Server, sogenannte Peers. In Version 0.1 wählen Sie diese Peers selbst aus und legen fest, wie sehr Sie jedem von ihnen vertrauen.
Keine Meldung ist ein Befehl. Jeder Server gewichtet, was er erhält, danach, wie sehr er dem Absender vertraut. Standardmäßig handelt er erst, wenn mindestens zwei vertrauenswürdige Quellen dieselbe Adresse melden (Ihr eigener Server zählt als eine) und ihre gemeinsame Konfidenz (wie sicher sie sich sind) hoch genug ist.
Adressen, die Sie niemals sperren dürfen, etwa Ihr Büronetz oder Ihre eigenen Gateways, kommen auf eine Schutzliste (eine Allowlist). Keine Meldung kann sie aushebeln.
Sind die Regeln erfüllt, sperrt der Server die Adresse in seiner Firewall für eine begrenzte Zeit. Die Sperre endet von selbst, damit ein Fehler nicht ewig bestehen bleibt.
Alle sechs Schritte laufen heute im Code von Version 0.1. Was sie noch nicht kann, steht unter „Status“.
Eine kurze Geschichte mit drei OBIE-Servern, zwei Angreifern und einem Störenfried. Gehen Sie sie in Ihrem eigenen Tempo durch und sehen Sie zu, wie jeder Server selbst entscheidet.
Illustration: erfundene Server und Beispieladressen, keine Live-Daten aus dem Netzwerk.
Hier sperrt ein Server eine Adresse, wenn die Meldungen, denen er vertraut, zusammen einen Wert von 1,2 erreichen (seine Schwelle) und von mindestens zwei Meldern stammen (sein Quorum). Der Leitfaden zur Föderation empfiehlt das für drei bis fünf Server; ab Werk liegt die Schwelle bei 1,8. Eine Fail2Ban-Meldung hat eine Konfidenz von 0,8. Diese Server sperren in ihren Firewalls; ein neuer Server beobachtet nur (Beobachtungsmodus), bis sein Betreiber das Sperren einschaltet.
Drei Server mit je einem anderen Betreiber: ein Webshop (A), ein Hochschullabor (B) und ein Homelab (C). Sie verbinden sich direkt, ohne zentralen Server. Jeder legt fest, wie sehr er den anderen vertraut, von 0 bis 1.
Geplant Peers werden heute von Hand eingetragen. Sie automatisch zu finden, ist geplant.
Ein Bot rät Passwörter, Server für Server, und beginnt bei A. Der eigene Log-Wächter von A (etwa Fail2Ban) sperrt ihn direkt: Zum Selbstschutz braucht A niemandes Erlaubnis. Weil ein Kollege sich mehrmals vertippt, wird auch eine Büroadresse gesperrt.
A schickt B und C eine kurze Meldung: die Adresse, was sie tat, wie oft und einen Fingerabdruck der Belege. Die Logs selbst bleiben auf A. Seine digitale Signatur beweist B und C, dass die Meldung von A stammt.
B und C speichern die Meldungen von A, sperren aber nicht. Jeder bewertet eine Meldung: Vertrauen in den Absender mal dessen Konfidenz (wie sicher er sich ist). Eine Meldung allein bleibt unter der Schwelle; jeder verlangt zwei unabhängige Melder.
Warum Ein einzelner fehlerhafter oder kompromittierter Server darf niemals erreichen, dass eine Adresse überall gesperrt wird. Die Büroadresse zeigt, warum.
Als Nächstes versucht es der Bot bei B. Die eigene Erkennung von B schlägt an, und B sperrt ihn direkt. Seine eigene Meldung und die frühere von A stimmen überein: zwei vertraute Stimmen.
B teilt seine signierte Meldung mit A und C. Zwei unabhängige, vertraute Meldungen (von A und B) erreichen nun die Schwelle von C, also sperrt C den Bot. Klopft der Bot Minuten später bei C an, wird er abgewiesen.
Geplant Heute zählt das Quorum Server, nicht Organisationen. Eine Prüfung, ob die Melder aus verschiedenen Netzen stammen, ist geplant.
Ein Web-Scanner tastet nur C ab. C sperrt und meldet ihn. A und B beobachten nur: Ein Melder reicht ihnen nicht, und jeder gewichtet C nach seinem eigenen Vertrauen. Jeder Server entscheidet selbst.
Ein unbekannter Teilnehmer überflutet die Server mit Meldungen, damit der Zahlungsdienst des Shops gesperrt wird. Niemand vertraut ihm: Seine Meldungen wiegen 0, egal wie viele. Und der Dienst steht auf der Schutzliste von A: nie gesperrt, was immer gemeldet wird.
Geplant Vertrauen, das mit der bisherigen Zuverlässigkeit eines Peers wächst oder schrumpft, ist geplant. Heute legt jeder Betreiber die Zahlen selbst fest.
A erfährt: Die Büroadresse ist der gemeinsame Anschluss eines Kollegen. A zieht seine Meldung per signiertem Widerruf zurück und hebt die Sperre auf. B und C verwerfen die Meldung automatisch. Sperren enden auch von selbst: Die einstündige Scanner-Sperre ist abgelaufen.
Geplant Ein Weg, über den der Inhaber einer gesperrten Adresse Einspruch einlegen kann, ist geplant.
Geteiltes Wissen, souveräne Durchsetzung: Server warnen einander früh, und jeder Server entscheidet weiterhin selbst, was er sperrt.
03Prinzipien
Zehn Prinzipien, und das erste lautet: Belege vor Autorität.
Vertrauen entsteht durch Daten, die Sie prüfen können, nicht durch ein Abzeichen. Jede Meldung ist signiert, Sie wissen also immer, wer sie geschickt hat.
Ihr Server trifft seine eigenen Entscheidungen. Meldungen anderer sind Ratschläge, niemals Befehle.
Es gibt keinen zentralen Server, der OBIE abschalten oder allen vorschreiben kann, was sie sperren.
Server teilen die Adressen von Angreifern. Die Identität Ihrer Nutzer oder Ihre unbearbeiteten Logs teilen sie nie.
Es gibt keine Kryptowährung und nichts zu handeln. Sie machen mit, weil gemeinsame Abwehr auch Sie schützt.
Wenn eine fähige Fachkraft es nicht an einem Wochenende in Betrieb nehmen kann, ist es Forschung, nicht Produktion.
04Status
Version 0.1 funktioniert im Code von Anfang bis Ende: Ein Server macht aus den Sperren von Fail2Ban signierte Meldungen, teilt sie mit den Peers, die Sie auswählen, entscheidet selbst und sperrt in seiner Firewall, sobald Sie das Sperren einschalten. Das erste Release ist noch nicht veröffentlicht, es gibt noch kein öffentliches Mesh zum Mitmachen, und eine unabhängige Sicherheitsprüfung hat noch nicht stattgefunden. Hier steht, was der Code heute kann und was als Nächstes kommt.
Was Version 0.1 schon kann, was noch nicht und was sie voraussetzt
Den Fortschritt auf GitHub verfolgen05Loslegen
OBIE ist für Fachleute gebaut, die ihre eigenen Linux-Server betreiben. Probieren Sie es zuerst auf Ihrem eigenen Rechner aus, dann auf einem Server.
Starten Sie in einer Kopie des Quellcodes vier OBIE-Knoten in Docker auf Ihrem eigenen Rechner. Melden Sie einen Angriff, sehen Sie zu, wie die anderen entscheiden, und fragen Sie sie nach dem Warum. Dabei wird nie etwas gesperrt, und Root-Rechte brauchen Sie nicht.
cd packaging/sandbox && ./sandbox upInstallieren Sie OBIE auf einem Linux-Server mit systemd und beantworten Sie die fünf Fragen des Einrichtungsassistenten. Der Knoten startet im Beobachtungsmodus: Er zeigt, was er sperren würde, und sperrt nichts.
sudo obied setupDer Selbsttest sagt, was stimmt und was als Nächstes zu beheben ist. Verbinden Sie Fail2Ban und einen Peer, dem Sie vertrauen. Schalten Sie das Sperren erst ein, wenn Sie sicher sind, dass Sie sich nicht selbst aussperren können.
sudo obied self-checkDie Release-Pakete mit dem Installationsprogramm kommen mit dem ersten Release, das noch nicht veröffentlicht ist. Bis dahin wird OBIE aus dem Quellcode gebaut, mit Go 1.26 oder neuer; die Sandbox erledigt das für Sie.
Die Sandbox Schritt für Schritt
06Gründer
Gründer von OBIE · Softwarearchitekt · Geschäftsführer, Cloudwerks Technology GmbH
Markus Niewerth entwickelt seit 15 Jahren Softwaresysteme, die Komplexität verringern. Als Gründer der Cloudwerks Technology GmbH entwirft und baut er ihre Produkte selbst, darunter QuickSelect, Krisis und OBIE, und arbeitet parallel als Softwarearchitekt an Automotive-Plattformen (Software-defined Vehicle, Android Automotive OS). OBIE startete er, nachdem er für ein Projekt Sicherheits-SDKs auf Crowdsourcing-Basis evaluiert hatte und dabei auf das gestoßen war, was er die Zentralisierungsfalle nennt.
Vorschläge, abgeleitet aus den Prinzipien von OBIE. Ein eigenes Thema können Sie im Formular unten vorschlagen.
07Kontakt
Für Vorträge, Workshops, Interviews, Forschungskooperationen und andere Fragen zu OBIE. Ihre Nachricht geht direkt an Markus Niewerth.
Lieber öffentlich fragen? Eröffnen Sie ein Issue auf GitHub08FAQ
Ja. Code und Spezifikation sind Open Source unter der MIT-Lizenz. Es gibt keine Tokens und keine Kryptowährung.
Nicht allein. In Version 0.1 reagiert Ihr Server nur auf Meldungen von Quellen, die Sie selbst als vertrauenswürdig ausgewählt haben: standardmäßig erst, wenn mindestens zwei davon dieselbe Adresse melden (Ihr eigener Server zählt als eine) und ihre gemeinsame Konfidenz ausreicht, und niemals gegen Ihre Schutzliste. Meldungen über private und interne Netzwerkadressen werden von vornherein abgelehnt. Peers, denen Sie vertrauen, könnten sich trotzdem bei einer falschen Meldung einig sein. Deshalb wählen Sie sie sorgfältig aus und können im Beobachtungsmodus beginnen. Automatisch erarbeitetes Vertrauen ist geplant.
Nur signierte Meldungen in dem Format, das die Spezifikation festlegt: die angreifende Adresse, der angegriffene Dienst, wie viele Ereignisse gesehen wurden, ein Begründungscode, ob ein Honeypot den Angriff gesehen hat, die vorgeschlagene Maßnahme, ein Konfidenzwert und wie lange die Maßnahme gelten soll. Optional sind ein Fingerabdruck der Logzeilen, der belegt, was Sie gesehen haben, ohne es offenzulegen, Codes für die Angriffstechnik (MITRE-ATT&CK-IDs) und die Nummer Ihres Netzes (seine ASN). Ein Server kann seine eigene Meldung auch mit einem signierten Widerruf zurückziehen, der einen Begründungscode trägt. Das Format hat keinen Platz für Logs, Benutzernamen, Passwörter oder Freitext. Jeder Knoten, der mit Ihrem Mesh verbunden ist, erhält Ihre Meldungen, ob Sie ihm vertrauen oder nicht, und sieht die Adresse Ihres Servers und seine öffentliche OBIE-ID.
Fail2Ban ist das erste Erkennungswerkzeug, mit dem OBIE zusammenarbeitet: Eine zusätzliche Zeile in einem Jail macht aus seinen Sperren signierte Meldungen. Ein Server braucht kein eigenes Erkennungswerkzeug, um auf Meldungen von Peers zu reagieren, denen er vertraut, und jedes Werkzeug, das einen Befehl ausführen kann, kann eine Adresse melden. Fertige Unterstützung für Honeypots (Köderserver, die Angreifer anlocken) ist geplant.
Noch nicht. Version 0.1 funktioniert von Anfang bis Ende: Sie meldet, teilt, entscheidet und sperrt, sobald Sie das Sperren einschalten. Aber das erste Release ist noch nicht veröffentlicht, eine unabhängige Sicherheitsprüfung hat noch nicht stattgefunden, und Simulationen haben Schwächen gefunden, die noch zu beheben sind (siehe „Status“). Wenn Sie OBIE auf einem Server ausprobieren, beginnen Sie im Beobachtungsmodus, der nichts sperrt, und lesen Sie, was OBIE noch nicht kann.
Nein. Server verbinden sich direkt miteinander. Es gibt keinen zentralen Server, kein Konto und keinen Ausschalter.
OBIE wird offen auf GitHub entwickelt, mit einer öffentlichen Spezifikation und Code unter MIT-Lizenz. Das Unternehmen, das es initiiert hat, ist in der Fußzeile genannt, und der Abschnitt über den Gründer weiter oben stellt die Person vor, die es gestartet hat. Jeder kann den Code lesen, Fehler melden und etwas beitragen.