bitcollector

bitcollector liest einen Host und veröffentlicht, was er findet. Er schreibt niemals auf den Host.

Er beantwortet „was ist auf dieser Maschine, und in welchem Zustand ist sie“ — kontinuierlich, über eine ganze Flotte hinweg, in einer Form, die Sie einem Auditor übergeben und verteidigen können.

Release	0.1.0-ga, Commit 8819759, gebaut mit go1.25.12
Plattformen	Linux amd64/arm64, macOS amd64/arm64, Windows amd64 — siehe Plattformen
Lieferkette	Reproduzierbarer Build, CycloneDX-SBOM, cosign-Signatur, SBOM-Attestierung, signierte SHA256SUMS
Eingehende Netzwerkfläche	Keine. Der einzige Listener bindet ausschließlich Loopback
Schreibzugriffe auf den Host	Sein eigenes Datenverzeichnis und seine Logdatei — dazu jede Datei, die Sie export-pubkey ausdrücklich schreiben lassen

Bevor Sie ihn ausführen, verifizieren Sie den Download.

Was er erfasst und was sein Betrieb kostet, steht weiter unten. Zwei Dinge, die er tut, sind groß genug für eigene Seiten: die Nachweiskette — das Signieren, das Verketten und die Offline-Verifizierung, die die Daten belastbar machen — und Datenschutz und lokale Konten, was ihn in Frankreich ohne Diskussion einsetzbar macht.

Was er erfasst

Neun Collectors, jeder einzeln aktivierbar und jeder mit eigenem Intervall:

Collector	Was er meldet
process	Laufende Prozesse. Kommandozeilen sind standardmäßig aus — siehe Datenschutz
port	Lauschende Ports
software	Installierte Pakete
system	Hardware und Betriebssystem
metrics	Ressourcenmetriken des Hosts
network	Schnittstellen und bestehende Gegenstellen
posture	Aktuelle Sicherheitslage — siehe Posture
accounts	Privilegierte und inaktive lokale Konten — siehe Konten
file	Log- und Datei-Eingaben (Opt-in; in der ausgelieferten Konfiguration deaktiviert)

Zwei Regeln ziehen sich durch alle:

• Jeder Datensatz trägt seinen Erfassungszeitstempel und den Collector, der ihn erzeugt hat.
• „Nicht vorhanden“ und „durfte nicht nachsehen“ sind niemals dieselbe Antwort. Ein Collector, der nicht laufen kann, meldet warum, als vollwertigen Wert. Ein unprivilegierter Agent, der /etc/shadow nicht lesen kann, meldet unknown samt Grund — er meldet niemals ein sauberes Ergebnis, das er nicht beobachtet hat.

Diese zweite Regel ist keine Nettigkeit. Ein Inventar, das stillschweigend „keine Feststellungen“ meldet, obwohl ihm in Wahrheit die Berechtigung verweigert wurde, ist schlimmer als gar kein Inventar, denn Sie werden danach handeln.

Posture: beobachtet, nicht angenommen

Der posture-Collector ist die Eingabe, die aus Tausenden von Feststellungen die wenigen macht, auf die es ankommt: „CVE vorhanden, aber Kontrolle Y ist nachweislich durchgesetzt.“

Alles, was er meldet, ist beobachteter Host-Zustand, nie eine Konfigurationsdatei:

Kontrolle	Gelesen aus
SELinux	/sys/fs/selinux/enforce — dem laufenden Kernel
AppArmor	/sys/module/apparmor/…, /sys/kernel/security/apparmor/…
Firewall	Dem laufenden nftables/iptables/ip6tables-Regelwerk, beide Adressfamilien
sshd	sshd -T (mit Rückfall auf sshd -G) — dem eigenen Parse des Daemons, der Include folgt
Sysctls	/proc/sys/… — nicht /etc/sysctl.conf

Dieser Unterschied ist das Produkt. Eine Konfigurationsdatei sagt, was jemand beabsichtigt hat. sshd -T sagt, was sshd tatsächlich tun wird. Beides weicht häufiger voneinander ab, als irgendjemandem lieb ist, und es ist genau diese Lücke, an der Audits scheitern.

