📦 bits ist allgemein verfügbar — vier signierte Agenten, die Sie herunterladen und verifizieren können

Die bits-Familie — die Agenten, die auf Ihren eigenen Maschinen laufen — ist ab sofort über die Download-Seite beziehbar. Vier Binaries, jedes mit demselben Schlüssel signiert, jedes vor der Ausführung verifizierbar.

Agent	Version	Was er tut	Plattformen
bitcollector	v0.1.0-ga	Beweisfähige Asset-Wahrheit von einem Host: Prozesse, Pakete, Ports, Konten, Sicherheitslage	Linux amd64/arm64, macOS amd64/arm64, Windows amd64
bitscanner	v0.1.3-ga	Findet die Geräte, die Ihr Inventar nicht enthält	Linux amd64/arm64
bitenforcer	v0.1.0-ga	Validierung von Härtungsrichtlinien und Pre-Flight	Linux amd64/arm64
bitmapper	v0.1.0-ga	Live-Mitschnitt von Verbindungen — Endpunkte, Ports, Protokoll, Zähler, Verbindungszustand. Keine Prozesszuordnung in diesem Release	Linux amd64

Korrektur: bitmapper v0.1.0-ga ordnet Flows keinen Prozessen zu

In der Zeile oben stand zunächst „Live-Mitschnitt von Verbindungen mit Zuordnung je Prozess", und der bitmapper-Eintrag unter Wofür jeder Agent da ist behauptete, bitmapper melde, „welche Prozesse tatsächlich womit sprechen, zugeordnet je Verbindung". Beides war für das Binary, das dieser Beitrag ankündigt, falsch — und zwar falsch in der Richtung, die Sie etwas kostet: Die Zuordnung je Prozess ist das, was bitmapper von einem Scanner außerhalb des Hosts unterscheidet, und sie ist der eigentliche Grund, ihn auszurollen.

Gemessen am veröffentlichten 0.1.0-ga — Commit 64ebc64, das Artefakt, das heute auf der Download-Seite liegt — trug kein einziger von 12 mitgeschnittenen Flows irgendeine Prozesszuordnung, darunter ein 60 Sekunden langer Flow, dessen besitzender Prozess durchgehend lebte und abfragbar war. destination_process wurde außerhalb von Testcode nie befüllt. In diesem Build wird die Auflösung genau einmal versucht, beim Anlegen der Verbindung, gegen einen Schnappschuss der Socket-Tabellen, der den Socket einer eben erst entstandenen ausgehenden Verbindung gar nicht enthalten kann; kein späteres Paket versucht es erneut, und es gibt keine Ableitung aus lauschenden Sockets, auf die zurückgefallen werden könnte — dieser Code steckt in 64ebc64 schlicht nicht drin.

Was v0.1.0-ga tatsächlich tut, ist passiver Flow-Mitschnitt, und dieser Teil ist echt. Jede verfolgte Verbindung wird als Flow-Datensatz exportiert: Quell- und Zielendpunkte, Ports, Protokoll, Verbindungszustand, Richtung, Schnittstelle, erste und letzte Beobachtung, Dauer sowie Byte- und Paketzähler — und niemals ein einziges Nutzdaten-Byte. Das ist eine brauchbare Antwort auf „womit spricht diese Maschine". Es ist keine Antwort auf „welcher Prozess tut es".

Die Zuordnung je Prozess ist implementiert und verifiziert — sie steckt nur nicht in dem Binary, das Sie herunterladen können. Auf demselben Prüfstand, der 0 von 12 gemessen hat, ordnet der Nachfolger 12 von 12 zu, schreibt die Antwort an das Ende, dem der Socket wirklich gehört, und trennt einen direkten Socket-Treffer von einer Ableitung — und benennt niemanden, wenn an einem Port mehrere Prozesse lauschen. Sie kommt mit dem nächsten bitmapper-Release. Ein Datum hängen wir hier nicht daran: Wir haben Ihnen bereits einmal gesagt, diese Fähigkeit sei ausgeliefert, als sie es nicht war.

Wenn Sie bitmapper im Vertrauen auf den ursprünglichen Satz heruntergeladen haben, ist das unser Fehler. Prozesszuordnung legt genau dar, was das heutige Binary auflöst und was es ablöst.

Warum manche Agenten weniger Plattformen aufführen als andere

Weil ein Binary, das sich installiert, sich als gesund meldet und nichts erfasst, schlechter ist als gar kein Binary.

Jede Plattform in dieser Tabelle ist eine, auf der der Agent seine Arbeit tut. Wo er das nicht täte, haben wir ihn nicht veröffentlicht — und wir sagen das lieber, als Sie es nach einem Rollout entdecken zu lassen:

• bitenforcer läuft nur unter Linux. Seine gesamte Oberfläche sind iptables, sysctl, systemd und SELinux. Unter macOS gibt es das nicht, der Agent würde also nichts validieren, und seine Rollback-Primitive hätten nichts wiederherzustellen.
• bitmapper läuft nur unter Linux amd64. Er braucht eine echte, einkompilierte Bibliothek für den Paketmitschnitt. Ein Build ohne sie erzeugt trotzdem ein lauffähiges Binary — eines, das überhaupt nichts mitschneidet —, deshalb verweigert unsere Release-Pipeline die Signatur für ein Artefakt, das nicht nachweislich mitschneiden kann.
• bitscanner läuft nur unter Linux, aus derselben Art von Grund: Seine Leser für Nachbarn und Routen sind für Linux implementiert.

Wir gehen davon aus, dass diese Listen wachsen. Wenn sie es tun, dann weil der Agent auf dieser Plattform erprobt wurde, nicht weil er sich kompilieren ließ.

Verifizieren, bevor Sie ausführen

Jedes Release liefert je Binary eine abgetrennte Signatur, eine SBOM und eine Build-Attestierung, dazu eine signierte SHA256SUMS über den gesamten Satz. Die Builds sind reproduzierbar: Die Pipeline baut zweimal von Grund auf neu und verweigert die Veröffentlichung, sofern beide nicht byte-identisch sind.

Der Signaturschlüssel ist an drei unabhängigen Stellen veröffentlicht, die übereinstimmen müssen: auf der Dokumentationsseite, in einem DNS-TXT-Record mit seinem Fingerabdruck und in einem zweiten TXT-Record mit dem Schlüssel selbst. Gleichen Sie mindestens zwei davon ab. Eine Signatur ist nur so viel wert wie der Vertrauensanker dahinter, und eine einzige Quelle ist ein Ritual, keine Prüfung.

# Den Schlüssel über DNS beziehen — funktioniert in der CI, wo Bot-Schutz einfache HTTPS-Abrufe blockiert
dig +short TXT _cosign-key.cert-ix.com | tr -d '"' | sed 's/.*key=//' \
  | base64 -d | openssl pkey -pubin -inform DER -out cosign.pub

# Bestätigen, dass es UNSER Schlüssel ist — gegen den auf der Dokumentationsseite veröffentlichten Fingerabdruck
openssl pkey -pubin -in cosign.pub -outform DER | sha256sum
# erwartet: 552839f6b1b1eb0934557e1886326c7270584fa602fbf56f84754a98be3de822

# Dann das heruntergeladene Release verifizieren
cosign verify-blob --key cosign.pub --bundle SHA256SUMS.sig \
  --insecure-ignore-tlog=true SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS

DNS ist der Transport, nicht der Vertrauensanker

cert-ix.com veröffentlicht noch keinen DS-Record, DNS-Antworten sind daher nicht kryptografisch Ende-zu-Ende validiert. Den Schlüssel über DNS zu beziehen, ist bequem und funktioniert dort, wo HTTPS blockiert ist — aber was Vertrauen herstellt, ist der Abgleich des Fingerabdrucks mit der Dokumentationsseite, geladen über HTTPS, mit validiertem Zertifikat. Überspringen Sie ihn nicht.

Die vollständige Anleitung — wozu jede Datei in einem Release da ist und wie eine fehlgeschlagene Prüfung aussieht — steht unter Ihre Downloads verifizieren.

Wofür jeder Agent da ist

• bitcollector — was auf dieser Maschine ist, als Nachweis statt als Behauptung. Jeder Batch ist attestiert, und die Kette lässt sich offline verifizieren, ganz ohne Zugriff auf Cert-IX.
• bitscanner — die Geräte, die ein agentenbasiertes Inventar bauartbedingt nicht sehen kann, weil auf ihnen nichts installiert ist. Wird inert ausgeliefert: Er bringt kein einziges Paket in Ihr Netz, bis Sie ihn ausdrücklich scharfstellen, und die Freigabe kann nicht aus einer Umgebungsvariable kommen.
• bitenforcer — was eine Härtungsrichtlinie ändern würde, bevor sie irgendetwas ändert. v1 validiert und berichtet; sie wendet nichts an.
• bitmapper — womit diese Maschine tatsächlich spricht, Flow für Flow: Endpunkte, Ports, Protokoll, Zähler und Verbindungszustand, live von ihren eigenen Schnittstellen mitgeschnitten. In v0.1.0-ga tragen diese Flows keine Prozesszuordnung — lesen Sie die Korrektur oben, bevor Sie darauf aufbauen.

Wo Sie anfangen

Laden Sie einen Agenten herunter, verifizieren Sie ihn und lesen Sie die Seite zu dem, für den Sie sich entschieden haben. Wenn Sie unsicher sind, welcher es sein soll: Was ist bits? erklärt, wie die vier zusammenpassen und — genauso wichtig — was jeder von ihnen bewusst nicht tut.