Configurare e testare il controllo delle applicazioni su Sophos Firewall

Application Control su Sophos Firewall riconosce le applicazioni indipendentemente dalla sola porta. Ciò consente, ad esempio, di consentire, bloccare o registrare in modo mirato strumenti di controllo remoto, applicazioni di tunneling, streaming, archiviazione cloud, messenger o bypass del browser rischiosi.

Il vantaggio pratico si manifesta solo quando Application Control è attivo nella regola del firewall corretta, l’applicazione viene effettivamente riconosciuta e i log vengono analizzati. Una policy di filtro delle applicazioni salvata da sola non blocca nulla.

Risposta breve

Application Control viene utilizzato in due passaggi:

1. Pianificare o creare una policy di filtro delle applicazioni sotto Applications > Application filter.
2. Nella regola del firewall appropriata, selezionare Identify and control applications (App control) sotto Other security features.

Nelle viste di navigazione precedenti, l’area può trovarsi talvolta sotto Protect > Applications > Application filter. Successivamente, è necessario verificare con un client di test reale se il traffico passa attraverso questa regola e se l’applicazione viene riconosciuta correttamente nel Log Viewer. In caso di traffico crittografato, l’ispezione TLS può essere decisiva, poiché altrimenti il firewall vede meno dettagli a seconda dell’applicazione.

Quando è utile Application Control

Application Control è particolarmente utile quando le sole porte non sono sufficientemente indicative. Molte applicazioni utilizzano HTTPS, destinazioni variabili o infrastrutture cloud. Una regola basata solo sulle porte vede quindi solo 443, ma non se dietro c’è un servizio aziendale consentito, uno strumento di controllo remoto o un archivio cloud indesiderato.

Casi d’uso tipici:

• Bloccare TeamViewer, AnyDesk, Tor o strumenti proxy
• Limitare lo streaming o i social media in determinate reti
• Controllare l’archiviazione cloud
• Limitare messenger o giochi in reti ospiti o scolastiche
• Attivare il riconoscimento delle applicazioni per report e analisi
• Preparare il Traffic Shaping per le applicazioni riconosciute

Se non si tratta di riconoscimento o blocco, ma di prioritizzazione o limitazione della larghezza di banda, è possibile configurare anche Application Traffic Shaping su Sophos Firewall.

Prerequisiti

Prima della configurazione, dovrebbero essere verificati i seguenti punti:

• licenza appropriata con Web Protection o Application Control
• regola del firewall interessata è nota
• Log firewall traffic è attivo per la regola di test
• applicazione o categoria desiderata è chiaramente definita
• client di test e obiettivo di test sono definiti
• per le applicazioni HTTPS è chiaro se utilizzare l’ispezione TLS
• firme Application e Pattern Updates funzionanti

Lo stato della licenza può essere verificato sotto System > Administration > Licensing. Nei tipici pacchetti Sophos Firewall con Web Protection è incluso Application Control. Tuttavia, la logica della licenza specifica dovrebbe essere controllata prima dell’introduzione in produzione, specialmente in caso di abbonamenti scaduti o licenze di prova.

Pianificare il filtro delle applicazioni

Un buon filtro delle applicazioni non è semplicemente una lunga lista di blocco. Prima di tutto, dovrebbe essere chiaro cosa si vuole ottenere.

• bloccare strumenti di controllo remoto rischiosi: bloccare applicazioni o categorie mirate
• limitare il Wi-Fi per gli ospiti: bloccare categorie indesiderate, lasciare aperti i servizi di base consentiti
• solo registrare l’applicazione: utilizzare inizialmente Allow con logging e report
• evitare falsi positivi: selezione più ristretta delle applicazioni invece di una categoria ampia
• prioritizzare applicazioni critiche per il business: combinare Application Control con Traffic Shaping

Per le reti produttive, una modalità di osservazione è spesso utile: attivare prima Application Control, controllare i log e i report, quindi bloccare in modo mirato. In questo modo si vede quali applicazioni sono effettivamente presenti e se un blocco disturberebbe processi legittimi.