Er ist rein lesend: sechs Listing-Befehle mit festem argv über eine Allowlist, keine Shell, jede Datei mit O_RDONLY geöffnet. Er läuft unprivilegiert und meldet pro Kontrolle, ob die Kontrolle nicht vorhanden war oder ob der Agent nicht nachsehen durfte. Als Root (oder mit CAP_NET_ADMIN) liefert er zusätzlich das Firewall-Regelwerk und das Inventar der AppArmor-Profile.

Der Änderungs-Feed

Vollzustands-Telemetrie in jedem Zyklus ist das, was einen DBA dazu bringt, Ihren Rollout zu blockieren. Der Änderungs-Feed (A4) sendet nur das, was sich geändert hat.

Auf einem echten Referenzhost gemessen, veröffentlicht zusammen mit der Host-Gestalt, die die Messung erzeugt hat:

Vollzustands-Baseline	284.57 KB/Zyklus (Mittel aus 4 aufeinanderfolgenden 60-s-Zyklen, 0.53 % Streuung)
Ausgeliefertes Delta	6.55 KB Mittel, 7.84 KB p95, 10.57 KB im schlechtesten Fall — in allen 21 Zyklen innerhalb des Budgets
Host-Gestalt	558 Prozesse, 714 Pakete, 45 lauschende Ports, 71 bestehende Verbindungen, 32 Schnittstellen, 6 Collectors, command_line: off, non-root

86.36 % der Bytes in den listenförmigen Collectors wiederholen sich in jedem Zyklus wortgleich, und rund 13 % der Prozess-Datensätze „ändern sich“ in jedem Zyklus allein durch die Messwerte für CPU und Speicher — weshalb dies ein Schema-Split ist (Bestandsfakten vs. Messwerte) und kein Diff-Algorithmus. Ein naiver Diff auf Datensatzebene erreichte gemessen nur 7.4× und lag damit immer noch weit über dem Budget.

Ein Delta-Strom rekonstruiert exakt denselben Zustand wie ein vollständiger Snapshot, und ein vollständiger Snapshot verankert den Strom planmäßig neu (standardmäßig snapshot_interval: 6h), sodass ein verlorenes Delta die Sicht der Plattform auf einen Host nicht stillschweigend desynchronisieren kann.

Der Änderungs-Feed wird AUSGESCHALTET ausgeliefert, und das ist Absicht

delta.enabled: false in der ausgelieferten Konfiguration, und ihn einzuschalten ist notwendig, aber nicht hinreichend: Der Agent verlangt zusätzlich, dass die Control Plane signalisiert, dass sie das Protokoll versteht, und sendet bis dahin weiterhin den Vollzustand.

Dieses zweite Tor steckt im Code und nicht in einem Runbook, weil der Fehlermodus stumm ist. Ein Delta, das an einen Empfänger geht, der es nicht versteht, wird stromabwärts weitergereicht, als wäre es eine vollständige Nutzlast — das erzeugt keinen Fehler, es beschädigt still und leise das Bild, das die Plattform von Ihrem Bestand hat. Schalten Sie ihn ein, wenn Ihr Cert-IX-Tenant ihn unterstützt, nicht als Nebeneffekt einer anderen Änderung.

Zwei Domänen laufen überhaupt nicht über den Delta-Pfad: posture und accounts werden ausschließlich über den vollständigen Pfad veröffentlicht, sodass ein Agent mit eingeschaltetem Änderungs-Feed sie nicht senden würde. Diese Grenze steht in der ausgelieferten Konfigurationsdatei und bleibt nicht der Entdeckung überlassen.

Sicher im Produktivbetrieb

Der Zweck dieses Abschnitts ist die Erlaubnis, den Agenten auf einer Maschine zu installieren, auf die es ankommt.

Ressourcen-Obergrenzen werden erzwungen, nicht dokumentiert.

agent:
  max_memory_mb: 50
  max_cpu_percent: 80

