Synchronized Application Control: verificare il database in sicurezza

Se Synchronized Application Control non rileva più nuove applicazioni, heartbeatd.log segnala errori oppure un firewall dispone di pochissimo spazio dopo un aggiornamento, il database interno delle applicazioni potrebbe essere interessato. Non è però un caso da affrontare con comandi PostgreSQL generici trovati in un forum o in una vecchia nota di supporto.

Sophos Firewall gestisce questi dati internamente e ha modificato il comportamento di conservazione a partire da SFOS 20.0 MR1. Se la pulizia automatica non riesce a causa dello spazio insufficiente, la documentazione Sophos attuale indica espressamente di rivolgersi al supporto. Questo articolo mostra quindi come circoscrivere il problema in sicurezza, raccogliere i dati corretti e accompagnare in modo controllato un intervento del supporto.

Inquadrare correttamente il problema

Synchronized Application Control utilizza le informazioni degli endpoint collegati al firewall tramite Security Heartbeat. In questo modo, il firewall identifica applicazioni che le firme tradizionali non riescono ad associare con certezza e le rende disponibili per la gestione in Applications > Synchronized Application Control.

Questi concetti non devono essere confusi:

• Security Heartbeat trasmette lo stato di integrità e sicurezza tra endpoint, firewall e Sophos Central.
• Synchronized Application Control rileva le applicazioni e le relative occorrenze sugli endpoint collegati.
• Missing heartbeat descrive l’assenza dello stato di un endpoint e può essere gestito tramite comandi supportati della Device Console.
• Un problema di App ID o del database riguarda l’archiviazione interna delle applicazioni rilevate e richiede una diagnosi specifica.

L’assenza dell’indicazione Heartbeat, un endpoint rosso o una regola firewall non corrispondente non indicano quindi automaticamente un errore del database. Per verificare il collegamento tra firewall e Central, consultare innanzitutto Collegare Sophos Firewall a Sophos Central.

Cosa ripulisce automaticamente SFOS

La documentazione Sophos attuale su Synchronized Application Control indica due limiti importanti:

• Synchronized Application Control supporta fino a 15'000 applicazioni.
• A partire da SFOS 20.0 MR1, il firewall conserva solo le ultime cinque occorrenze di ogni applicazione per endpoint.

Durante la migrazione a SFOS 20.0 MR1 o versioni successive, il firewall conserva le cinque occorrenze più recenti e rimuove automaticamente i dati applicativi meno recenti. Sophos avverte tuttavia che questa pulizia può non riuscire se lo spazio libero è insufficiente. In questo caso occorre coinvolgere Sophos Support.

Per l’operatività quotidiana, ciò significa che un firewall aggiornato normalmente non richiede una manutenzione manuale di questi dati. Una crescita ricorrente, una migrazione non riuscita o l’esaurimento dell’intervallo App ID sono anomalie, non attività di manutenzione ordinaria.

Distinguere i sintomi tipici

Problema di spazio dopo un aggiornamento

Possibili indizi sono una partizione quasi piena, problemi con report o servizi e una correlazione temporale con un aggiornamento a SFOS 20.0 MR1 o versione successiva. Questi elementi, da soli, non dimostrano ancora che la causa sia Synchronized Application Control.

Occorre prima controllare report, log di debug, archivi di supporto, coda e-mail, quarantena e dimensione del disco virtuale. La procedura è descritta in Verificare lo spazio su Sophos Firewall e gestire i report.

Intervallo App ID esaurito

Un altro sintomo è un messaggio come il seguente:

Cannot create ID for application, because appId range is exhausted.
Application will be ignored.

In questo caso, il firewall può continuare a mostrare le applicazioni esistenti, ma non riesce più a rilevarne correttamente di nuove. Il messaggio riguarda Synchronized Application Control, non un database generico di report o log.

Security Heartbeat non funziona

Se gli endpoint non segnalano lo stato Heartbeat oppure le regole con condizioni Heartbeat non si comportano come previsto, occorre verificare prima la registrazione in Central, la comunicazione degli endpoint, le zone interessate e la regola firewall. La pulizia diretta del database non è l’approccio corretto per questo problema.

Diagnosi prima di aprire il caso di supporto

1. Documentare firmware e contesto

Le note del caso devono includere:

• modello del firewall, numero di serie e versione SFOS completa, inclusa la build
• Standalone, HA Primary o HA Auxiliary
• data dell’ultimo aggiornamento e versione SFOS precedente
• momento a partire dal quale il problema è visibile
• servizi interessati e impatto concreto

In ambiente HA deve essere chiaro su quale Node si manifesta il sintomo. I log locali e l’occupazione dello spazio possono differire tra Primary e Auxiliary.

2. Controllare la vista delle applicazioni

In Applications > Synchronized Application Control, verificare:

