eBPF-Backstop verbinden

Der Kernel-Level-eBPF-Observer -- nicht-kooperative Ground Truth fuer Datei- und Netzwerk-I/O, die kein Agent umgehen kann.

Der eBPF-Backstop ist der nicht-kooperative Ground-Truth-Observer. Er haengt sich an Kernel-Syscall-Tracepoints an und meldet Datei- und Netzwerk-I/O als Zugriffskarten-Kanten, die kein Userspace-Agent umgehen, deaktivieren oder falsch darstellen kann. Wo kooperative Telemetrie dem Agenten vertraut, ehrlich zu berichten, tut der Backstop das nicht — er beobachtet den Kernel, nicht den Agenten.

Fuer das allgemeine Quellmodell und die OLIVARES_SOURCES_CONFIG-Struktur siehe Eine Quelle verbinden. Fuer den kooperativen Pfad, den der Backstop ergaenzt, siehe Claude Code verbinden.

Was er beobachtet

Der Backstop instrumentiert Kernel-Level-Syscalls — open, read, write, connect, sendto, recvfrom und ihre Varianten — und gibt eine Beobachtung pro relevantem I/O-Ereignis aus. Die Lese-/Schreibklassifikation kommt vom Syscall selbst, nicht von dem, was der Agent behauptet, sodass sie autoritativ ist auf dieselbe Weise wie pgAudits READ/WRITE-Klasse autoritativ ist: Der Kernel hat die Operation ausgefuehrt, also fand die Operation statt.

Das Ergebnis ist ein Strom von Zugriffskarten-Kanten, die Datei- und Netzwerk-I/O einer Prozessidentitaet auf dem Host zuordnen. Diese Kanten speisen dieselbe Zugriffskarte wie jede andere Quelle.

Warum er existiert

Kooperative Telemetrie — OpenTelemetry-Exporte, Hook-Payloads, MCP-Introspektion — ist reichhaltiger und hoeherwertig, aber sie ist kooperativ: Der Agent ist derjenige, der sie emittiert. Ein Agent, der seinen OTel-Exporter deaktiviert, oder eine Runtime, die nie einen hatte, produziert ueberhaupt kein kooperatives Signal.

Der eBPF-Backstop schliesst diese Luecke. Ein Agent, der aufhoert, Telemetrie zu exportieren, macht weiterhin Syscalls; der Kernel sieht sie weiterhin; der Backstop meldet sie weiterhin. Das ist die Ground Truth, auf die das Dokument Claude Code verbinden verweist:

Ground Truth fuer wirklich nicht-kooperative Aktivitaet ist der Kernel/eBPF-Backstop, nicht diese Heuristik.

Diese Heuristik — das Erkennen einer Sitzung, die aufhoert, OTel zu emittieren, waehrend ihre Hooks weiter feuern — ist ein kooperativseitiges Anomaliesignal. Der Backstop macht die nicht-kooperative Seite beobachtbar.

Abdeckungsstufe

Der Backstop ist clean-Stufe im Genauigkeitsmodell. Lesen vs Schreiben wird vom Syscall bestimmt, nicht von dem, was der Agent behauptet. Das Genauigkeitsdokument listet ihn neben pgAudit und CloudTrail: “die Kernel-Level eBPF Ground Truth.” Saubere Abdeckung impliziert nicht saubere Zuordnung — siehe Grenzen unten.

Wann ihn verwenden vs kooperative Beobachtung

Sie ergaenzen sich; sie ersetzen sich nicht gegenseitig.

Kooperativ (OTel, Hooks, MCP) — hoeher-Level-Kontext: Sitzungen, Tools, Modelle, Kosten. Die reichhaltigere Karte.
Nicht-kooperativ (eBPF) — die Anti-Evasion-Garantie: Was tatsaechlich auf Kernel-Ebene passiert ist, unabhaengig davon, was der Agent zu berichten gewaehlt hat.

Betreiben Sie beides. Der kooperative Pfad baut die reichhaltige Karte, gegen die Sie steuern. Der Backstop bietet den unfaelschbaren Boden, der alles auffaengt, was der kooperative Pfad verpasst hat — Evasion, Fehlkonfiguration oder eine Runtime ohne Telemetrie.

Deployment-Modell

