Configurare e testare il controllo delle applicazioni su Sophos Firewall

Application Control identifica il traffico delle applicazioni che non può essere distinto in modo adeguato basandosi soltanto sulle porte. Sophos Firewall può così, ad esempio, consentire o bloccare in modo selettivo strumenti di controllo remoto, applicazioni di tunneling, streaming o cloud storage. La corrispondenza viene registrata tramite la relativa regola firewall; un Application Filter non dispone di un’azione Log propria.

Il procedimento essenziale è breve: in Applications > Application filter si crea il filtro, in Rules and policies > Firewall rules lo si assegna alla regola effettivamente applicata e infine si verificano Rule ID, applicazione e azione con un client reale. Una policy di filtro salvata, da sola, non modifica il traffico.

Definire prerequisiti e obiettivo

Application Control fa parte della Web Protection Subscription. Lo stato della licenza si verifica in Administration > Licensing. Prima della configurazione occorre inoltre definire:

• l’utente o il segmento di rete interessato e i relativi percorsi IPv4/IPv6;
• l’applicazione o il gruppo da monitorare o bloccare inizialmente;
• la regola firewall che attualmente gestisce questo traffico;
• un client di test, una richiesta di test riproducibile e il risultato atteso;
• l’Application Filter attualmente assegnato, la posizione della regola e l’associazione NAT esistente come stato iniziale per il ripristino.

Gli aggiornamenti delle firme si controllano in Backup & firmware > Pattern updates. Per impostazione predefinita vengono eseguiti automaticamente; se necessario, Update pattern now aggiorna tutte le definizioni dei pattern, esclusi i pattern del firmware per AP e RED. Gli stati Ready to install, Downloading, Success e Failed aiutano a circoscrivere il problema. Le firme delle applicazioni restano disponibili anche senza una licenza IPS attiva, mentre le firme IPS richiedono una licenza appropriata e IPS attivo. Sophos documenta un’eccezione per le installazioni air gap: le firme IPS e delle applicazioni vengono aggiornate anche quando la protezione IPS è disattivata.

Per la regola di test si attiva Log firewall traffic. Il logging è gestito dalla regola firewall, non dall’Application Filter. Per il solo monitoraggio, si utilizza quindi un filtro con azione di autorizzazione e si analizza il traffico rilevato prima di impostare singole applicazioni su Deny.

Se il vero obiettivo è la definizione delle priorità o la limitazione della larghezza di banda, Configurare il traffic shaping delle applicazioni su Sophos Firewall integra il filtro. Per le route SD-WAN basate sulle applicazioni si utilizza invece un Application Object; la procedura è illustrata in Configurare una route SD-WAN con failover del gateway su Sophos Firewall.

Pianificare e creare l’Application Filter

In Applications > Application list si può verificare se Sophos dispone di una firma specifica e a quale categoria o livello di rischio è attualmente associata. Per il campo Name del filtro sono disponibili contains, is, is not e does not contain. Una corrispondenza nel catalogo non dimostra ancora che l’applicazione venga identificata nella propria rete; a questo scopo verrà eseguito successivamente il test con il client.

Una selezione fissa di singole applicazioni offre risultati prevedibili. Criteri come Risk, Category o Classification, disponibile soltanto per le applicazioni cloud, rimangono invece dinamici: in futuro potrebbero corrispondere anche firme nuove o riclassificate. Queste regole richiedono l’indicazione del responsabile nella documentazione e una revisione dopo le modifiche ai pattern o alla classificazione.

Il percorso completo per una policy e la relativa regola è:

Applications > Application filter > Add
Applications > Application filter > Edit policy > Add

1. In Add, assegnare un nome univoco, ad esempio Block_File_Transfer_Pilot.
2. Scegliere un template. Per un blocco mirato, Allow All è un punto di partenza comprensibile; non bisogna presumere che ogni nuova policy vuota funzioni automaticamente in questo modo.
3. Salvare la policy, riaprirla e creare una regola del filtro con Add.
4. Utilizzare Select Individual Application oppure, con Select All, limitare le corrispondenze in base ad Application, Category, Risk, Characteristics, Technology, Classification o Smart Filter.
5. Impostare Action su Allow o Deny.
6. In Schedule, scegliere ad esempio All the time oppure assegnare una pianificazione appropriata.
7. Salvare prima la regola del filtro e poi la policy.

SFOS include, tra gli altri, i template Allow All, Deny All, Block filter avoidance apps, Block generally unwanted apps, Block high risk (Risk Level 4 and 5) apps, Block peer to peer (P2P) networking apps e Block very high risk (Risk Level 5) apps. Un template è un punto di partenza, non una configurazione standard già pronta. Prima di un’assegnazione su vasta scala, soprattutto le regole basate su Risk e Category devono essere confrontate con le applicazioni necessarie nella propria rete.