• Le nuove applicazioni vengono ancora rilevate?
• L’elenco è vicino al limite di 15'000 applicazioni?
• Il problema riguarda solo le nuove applicazioni o anche le voci esistenti?
• È possibile cercare, aprire e gestire le applicazioni?
• Le applicazioni eliminate vengono ricreate come previsto dopo un nuovo rilevamento?

L’eliminazione di singole applicazioni dall’interfaccia è una funzione supportata, ma le rimuove anche dagli Application Filters. Se il firewall rileva nuovamente l’applicazione, questa ricompare. Questa funzione dell’interfaccia non costituisce quindi una riparazione del database.

3. Verificare separatamente lo spazio disponibile

L’occupazione dello spazio deve essere documentata prima di qualsiasi altra misura. È importante registrare la partizione interessata e l’andamento nel tempo, non soltanto un singolo valore percentuale.

Se contemporaneamente vengono eliminati report, log o archivi di supporto, in seguito non sarà più possibile stabilire quale intervento abbia realmente risolto il problema. Occorre quindi prima raccogliere le prove e poi apportare una sola modifica alla volta.

4. Salvare log e Troubleshooting Report

Per Synchronized Application Control e Security Heartbeat è particolarmente rilevante heartbeatd.log. Occorre inoltre registrare l’ora esatta dell’errore e salvare un Troubleshooting Report.

I file appropriati e le modalità di raccolta sono descritti in Risoluzione dei problemi di Sophos Firewall: servizi e log e Salvare i log di Sophos Firewall per un’analisi esterna.

Non utilizzare comandi di database pubblici

Su Internet circolano diversi comandi psql, DELETE, VACUUM FULL e di riavvio dei servizi destinati a vecchie versioni SFOS e a differenti problemi di Heartbeat. Queste procedure non sono intercambiabili:

• Un VACUUM FULL libera spazio in una tabella, ma non elimina automaticamente la causa della sua crescita.
• Un DELETE può modificare le associazioni di applicazioni, endpoint o utenti autenticati attivamente.
• Le tabelle e le procedure di supporto possono variare tra le versioni SFOS.
• In HA, la procedura dipende inoltre dal Node, dallo stato di sincronizzazione e dalle istruzioni del supporto.

⚠️ Senza istruzioni attuali e specifiche per il caso fornite da Sophos Support, non devono essere apportate modifiche dirette al database PostgreSQL interno. Un backup della configurazione è importante, ma non consente un rollback completo del database interno.

Anche i comandi provenienti da un ticket precedente non devono essere applicati senza verifica a un firewall, firmware o ruolo HA diverso. Le istruzioni esatte devono essere riportate nel caso di supporto attuale e indicare il Node interessato e l’effetto previsto.

Preparare completamente il caso di supporto

Un caso ben preparato accelera l’analisi ed evita ulteriori richieste. È opportuno allegare:

• versione SFOS completa e modello del firewall
• numero di serie e ruolo HA del Node interessato
• ora e testo esatto del messaggio di errore
• screenshot di Applications > Synchronized Application Control
• occupazione dello spazio prima di qualsiasi intervento di pulizia
• heartbeatd.log e Troubleshooting Report relativi al periodo appropriato
• data e percorso dell’ultimo aggiornamento firmware
• descrizione che specifichi se mancano nuove applicazioni, se lo spazio è insufficiente o se si verificano entrambe le condizioni

Prima di un intervento del supporto deve essere disponibile un backup aggiornato della configurazione del firewall. La procedura per aprire il caso è descritta in Aprire un ticket di supporto Sophos.

Se il supporto ordina un intervento sul database, nel Change devono essere documentati il numero del ticket, i comandi approvati, il Node di destinazione, la finestra di manutenzione, l’output previsto e i criteri di interruzione. Eventuali messaggi di errore diversi devono essere documentati e comunicati, anziché proseguire sperimentando comandi simili.

Verifiche dopo l’intervento del supporto

Dopo l’intervento approvato, non è sufficiente controllare lo spazio libero o la corretta esecuzione di un comando. Occorre verificare l’intero flusso funzionale:

1. Aprire Applications > Synchronized Application Control e controllare le voci esistenti.
2. Avviare su un endpoint di test una nuova applicazione mai rilevata in precedenza.
3. Verificare che la nuova applicazione compaia e possa essere gestita.
4. Controllare lo stato Security Heartbeat dell’endpoint di test.
5. Testare le regole firewall con condizioni Heartbeat o Application Control.
6. Controllare heartbeatd.log per individuare nuovi errori durante il periodo di test.
7. Monitorare l’occupazione dello spazio per diverse ore o giorni.

Se l’errore o la crescita si ripresentano rapidamente, la pulizia ha fornito solo un sollievo temporaneo. Sophos Support avrà quindi bisogno del nuovo andamento temporale, dei log aggiornati e dell’informazione relativa all’azione dopo la quale il problema si è ripresentato.

FAQ