• max_memory_mb wird als Speichergrenze der Go-Laufzeit angewendet, sodass der Garbage Collector zunehmend härter arbeitet, um darunter zu bleiben. Sie deckt den Go-Heap, die Goroutine-Stacks und die Laufzeitstrukturen ab. Sie ist kein OOM-Killer: Sie zu überschreiten macht den Agenten langsamer, niemals tot — ein Agent, der sich unter Speicherdruck selbst beendet, hört genau dann auf, Nachweis zu sein, wenn etwas Interessantes passiert.
• max_cpu_percent ist eine Obergrenze für den eigenen Arbeitsanteil des Agenten, als Prozentsatz eines Kerns (80 = 0.8 Kerne). Die Durchsetzung erfolgt durch Aufschieben: Liegt der Mittelwert des Schiebefensters über der Obergrenze, wird der nächste Erfassungs-Tick übersprungen und gezählt. Auslieferung, Heartbeats, die Replay-Queue und der lokale Health-Endpunkt werden niemals aufgeschoben — ein Host unter Last muss weiterhin versenden können, was er bereits hat.

Das Aufschieben ist sichtbar, wenn es passiert:

Collection tick DEFERRED: this agent is above agent.max_cpu_percent. Delivery and
heartbeats are unaffected; the deferral is counted on the local health endpoint so a
permanently throttled agent cannot pass for a quiet host

Null eingehende Netzwerkfläche. Der einzige Listener ist ein lokaler Health-/Metrics-Endpunkt, und er bindet ausschließlich Loopback — 127.0.0.1 und [::1], als zwei explizite Listener, mit den Bind-Adressen als Compile-Time-Konstanten. Es gibt keinen Konfigurationsschlüssel, um ihn zu erweitern, denn ein Listener, den ein Operator erweitern kann, wird irgendwann erweitert.

curl -s 127.0.0.1:9713/status

Ein Watchdog startet einen festgefahrenen Collector neu, ohne den Agenten neu zu starten. Langsam und festgefahren werden durch Messung unterschieden, nicht durch Raten: langsam heißt, der Collector kehrt zu spät zurück (bereits als Timeout gemeldet); festgefahren heißt, sein Kontext wurde abgebrochen und er ist immer noch nicht zurückgekehrt. Die Log-Rotation räumt sowohl nach Größe als auch nach Alter auf, sodass der Agent Ihr /var nicht vollschreiben und Ihnen damit einen Ausfall bescheren kann.

Store-and-Forward. Telemetrie, die nicht zugestellt werden konnte, wird mit Backoff erneut versucht und zugestellt, sobald das Gateway zurück ist. Ein 401 auf dem Telemetrie-Pfad erneuert das Token und versucht es erneut. Was nicht zugestellt werden konnte, ist zurechenbar — eine Lücke ist niemals ununterscheidbar von „es gab keine Daten“.

Ausführen

bitcollector ist ein einzelnes statisches Binary. Verifizieren Sie es zuerst (wie), dann:

# Check what you have
bitcollector --version
# bitcollector 0.1.0-ga (commit: 8819759, built: 2026-08-09T12:08:13Z)

# Run with a configuration file
bitcollector -config /etc/bitcollector/bitcollector.yaml

# Turn up the detail while you are setting it up
bitcollector -config /etc/bitcollector/bitcollector.yaml -log-level debug

Umgebungsvariablen überschreiben die Werte aus der Konfigurationsdatei:

Variable	Zweck
CERTIX_TENANT_ID	Ihr Tenant, aus Settings → Organization
CERTIX_ENROLLMENT_TOKEN	Einmalig verwendbares Enrolment-Token, im Dashboard erzeugt. Erforderlich, sofern keine mTLS-Client-Zertifikate konfiguriert sind
CERTIX_GATEWAY_URL	Agent Gateway (Registrierung, Token-Erneuerung, Richtlinien)
CERTIX_INGEST_URL	Agent Ingestion Gateway (Heartbeat, Telemetrie)
CERTIX_TLS_CA_CERT / CERTIX_TLS_CLIENT_CERT / CERTIX_TLS_CLIENT_KEY	mTLS-Material

