Due gruppi di client, un server: dove applicare la politica

Mettere due gruppi di client su sottoreti diverse sembra isolamento, e non lo è. Gli indirizzi descrivono da dove un pacchetto sembra provenire, mentre il permesso è una decisione presa da chi lo inoltra. A quella domanda risponde la configurazione e non la maschera, quindi decidete quale componente inoltra il traffico tra pari prima di scrivere qualsiasi regola.

Una sottorete è un’etichetta, non una regola

Assegnare un pool per gruppo dà indirizzi leggibili e nulla più. Un client che accetta una rotta aggiuntiva ha guadagnato raggiungibilità, e la raggiungibilità non è autorizzazione. Il permesso di parlare sta nella decisione di inoltro, che può vivere nel demone o nel kernel a seconda di come è configurato il server.

La proprietà dell’indirizzo è ciò che rende un prefisso utilizzabile come selettore di gruppo. Ogni identità autenticata deve corrispondere a un indirizzo o a un intervallo prevedibile, e quella mappatura fallisce appena più dispositivi condividono una credenziale e un’assegnazione. Risolvete identità e concorrenza prima di affidarvi a un prefisso di origine, perché una politica che indovina quale macchina chiama autorizza quella sbagliata nel momento peggiore.

Scegliete il percorso che trasporta il traffico tra pari

Quando il demone inoltra i pacchetti tra pari all’interno del proprio processo, quei pacchetti non raggiungono mai l’hook di inoltro dell’host, quindi una regola del kernel non può vederli. Disattivate quell’inoltro interno e il kernel diventa il punto di inoltro, dove valgono le regole di inoltro ordinarie.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

I canali dati scaricati e i server gestiti dal prodotto pubblicano i propri modelli di applicazione, quindi verificate quale state eseguendo invece di presumere il comportamento della comunità. Il guasto che vale la pena evitare è una regola che sembra corretta in una revisione e non viene mai consultata a runtime.

Scrivete la matrice prima delle regole

Una matrice breve è più facile da rivedere di un set di regole, ed è il contratto che l’implementazione deve soddisfare: pari dello stesso gruppo consentiti, pari tra gruppi negati, entrambi i gruppi consentiti verso un servizio condiviso con nome, tutto il resto negato. Scrivete quelle quattro righe prima di aprire un editor di firewall. Un revisore che non legge la sintassi delle regole può comunque controllare la matrice. Poi l’implementazione deve solo corrispondere alle righe.

Tenete separate le tre classi di destinazione mentre la scrivete. Un servizio sull’host VPN è input locale, un altro client è transito tra pari e una macchina dietro il gateway è un percorso di inoltro diverso. Una sola regola generosa può concedere tutte e tre per errore, ed è così che una politica di gruppo diventa una rete piatta con passaggi in più. Scrivete la classe accanto a ogni riga perché l’intento sopravviva alla modifica successiva.

Mettete le regole dove sopravvivono

Aggiungete le decisioni nello stesso punto in cui si mantiene il resto del firewall, prima di qualsiasi regola permissiva che altrimenti le inghiottirebbe. L’ordine delle regole fa parte della politica, e una regola corretta collocata dopo un’accettazione ampia non applica nulla. Annotate i numeri delle regole prima e dopo la modifica. Una politica che esiste in un editor ma non nel set di regole in esecuzione è un piano, non un controllo.

Decidete cosa succede ai flussi già esistenti quando la politica cambia, perché una sessione aperta prima della modifica può continuare dopo. Se un membro che se ne va deve perdere l’accesso subito, il set di regole ha bisogno di un modo per terminare quello stato invece di aspettare che la connessione si chiuda da sola.

Rendete persistenti le regole tramite il meccanismo che possiede il resto del firewall, e registrate la matrice accanto. Una politica non registrata viene riderivata dalla memoria durante il prossimo incidente, di solito da qualcuno di fretta.

Dimostratelo da entrambi i lati

Provate la raggiungibilità all’interno dello stesso gruppo, il fallimento tra gruppi e il servizio condiviso da un client di ciascun gruppo. Un solo test da un solo client dimostra metà della matrice, e la metà che tralascia è di solito quella sbagliata. Ripetete la direzione di negazione due volte, perché una sessione in cache può nascondere un errore di applicazione. Registrate quale coppia avete provato perché la persona successiva non la ripeta.

Ripetete il controllo su IPv6 se il tunnel lo trasporta, e mantenete l’autenticazione applicativa ordinaria. Un prefisso di origine non è un account, quindi superare la politica di rete non significa che un servizio debba fidarsi del chiamante.