Nessun tun0? Fate corrispondere l’IPsec decifrato in nftables con meta ipsec

Ti aspetti un’interfaccia di tunnel, la cerchi, e nel firewall non c’è nulla da far corrispondere. È normale per un gateway basato su policy: lo scambio cifrato arriva sull’interfaccia fisica, e il pacchetto interno decifrato che viene poi inoltrato si osserva anch’esso in arrivo su quella stessa interfaccia. Non c’è tun0 perché nulla l’ha creato.

La richiesta interna resta un pacchetto distinto con la propria origine, destinazione e servizio, e il kernel sa da quale associazione di sicurezza è uscito. È questa conoscenza che una regola del firewall può far corrispondere.

Due pacchetti, un’interfaccia

Immagina la direzione in ingresso. Arriva un pacchetto incapsulato in ESP o UDP, il kernel trova la policy corrispondente, lo decifra e consegna il pacchetto in chiaro al percorso di inoltro. Una regola che guarda solo il nome dell’interfaccia non può distinguere quel pacchetto da qualsiasi altro traffico in arrivo sullo stesso cavo.

Ciò che lo distingue è il contesto del percorso di sicurezza in ingresso associato al pacchetto. nftables lo espone come meta ipsec exists, che è vero quando il pacchetto è arrivato attraverso un percorso di sicurezza IPsec. Combinalo con il pool di client, la destinazione e il servizio, e la regola diventa abbastanza specifica da essere sicura.

Omettere il contesto è l’errore comune, ed è un errore di sicurezza, non estetico. Una regola che accetta qualunque cosa provenga dal pool di client accetta altrettanto volentieri un pacchetto falsificato dalla rete locale, perché l’indirizzo di origine non è prova di nulla da solo. Il contesto del percorso di sicurezza è il modo più economico per rendere l’origine significativa. Scrivi la regola con esso fin dall’inizio invece di aggiungerlo dopo un controllo.

Scrivete la regola di inoltro

Supponete un servizio di accesso remoto IPv4 autenticato con client in 10.90.0.0/24 e una destinazione approvata su 203.0.113.40. Un frammento di regola per quel flusso appare così.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Gli indirizzi e l’interfaccia sono esempi da sostituire. Collocate l’equivalente revisionato nella policy di inoltro prima della regola che altrimenti rifiuterebbe il flusso, e non svuotate un set di regole esistente per installarlo; un gateway non è un esperimento in camera bianca.

Vale la pena mantenere il termine oifname. Documenta la decisione di uscita e impedisce alla regola di corrispondere in una direzione che non intendevi, cosa che conta su un gateway con diversi percorsi verso internet. Su una macchina di prova con un solo collegamento in salita il termine sembra ridondante, ed è esattamente per questo che viene rimosso prima che la macchina ottenga un secondo collegamento.

I permessi per lo scambio esterno sono separati. Il percorso di ingresso del gateway ha bisogno delle porte IKE ed ESP o di incapsulamento UDP che utilizza davvero, e quei permessi non autorizzano nulla riguardo al pacchetto decifrato all’interno. Mescolare i due è il modo in cui un tunnel funzionante finisce con un firewall che inoltra tutto.

Il contesto in ingresso non è quello in uscita

La stessa famiglia di espressioni copre l’altra direzione con rt ipsec, che descrive l’associazione di sicurezza in uscita che un pacchetto userà. Risponde a una domanda diversa: non da dove viene questo pacchetto, ma se sarà protetto nel suo tratto successivo.

Questa distinzione conta su un gateway che termina un tunnel e insieme inoltra verso un altro. Un pacchetto può arrivare decifrato e dover comunque uscire cifrato, e un’accettazione scritta solo per il contesto in ingresso non dice nulla sul requisito in uscita. Se la policy richiede quella protezione, il set di regole dovrebbe esprimerla invece di presumere che il routing se ne occupi.

Tenete le due domande in regole separate così che il lettore veda quale viene applicata. Una sola regola astuta che controlla entrambe è più difficile da rivedere e molto più difficile da depurare quando una delle sue metà smette di corrispondere. Due regole con contatori vi dicono anche quale requisito sta fallendo, cosa che una regola combinata non farà mai.

NAT non è una decisione del firewall

Il traffico verso internet da un pool di client privato di solito richiede la traduzione dell’origine perché la risposta trovi la via del ritorno. Ma il traffico selezionato per un’altra policy IPsec in uscita deve conservare la sua esenzione necessaria, e mascherare ogni origine privata senza pensare alla successiva decisione di protezione lo rompe.

Un’accettazione dentro una catena NAT non è nemmeno un permesso generale. NAT e filtro hanno compiti diversi, e una catena NAT non esamina ogni pacchetto successivo di un flusso stabilito, ed è proprio per questo che affidarsi ad essa per la sicurezza produce regole che sembrano funzionare in prova e falliscono sotto carico.

Vale anche il contrario e sorprende: un’accettazione da qualche parte in una catena base di filtro non ha alcun peso contro un rifiuto successivo in un’altra catena applicabile. Sono l’ordine e l’ambito della catena a decidere l’esito, non la presenza di un’accettazione nel file.

Verificate il servizio interno esatto

Provate la destinazione e la porta precise che avete autorizzato, da un client reale, e confermate che la risposta torni. Poi provate qualcosa che non avete autorizzato e verificate che non passi, perché una regola troppo ampia supera la prima prova altrettanto bene di una corretta. Una richiesta che non lascia mai il client non è nemmeno un risultato del firewall, quindi leggete i contatori per vedere se il pacchetto è stato valutato. Due prove e una lettura di contatore vi diranno più di un intero pomeriggio passato a leggere il set di regole.

La guida di riferimento di nftables documenta meta ipsec, rt ipsec e le espressioni specifiche per direzione, ed è il posto dove verificare la sintassi rispetto alla versione installata. E mantenete esplicito l’ambito: questo è un esempio IPv4, non dice nulla su IPv6, e non trasforma un inoltro arbitrario di porte pubbliche in parte del servizio VPN.