IPsec tra due host: dove inizia e dove finisce la protezione
Una coppia di host può proteggere flussi selezionati senza un gateway. Definite gli estremi, la politica che seleziona il traffico e le autorizzazioni che restano separate.
La protezione su una coppia di host inizia dove termina l’associazione di sicurezza, ed è esattamente il fatto che l’intuizione modellata dai gateway manca più spesso. Un server applicativo e il suo server di database possono proteggere la propria conversazione direttamente, senza alcun concentratore di accesso remoto sul percorso, e il confine di protezione si colloca allora dentro ciascun host invece che in un firewall. Ciò che questo vi dà è una copertura da un estremo all’altro per flussi selezionati. Ciò che non vi dà è una decisione su chi possa leggere quale riga.
Il confine è dove termina la SA
L’RFC 4301 descrive le associazioni di sicurezza in modalità trasporto come la disposizione usata di solito tra una coppia di host per la protezione da un estremo all’altro. Quei due host detengono le chiavi, e ciascuno decide quali dei propri pacchetti entrano nell’associazione. Un tunnel gateway termina altrove del tutto e raggiunge l’host attraverso un segmento interno aggiuntivo, che è un confine di fiducia diverso anche quando il pacchetto è cifrato per la maggior parte del suo percorso.
Host a host e modalità trasporto non sono però sinonimi. Due host possono altrettanto correttamente costruire tra loro un’associazione in modalità tunnel, quindi scegliete prima la modalità e poi descrivete gli estremi. Scrivete entrambi nella nota di progetto accanto agli indirizzi dei peer, perché un revisore che conosce solo la modalità presumerà l’altra.
La SPD decide la protezione, la rotta decide la direzione
Una tabella di routing risponde a dove va un pacchetto. Il database delle politiche di sicurezza risponde a come il traffico selezionato attraversa il confine di protezione, e lo fa per direzione con i propri selettori. Questa separazione è il motivo per cui una rotta funzionante verso il database non dimostra nulla su se la richiesta fosse protetta, e per cui una negoziazione stabilita non dimostra nulla su se questa particolare applicazione vi corrispondesse. Confrontate i selettori prima di confrontare i contatori, poiché i contatori descrivono solo i flussi che sono arrivati fin lì.
Su Linux, ip xfrm policy stampa quelle voci con la loro direzione, priorità, selettore e azione allow, block o trap, mentre ip xfrm state mostra le associazioni risultanti e i loro contatori. Leggere i due insieme è il modo per trovare il flusso che ha aggirato il tunnel in silenzio perché una voce allow più ampia corrispondeva per prima.
L’ordine di priorità fa parte della politica, non è un dettaglio implementativo. Una voce stretta che dovrebbe proteggere la porta del database perde contro una voce più ampia con priorità maggiore, e il guasto sembra indicare che la politica non sia mai stata consultata.
La modalità trasporto copre il livello successivo, non l’intestazione IP
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
In modalità trasporto l’intestazione ESP si colloca tra l’intestazione IP e il payload, e i campi di indirizzo di quell’intestazione restano visibili a ogni dispositivo sul percorso. Va bene quando gli indirizzi non sono il segreto e il payload lo è. È la scelta sbagliata se dovete nascondere anche la topologia interna, perché solo la modalità tunnel avvolge l’intestazione originale dentro una nuova.
Entrambe le modalità possono trasportare diversi protocolli del livello successivo, e ESP proteggerà ciò che il selettore individua invece di tutto ciò che l’host invia.
La selezione è più stretta della connessione
Una singola associazione può trasportare più flussi, ma solo quelli che la politica seleziona. Registrate le identità dei peer, gli indirizzi di origine e destinazione, il protocollo e l’ambito del servizio per la relazione che intendete, poi decidete separatamente se il traffico non corrispondente possa passare in chiaro, debba essere protetto o debba essere scartato quando l’associazione non è disponibile. È quest’ultima decisione a produrre sorprese, perché una regola che richiede protezione per l’origine sbagliata può bloccare il vostro stesso accesso di gestione con la stessa efficacia con cui blocca un intruso.
Mantenete un percorso fuori banda approvato mentre cambiate l’applicazione, e provatelo prima di averne bisogno invece che dopo che entrambi gli host sono diventati irraggiungibili.
L’identità della macchina non è un’autorizzazione applicativa
IPsec autentica un peer configurato e protegge i pacchetti selezionati. Non decide quale record del database una persona possa modificare, e non trasforma l’identità fidata di un server nella concessione di ogni privilegio applicativo. Gli account, i ruoli e l’autorizzazione dell’applicazione restano esattamente dove erano, e un requisito TLS a livello applicativo conserva il proprio scopo anche quando il percorso di rete è già protetto.
Accettate il progetto con un’operazione dall’origine prevista e una che deve essere rifiutata, e includete che cosa succede quando l’associazione richiesta non può essere stabilita. Un normale test di raggiungibilità vi dice che i pacchetti si muovono; non vi dice che si sono mossi secondo la politica che avete scritto.