Cosa può significare una regola di accesso per nome host a ogni livello di rete
Un nome di servizio può essere applicato a livello di DNS, browser, proxy o firewall. Scegliete il livello che vede l’identità che volete governare.
Tre persone chiedono la stessa cosa con le stesse parole: bloccare l’accesso a un nome di servizio. Una intende che un browser non debba aprire il sito, un’altra che un client vocale desktop non debba raggiungere il suo server, e la terza che un gruppo di appaltatori non debba usare una particolare applicazione interna. La frase è identica, e i meccanismi di applicazione non hanno quasi nulla in comune.
Scegliete il livello in base all’identificatore che riesce davvero a vedere, poi in base ai client che copre. Partire da un comando del firewall che già conoscete è il modo in cui le regole finiscono per non bloccare nulla, o per bloccare troppo.
Un nome non è un’identità che ogni livello può verificare
Netfilter e i filtri di pacchetti simili vedono indirizzi, protocolli e porte. Non vedono i nomi host, e quando un pacchetto li raggiunge il nome è già stato risolto. Una regola scritta contro un indirizzo è una regola su quell’indirizzo, qualunque nome un utente abbia digitato per raggiungerlo.
La politica DNS si trova prima nel percorso e vede la query, che è un oggetto diverso dalla connessione che segue. Governa le risposte restituite da un resolver controllato, non le connessioni già aperte, né i client configurati per aggirare quel resolver. Un indirizzo risolto può anche cambiare tra la revisione della politica e la richiesta successiva, perciò una risposta DNS non è una dichiarazione di autorizzazione duratura.
I livelli superiori vedono più contesto e coprono meno client. Questo scambio è l’intero argomento, e spiega perché nessuna singola riga della tabella sia mai la risposta giusta. Scegliete la riga che vede l’identificatore di cui tratta davvero la vostra politica. Poi accettate la copertura che quella riga implica.
Cosa può identificare ogni livello
Leggete la tabella dalla colonna centrale verso l’esterno: l’identificatore che un livello può vedere detta la politica che può applicare onestamente.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
Un livello appartiene alla politica solo quando l’identificatore che vede corrisponde all’identificatore che governate. La tabella spiega anche perché una regola scritta a un livello raramente si trasferisca a un altro senza decidere di nuovo cosa protegge.
Dove fallisce la regola ovvia
Una regola di indirizzo è esattamente giusta per un servizio con un indirizzo dedicato che controllate, e quella proprietà dovrebbe essere scritta nella politica. È esattamente sbagliata per qualunque cosa dietro un indirizzo condiviso di distribuzione dei contenuti, dove la stessa regola tocca servizi non correlati e una risposta DNS aggiornata non trasforma la regola in autorizzazione per nome host.
Una politica per browser gestito esprime una restrizione web più direttamente di un elenco di indirizzi copiato, ma si applica ai browser e ai profili che il sistema di gestione governa.
Quella regola del browser non fa nulla per un client vocale che invia UDP a un altro host, e i suoi schemi sono definiti da quel prodotto, non da convenzioni sui caratteri jolly prese altrove. Anche un proxy CONNECT riceve host e porta per una richiesta incanalata, e non può leggere il percorso dentro la sessione cifrata. Progettate la regola intorno a ciò che il protocollo espone. Poi annotate ciò che lascia scoperto, perché quel vuoto è da dove verrà la richiesta successiva.
Scegliete in base ai client, non al comando
Chiedete quali client la politica deve coprire e quali può mancare. Una politica per browser gestito copre ciò che il sistema di gestione raggiunge e si ferma al confine del browser. Una politica del resolver copre tutto ciò che usa il vostro resolver, che è un insieme più ampio, e fallisce in aperto per chi non lo fa.
Per un servizio che gestite, l’autorizzazione nell’applicazione è più forte di qualsiasi confine di rete, perché segue l’account e non il percorso. Una rotta VPN è raggiungibilità e nulla più: poter inviare un pacchetto a un servizio non è il permesso di usarlo. Dove l’identificatore che conta è un utente o un permesso di canale, applicatelo lì e trattate la regola di rete come secondo livello.
Scrivete la regola in termini di risorsa
Una politica difendibile nomina la risorsa, le identità, le applicazioni nell’ambito e il percorso che le trasporta, comprese entrambe le famiglie di indirizzi in uso. Dichiara anche cosa succede all’infrastruttura condivisa che la regola toccherà incidentalmente.
Quella formulazione produce una decisione che qualcuno potrà verificare in seguito. Una regola giustificata dall’indirizzo risolto di oggi produce un incidente la prima volta che l’indirizzo cambia, e nessuno saprà spiegare perché il blocco fosse mai corretto.