Un selettore IPsec ampio non è permesso per ogni servizio

Due peer concordano di proteggere un’intera sottorete, e qualcuno legge quell’accordo come permesso di raggiungere ogni servizio al suo interno. Questo è il mito: il selettore dice quale traffico il tunnel è disposto a trasportare, e non dice nulla su quali servizi l’organizzazione consente. Una coppia di dispositivi può negoziare legittimamente un intervallo di indirizzi ampio mentre la politica di accesso al suo interno permette due porte, ed entrambe le affermazioni restano vere nello stesso momento.

La copertura protetta non è autorizzazione

Un selettore di traffico fa parte dell’accordo del tunnel. Restringe o conferma cosa i peer cifreranno tra loro, e un selettore ampio è spesso la cosa più semplice da gestire quando i due lati hanno molti flussi da trasportare. Il filtro dei servizi è un altro controllo in un altro punto del percorso, e decide cosa può essere effettivamente usato una volta decifrato il pacchetto. Rimuovere il filtro per far passare un test trasforma una decisione di politica in un incidente.

Tenete i due registri separati nel documento di progettazione, perché un lettore che vede solo il selettore dedurrà un’autorizzazione che non è mai stata concessa. Due righe in un registro delle modifiche lo evitano, e richiedono meno tempo della discussione che segue.

Descrivete un flusso da entrambe le estremità

Annotate l’iniziatore, il risponditore, l’origine e la destinazione come presentati, il protocollo ed entrambe le porte. Poi invertite ciascuna di queste etichette per l’altro estremo, perché la porta di origine effimera di un client diventa la porta di destinazione di una risposta e la rete remota diventa quella locale. Una configurazione copiata da un lato all’altro senza quell’inversione è il modo in cui i filtri finiscono per permettere esattamente la direzione sbagliata. Scrivete la tabella una volta e costruite entrambi i filtri da essa.

Concordate il modello di selezione prima di copiare qualsiasi cosa, perché un progetto basato su policy e un progetto basato su route esprimono la stessa intenzione tramite oggetti diversi. Scrivete il nome del modello accanto al flusso, altrimenti l’ingegnere successivo passerà un pomeriggio ad abbinare oggetti che non sono mai stati confrontabili.

Trovate il filtro che si applica davvero

Su un ASA, il filtro VPN è un’ACL collegata a una policy di gruppo e applicata al traffico dopo la decifratura e prima della cifratura. La documentazione Cisco sulle policy di gruppo descrive anche l’ereditarietà, compreso un valore a livello utente che sostituisce quello della policy di gruppo. Quindi l’ACL che avete modificato potrebbe non essere quella che governa la sessione davanti a voi. Lo stesso vale per l’oggetto utente, che può prevalere sul gruppo senza lasciare molte tracce visibili.

Ispezionate la sessione effettiva invece dell’oggetto che ricordate di aver modificato, e annotate quale oggetto di policy la fornisce. Quell’unico passo risolve un numero sorprendente di segnalazioni del tipo il filtro è corretto ma non funziona.

Direzione, porte e il caso inverso

La convenzione documentata colloca la rete remota, o gli indirizzi assegnati ai client remoti, in posizione di origine e la rete locale in posizione di destinazione, con le risposte espresse scambiando le posizioni degli indirizzi. Le regole di porta si sovrappongono a quella convenzione e meritano più cura degli indirizzi.

Il modello documentato può consentire a una regola di porta di destinazione di influire sull’inizio inverso che usa quella stessa porta di origine, il che significa che il filtro non è semplicemente una regola di richiesta unidirezionale con risposte innocue. Ragionate esplicitamente su entrambe le direzioni di inizio e includete il caso che intendete negare.

La stessa documentazione limita il filtro alle connessioni iniziali, quindi non è un’applicazione universale di ogni canale secondario che un’applicazione ispezionata apre. Dove la politica completa richiede quella copertura, essa appartiene a un confine separato e non a un’ACL tirata oltre il suo scopo.

Provate tre casi prima di dichiararlo finito

Accettate il flusso previsto, rifiutate un servizio che la policy vieta ed esercitate il caso di direzione inversa che avete ragionato. Eseguiteli secondo un piano approvato con le stesse identità e gli stessi selettori che distribuirete. Un test che mostra solo che il servizio consentito funziona dimostra il tunnel, non la policy.

Tenete la copertura negoziata e la decisione di accesso come due registri, perché spiegare cosa consente una VPN richiede entrambi.