Una regola di firewall classica decide guardando sorgente, destinazione e servizio, e il servizio si riconosce dal protocollo IP, dal numero di porta TCP o UDP e dalla firma di protocollo. Il modello regge finché a una porta corrisponde un’applicazione sola. Non regge più quando decine di servizi diversi viaggiano tutti su http e https. Application Control e URL Filtering nascono da questo scollamento.

Il problema che risolvono

Sulla porta 443 oggi passano posta web, archiviazione di file, social network, streaming, strumenti di amministrazione remota e servizi di anonimizzazione. Aprire la porta significa aprire tutto; chiuderla significa fermare il lavoro. Il firewall non ha più abbastanza informazione per decidere, perché la porta ha smesso di descrivere il contenuto. Servono due capacità nuove: riconoscere quale applicazione sta davvero viaggiando dentro la sessione, e sapere che tipo di sito sta rispondendo dall’altra parte.

Application Control: decidere sull’applicazione

L’Application Control Software Blade identifica, consente o blocca migliaia di applicazioni riconoscendole dal traffico anziché dalla porta. Si appoggia a un database di applicazioni e widget che Check Point aggiorna di frequente e che è consultabile pubblicamente tramite AppWiki. Il beneficio non si esaurisce nel blocco: la stessa capacità serve a scrivere politiche che distinguono fra due servizi affini, a separare l’uso professionale da quello personale di una stessa piattaforma e, soprattutto, a produrre log che dicono quale applicazione ha usato la connessione. Come tutti i Software Blade, si abilita sull’oggetto del Security Gateway che deve ispezionare il traffico, mentre le capacità di gestione stanno sul Management Server.

URL Filtering: decidere sulla categoria del sito

L’URL Filtering Software Blade controlla l’accesso a siti web e applicazioni in base alla loro categorizzazione. Il vantaggio principale è la scala: nessuna organizzazione può mantenere a mano l’elenco dei siti di gioco d’azzardo, di phishing o di condivisione file, e quell’elenco cambierebbe comunque ogni giorno. La categorizzazione delega al vendore il lavoro di classificazione e lascia all’amministratore la sola decisione di politica. Il database di Application Control e URL Filtering si mantiene aggiornato dalla vista Security Policies, nella sezione Access Tools, alla voce Updates: la protezione vale quanto vale la freschezza di quel database.

I benefici da citare in sede d’esame

Quattro, e conviene saperli nominare. Visibilità: i log smettono di raccontare indirizzi e porte e cominciano a raccontare applicazioni, siti e categorie, così si capisce che cosa succede in rete prima ancora di bloccare qualcosa. Granularità: l’azione non è solo Accept o Drop, ci sono anche Reject, il limite di banda con Limit e le azioni interattive. Riduzione della superficie esposta: si negano intere classi di rischio, per esempio l’amministrazione remota o gli anonimizzatori, senza elencare un solo host. Coinvolgimento dell’utente: con UserCheck le azioni Ask e Inform mostrano un messaggio che spiega la regola aziendale, invece di lasciare l’utente davanti a un errore muto; Ask chiede una conferma esplicita e la registra. Un limite va tenuto presente: entrambi i blade ragionano su traffico leggibile, quindi sulle sessioni cifrate la loro efficacia dipende da che cosa HTTPS Inspection mette a disposizione.

Trappole tipiche d’esame

  • Politiche troppo restrittive: la risposta attesa è affinare, non spegnere. Se il blocco di una categoria ferma un reparto, la soluzione da scegliere è una regola più specifica che consente il caso legittimo, collocata sopra la regola generale. Disabilitare il blade o rimettere tutto in Accept è quasi sempre il distrattore. Prima di applicare un blocco esteso conviene una fase di sola osservazione dei log, perché nessuno conosce davvero il traffico della propria rete finché non lo guarda.
  • Impatto prestazionale: non è il numero di regole in sé. Le regole che nominano applicazioni e tipi di contenuto richiedono un’ispezione profonda, quindi la best practice è tenere in alto le regole che decidono su rete e servizio e più in basso quelle che decidono su applicazione e contenuto, evitando di scrivere Any sia in Source sia in Destination in una regola applicativa.
  • Application Control e URL Filtering non vanno mescolati nella stessa regola. È una raccomandazione esplicita del vendore per evitare corrispondenze sbagliate: vanno in regole separate.
  • Identificazione sbagliata di un sito o di un’applicazione. Un sito classificato male non è un guasto del gateway e non si cura spegnendo il filtro: si gestisce con una richiesta di ricategorizzazione al vendore e, nel frattempo, con un’eccezione mirata nella policy.
  • Consentito e bloccato non sono simmetrici. Un’applicazione consentita fa corrispondenza sui servizi raccomandati, mentre un’applicazione bloccata viene bloccata su tutte le porte, salvo configurazione diversa: è la scelta più sicura, e una domanda sul perché un’applicazione «consentita» non funzioni su una porta insolita punta esattamente qui.