Con criteri ampi bisogna considerare anche la manutenzione successiva. Le nuove applicazioni vengono incluse automaticamente nelle Application Filter Policies e nelle regole del firewall tramite gli aggiornamenti del database delle firme Application. Se una regola, ad esempio, blocca tutte le applicazioni High Risk, una nuova firma High Risk può essere bloccata in seguito senza ulteriori modifiche manuali alla policy. Questo è voluto, ma deve essere noto nel processo di change e review.

Pianificare il rollout in fasi

Application Control non dovrebbe essere attivato in un unico grande passo per tutte le reti. È meglio un rollout graduale con un gruppo di test chiaro, logging visibile e una decisione definita su quando passare dall’osservazione al blocco.

Un processo praticabile:

• Inventario: scoprire quali applicazioni sono effettivamente presenti. Filtro delle applicazioni con logging, ancora senza blocco ampio
• Pilota: verificare utenti selezionati o una rete di test. bloccare singole applicazioni rischiose, controllare attentamente ID regola e log
• Messa in produzione: applicare la policy confermata alla rete di destinazione. attivare il filtro nella regola produttiva, documentare le eccezioni
• Operatività: monitorare effetti e effetti collaterali. controllare regolarmente report, Log Viewer, Central Reporting o Syslog

Prima della messa in produzione, dovrebbe essere chiaro quali applicazioni devono rimanere consentite. Questi includono spesso servizi di aggiornamento, supporto remoto, strumenti di collaborazione, archiviazione cloud, telefonia o applicazioni specifiche del settore. Se queste dipendenze diventano visibili solo dopo il blocco, Application Control appare rapidamente come un fattore di disturbo anziché una funzione di protezione.

Per l’accettazione, vale la pena avere una breve lista di decisioni: quale applicazione viene bloccata, quale gruppo di utenti è interessato, quale eccezione è consentita, chi è il proprietario tecnico e quando la policy verrà riesaminata? Questa documentazione è più importante di un primo filtro perfetto.

Distinguere Application Filter, Application Object e Shaping

I termini sono simili, ma risolvono compiti diversi. Questa distinzione evita molta ricerca guasti:

• Application Filter: stabilisce quali applicazioni vengono consentite, bloccate o registrate. Tipico per strumenti di controllo remoto, archiviazione cloud o una modalità di osservazione.
• Application Object: raggruppa applicazioni come oggetto. Utile per gruppi riutilizzabili quando la stessa selezione serve più volte.
• Application-based Traffic Shaping: prioritizza o limita le applicazioni riconosciute. Tipico per la prioritizzazione di Teams, la limitazione dello streaming o il throttling del Wi-Fi ospiti.
• Synchronized Application Control: integra il riconoscimento delle applicazioni con dati dei sistemi Sophos Endpoint tramite Security Heartbeat. È utile soprattutto per programmi che altrimenti il firewall riconosce solo in modo generico o non riconosce affatto.

Per una semplice policy di blocco o allow, l’Application Filter è il punto di partenza più importante. Application Objects e Traffic Shaping diventano interessanti solo quando la selezione di applicazioni deve essere riutilizzata o la banda deve essere controllata in modo mirato.

Synchronized Application Control non sostituisce regole firewall pulite. Richiede Sophos Central, Security Heartbeat e una copertura Sophos Endpoint adeguata. Le nuove applicazioni rilevate appaiono in categorie proprie come SyncAppCtl discovered e non dovrebbero essere bloccate alla cieca. Prima verificare, poi categorizzare, quindi includere nell’Application Filter.

Le applicazioni rilevate ricevono automaticamente un’etichetta di stato: New per le applicazioni ancora sconosciute, Mapped per le applicazioni assegnate automaticamente a una categoria e Customized per le voci modificate manualmente. Sophos supporta Synchronized Application Control fino a 15.000 applicazioni e conserva solo le ultime cinque occorrenze per applicazione ed endpoint per risparmiare spazio di archiviazione. Questo limite è particolarmente rilevante quando serve ricostruire dal punto di vista forense quante volte un’applicazione si è verificata su un endpoint.

