Citrix Endpoint Analysis è una funzionalità presente sul NetScaler che può essere attivata su ogni pagina di autenticazione per verificare lo stato del client da cui si accede. In funzione del risultato dell’analisi è possibile modificare la risposta del NetScaler o creare delle policy per l’accesso a Virtual Apps and Desktop (o tramite ICA Policies o tramite Smart Access).
L’EndPoint Analysis (EPA) è a tutti gli effetti una soluzione mirata ad aumentare la sicurezza, e in quanto tale vale sempre l’idea di “security through obscurity”: per questo di default, l’EPA non visualizza messaggi di errore specifici per i test che falliscono (neanche nei file di log) e non è previsto un messaggio specifico nella pagina di login, al fine di dare meno infomazioni possibili ad un potenziale attaccante. Tuttavia può essere necessario informare l’utente di quali test sono falliti, ma questa funzionalità non è prevista dagli attuali firmware.
Con le classic polcies deprecate nella versione 13.1 (più o meno….) bisogna utilizzare le advanced policies che, nel caso dell’EPA, richiedono di lavorare con l’nFactor che ci permette tramite i LogonSchema di visualizzare delle pagine specifiche con semplici messaggi informativi.
Questo articolo si occupa esclusivamente della parte di EndPoint Analysis, e presuppone una conoscenza del NetScaler, dell’nFactor e della creazione di Login Schema personalizzati, che non verranno approfonditi.
La chiave del funzionamento dell’EPA sta proprio nei Fattori che compongono i flussi nFactor:
Sulla destra del fattore vengono visualizzati un + verde e un + rosso dove solitamente vengono agganciate le policy o i fattori in caso di match positivo (verde) o negativo (rosso) della policy (in questo esempio chiamta EPA-Test_Pol).
Voi sapete bene che la policy risulta positiva quando la sia espressione ha esito positivo: in questo caso viene eseguita la action abbinata. Nel caso delle policy EPA però la policy sempre positiva e la action è in realtà il test da eseguire (che a sua volta potrà essere dare uno Scan pass o uno Scan fail).
La prima idea che viene in mente è quella di creare tanti fattori quanti test vogliamo fare e mettere in cascata risultati positivi e negativi costruendo una maglia con i diversi messaggi di errore in diversi Schema. Questa soluzione presenta un grosso problema: oltre al numero di fattori da configurare, ogni fattore manda in esecuzione il client EPA. Se volessimo controllare il tipo di sistema operativo, l’antivirus è la presenza di un processo attivo, il client EPA verrebbe avviato una prima volta per l’OS, poi una seconda volta per controllare l’antivirus ed infine rilanciato una terza volta per controllare il processo. Anche nello scrivere ho cercato di portarvi la noia e il fastidio che l’utente dovrebbe vivere ogni volta in attesa che i controlli finiscano!
Ecco allora le “scoperte” legate ad una documentazione non proprio precisa, o almeno di facile lettura.
La prima scoperta è che se mettiamo più policy in cascata in un singolo fattore assicurandoci che ogni bind sia configurato con il “Goto Expression” su NEXT, l’EPA client effettua tutti i test in un colpo solo! Archimede direbbe “Eureka!”: + verde caso positivo, + rosso caso negativo, creiamo i fattori successivi con il login schema con il messaggio adeguato e il gioco è fatto! ….e invece non funziona nulla!
A questo punto arriva la seconda scoperta: all’interno di un singolo fattore con più policy EPA in binding con NEXT, il NetScaler è in grado di gestire un solo caso negativo! Non sono stato in grado di capire se questo è by-design, ma in generale il fatto che l’EPA sia una Action e non una policy non ci permette di intercettare correttamente i casi che falliscono in cascata.
Complicandosi un po’ la vita, c’è però modo per ottenere quanto vogliamo, sfruttando il fatto che l’esito positivo di uno scan EPA può essere intercettato correttamente.
L’idea è quella di fare gli EPA scan al contrario (banalmente inserendo tra parentesi lo scan e aggiungendo un .NOT al termine) in modo da avere un esito positivo quando lo scan fallisce.
Nello schema qui di fianco, la policy OS.NOT_pol restituisce un esito positivo quando lo scan dell’OS fallisce, mandandoci sul fattore EPA-OS-Fail.
Analogamente la policy AV.NOT_pol restituisce un esito positivo quando lo scan dell’Antivirus fallisce, mandandoci sul fattore EPA-AV-Fail.
Resta ancora da gestire l’utente che salta lo scan (premendo Skip). In questo caso le due precedenti policy hanno dato esito negativo (a prescindere dal fatto che abbiamo fatto uno scan invertito, se l’EPA viene saltato la policy restituisce comunque un False).
Per questo motivo ho inserito un ulteriore policy, questa volta analoga ad una delle due precedenti, ma non invertita: se l’EPA viene eseguito e l’OS è idoneo (quindi è fallito nel test della prima policy che era invertito) non potrà che dare esito positivo questa volta, finendo quindi sul fattore EPA-OK.
L’unico caso quindi in cui questa ultima policy potrà dare esito negativo è quello in cui l’EPA è stato saltato, portandoci sul fattore EPA-Skipped.
L’obiettivo di questo articolo non è quello di dare una configurazione funzionante, ma semplicemente di spiegare come impostare il flusso nFactor. Una configurazione più dettagliata non sarebbe stata comunque definitiva, perché la scelta di cosa fare, quali tipi di autenticazione utilizzare è veramente troppo ampia.
Vorrei ringraziare Stefano, Davide, Cristian e Matteo con cui ho lavorato su un caso reale, molto più complesso, a cui abbiamo dedicato alcune ore di confronto e test.