Le regole basate sul tempo richiedono uno Schedule adeguato. La procedura per crearlo e verificarlo rispetto all’ora del firewall e alle regole di fallback è descritta in Configurare le pianificazioni per regole e policy su Sophos Firewall.

Esempio: bloccare i trasferimenti di file tramite browser

L’esempio ufficiale non interviene sulle altre applicazioni di trasferimento file e limita soltanto i trasferimenti tramite browser:

1. Creare la policy Block_File_Transfer_Pilot a partire da Allow All e riaprirla.
2. Creare una regola con Add > Select All.
3. Selezionare Category: File Transfer, Characteristics: Transfer files e Technology: Browser Based.
4. Impostare Action: Deny e Schedule: All the time.
5. Salvare la regola del filtro e la policy.

Anche questa selezione può coinvolgere procedure legittime di upload, collaborazione o backup. Il client pilota dovrebbe quindi testare sia un trasferimento da bloccare sia un servizio aziendale esplicitamente consentito nello stesso ambito.

Assegnare il filtro alla regola firewall corretta

Application Control diventa operativo soltanto all’interno di una regola firewall. Per una nuova regola, il percorso attuale è:

Rules and policies > Firewall rules
> IPv4 o IPv6
> Add firewall rule
> New firewall rule
> Other security features
> Identify and control applications (App control)

Per una regola esistente, si apre direttamente Other security features e si seleziona l’Application Filter preparato. Log firewall traffic rimane attivo durante il progetto pilota e il collaudo.

La regola deve corrispondere realmente a Source Zone, Source Network, Destination Zone, Destination Network, Services e, se applicabile, Match known users del client di test. Le regole firewall vengono valutate dall’alto verso il basso; la prima corrispondenza interrompe la ricerca. Una regola più generica collocata più in alto è quindi una causa di problemi più frequente dello stesso Application Filter.

Per una nuova regola Internet, anche il percorso NAT deve essere corretto. Negli esempi Sophos, Create linked NAT rule può creare una regola MASQ. In un ambiente esistente non si crea una seconda regola NAT senza una motivazione precisa; si verifica invece la regola SNAT/MASQ già operativa e si annota la relativa NAT Rule ID.

IPv4 e IPv6 dispongono di percorsi delle regole distinti. Se il client utilizza entrambi i protocolli, occorre testarli entrambi oppure limitare intenzionalmente il progetto pilota a uno solo. I fondamenti delle regole sono illustrati in Comprendere e configurare in sicurezza le regole di Sophos Firewall.

Verificare l’effetto con Live connections e Log viewer

Un test attendibile risponde a tre domande distinte: quale regola gestisce il flusso, quale applicazione identifica SFOS e quale azione viene eseguita?

1. Annotare client di test, IP di origine, utente, ora e destinazione.
2. Facoltativamente, eseguire Reset data transfer count nelle opzioni della regola pilota, così da poter associare più facilmente i nuovi byte.
3. Avviare la richiesta di test e controllare la connessione ancora aperta in Current activities > Live connections.
4. Confrontare Application, Source IP, Username, Interfaces, porte di origine/destinazione, Firewall Rule ID e NAT Rule ID con il percorso pianificato.
5. Aprire Log viewer in alto a destra nell’interfaccia WebAdmin e filtrare per IP di origine, utente, destinazione, Rule ID e applicazione.
6. Eseguire un blocco previsto e una richiesta di controllo consentita nello stesso ambito.

Una corrispondenza negata dall’Application Filter viene visualizzata come Content Filtering > Application > Denied. Il traffico consentito e identificato compare nel log del firewall in Firewall > Firewall Rule > Allowed. Per il collaudo si documentano almeno Firewall Rule ID, Application Filter, applicazione, categoria, rischio, azione, utente, origine e destinazione.

Le sessioni firewall compaiono spesso soltanto al Connection Destroy event, quando SFOS chiude la connessione. Una sessione del browser o di streaming ancora aperta può quindi essere già visibile in Live connections, anche se non è ancora presente la relativa voce conclusiva nel log del firewall. Le connessioni SSL/TLS vengono registrate dopo il completamento dell’handshake e alla chiusura.

In Reports > Dashboards > Traffic dashboard > Allowed policies si possono controllare anche i dati trasferiti dalle regole che consentono il traffico. Il report, tuttavia, non sostituisce il test specifico della Rule ID e dell’applicazione. I report locali non sono disponibili su XGS 87/87w e XGS 88/88w; su questi modelli utilizzare i controlli dei log e delle connessioni.

