danthegoodman1/netfenceComo Envoy xDS, mas para filtros eBPF
Como o Envoy xDS, mas para filtros eBPF.
O Netfence é executado como um serviço em seus hosts de VM/contêineres e injeta automaticamente programas de filtro eBPF em cgroups e interfaces de rede, com um servidor DNS interno que resolve domínios permitidos e popula a lista de permissões de IP.
Os serviços Netfence podem ser controlados apenas por meio de sua API local de socket Unix, ou conectam-se a um plano de controle central que você implementa via gRPC para sincronizar listas de permissão/bloqueio com seu backend.
Seu plano de controle envia regras de rede como ALLOW *.pypi.org ou ALLOW 10.0.0.0/16 para interfaces/cgroups anexados. Quando uma VM/contêiner consulta o DNS, o Netfence a resolve, adiciona os IPs ao filtro eBPF e descarta tráfego para IPs desconhecidos antes que ele saia do host, com uma sobrecarga de caminho aquecido que é virtualmente indistinguível de uma conexão normal de socket nos benchmarks atuais.
No modo de lista de permissão, o IPv4 link-local (169.254.0.0/16) não é mais automaticamente permitido
por padrão — então o serviço de metadados da nuvem (169.254.169.254) é bloqueado a menos que
explicitamente permitido. Isso é proposital: o serviço de metadados é um
alvo de roubo de credenciais, e workloads em sandbox não devem ser capazes de alcançá-lo
implicitamente. Localhost (127.0.0.0/8, ::1) e descoberta de vizinhos IPv6
(fe80::/10, ff02::/16) permanecem permitidos por padrão para que a conectividade básica e NDP
continuem funcionando. Para permitir o serviço de metadados para um workload, coloque na lista de permissão
169.254.169.254/32 (uma substituição de isenção por anexação via plano de controle
é um acompanhamento planejado).
Broadcast IPv4 (255.255.255.255) e multicast (224.0.0.0/4) não possuem isenção e estão sujeitos à política, portanto, no modo de lista de permissão TC, tráfego como broadcasts de renovação de DHCP é bloqueado a menos que explicitamente permitido. As verificações de isenção são executadas antes da lista de bloqueio, portanto, um intervalo isento só pode ser bloqueado desativando sua isenção — e como o IPv4 link-local agora está desativado por padrão, o modo de lista de bloqueio também pode bloquear o serviço de metadados.
Alguns benefícios principais desta solução que outras opções geralmente não suportam:
secretdata.someattacker.com)Até onde sei, nenhuma outra solução oferece todos esses recursos juntos.
Limitação conhecida: anexações de cgroup filtram na camada de socket (hooks connect/sendmsg),
portanto, um processo com CAP_NET_RAW pode criar pacotes brutos que os ignoram. Use
uma anexação TC (interface), que filtra na camada do dispositivo, para workloads que
possam ter CAP_NET_RAW.
No entanto, isso tem um pouco mais de sobrecarga do que algo como httpjail.
Estes números foram medidos no gateway Linux Docker privilegiado em linux/arm64
usando make bench-docker. Os valores são medianas de cinco amostras.
O benchmark de socket aquecido usa sockets UDP conectados para isolar o
custo do hook eBPF cgroup/connect4 da latência do handshake TCP. Neste caminho, o DNS já
resolveu o domínio, o IP ainda está dentro do TTL e o IP/CIDR já
está presente no mapa eBPF.
| Caminho | Latência mediana |
|---|---|
| Conexão normal de socket, sem eBPF | ~2,647 us |
| Lista de permissão aquecida, acerto LPM protegido | ~2,691 us |
| Lista de permissão aquecida, acerto exato de host DNS | ~2,741 us |
| Erro na lista de permissão, bloqueio local | ~1,652 us |
A diferença medida entre os caminhos de conexão normal, LPM protegido e acerto exato de host DNS está dentro do ruído da amostra.
Não há caminho de "erro no kernel pergunta ao processo pai" atualmente. Um erro de lista de permissão de cgroup é decidido localmente pelo eBPF e é bloqueado imediatamente.
Estes números medem o caminho do servidor DNS, não o caminho de socket aquecido.
| Caminho | Latência mediana |
|---|---|
| Consulta proxy fria, função de política em processo | ~31,336 us |
| Consulta proxy quente | ~27,964 us |
| Consulta de lista de permissão fria com upstream local | ~53,510 us |
| Consulta de lista de permissão quente com upstream local | ~53,432 us |
As linhas frias sincronizam através da barreira de mutação de anexação real e limpam
o gráfico de propriedade do benchmark e o instantâneo de mapa exato falso entre as consultas.
O timer é executado continuamente para preservar a localidade do escalonador UDP, enquanto ns/op
subtrai o fixture-reset-ns/op de tempo de parede relatado separadamente (incluindo
qualquer cauda do manipulador anterior após o cliente receber seu pacote) e, portanto,
mede a troca do cliente atual. raw-total-ns/op relata ambos juntos.
A reinicialização preserva os domínios de política configurados e o armazenamento de suporte, e o
benchmark afirma uma adição de mapa exato físico por consulta. As linhas quentes pré-configuram
a propriedade uma vez e afirmam uma adição física em toda a execução.
Os microbenchmarks de propriedade interna abaixo são diagnósticos de escalabilidade, não linhas de aceitação de caminho de consulta DNS fim a fim. O auxiliar em cache é mantido apenas para testes e benchmarks; ele envolve um registro por vez e repete a validação de domínio. Tanto ele quanto o tráfego normal de resolução atravessam a barreira de mutação de anexação, enquanto o tráfego normal de resolução admite cada resposta completa como uma transação.
| Diagnóstico interno de escalabilidade | Mediana atual | Memória / alocações |
|---|---|---|
| Admissão de nova chave fria, gráfico de propriedade vazio | ~370,3 ns | 232 B, 5 allocs/op |
| Admissão de nova chave fria, 4.095 entradas não relacionadas | ~451,2 ns | 232 B, 5 allocs/op |
| Pressão de capacidade física e substituição LRU | ~3,820 ms | ~4,23 MB (4.226.243 B), 4.336 allocs/op |
| Pré-verificação de orçamento físico esgotado | ~611,9 ns | 344 B, 9 allocs/op |
| Pressão máxima de borda, resposta de 64 endereços | ~6,849 ms | ~7,66 MB (7.658.774 B), 2.233 allocs/op |
| Guarda de trabalho máximo do gráfico, plano completo permitido | ~2,763 ms | ~4,26 MB (4.264.386 B), 3.074 allocs/op |
| Guarda de trabalho máximo do gráfico, rejeição de pré-projeção esgotada | ~10,935 us | 8,76 KB (8.760 B), 14 allocs/op |
| Operação de orçamento de rotatividade perto do limite numérico | ~18,98 ns | 0 B, 0 allocs/op |
| Instantâneo coerente de estatísticas de propriedade | ~2,094 ns | 0 B, 0 allocs/op |
| Varredura de expiração sem operação em 4.095 entradas | ~74,849 us/varredura | 0 B, 0 allocs/op |