I criteri di gruppo NPS non sono l’applicazione delle risorse VPN

Due gruppi, due profili di accesso, un gateway VPN e, alla fine, entrambi i gruppi raggiungono gli stessi server. Il motivo abituale non è un criterio rotto ma una seconda metà mancante della progettazione: NPS decide chi può stabilire una sessione, e qualcos’altro deve decidere a cosa quella sessione può arrivare. Quando esiste solo la prima metà, l’autorizzazione riesce per tutti coloro che si autenticano. Il criterio fa il suo lavoro e la progettazione resta incompleta.

Un criterio di rete che corrisponde a un gruppo è una prova sull’ammissione. Non è una prova sui pacchetti, e il divario tra queste due affermazioni è il punto in cui avviene la maggior parte di questo lavoro.

Trovate il criterio che ha effettivamente ammesso la sessione

NPS valuta criteri di rete ordinati e vince la prima regola abilitata le cui condizioni corrispondono. Le condizioni possono includere l’appartenenza a un gruppo di utenti o computer, il tipo di connessione, l’ora e lo stato del dispositivo. Un criterio ampio collocato più in alto nell’elenco ammette quindi una connessione prima che una regola più stretta più in basso venga mai considerata. L’ordine non è un dettaglio dell’interfaccia; l’ordine è il criterio.

Leggete l’elenco in ordine e individuate quella che ha corrisposto, poi annotate quali impostazioni ha restituito. Il nome del gruppo nell’editor non è il risultato; il risultato è l’autorizzazione che il server ha ricevuto. Tenete separati l’autorizzazione utente e l’autorizzazione dispositivo dove la distribuzione usa entrambe, perché un account che può aprire un tunnel non è automaticamente un account che dovrebbe raggiungere ogni servizio interno.

La risposta RADIUS è un’istruzione, non un filtro

Un attributo Filter-Id porta il nome di un elenco di filtri. Non trasporta un insieme portabile di regole di filtro dei pacchetti che ogni destinatario comprenda, e inviare un nome che il gateway non ha mai definito non applica proprio nulla. La stessa cautela vale per gli attributi VLAN: assegnare una sessione tunnel a una VLAN non è, di per sé, una regola di accesso instradata per quell’utente.

È qui che una progettazione che sembra completa sul lato NPS non fa silenziosamente nulla. Confermate con la documentazione del fornitore del gateway quali attributi di autorizzazione sono supportati e cosa fa il destinatario con ciascuno, invece di supporre che un nome di attributo standard implichi un comportamento standard.

Mettete l’applicazione dove passa il traffico

Un gateway che elabora i pacchetti dell’utente può applicare un filtro per sessione, mappare un gruppo su un criterio del gateway o assegnare alla sessione un indirizzo da un pool segregato che il firewall tratta diversamente. Ognuna di queste opzioni può funzionare, e falliscono in modi diversi. Determinate quale meccanismo supporta il vostro gateway prima di scrivere il criterio che lo nomina. Poi annotate cosa succede a una sessione quando quel meccanismo manca, perché il silenzio è il valore predefinito.

Descrivete l’autorizzazione prevista in quattro parti: identità di origine o gruppo, destinazione, protocollo e porta. Aggiungete le dipendenze di cui l’utente ha davvero bisogno, come DNS o un servizio di autenticazione, altrimenti la restrizione romperà flussi di accesso che nessuno ha pensato di testare. Scrivete la regola rispetto all’interfaccia che filtra davvero, non rispetto all’interfaccia che per caso è aperta nell’editor.

Considerate anche la traduzione degli indirizzi. Se un firewall a valle vede un solo indirizzo di origine tradotto per ogni utente del tunnel, non può distinguere gli individui solo da quell’indirizzo, e una regola scritta come se potesse sarà inutile o troppo ampia.

I profili client vivono sul lato non attendibile

Un profilo VPN gestito può spingere rotte, regole di tunnel diviso o filtri applicativi, e questi modellano il comportamento di un dispositivo ben educato. Non sono una protezione per il servizio, perché il client è la parte che state cercando di vincolare. Rimuovere una rotta da un profilo non è nemmeno un’autorizzazione, dato che un client può avere un altro percorso verso la stessa destinazione.

Trattate le impostazioni del client come comodità e quelle del gateway come controllo. Quando le due sono in disaccordo, ha ragione il gateway, perché è quello che vede i pacchetti.

Accettate con due account, poi tracciate in ordine

Create due normali account di test con autorizzazioni previste diverse, stabilite sessioni nuove e verificate il criterio effettivo del gateway per ciascuno. Poi provate un’operazione consentita innocua e una risorsa specificamente negata. Un ping fallito dimostra da solo molto poco, dato che ICMP può essere filtrato mentre il servizio TCP dietro risponde volentieri.

Quando entrambi gli account ottengono ancora un accesso ampio, tracciate in un ordine fisso: quale criterio ha corrisposto, quale autorizzazione portava la risposta e cosa ne ha fatto il gateway. Aggiungere altri attributi NPS prima di confermare che il destinatario li implementi è il modo in cui un piccolo problema di autorizzazione diventa una finestra di cambiamento senza risultato.