danthegoodman1/netfenceComme Envoy xDS, mais pour les filtres eBPF
Comme Envoy xDS, mais pour les filtres eBPF.
Netfence s'exécute en tant que démon sur vos hôtes de VM/containers et injecte automatiquement des programmes de filtrage eBPF dans les cgroups et les interfaces réseau, avec un serveur DNS intégré qui résout les domaines autorisés et remplit la liste blanche d'adresses IP.
Les démons Netfence peuvent être pilotés uniquement via leur API locale sur socket Unix, ou se connecter à un plan de contrôle central que vous implémentez via gRPC pour synchroniser les listes blanches/noires avec votre backend.
Votre plan de contrôle envoie des règles réseau comme ALLOW *.pypi.org ou ALLOW 10.0.0.0/16 aux interfaces/cgroups attachés. Quand une VM/container interroge le DNS, Netfence le résout, ajoute les IP au filtre eBPF, et bloque le trafic vers des IP inconnues avant qu'il ne quitte l'hôte, avec une surcharge de chemin préchauffé pratiquement indistinguable d'un socket connect normal dans les benchmarks actuels.
En mode liste blanche, le lien-local IPv4 (169.254.0.0/16) n'est plus automatiquement autorisé par défaut — donc le service de métadonnées cloud (169.254.169.254) est bloqué sauf s'il est explicitement ajouté à la liste blanche. C'est délibéré : le service de métadonnées est une cible de vol d'identifiants, et les charges de travail en bac à sable ne doivent pas pouvoir l'atteindre implicitement. Localhost (127.0.0.0/8, ::1) et la découverte de voisinage IPv6 (fe80::/10, ff02::/16) restent autorisés par défaut pour que la connectivité de base et le NDP continuent de fonctionner. Pour autoriser le service de métadonnées pour une charge de travail, ajoutez 169.254.169.254/32 à la liste blanche (une dérogation par attachement via le plan de contrôle est prévue dans une prochaine version).
La diffusion IPv4 (255.255.255.255) et le multicast (224.0.0.0/4) n'ont pas de dérogation et sont soumis à la politique, donc en mode liste blanche TC, le trafic comme les broadcasts de renouvellement DHCP est bloqué sauf autorisation explicite. Les vérifications de dérogation s'effectuent avant la liste noire, donc une plage dérogée ne peut être bloquée qu'en désactivant sa dérogation — et comme le lien-local IPv4 est maintenant désactivé par défaut, le mode liste noire peut aussi bloquer le service de métadonnées.
Quelques avantages majeurs de cette solution que les autres options ne proposent généralement pas :
secretdata.someattacker.com)À ma connaissance, aucune autre solution n'offre toutes ces fonctionnalités ensemble.
Limitation connue : les attachements cgroup filtrent au niveau socket (hooks connect/sendmsg), donc un processus avec CAP_NET_RAW peut fabriquer des paquets bruts qui les contournent. Utilisez un attachement TC (interface), qui filtre au niveau de la couche dispositif, pour les charges de travail pouvant détenir CAP_NET_RAW.
Cependant, cela a un peu plus de surcharge que quelque chose comme httpjail.
Ces mesures ont été effectuées dans la passerelle Docker privilégiée sur linux/arm64 en utilisant make bench-docker. Les valeurs sont les médianes de cinq échantillons.
Le benchmark de socket à chaud utilise des sockets UDP connectés pour isoler le coût du hook eBPF cgroup/connect4 de la latence de la poignée de main TCP. Dans ce chemin, le DNS a déjà résolu le domaine, l'IP est toujours dans le TTL, et l'IP/CIDR est déjà présente dans la map eBPF.
| Chemin | Latence médiane |
|---|---|
| Connexion socket normale, sans eBPF | ~2,647 us |
| Liste blanche à chaud, hit LPM protégé | ~2,691 us |
| Liste blanche à chaud, hit hôte exact DNS | ~2,741 us |
| Échec de liste blanche, blocage local | ~1,652 us |
L'écart mesuré entre les chemins de connexion normal, LPM protégé et hôte exact DNS se situe dans le bruit de l'échantillon.
Il n'existe pas aujourd'hui de chemin « échec noyau demande au processus parent ». Un échec de liste blanche cgroup est décidé localement par eBPF et est bloqué immédiatement.
Ces chiffres mesurent le chemin du serveur DNS, pas le chemin de connexion socket à chaud.
| Chemin | Latence médiane |
|---|---|
| Requête proxy à froid, fonction de politique dans le processus | ~31,336 us |
| Requête proxy à chaud | ~27,964 us |
| Requête liste blanche à froid avec amont local | ~53,510 us |
| Requête liste blanche à chaud avec amont local | ~53,432 us |
Les lignes « à froid » synchronisent via la barrière de mutation d'attachement réelle et effacent le graphe de propriété du benchmark et l'instantané de map exacte fictive entre les requêtes. Le minuteur tourne en continu pour préserver la localité du planificateur UDP, tandis que ns/op soustrait le fixture-reset-ns/op (incluant toute queue du gestionnaire précédent après que le client a reçu son paquet) et mesure ainsi l'Exchange du client actuel. raw-total-ns/op rapporte les deux ensemble. La réinitialisation préserve les domaines de politique configurés et le stockage de sauvegarde, et le benchmark affirme une addition physique de map exacte par requête. Les lignes « à chaud » amorcent la propriété une fois et affirment une addition physique sur l'ensemble de l'exécution.
Les microbenchmarks de propriété interne ci-dessous sont des diagnostics de passage à l'échelle, pas des lignes d'acceptation de chemin de requête DNS de bout en bout. L'helper en cache n'est conservé que pour les tests et benchmarks ; il encapsule un enregistrement à la fois et répète la validation du domaine. Lui et le trafic normal du résolveur traversent la barrière de mutation d'attachement, tandis que le trafic normal du résolveur admet chaque réponse complète comme une transaction.