danthegoodman1/netfenceWie Envoy xDS, aber für eBPF-Filter
Wie Envoy xDS, aber für eBPF-Filter.
Netfence läuft als Dienstprogramm auf Ihren VM/Container-Hosts und injiziert automatisch eBPF-Filterprogramme in Cgroups und Netzwerkschnittstellen, mit einem integrierten DNS-Server, der erlaubte Domänen auflöst und die IP-Erlaubnisliste befüllt.
Netfence-Daemons können allein über ihre lokale Unix-Socket-API gesteuert werden oder sich mit einer zentralen Steuerungsebene verbinden, die Sie über gRPC implementieren, um Erlaubnislisten/Sperrlisten mit Ihrem Backend zu synchronisieren.
Ihre Steuerungsebene schiebt Netzwerkregeln wie ALLOW *.pypi.org oder ALLOW 10.0.0.0/16 an angehängte Schnittstellen/Cgroups. Wenn eine VM/ein Container DNS abfragt, löst Netfence dies auf, fügt die IPs zum eBPF-Filter hinzu und verwirft den Verkehr zu unbekannten IPs, bevor er den Host verlässt, mit einem Overhead auf dem warmen Pfad, der in aktuellen Benchmarks praktisch nicht von einem normalen Socket-Connect zu unterscheiden ist.
Im Erlaubnislistenmodus ist IPv4-Link-Local (169.254.0.0/16) standardmäßig nicht mehr automatisch erlaubt – der Cloud-Metadatendienst (169.254.169.254) ist also blockiert, sofern nicht explizit erlaubt. Dies ist beabsichtigt: Der Metadatendienst ist ein Ziel für Credential-Diebstahl, und sandboxed Workloads müssen ihn nicht implizit erreichen können. Localhost (127.0.0.0/8, ::1) und IPv6-Nachbarschaftserkennung (fe80::/10, ff02::/16) bleiben standardmäßig erlaubt, damit grundlegende Konnektivität und NDP funktionieren. Um den Metadatendienst für einen Workload zuzulassen, erlauben Sie 169.254.169.254/32 (eine Überschreibung pro Anhang über die Steuerungsebene ist als geplante Erweiterung vorgesehen).
IPv4-Broadcast (255.255.255.255) und Multicast (224.0.0.0/4) haben keine Ausnahme und unterliegen der Richtlinie. Daher wird im TC-Erlaubnislistenmodus Verkehr wie DHCP-Erneuerungs-Broadcasts blockiert, sofern nicht explizit erlaubt. Ausnahme-Prüfungen laufen vor der Sperrliste, daher kann ein ausgenommener Bereich nur blockiert werden, indem seine Ausnahme deaktiviert wird – und da IPv4-Link-Local jetzt standardmäßig deaktiviert ist, kann der Sperrlistenmodus auch den Metadatendienst blockieren.
Einige wesentliche Vorteile dieser Lösung, die andere Optionen normalerweise nicht bieten:
secretdata.someattacker.com gibt)Meines Wissens nach bietet keine andere Lösung alle diese Funktionen zusammen.
Bekannte Einschränkung: Cgroup-Anhänge filtern auf der Socket-Ebene (connect/sendmsg-Hooks), daher kann ein Prozess mit CAP_NET_RAW Rohpakete erstellen, die diese umgehen. Verwenden Sie einen TC-Anhang (Schnittstelle), der auf der Geräteebene filtert, für Workloads, die CAP_NET_RAW halten könnten.
Allerdings hat dies etwas mehr Overhead als so etwas wie httpjail.
Diese Zahlen wurden im privilegierten Docker-Linux-Gate auf linux/arm64 mit make bench-docker gemessen. Die Werte sind Mediane von fünf Stichproben.
Der Warm-Socket-Benchmark verwendet verbundene UDP-Sockets, um die Kosten des EBPF-Hooks cgroup/connect4 von der TCP-Handshake-Latenz zu isolieren. In diesem Pfad hat DNS die Domäne bereits aufgelöst, die IP liegt noch innerhalb der TTL, und die IP/CIDR ist bereits in der eBPF-Karte vorhanden.
| Path | Median latency |
|---|---|
| Normale Socket-Verbindung, kein eBPF | ~2.647 us |
| Warme Erlaubnisliste, geschützter LPM-Treffer | ~2.691 us |
| Warme Erlaubnisliste, DNS-Exact-Host-Treffer | ~2.741 us |
| Erlaubnislisten-Fehltreffer, lokale Sperre | ~1.652 us |
Die gemessene Streuung zwischen den normalen, geschützten LPM- und DNS-Exact-Host-Verbindungspfaden liegt innerhalb der Stichprobenvarianz.
Es gibt derzeit keinen Pfad 'Kernel-Fehltreffer fragt Elternprozess'. Ein Fehlschlag der Cgroup-Erlaubnisliste wird lokal durch eBPF entschieden und sofort blockiert.
Diese Zahlen messen den DNS-Serverpfad, nicht den gewärmten Socket-Verbindungspfad.
| Path | Median latency |
|---|---|
| Proxy-Abfrage kalt, prozessinterne Richtlinienfunktion | ~31.336 us |
| Proxy-Abfrage warm | ~27.964 us |
| Erlaubnislisten-Abfrage kalt mit lokalem Upstream | ~53.510 us |
| Erlaubnislisten-Abfrage warm mit lokalem Upstream | ~53.432 us |
Kalte Zeilen synchronisieren durch die reale Anhangs-Mutationsbarriere und leeren den Benchmark-Besitzgraphen und den gefälschten Exact-Map-Snapshot zwischen den Abfragen. Der Timer läuft kontinuierlich, um die UDP-Scheduler-Lokalität zu erhalten, während ns/op die separat gemeldete fixture-reset-ns/op-Wandzeit abzieht (einschließlich eines eventuellen Nachlaufs des vorherigen Handlers, nachdem der Client sein Paket erhalten hat) und somit die aktuelle Client-Exchange misst. raw-total-ns/op meldet beide zusammen. Der Reset bewahrt die konfigurierten Richtliniendomänen und den Backing-Speicher, und der Benchmark behauptet einen physischen Exact-Map-Add pro Abfrage. Warme Zeilen initialisieren den Besitz einmal und behaupten einen physischen Add über den gesamten Lauf.
Die folgenden internen Besitz-Mikrobenchmarks sind Skalierungsdiagnostiken, keine End-to-End-DNS-Abfragepfad-Akzeptanzzeilen. Der gecachte Helfer wird nur für Tests und Benchmarks beibehalten; er kapselt jeweils einen Datensatz und wiederholt die Domänenvalidierung. Sowohl er als auch normaler Resolver-Traversal durchlaufen die Anhangs-Mutationsbarriere, während normaler Resolver-Traversal jede vollständige Antwort als eine Transaktion akzeptiert.
| Internal scalability diagnostic | Current median | Memory / allocations |
|---|---|---|
| Kalte Neuaufnahme eines Schlüssels, leerer Besitzgraph | ~370.3 ns | 232 B, 5 allocs/op |
| Kalte Neuaufnahme eines Schlüssels, 4.095 nicht verwandte Einträge | ~451.2 ns | 232 B, 5 allocs/op |
| Physischer Kapazitätsdruck und LRU-Ersatz | ~3.820 ms | ~4.23 MB (4,226,243 B), 4,336 allocs/op |
| Vorabprüfung des erschöpften physischen Budgets | ~611.9 ns | 344 B, 9 allocs/op |
| Maximaler Kantendruck, 64-Adress-Antwort | ~6.849 ms | ~7.66 MB (7,658,774 B), 2,233 allocs/op |
| Maximaler Graph-Arbeitswächter, erlaubter vollständiger Plan | ~2.763 ms | ~4.26 MB (4,264,386 B), 3,074 allocs/op |
| Maximaler Graph-Arbeitswächter, erschöpfte Vorprojektionsablehnung | ~10.935 us | 8.76 KB (8,760 B), 14 allocs/op |
| Churn-Budget-Operation nahe der numerischen Obergrenze | ~18.98 ns | 0 B, 0 allocs/op |
| Kohärenter Besitz-Statistik-Snapshot | ~2.094 ns | 0 B, 0 allocs/op |
| No-op-Ablaufscan über 4.095 Einträge | ~74.849 us/scan | 0 B, 0 allocs/op |