Creare un filtro delle applicazioni

Percorso del menu:

Applications > Application filter

Nelle viste di navigazione precedenti, il percorso può apparire come Protect > Applications > Application filter.

Procedura:

1. Aprire Add.
2. Assegnare un nome significativo, ad esempio Block_Remote_Control_Tools.
3. Scegliere una policy esistente come template, ad esempio una policy Allow-All come punto di partenza per regole di blocco mirate.
4. Salvare la policy.
5. Riaprire la policy e aggiungere una regola all’interno del filtro.
6. Selezionare applicazione, categoria, rischio, Characteristics, Technology, Classification o Smart Filter.
7. Impostare l’azione, ad esempio Deny o Allow.
8. Impostare lo Schedule, se la regola deve valere solo in determinati orari.
9. Salvare la regola e poi salvare la policy.

Con le categorie bisogna essere cauti. Una categoria ampia può colpire più applicazioni del previsto. Per i primi test, singole applicazioni o gruppi chiaramente definiti sono spesso migliori di un grande blocco collettivo.

Quando si aggiunge una regola ci sono due modalità operative tipiche. Select All con filtri è adatto quando si intende un intero gruppo, ad esempio Category File Transfer, Characteristics Transfer files e Technology Browser Based. Select Individual Application è migliore quando devono essere interessate solo singole applicazioni come AnyDesk, TeamViewer o uno specifico servizio cloud. Lo Smart Filter cerca nel nome e nella descrizione di un’applicazione; non sostituisce una verifica tecnica dell’elenco dei risultati.

Il filtro Classification vale solo per applicazioni cloud. Se una Cloud App viene riclassificata in seguito, Sophos Firewall aggiorna anche le regole basate su questa Classification. Queste regole sono pratiche, ma più dinamiche di un elenco fisso di singole applicazioni.

Esempio: bloccare trasferimenti file basati su browser

Un buon primo esempio è il blocco dei trasferimenti file basati su browser in una rete guest o client. Non si blocca in modo generico l’intera categoria File Transfer, ma si limita la selezione ai trasferimenti file basati su browser.

Configurazione nell’Application Filter:

1. Aprire Applications > Application filter.
2. Creare una policy, ad esempio Block_File_Transfer.
3. Scegliere come template una policy allow adatta.
4. Salvare la policy e riaprirla.
5. Aprire Add per una nuova regola di filtro.
6. Usare Select All e restringere la selezione con Category: File Transfer, Characteristics: Transfer files e Technology: Browser Based.
7. Impostare Action su Deny.
8. Impostare Schedule su All the time, se non è necessaria una pianificazione oraria.
9. Salvare la regola di filtro e poi salvare la policy.

L’esempio è volutamente più preciso di un blocco globale di tutte le applicazioni di file transfer. In molte aziende, altrimenti, verrebbero colpiti anche servizi cloud, update, backup o collaboration legittimi. Prima dell’uso in produzione, testare il filtro nel Log Viewer con client reali.

Attivare nella regola del firewall

Application Control ha effetto solo quando il filtro è selezionato in una regola del firewall.

Percorso del menu:

Protect > Rules and policies > Firewall rules

Procedura:

1. Aprire la regola del firewall attraverso cui passa effettivamente il traffico interessato.
2. Aprire la sezione Other security features.
3. Selezionare il filtro delle applicazioni in Identify and control applications (App control).
4. Attivare Log firewall traffic, almeno per test e accettazione.
5. Salvare la regola.
6. Testare con un client definito.

L’ordine delle regole è cruciale. Se il traffico viene già elaborato da una regola più generale in alto, non raggiunge la regola con Application Control. In tal caso, la configurazione nel WebAdmin sembra corretta, ma non ha effetto.