Der Backstop laeuft auf jedem Host, auf dem Agenten ausfuehren, im Standard-serve als Source-Kind ebpf verdrahtet neben pgaudit, s3cloudtrail, runtime, mcp und claude. Weil eBPF-Programme sich an den Host-Kernel anhaengen, deckt eine Instanz pro Host jeden Agentenprozess ab. Es gibt keinen Pro-Agent-Installationsschritt.

Linux-Capabilities

eBPF-Tracing erfordert erhoehte Kernel-Privilegien. Mindestens braucht der Prozess, der die eBPF-Programme laedt, Capabilities in der CAP_BPF- und CAP_PERFMON-Familie (oder Aequivalent, abhaengig von der Kernel-Version — aeltere Kernel fassen diese in CAP_SYS_ADMIN zusammen).

:::caution Der genaue Capability-Satz haengt von Ihrer Kernel-Version, Distribution und Sicherheitsmodul (AppArmor, SELinux) ab. Pruefen Sie die eigene Dokumentation des Konnektors fuer die praezisen erforderlichen Flags — diese Seite listet keinen definitiven Satz auf, weil er ueber Umgebungen hinweg variiert. Der Betrieb in einem Container erfordert explizite Capability-Grants (und moeglicherweise ein BPF-Dateisystem-Mount); ein gesperrter Kubernetes-Pod braucht securityContext-Overrides. :::

Konfiguration

Waehlen Sie kind: "ebpf" in OLIVARES_SOURCES_CONFIG, mit derselben Quelleintrag-Struktur wie bei jedem anderen Konnektor:

{
  "sources": [
    {
      "name": "host-backstop",
      "kind": "ebpf",
      "tenant": "acme",
      "config": {}
    }
  ]
}

Die genauen Config-Keys gehoeren dem Konnektor; lesen Sie seinen Deskriptor, anstatt ein unverifiziertes Schema zu kopieren. Das config-Objekt oben ist absichtlich leer — diese Seite folgt derselben Regel wie Eine Quelle verbinden: Wir dokumentieren nur Schluessel, die wir verifiziert haben, und wir haben die Config-Oberflaeche des eBPF-Konnektors von diesen Web-Docs aus nicht verifiziert.

Anti-Evasion-Eigenschaften

Der Backstop haengt nicht von Agentenkooperation ab:

Ein Agent, der seinen OTel-Exporter deaktiviert, generiert weiterhin Kernel-Syscalls — der Backstop sieht diese.
Ein Agent, der in seiner kooperativen Telemetrie luegt, kann den Kernel nicht beluegen. Der Syscall-Datensatz ist autoritativ.
Ein MCP-Server, der readOnlyHint / destructiveHint falsch meldet, beeinflusst nicht, was der Backstop beobachtet — das sind kooperative Signale, die er nicht konsumiert.

Die kooperativseitige Heuristik in Claude Code verbinden — eine Sitzung, deren OTel verstummt, waehrend Hooks weiter feuern — ist ein Erkennungssignal. Der Backstop ist die Ground Truth, auf die dieses Signal zeigt.

Ehrliche Grenzen

Der Backstop beobachtet, was der Kernel sieht, nicht was der Agent beabsichtigt. Diese Unterscheidung ist wichtig:

Die Zuordnung ist auf Prozessebene. I/O wird einer Prozessidentitaet zugeordnet (PID, UID, Binary-Pfad). Wenn mehrere Agenten einen Prozess teilen, kann der Backstop ihre Zugriffe nicht trennen — die Zuordnung ist approximate, nicht firm. Pro-Agent-Zuordnung erfordert ein Pro-Agent-Identitaetssignal; siehe Genauigkeit.
Kein Sitzungs- oder Tool-Kontext. Der Backstop sieht Syscalls, keine Sitzungen oder Tool-Namen. Er kann Ihnen nicht sagen, welcher Tool-Call einen Dateischreibvorgang ausgeloest hat — nur dass der Prozess die Datei geschrieben hat. Der kooperative Pfad traegt diesen Kontext.
Kernel-Versions-Abhaengigkeit. Die Verfuegbarkeit von eBPF-Tracepoints variiert ueber Kernel-Versionen. Bestaetigen Sie die Minimum-Kernel-Version gegen die eigene Dokumentation des Konnektors.
Kein Payload-Inhalt. Wie jede Quelle gibt der Backstop Identifikatoren und eine Lese-/Schreibklassifikation aus, nie Dateiinhalte oder Netzwerk-Payloads.