Con Syslog o SIEM, i nomi dei campi variano in base al formato di output. Il Central Reporting Format utilizza, tra gli altri, fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier e status. Nel Device Standard Format (Legacy) i campi corrispondenti si chiamano, ad esempio, application_filter_policy, application_name, application_category, application_risk e appresolvedby. app_resolved_by e appresolvedby distinguono, tra gli altri, Signature, Proxy e Synchronized Application Control (EAC).

Gli eventi tecnici relativi ad Application Filter e DPI vengono registrati in ips.log; sig_upgrade.log e sigmigration.log sono utili per gli aggiornamenti delle firme. L’associazione dei log è descritta in Risoluzione dei problemi su Sophos Firewall: servizi e log. Packet Capture può confermare IP, porte, interfaccia e percorso dei pacchetti, ma non dimostra la classificazione dell’applicazione. La procedura diagnostica combinata è illustrata in Testare una regola di Sophos Firewall con Log Viewer, Policy Test e Packet Capture.

Valutare HTTPS, QUIC e le eccezioni web

SFOS identifica molte applicazioni basate sulle firme anche senza decrittografia completa. Le Micro Apps basate su URL, come i trasferimenti di file in Dropbox o Gmail, richiedono tuttavia l’URL decrittografato nel traffico crittografato. Nel percorso DPI è necessaria una regola appropriata in Rules and policies > SSL/TLS inspection rules. Scan HTTP and decrypted HTTPS attiva la scansione antimalware per il traffico HTTPS già decrittografato, ma non attiva la decrittografia stessa.

Nel percorso web proxy, Decrypt HTTPS during web proxy filtering gestisce la decrittografia. La presenza di una Web Policy non dimostra né che HTTPS venga decrittografato né che venga applicata la stessa regola DPI. L’implementazione controllata è descritta in Introdurre correttamente TLS Inspection su Sophos Firewall.

Block QUIC protocol elimina, nell’ambito della regola firewall, i pacchetti UDP in uscita verso le porte 80 e 443, affinché i client ripieghino su un percorso TCP verificabile. SFOS seleziona questa opzione per impostazione predefinita non appena si sceglie una Web Policy o si attiva Scan HTTP and decrypted HTTPS. Il web filter non può analizzare QUIC; ciò non significa, tuttavia, che ogni altro controllo del firewall venga aggirato. Bloccare correttamente QUIC e HTTP/3 su Sophos Firewall descrive il test positivo e quello negativo.

In caso di identificazione imprevista, occorre controllare anche Web > Exceptions. Una Web Exception può escludere Decryption, scansione antimalware/dei contenuti e Policy Checks e, a seconda della selezione, può applicarsi sia al percorso DPI sia a quello proxy. Un’eccezione troppo ampia può quindi eliminare il contesto applicativo previsto.

Nel traffico web proxy, un log del firewall con Allowed non dimostra automaticamente che l’accesso dell’utente sia stato consentito: il firewall può inizialmente inoltrare la connessione al proxy, mentre il Web Filter la registra successivamente come Blocked. In questi casi, il log del firewall e quello web vanno analizzati insieme.

Classificare le applicazioni cloud

In Applications > Cloud applications, SFOS mostra soltanto il traffico consentito e le applicazioni per le quali è presente del traffico. La vista può essere filtrata per data, Classification, Category e byte trasferiti; Expand apre i dettagli. L’assenza di una voce non esclude quindi un tentativo bloccato.

Le nuove applicazioni cloud hanno inizialmente la Classification new. Dopo averle verificate, con Classify si assegna sanctioned, unsanctioned o tolerated. La nuova Classification si applica al traffico futuro e, da sola, non consente né blocca alcunché. Soltanto un Application Filter che utilizza questo criterio ed è assegnato a una regola firewall corrispondente applica l’azione desiderata.

I dati di base sull’utilizzo e sui byte richiedono il logging del firewall. I contatori di upload/download e i dettagli sui tipi di file richiedono la decrittografia HTTPS; secondo Sophos, una Web Policy diversa da None migliora inoltre l’accuratezza e il livello di dettaglio. Alcune applicazioni utilizzano meccanismi di trasferimento propri, perciò alcuni campi di dettaglio possono comunque rimanere vuoti.

Con Traffic shaping è possibile assegnare a un’applicazione cloud identificata una policy di larghezza di banda già predisposta. Questa assegnazione non sostituisce né l’Application Filter né la regola firewall.

Casi particolari: archiviazione online e video di Facebook