Der Agent verweigert den Start, statt ohne eine belegbare Identität zu laufen:

ERROR: Failed to load configuration: missing required configuration:
control_plane.enrollment_token (CERTIX_ENROLLMENT_TOKEN) required when mTLS client
certificates are not configured

Justieren, was er kostet

Die Werte interval: und timeout: je Collector werden beachtet. Jeder aktivierte Collector läuft in seinem eigenen Intervall und füllt einen Cache; ein separater Publish-Tick mit agent.collection_interval sendet einen Batch, der die Domänen trägt, die neue Daten erzeugt haben.

Gemessener Anteil je Collector an einem Batch, damit Sie gegen echte Zahlen justieren können statt gegen eine Vermutung (5 Zyklen à 60 s, non-root, command_line: off):

Collector	Anteil am Batch
process	89.79 %
software	6.85 %
port	1.86 %
system	1.20 %
network	0.27 %
metrics	0.01 %

Der Collector, dessen Intervall Sie verlängern sollten, wenn Sie weniger Bytes wollen, ist process, nicht software.

Es gibt keinen Wert, der „unbegrenzt“ bedeutet

timeout: 0s bedeutet „nicht konfiguriert“: Es wird die eingebaute Voreinstellung verwendet, und der Agent protokolliert eine Warnung, die den Schlüssel nennt. Es ist kein Weg zu sagen „nimm dir so viel Zeit, wie du brauchst“ — alle Collectors teilen sich eine einzige Scheduler-Goroutine, sodass ein Lauf, den nichts abbrechen kann, auch das Veröffentlichen, den Heartbeat und jeden anderen Collector anhält. Setzen Sie die längste Dauer, die ein gesunder Lauf auf diesem Host braucht, mit Reserve.

Plattformen

0.1.0-ga veröffentlicht fünf signierte Binaries, und nichts wird zurückgehalten — bitcollector ist das einzige bit, das auf jeder Plattform ausgeliefert wird, die die Familie adressiert:

Plattform	Veröffentlicht	Anmerkungen
Linux amd64	Ja
Linux arm64	Ja
macOS amd64	Ja
macOS arm64	Ja
Windows amd64	Ja	Wird als bitcollector-windows-amd64.exe ausgeliefert

Er kann das, weil er liest, und jeder Collector hat eine Implementierung je Betriebssystem, mit einer ausdrücklichen Antwort „hier nicht verfügbar“ dort, wo eine Plattform keine Entsprechung hat. Die anderen drei bits halten jeweils mindestens eine Plattform zurück, und jede ihrer Seiten sagt, welche und warum — bitscanner, bitenforcer, bitmapper.

Auf einer Plattform ausgeliefert zu werden ist nicht dasselbe, wie dort alles zu beobachten. Kontrollen, die der Agent auf einem bestimmten Betriebssystem nicht liest, werden mit einem eigenen Status gemeldet — vom Agenten auf dieser Plattform nicht unterstützt — der die Plattform als Quelle trägt und die ausdrückliche Anweisung, die Kontrolle nicht als fehlend zu bewerten. Es ist eine Aussage über den Agenten, niemals ein Befund über den Host.

Das ist dieselbe Regel wie überall sonst auf dieser Seite: fehlend, nicht nachsehen dürfen und auf dieser Plattform nicht beobachtet sind drei verschiedene Antworten, und keine davon ist ein Unbedenklichkeitsnachweis.

Nächste Schritte

• Die Nachweiskette — wie ein Batch signiert, verkettet und offline von jemandem verifiziert wird, der uns nicht vertraut.
• Datenschutz und lokale Konten — was über Personen erfasst wird, was nicht, und wofür Sie sich aktiv entscheiden müssen.
• Ihre Downloads verifizieren — tun Sie das vor der ersten Installation.
• bitenforcer — die andere Hälfte des Paares.
• Asset Management — wo die Telemetrie landet.