Se viene creata una nuova regola LAN-WAN, NAT deve essere considerato separatamente. Gli esempi Sophos usano spesso Create linked NAT rule con MASQ per un accesso Internet semplice. Con regole produttive esistenti, però, non si dovrebbero creare nuove regole NAT senza verifica, ma controllare quale regola SNAT/MASQ si applica già a questo traffico.

Per policy Application Control basate su utenti o gruppi, la regola del firewall deve davvero fare match sul contesto utente. Match known users e un’autenticazione funzionante sono quindi importanti quanto l’Application Filter stesso. Senza contesto utente, la policy si applica solo a criteri di rete, zone e servizi.

Con nuove regole bisogna inoltre scegliere consapevolmente tra IPv4 e IPv6. Application Control viene attivato nella rispettiva regola del firewall. Se un client usa un percorso diverso tramite IPv6 rispetto a IPv4, il test può sembrare pulito anche se una parte del traffico passa fuori dalla regola prevista.

Le basi su Source, Destination, Services, Security Features e ordine delle regole sono disponibili in Comprendere e configurare in modo sicuro le regole del firewall Sophos.

Verificare consapevolmente il match della regola

Prima del salvataggio, la regola dovrebbe essere letta come un caso di test:

• Source zone e Source network: Il client di test deve provenire davvero da questa zona e da questa rete
• Destination zone e Destination network: Destinazioni ampie possono funzionare, ma sono più difficili da ricostruire
• Services: Per il traffico web sono spesso rilevanti TCP 80/443; QUIC usa UDP 443
• Web policy, IPS e TLS Inspection: Più Security Features possono influenzare lo stesso flow
• Log firewall traffic: Senza logging, l’effetto è difficile da dimostrare nel Log Viewer

Quando Application Control viene introdotto per la prima volta, la prima regola dovrebbe essere preferibilmente un po’ più stretta e facile da misurare. Una grande regola LAN-to-WAN con molte eccezioni rende l’accettazione molto più laboriosa.

Ispezione TLS e riconoscimento

Application Control può riconoscere determinate applicazioni anche senza un’ispezione TLS completa. Tuttavia, con molti servizi moderni HTTPS e cloud, il firewall senza decrittazione vede solo informazioni limitate come indirizzo IP, SNI, dati del certificato, nome host o metadati della connessione.

Questo non è sufficiente in ogni caso per un riconoscimento affidabile. Se un’applicazione tramite HTTPS non viene riconosciuta come previsto, si dovrebbe verificare:

• il traffico passa attraverso la regola del firewall corretta?
• Application Control è attivo in questa regola?
• l’applicazione è generalmente riconosciuta da Sophos?
• l’ispezione TLS è necessaria e accettabile per questo traffico?
• ci sono QUIC o HTTP/3 che rendono il controllo più difficile?
• Web Policy, IPS o DNS Protection intervengono ulteriormente?

L’ispezione TLS dovrebbe essere introdotta gradualmente e con eccezioni. La procedura appropriata è descritta in Introdurre correttamente l’ispezione TLS su Sophos Firewall. Per QUIC e HTTP/3, vedere Bloccare correttamente il protocollo QUIC e HTTP/3 su Sophos Firewall.

Per le applicazioni cloud la differenza è particolarmente visibile: i dati di base su byte e utilizzo richiedono soprattutto il logging firewall attivato. Informazioni più precise su upload, download e tipo di file si vedono però in modo affidabile solo quando HTTPS viene decrittato. Alcune applicazioni trasferiscono file tramite meccanismi propri; in questi casi i campi di dettaglio possono restare vuoti o sembrare incompleti anche se il traffico è presente.

Per il Cloud App Reporting è quindi consigliabile una combinazione di tre elementi: attivare Log firewall traffic, decrittare HTTPS dove è sostenibile dal punto di vista organizzativo e tecnico, e usare una Web Policy che non sia semplicemente None. Questo rende i dati di Application Control molto più utili nell’esercizio operativo.

Testare l’efficacia