L’esempio ufficiale per Google Drive combina l’Application Filter Block_GoogleDrive con la Web Policy BlockPersonalStorage. Il filtro viene creato a partire da Allow All, cerca google drive tramite Smart Filter e imposta le applicazioni selezionate su Deny e All the time. In Web > Policies, per la regola mirata allo storage si deseleziona All web traffic, si cerca personal con Add new item > Web category e si impostano le categorie appropriate su Block HTTP e Block HTTPS. Entrambe le policy devono essere assegnate alla stessa regola firewall effettivamente applicata. Configurare Web Protection su Sophos Firewall illustra il funzionamento delle policy.

Nell’esempio per i video di Facebook, nell’Application Filter si selezionano tramite Select Individual Application le corrispondenze per Facebook videos. Per una categoria personalizzata, Sophos indica inoltre attualmente facebook.com/watch, facebook.com/reel, gateway.facebook.com, facebook.com/ajax e facebook.com/stories, oltre alle parole chiave watch, reel, gateway, ajax e videos. Questi valori rappresentano un punto di partenza legato alla versione e vanno verificati prima dell’uso, poiché parole chiave generiche possono intercettare anche altri percorsi. La categoria deve trovarsi in una regola della Web Policy con un’azione di blocco; l’attuale procedura per Facebook non specifica questa azione in modo esplicito come l’esempio per lo storage.

L’esempio Sophos utilizza il Web Proxy, decrittografa HTTPS e blocca QUIC. A tale scopo, i client devono considerare attendibile la CA di Sophos Firewall. Un ambiente DPI esistente non va convertito soltanto per questo caso particolare. La procedura proxy non dimostra un blocco equivalente dei video Facebook tramite DPI; convalidare un progetto DPI separato con Sophos Support e test client prima di farvi affidamento. La procedura per le categorie personalizzate è illustrata in Creare categorie web su Sophos Firewall, mentre la distribuzione della CA è descritta in Distribuire il certificato CA di Sophos Firewall per la scansione HTTPS.

Utilizzare Synchronized Application Control in modo mirato

Synchronized Application Control integra l’identificazione sulla rete con i dati degli endpoint Sophos gestiti. Oltre alla Web Protection Subscription, richiede Security Heartbeat, una Network Protection Subscription, un account Sophos Fusion (in precedenza Sophos Central) e un endpoint gestito con licenza di prova o completa.

La registrazione avviene in:

System > Sophos Central > Sophos Central registration > Register

Dopo la registrazione, SFOS attiva automaticamente Security Heartbeat e Synchronized Application Control. Se Security Heartbeat viene disattivato, si disattiva anche Synchronized Application Control; questa soluzione non costituisce quindi un rollback mirato per una singola applicazione.

Al primo utilizzo, dopo la registrazione, verificare in Sophos Fusion (in precedenza Sophos Central) che Synchronized Application Control sia attivato e attivarlo se necessario. Il dominio creato sul firewall deve corrispondere al dominio selezionato sull’endpoint.

In Applications > Synchronized Application Control si può effettuare una ricerca per nome, percorso, categoria o endpoint ed espandere la voce per visualizzare le occorrenze. Sophos supporta fino a 15'000 applicazioni. A partire da SFOS 20.0 MR1, SFOS memorizza soltanto le cinque occorrenze più recenti di ogni applicazione per endpoint.

Durante una migrazione a SFOS 21.0 o versione successiva, SFOS attiva la pulizia automatica solo se Synchronized Application Control (SAC) è attivato. Il periodo di conservazione predefinito è di dodici mesi. Se in precedenza era stato configurato un periodo personalizzato, questo viene mantenuto. Se SAC è disattivato, sia SAC sia la pulizia automatica rimangono disattivati. La pulizia rimuove le applicazioni aggiunte singolarmente anche dagli Application Filter. Durante una migrazione a SFOS 20.0 MR1 o versione successiva, SFOS elimina le occorrenze meno recenti; se la pulizia automatica non riesce per mancanza di spazio, Sophos invita a contattare il supporto.

New identifica le nuove voci, Mapped le applicazioni associate automaticamente e Customized le voci modificate manualmente. In Manage > More options sono disponibili le azioni seguenti:

• Customize: assegnare un nome comprensibile e una categoria appropriata, quindi selezionare Apply;
• Acknowledge: cambiare l’etichetta da New a Customized senza modificare il nome o la categoria;
• Hide e Show: nascondere o mostrare nuovamente la voce;
• Delete: eliminare l’applicazione e rimuoverla contemporaneamente dagli Application Filter che la utilizzano.

Dopo Customize o Acknowledge, l’applicazione verificata viene aggiunta a un Application Filter nuovo o esistente. Il filtro viene quindi assegnato alla regola firewall effettivamente applicata. Successivamente, si avvia un flusso di test riproducibile e si verificano nel Log Viewer la Rule ID prevista, il nome dell’applicazione e l’azione. Solo dopo questa fase pilota il rilevamento viene convertito in una regola Allow o Deny di produzione.

