danthegoodman1/netfenceCome Envoy xDS, ma per filtri eBPF
Come Envoy xDS, ma per filtri eBPF.
Netfence funge da demone sui tuoi host VM/container e inietta automaticamente programmi di filtro eBPF nei cgroups e nelle interfacce di rete, con un server DNS integrato che risolve i domini consentiti e popola la lista di IP consentiti.
I demoni di Netfence possono essere gestiti tramite la loro API locale su socket Unix, oppure connettersi a un piano di controllo centrale che implementi tramite gRPC per sincronizzare liste consentite/bloccate con il tuo backend.
Il tuo piano di controllo invia regole di rete come ALLOW *.pypi.org o ALLOW 10.0.0.0/16 alle interfacce/cgroups collegati. Quando una VM/container interroga il DNS, Netfence lo risolve, aggiunge gli IP al filtro eBPF e blocca il traffico verso IP sconosciuti prima che lasci l'host, con un overhead di percorso riscaldato che è praticamente indistinguibile da una normale connessione socket nei benchmark attuali.
Nella modalità lista consentiti, il link-local IPv4 (169.254.0.0/16) non è più automaticamente consentito per impostazione predefinita — quindi il servizio metadata cloud (169.254.169.254) è bloccato a meno che non sia esplicitamente inserito nella lista consentiti. Questa è una scelta deliberata: il servizio metadata è un bersaglio per il furto di credenziali, e i carichi di lavoro sandboxed non devono poterlo raggiungere implicitamente. Localhost (127.0.0.0/8, ::1) e la scoperta di vicini IPv6 (fe80::/10, ff02::/16) rimangono consentiti per impostazione predefinita in modo che la connettività di base e NDP continuino a funzionare. Per consentire il servizio metadata per un carico di lavoro, inserisci 169.254.169.254/32 nella lista consentiti (un override di esclusione per allegato tramite il piano di controllo è un follow-up pianificato).
Il broadcast IPv4 (255.255.255.255) e il multicast (224.0.0.0/4) non hanno esclusioni e sono soggetti alla policy, quindi in modalità lista consentiti TC il traffico come i broadcast di rinnovo DHCP è bloccato a meno che non sia esplicitamente consentito. I controlli di esclusione vengono eseguiti prima della lista bloccati, quindi un intervallo escluso può essere bloccato solo disattivando la sua esclusione — e poiché il link-local IPv4 è ora disattivato per impostazione predefinita, la modalità lista bloccati può bloccare anche il servizio metadata.
secretdata.someattacker.com)A mia conoscenza, nessun'altra soluzione offre tutte queste funzionalità insieme.
Limitazione nota: gli allegati cgroup filtrano a livello di socket (hook connect/sendmsg), quindi un processo con CAP_NET_RAW può creare pacchetti raw che li bypassano. Usa un allegato TC (interfaccia), che filtra a livello di dispositivo, per carichi di lavoro che potrebbero avere CAP_NET_RAW.
Tuttavia, questo ha un po' più di overhead rispetto a qualcosa come httpjail.
Questi numeri sono stati misurati nel gate Docker Linux privilegiato su linux/arm64 usando make bench-docker. I valori sono mediane di cinque campioni.
Il benchmark del socket riscaldato utilizza socket UDP connessi per isolare il costo dell'hook eBPF cgroup/connect4 dalla latenza della stretta di mano TCP. In questo percorso, il DNS ha già risolto il dominio, l'IP è ancora entro il TTL e l'IP/CIDR è già presente nella mappa eBPF.
| Path | Median latency |
|---|---|
| Connessione socket normale, nessun eBPF | ~2.647 us |
| Lista consentiti riscaldata, hit LPM protetto | ~2.691 us |
| Lista consentiti riscaldata, hit host esatto DNS | ~2.741 us |
| Mancata lista consentiti, blocco locale | ~1.652 us |
La differenza misurata tra i percorsi di connessione normale, LPM protetto e host esatto DNS è all'interno del rumore del campione.
Non esiste oggi un percorso "kernel miss chiede al processo padre". Una mancata nella lista consentiti cgroup è decisa localmente da eBPF e viene bloccata immediatamente.
Questi numeri misurano il percorso del server DNS, non il percorso di connessione socket riscaldato.
| Path | Median latency |
|---|---|
| Query proxy a freddo, funzione policy in-process | ~31.336 us |
| Query proxy a caldo | ~27.964 us |
| Query lista consentiti a freddo con upstream locale | ~53.510 us |
| Query lista consentiti a caldo con upstream locale | ~53.432 us |
Le righe a freddo si sincronizzano attraverso la reale barriera di mutazione degli allegati e cancellano il grafico di proprietà del benchmark e lo snapshot falso della mappa esatta tra le query. Il timer viene eseguito continuamente per preservare la località dello scheduler UDP, mentre ns/op sottrae il tempo reale fixture-reset-ns/op riportato separatamente (inclusa qualsiasi coda del gestore precedente dopo che il client ha ricevuto il suo pacchetto) e quindi misura lo scambio corrente del client. raw-total-ns/op riporta entrambi insieme. Il reset preserva i domini policy configurati e l'archiviazione di supporto, e il benchmark asserisce un'aggiunta fisica alla mappa esatta per query. Le righe a caldo inizializzano la proprietà una volta e asseriscono un'aggiunta fisica durante l'esecuzione.
I microbenchmark di proprietà interna di seguito sono diagnostici di scalabilità, non righe di accettazione del percorso di query DNS end-to-end. L'helper nella cache viene mantenuto solo per test e benchmark; avvolge un record alla volta e ripete la convalida del dominio. Sia esso che il traffico del resolver normale attraversano la barriera di mutazione degli allegati, mentre il traffico del resolver normale ammette ogni risposta completa come una transazione.