Dopo l’attivazione, non si dovrebbe solo aspettare il feedback degli utenti. Un test accurato risparmia molto tempo.

Procedura pratica:

1. Definire il client di test e l’IP di origine.
2. Avviare consapevolmente l’applicazione o accedere all’obiettivo.
3. Nel Log viewer, filtrare per IP di origine, destinazione, servizio e applicazione.
4. Verificare quale ID regola del firewall è stato colpito.
5. Verificare se Application Control riconosce l’applicazione.
6. Annotare Application ID, categoria, azione e Application Filter.
7. In caso di blocco, verificare se il blocco è tecnicamente voluto.
8. In caso di riconoscimento incerto, integrare Packet Capture, Service Logs e, con logging centrale, i campi Syslog.

Gli eventi Application Control appaiono nel Log Viewer come eventi Application o Content Filtering. Per l’accettazione sono rilevanti soprattutto Firewall Rule ID, utente, applicazione, categoria, rischio, azione, sorgente e destinazione. Per analisi Syslog o SIEM vanno verificati anche campi come fw_rule_id, application_name, application_filter_policy, application_category, application_risk, status e appresolvedby. Quest’ultimo aiuta a capire se l’applicazione è stata riconosciuta tramite firma, logica proxy o Synchronized Application Control.

Application Control utilizza frequentemente ips.log nel percorso tecnico. L’assegnazione dei log è descritta in Risoluzione dei problemi di Sophos Firewall: Servizi e log. Per la delimitazione con Log Viewer e Packet Capture, vedere Testare le regole del firewall Sophos con Log Viewer, Policy Test e Packet Capture.

Passare dall’osservazione al blocco

Il passaggio dalla sola rilevazione al blocco deve essere consapevole. In molti ambienti è meglio usare prima Application Control come strumento di osservazione e reporting. Solo dopo si bloccano le applicazioni di cui sono chiari rischio, utenti interessati e dipendenze aziendali.

Prima di bloccare, verificare:

• Quali utenti, reti o dispositivi usano davvero l’applicazione?
• Quale regola firewall e quale Rule ID si vedono nel Log Viewer?
• L’applicazione viene riconosciuta in modo affidabile o solo come categoria generica?
• Esiste un uso business legittimo, un caso di supporto o uno strumento del produttore?
• L’applicazione deve essere bloccata ovunque o solo in reti guest, scolastiche, client o server?
• Chi approva un’eccezione e quando viene riesaminata?

Un flusso pratico pulito è: raccogliere prima i log, poi bloccare una singola applicazione o un piccolo gruppo, quindi validare con un client di test e Log Viewer. Se un blocco è troppo ampio, non bisogna disattivare l’intero Application Filter, ma modificare in modo mirato l’applicazione, la categoria o la posizione della regola interessata.

Se Application Control non ha effetto

In caso di problemi non si dovrebbe disattivare subito l’intero filtro. Prima bisogna verificare in quale punto il processo si interrompe.

• Nessuna voce di log per la connessione di test: Manca il logging o il traffico non raggiunge la regola del firewall. Verificare Rule ID, zona sorgente e Packet Capture
• Log Viewer mostra un’altra Rule ID: Una regola più generale si trova più in alto. Correggere ordine delle regole e criteri di match
• L’applicazione resta unknown o generica: Il riconoscimento non basta senza più contesto. Verificare TLS Inspection, QUIC e firme applicative
• Il blocco colpisce troppi servizi: Categoria o Smart Filter troppo ampio. Usare singole applicazioni o gruppi più piccoli
• Dopo un Pattern Update viene improvvisamente bloccato di più: Una regola ampia su Risk, Category o Classification intercetta nuove firme. Verificare criteri della regola e processo di change.
• Mancano dettagli Cloud App: Senza HTTPS-Decryption o senza Web Policy, i dettagli su upload, download e tipo di file sono limitati. Verificare Cloud App Reporting e stato TLS.
• Il blocco funziona solo per alcuni client: Regola, zona, gruppo utenti o percorso browser diverso. Confrontare client di test, utente e percorso di rete
• IPv6 si comporta diversamente da IPv4: Possibile regola IPv6 separata, percorso DNS diverso o percorso browser diverso. Testare consapevolmente entrambi i protocolli o considerarli correttamente nel set di regole.