Una voce eliminata ricompare se un endpoint la segnala nuovamente. Prima di selezionare Delete, occorre quindi controllare i filtri che la utilizzano; in seguito si eseguono un nuovo flusso di test e la verifica della Rule ID prevista. Per l’IA generativa, Identificare e controllare l’IA generativa con Sophos Firewall illustra una procedura pilota specifica.

Verificare integralmente selezione e configurazione di esempio

Catalogo, template e blocchi mirati

Nel catalogo, aprire Filter accanto al campo interessato; tranne per Name, scegliere un valore dall’elenco. Smart Filter cerca nei nomi e nelle descrizioni. Qualsiasi Application Filter Policy esistente, anche personalizzata, può fungere da template. Verificarne regole e pianificazioni prima di copiarla.

Le categorie descrivono scopi diversi, non automaticamente una valutazione di sicurezza:

• File transfer: trasferimenti e upload; Download applications: download, condivisione di file, storage e acceleratori; Storage and backup: archiviazione di file, collaborazione e archiviazione di password.
• Gaming: giochi e competizioni; Streaming media: audio, video e trasmissioni in diretta; Social networking: social network; E-commerce: applicazioni commerciali.
• Instant messenger: chat; VoIP: telefonia IP; Conferencing: riunioni virtuali; Web mail: posta nel browser; Desktop mail: client di posta.
• General internet: tra l’altro notizie, ricerca, browser, acquisti e spazi di lavoro; General business: hosting, collaborazione, contabilità e backup; Mobile applications: app dei sistemi operativi mobili; Software update: aggiornamenti di sistemi e applicazioni.
• Infrastructure: ad esempio DNS, DHCP, SMTP, MySQL, QUIC e TLS su altre porte; Network services: routing, avvio, QoS e FTPS; P2P: condivisione di file peer-to-peer; Proxy and tunnel: proxy e VPN; Remote access: accesso e desktop remoti; Industrial control system: comunicazioni di edifici, telecontrollo e processi.
• SyncAppCtl discovered: applicazioni sconosciute rilevate tramite SAC; Sophos applications: applicazioni Sophos associate da SAC; System applications: servizi di sistema associati da SAC, ad esempio Windows o Linux; Generative AI: applicazioni e servizi di IA.

Allow All consente e Deny All scarta tutte le applicazioni. Block filter avoidance apps blocca tunnel, proxy e applicazioni che aggirano le policy; Block generally unwanted apps include trasferimenti di file, proxy/tunnel, applicazioni rischiose e P2P. Il P2P può distribuire malware; bloccarlo è sensato salvo esigenze aziendali approvate. I template ad alto rischio riguardano i livelli 4/5 oppure solo il 5.

Per un blocco individuale, filtrare Facebook Games in Select Individual Application > Name, selezionarlo e salvare con Action: Deny, Schedule: All the time. La stessa procedura è adatta a WhatsApp, Skype, LinkedIn o Internet Download Manager. Per gruppi, usare Category: Generative AI oppure Category: P2P. L’esempio UltraVPN usa Category: Proxy and Tunnel e PPTP Protocol; non garantisce il rilevamento di ogni tunnel VPN.

Per Block_High_Risk_Apps, dopo il salvataggio e la riapertura scegliere Add > Select All > Risk, selezionare High e Very High, confermare con OK e impostare Deny e All the time. Salvare regola e policy e assegnare quest’ultima alla regola firewall Block_High_Risk_Apps_Rule. Dopo gli aggiornamenti dei pattern vengono incluse anche nuove firme corrispondenti. Gli esempi più vecchi descrivono una policy vuota permissiva e la sezione Advanced; per SFOS 22/23 usare esplicitamente Allow All e verificare l’assegnazione in Other security features, senza trasferire quei dettagli senza controllo.

Impostazioni comuni di firewall e web

Gli esempi di trasferimento e storage usano una regola firewall Accept da LAN a WAN, Log firewall traffic, Rule group: None, During scheduled time: All the time e Rule position: Top. Reti di origine, reti di destinazione e servizi sono Any; l’esempio ad alto rischio usa persino Any per entrambe le zone. Questi valori ampi non sono una raccomandazione per il pilota: limitare l’origine al client di test, adattare zone e servizi al percorso reale e scegliere consapevolmente la posizione sopra la regola che altrimenti corrisponderebbe. Senza Match known users, la regola si applica al traffico di rete corrispondente indipendentemente dall’utente; con questa opzione selezionare, ad esempio, Marketing per lo storage o Open Group per i trasferimenti in User or groups > Add new item. Sostituire questi nomi con il proprio gruppo approvato; il log di test deve mostrare l’associazione corretta dell’utente.

