danthegoodman1/netfenceComo Envoy xDS, pero para filtros eBPF
Como Envoy xDS, pero para filtros eBPF.
Netfence se ejecuta como un daemon en tus hosts de VM/contenedores e inyecta automáticamente programas de filtro eBPF en cgroups e interfaces de red, con un servidor DNS integrado que resuelve dominios permitidos y llena la lista de IPs permitidas.
Los daemons de Netfence pueden manejarse a través de su API local de socket Unix, o conectarse a un plano de control central que implementes vía gRPC para sincronizar listas permitidas/denegadas con tu backend.
Tu plano de control envía reglas de red como ALLOW *.pypi.org o ALLOW 10.0.0.0/16 a las interfaces/cgroups adjuntos. Cuando una VM/contenedor consulta DNS, Netfence lo resuelve, añade las IPs al filtro eBPF, y descarta el tráfico hacia IPs desconocidas antes de que salga del host, con una sobrecarga de ruta caliente que es efectivamente indistinguible de una conexión de socket normal en los benchmarks actuales.
En modo lista permitida, el enlace local IPv4 (169.254.0.0/16) ya no está permitido automáticamente
por defecto — por lo que el servicio de metadatos en la nube (169.254.169.254) está bloqueado a menos
que se incluya explícitamente en la lista permitida. Esto es deliberado: el servicio de metadatos es un
objetivo de robo de credenciales, y las cargas de trabajo en sandbox no deben poder alcanzarlo
implícitamente. Localhost (127.0.0.0/8, ::1) y el descubrimiento de vecinos IPv6
(fe80::/10, ff02::/16) permanecen permitidos por defecto para que la conectividad básica y NDP
sigan funcionando. Para permitir el servicio de metadatos para una carga de trabajo, incluya
169.254.169.254/32 en la lista permitida (una anulación de exclusión por adjunto a través del plano de control
es un seguimiento planificado).
El broadcast IPv4 (255.255.255.255) y el multicast (224.0.0.0/4) no tienen exclusión y están sujetos a la política, por lo que en modo TC lista permitida el tráfico como las renovaciones DHCP broadcast se bloquea a menos que se incluya explícitamente en la lista permitida. Las comprobaciones de exclusión se ejecutan antes de la lista denegada, por lo que un rango excluido solo puede bloquearse desactivando su exclusión — y dado que el enlace local IPv4 ahora está desactivado por defecto, el modo lista denegada también puede bloquear el servicio de metadatos.
Algunos beneficios importantes de esta solución que otras opciones normalmente no soportan:
secretdata.someattacker.com)Hasta donde sé, ninguna otra solución ofrece todas estas características juntas.
Limitación conocida: los adjuntos a cgroup filtran a nivel de socket (hooks connect/sendmsg),
por lo que un proceso con CAP_NET_RAW puede crear paquetes sin procesar que los eviten. Use
un adjunto TC (interfaz), que filtra a nivel de dispositivo, para cargas de trabajo que
puedan tener CAP_NET_RAW.
Sin embargo, esto tiene un poco más de sobrecarga que algo como httpjail.
Estos números se midieron en el gate Linux Docker privilegiado en linux/arm64
usando make bench-docker. Los valores son medianas de cinco muestras.
El benchmark de socket caliente utiliza sockets UDP conectados para aislar el
costo del hook eBPF cgroup/connect4 de la latencia del handshake TCP. En esta ruta, DNS ya
ha resuelto el dominio, la IP aún está dentro del TTL, y la IP/CIDR ya
está presente en el mapa eBPF.
| Ruta | Latencia mediana |
|---|---|
| Conexión de socket normal, sin eBPF | ~2.647 us |
| Lista permitida caliente, acierto LPM protegido | ~2.691 us |
| Lista permitida caliente, acierto de host exacto DNS | ~2.741 us |
| Fallo en lista permitida, bloqueo local | ~1.652 us |
La dispersión medida entre las rutas de conexión normal, LPM protegido y host exacto DNS está dentro del ruido de la muestra.
No existe la ruta "fallo en kernel pregunta al proceso padre" hoy. Un fallo en lista permitida de cgroup es decidido localmente por eBPF y se bloquea inmediatamente.
Estos números miden la ruta del servidor DNS, no la ruta de conexión de socket caliente.
| Ruta | Latencia mediana |
|---|---|
| Consulta proxy en frío, función de política en proceso | ~31.336 us |
| Consulta proxy en caliente | ~27.964 us |
| Consulta lista permitida en frío con upstream local | ~53.510 us |
| Consulta lista permitida en caliente con upstream local | ~53.432 us |
Las filas en frío se sincronizan a través de la barrera de mutación de adjunto real y borran
el gráfico de propiedad del benchmark y la instantánea del mapa exacto falsa entre consultas.
El temporizador se ejecuta continuamente para preservar la localidad del planificador UDP, mientras que ns/op
resta el fixture-reset-ns/op de tiempo de pared reportado por separado (incluyendo
cualquier cola del manejador anterior después de que el cliente recibiera su paquete) y por lo tanto
mide el Exchange actual del cliente. raw-total-ns/op reporta ambos juntos.
El restablecimiento preserva los dominios de política configurados y el almacenamiento de respaldo, y el
benchmark afirma una adición física al mapa exacto por consulta. Las filas en caliente preparan
la propiedad una vez y afirman una adición física a lo largo de la ejecución.
Los microbenchmarks internos de propiedad a continuación son diagnósticos de escalabilidad, no filas de aceptación de ruta de consulta DNS de extremo a extremo. El helper en caché se conserva solo para pruebas y benchmarks; envuelve un registro a la vez y repite la validación de dominio. Tanto este tráfico como el del resolvedor normal atraviesan la barrera de mutación de adjunto, mientras que el tráfico normal del resolvedor admite cada respuesta completa como una transacción.