Il punto di controllo più importante è la Rule ID. Se la regola attesa non viene colpita, la policy Application Control non è quasi mai la vera causa.

Gestire correttamente i falsi positivi

Se Application Control blocca il traffico legittimo, non si dovrebbe disattivare immediatamente l’intero filtro.

Ordine sensato:

1. Documentare l’applicazione interessata e la voce di log.
2. Verificare quale regola del firewall e quale filtro delle applicazioni sono coinvolti.
3. Verificare applicazione, categoria e azione nel filtro.
4. Verificare se l’applicazione viene riconosciuta diversamente tramite ispezione TLS.
5. Impostare l’eccezione il più strettamente possibile: applicazione, rete di origine, gruppo di utenti o destinazione.
6. Documentare il proprietario e la data di revisione per l’eccezione.

Un’eccezione per Any o una categoria ampia risolve spesso rapidamente il caso attuale, ma indebolisce il controllo in modo permanente. È meglio un’eccezione piccola e giustificabile con una chiara motivazione.

Errori tipici

• Filtro delle applicazioni creato, ma non selezionato nella regola: nessun effetto sul traffico. Attivare il filtro nella vera regola del firewall
• Il traffico passa attraverso un’altra regola: Il filtro non viene mai raggiunto. Verificare l’ID regola nel Log Viewer
• Categoria troppo ampia bloccata: Servizi cloud o aziendali legittimi colpiti. Utilizzare singole applicazioni o gruppi più ristretti
• Filtri dinamici non compresi: Risk, Category o Classification possono produrre nuovi match tramite aggiornamenti delle firme e delle Cloud App. Verificare regolarmente.
• Riconoscimento HTTPS sopravvalutato: L’applicazione non viene riconosciuta in modo affidabile. Verificare ispezione TLS e comportamento QUIC
• Mancanza di logging: L’effetto rimane invisibile. Attivare il logging delle regole per test e operatività
• Eccezione troppo ampia: La funzione di protezione viene praticamente annullata. Impostare eccezioni strette e con data di revisione

Controllo operativo

Application Control dovrebbe essere controllato regolarmente. Le applicazioni cambiano, i servizi cloud utilizzano nuovi endpoint, gli utenti utilizzano nuovi strumenti e le firme vengono aggiornate.

Dovrebbe essere documentato:

• Scopo del filtro delle applicazioni
• Regole del firewall interessate
• Applicazioni bloccate o consentite
• Eccezioni conosciute
• Proprietario tecnico
• Data di revisione
• Ultima modifica rilevante

Se Application Control viene utilizzato per applicazioni aziendali critiche, reti scolastiche o requisiti di conformità, dovrebbero essere controllati anche Central Reporting, Syslog o SIEM. Per la valutazione centrale, vedere Attivare Central Firewall Reporting o Configurare Syslog e SIEM su Sophos Firewall.

Checklist

• Stato della licenza verificato.
• Regola del firewall interessata chiaramente identificata.
• Filtro delle applicazioni creato con uno scopo chiaro.
• Template, filtri dinamici e criteri della regola documentati.
• Filtro selezionato nella regola del firewall corretta.
• Logging delle regole attivo.
• Client di test e applicazione di test definiti.
• Log Viewer controllato per ID regola e Application Control.
• Uso reale, owner e regola di eccezione chiariti prima del blocco.
• Percorso IPv4 e IPv6 verificato, se entrambi sono attivi nella rete.
• Ispezione TLS e QUIC valutati, se il riconoscimento HTTPS è incerto.
• Cloud App Reporting verificato se necessario con HTTPS-Decryption e Web Policy.
• Eccezioni documentate in modo stretto.
• Data di revisione impostata.

Domande frequenti