Se necessario, Create linked NAT rule crea una regola con Translated source (SNAT): MASQ; anche questa è su Top nell’esempio. Salvare prima la regola NAT, poi la regola firewall. Nelle reti esistenti resta determinante l’associazione NAT verificata in precedenza.

Per lo storage, attivare la regola web in Status dopo aver impostato Block HTTP/Block HTTPS, quindi salvare. Nel percorso proxy bloccare anche QUIC, attivare Scan HTTP and decrypted HTTPS e Decrypt HTTPS during web proxy filtering e distribuire la CA prima del test.

Per Facebook, salvare la categoria personalizzata in Web > Categories > Add con Classification: Unproductive e i valori Domain e Keyword indicati sopra. In Web > Policies > Add policy > Add rule, rimuovere All web traffic da Activities, selezionare la categoria tramite Add new item > Web category, scegliere Apply selected items, verificare azioni di blocco HTTP/HTTPS e stato attivo, quindi Save e, se applicabile, Skip this step. Salvare tutte le corrispondenze Facebook videos nell’Application Filter con Deny e All the time. L’esempio proxy completo attiva anche Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, Scan FTP for malware, Decrypt HTTPS during web proxy filtering e Block QUIC protocol. La scansione FTP è una protezione aggiuntiva, non una prova del blocco video. Un’opzione dal nome simile non dimostra da sola che il percorso DPI sia stato testato come equivalente; se il blocco non funziona, seguire il percorso diagnostico e di supporto descritto sopra.

Completare le operazioni cloud e SAC

Dopo Classify, confermare con Apply; dopo Traffic shaping, selezionare una policy esistente e Save. Ad esempio, verificare le applicazioni social unsanctioned in un determinato periodo oppure limitare lo streaming video.

Le applicazioni SAC sconosciute vengono inizialmente inserite in SyncAppCtl discovered; quelle note vengono categorizzate automaticamente. Limitare l’ambito di ricerca, ad esempio a System applications. Dopo Hide, le voci sono visibili solo in Hidden applications; ripristinarle con Show. Customize resta disponibile anche successivamente e imposta l’etichetta su Customized.

Clean up application database richiede la registrazione presso Sophos Fusion/Sophos Central. Dopo un controllo giornaliero, SFOS elimina le vecchie applicazioni in gruppi di 100 ogni cinque minuti, comprese le voci aggiunte singolarmente alle policy. Verificarne l’uso prima di modificare il periodo; ridurlo non è una soluzione di storage priva di rischi. Senza una Web Protection Subscription valida, SAC può essere configurato, ma non utilizzato.

Automatizzare Application Control tramite l’API XML

I riferimenti XML per SFOS 22/23 descrivono diversi oggetti con nomi simili. Una classificazione cloud non è né una regola di filtro né l’interruttore globale della Device Console. Prima di una chiamata di scrittura, si salvano lo stato esistente e le policy che lo utilizzano. L’accesso, la valutazione delle risposte e i tentativi ripetuti sicuri sono spiegati in Proteggere l’accesso all’API XML di Sophos Firewall. Prima dell’invio occorre completare la struttura XML per l’oggetto e la build installata.

Classificazioni cloud singole e multiple

ApplicationClassificationAssignment aggiorna esattamente un’assegnazione: i due campi obbligatori Application e Classification sono stringhe. L’esempio di riferimento riporta Facebook Website e New. Non si tratta di un catalogo completo delle classificazioni ammesse; i valori dell’interfaccia utente e l’uso di maiuscole e minuscole non vengono automaticamente considerati valori enumerati dell’API.

ApplicationClassificationBatchAssignment utilizza invece ClassAssignmentList con oggetti ClassAssignment ripetuti. In ogni oggetto sono presenti i campi in minuscolo app e class, non Application e Classification. La struttura documentata si presenta, ad esempio, così:

<ApplicationClassificationBatchAssignment>
  <ClassAssignmentList>
    <ClassAssignment>
      <app>iCloud</app>
      <class>New</class>
    </ClassAssignment>
    <ClassAssignment>
      <app>iPlay Website</app>
      <class>New</class>
    </ClassAssignment>
  </ClassAssignmentList>
</ApplicationClassificationBatchAssignment>

I nomi sono esempi di riferimento e vengono sostituiti con applicazioni effettivamente presenti. La tabella dei parametri descrive ClassAssignmentList come un array opzionale di oggetti con più valori. Da ciò non deriva né che un’operazione batch vuota sia sensata né una garanzia di elaborazione atomica, rollback o stato per ogni voce. Dopo una modifica, rileggere separatamente ogni assegnazione richiesta e verificare l’effetto di un filtro Classification solo con nuovo traffico. Per il batch, il riferimento indica 200 con Operation Successful. e 500 con Operation Fail.; per l’operazione singola riporta 200 e 500 con i simboli non risolti Message.AppClassificationUpdateSuccess e Message.AppClassificationUpdateFail, rispettivamente.

Policy di filtro: template o regole personalizzate

In ApplicationFilterPolicy, Template ha la precedenza: se viene fornito, il contratto documentato ignora DefaultAction e RuleList. Una richiesta con un template e una regola Deny personalizzata non è quindi una combinazione affidabile delle due varianti. Senza template, il riferimento descrive DefaultAction con Allow o Deny e RuleList/Rule per le regole personalizzate. La lunghezza massima di un carattere indicata nello stesso riferimento contraddice queste parole; da ciò non si deduce un valore abbreviato di un solo carattere. L’esempio XML riporta AllowAll, mentre l’interfaccia utente mostra Allow All. Non utilizzare il testo dell’interfaccia utente come token API senza verificarlo.

All’interno di Rule si trovano SelectAllRule, i contenitori di selezione, nonché Action e Schedule. I contenitori sono CategoryList/Category, RiskList/Risk, CharacteristicsList/Characteristics, TechnologyList/Technology, ClassificationList/Classification e ApplicationList/Application. Nell’esempio, SelectAllRule utilizza Enable/Disable; si tratta di un interruttore e non del valore di elenco per una categoria. I primi cinque elenchi mostrano SelectALL, mentre l’elenco delle applicazioni mostra SelectAll. I commenti dell’esempio indicano che una selezione di tutti gli elementi ignora le altre voci dello stesso elenco. Non normalizzare le grafie né dedurne una precedenza non documentata tra criteri diversi. La tabella dei parametri riporta inoltre Search come stringa di ricerca; non confonderlo con lo SmartFilter di un Application Object.

Il nome della policy è obbligatorio, ammette UTF-8, ma non le virgole, e può contenere al massimo 60 caratteri; Description ammette al massimo 1000 caratteri. MicroAppSupport riporta True e False, ma non dimostra che la decrittografia HTTPS sia attivata. La tabella elenca Action e Schedule come array i cui duplicati non vengono ignorati, mentre l’esempio XML li mostra per ogni regola. Non deduplicare né riordinare quindi gli elenchi di propria iniziativa. Dopo il salvataggio, rileggere l’azione predefinita, l’ordine, la selezione e Schedule; solo l’assegnazione alla regola firewall appropriata e il test dal client confermano il blocco desiderato.

Distinguere il QoS di categoria dagli oggetti SD-WAN

ApplicationFilterCategory identifica la categoria esistente tramite il campo obbligatorio Name; questo nome di categoria non può essere modificato. Il campo obbligatorio QoSPolicy a livello di categoria va distinto da ApplicationSettings/Application/QoSPolicy: quest’ultimo appartiene all’applicazione il cui Name si trova nel rispettivo sotto-oggetto. L’esempio mostra inoltre BandwidthUsageType con Individual/Shared. Ciò rende visibile il contesto della condivisione della larghezza di banda, ma non dimostra una regola di precedenza completa tra l’assegnazione alla categoria e quella all’applicazione. Prima della modifica, verificare le assegnazioni QoS esistenti e l’utilizzo condiviso o individuale desiderato; la procedura operativa è illustrata in Application Traffic Shaping.

ApplicationObject fornisce una selezione di applicazioni per le route SD-WAN basate sulle applicazioni, non una ApplicationFilterPolicy con regole Allow/Deny. I suoi campi obbligatori sono Name e SelectAllRule (Enable o Disable); il nome ammette UTF-8, non le virgole, e può contenere al massimo 80 caratteri. L’esempio XML utilizza gli stessi sei contenitori di selezione indicati sopra e, in aggiunta, SmartFilter come stringa di ricerca. Anche qui mostra SelectALL per i criteri e SelectAll per le applicazioni. La selezione visibile delle applicazioni non costituisce l’identità dell’oggetto denominato: durante un aggiornamento, rileggere l’oggetto previsto; per Delete, questa pagina Add/Edit non dimostra il contratto di identità.

Per Application object add e Application object edit, il riferimento assegna in entrambi i casi gli stessi codici:

Questi simboli non sono messaggi di errore formulati per esteso e i codici non equivalgono automaticamente a codici di stato HTTP. Registrare insieme l’operazione, il codice e la risposta effettiva. Prima di un nuovo tentativo, rileggere il nome dell’oggetto effettivamente salvato e la selezione; un errore poco chiaro non deve portare a un secondo oggetto o a un oggetto con una selezione più ampia. Per Policy-Edit, il riferimento indica inoltre 502 con Message.AFPRecordExists, oltre a 200/Message.AFPUpdateSuccess e 500/Message.AFPUpdateFail. Anche qui il significato del testo del messaggio non risolto resta indefinito; un codice di successo non sostituisce né il controllo dello stato né il test del traffico.

Circoscrivere gli errori in base al sintomo

• La Rule ID prevista non compare: verificare l’ordine delle regole, Source/Destination, Service, la corrispondenza dell’utente e il percorso IPv4/IPv6. Finché il flusso intercetta un’altra regola, la causa non è ancora l’Application Filter.
• Nessuna voce conclusiva nel log del firewall: cercare prima la sessione aperta in Current activities > Live connections e terminarla in modo controllato. Verificare il logging e l’intervallo di filtro nel Log viewer.
• L’applicazione rimane unknown o generica: verificare lo stato dei pattern, Application list, la decrittografia HTTPS, QUIC e le Web Exceptions. Packet Capture serve soltanto a confermare il percorso di rete.
• Il blocco interessa troppi servizi: limitare la regola basata su Risk, Category, Classification o Smart Filter a singole applicazioni o a un gruppo più ristretto. Ripetere quindi la richiesta bloccata e quella di controllo.
• Dopo un aggiornamento dei pattern vengono bloccati più elementi: verificare quale nuova firma soddisfa un criterio dinamico. Creare un’eccezione mirata per un’applicazione necessaria, anziché disattivare l’intero filtro.
• Il Log viewer mostra Allowed per il firewall, ma il browser visualizza una pagina di blocco: in caso di elaborazione tramite proxy, consultare anche il log web.
• Mancano i dettagli dell’app cloud: verificare separatamente il logging del firewall, la decrittografia HTTPS e la Web Policy. Non tutti i metodi di trasferimento forniscono tutti i campi di dettaglio.
• I video di Facebook restano accessibili nonostante il percorso sia configurato completamente: verificare Rule ID, Application Filter, Web Policy, voci di categoria attuali, QUIC, Decryption, CA del client e Web Exceptions. Se il test rimane riproducibile, Sophos indica il supporto come livello successivo a cui inoltrare il problema.

Rollback e gestione operativa

Prima del progetto pilota, occorre documentare Application Filter, Web Policy, stato della regola, posizione della regola, associazione NAT, percorso TLS ed eccezioni. Il ripristino avviene nel seguente ordine:

1. Disattivare una regola pilota separata oppure selezionare nuovamente l’Application Filter precedente o None nella regola esistente.
2. Ripristinare la posizione documentata della regola e soltanto l’associazione NAT che appartiene inequivocabilmente alla configurazione pilota.
3. Verificare con il client di controllo che le nuove connessioni utilizzino la Rule ID precedente e presentino il comportamento atteso.
4. Soltanto a questo punto rimuovere i filtri pilota o gli oggetti non più necessari. Non eliminare senza verifica i filtri condivisi, le regole NAT e le voci di Synchronized Application Control.

Durante la gestione operativa si documentano scopo, regole firewall assegnate, criteri dinamici, eccezioni consentite, responsabile, ultima modifica e data di revisione. Per l’analisi centralizzata sono utili Attivare Central Firewall Reporting e Configurare Syslog e SIEM su Sophos Firewall.

Modificare la classificazione globale soltanto con il supporto Sophos

L’Application Filter di una regola firewall è distinto dalla Application Classification globale della Device Console. Sophos sconsiglia di modificare queste opzioni senza istruzioni del supporto. Inizialmente occorre limitarsi a leggere lo stato:

system application_classification show
system application_classification microapp-discovery show

Per impostazione predefinita, la classificazione globale è on e microapp-discovery è off. Se il supporto Sophos richiede una modifica, occorre documentare lo stato precedente e il ticket. Le opzioni documentate sono:

system application_classification on
system application_classification off
system application_classification microapp-discovery on
system application_classification microapp-discovery off

L’attivazione di microapp-discovery riavvia i servizi e interrompe il traffico. Dopo una modifica autorizzata, si verificano entrambi gli output di show, un flusso applicativo reale e i log. Il rollback ripristina esattamente lo stato precedente: un valore precedente on viene reimpostato con on, un valore precedente off con off, quindi si esegue una nuova verifica con show. Per gli IoC di dominio, la classificazione globale riguarda anche il contesto dei Third-Party Threat Feeds.

Domande frequenti