Controllare Sophos Firewall ogni giorno: checklist operativa
Una Sophos Firewall può rimanere tecnicamente raggiungibile e mostrare comunque i primi segnali di allarme: una connessione WAN oscilla, l’occupazione del disco aumenta, un servizio segnala un errore o si accumulano accessi amministrativi non riusciti. Un controllo operativo breve e ripetibile rende visibili questi cambiamenti prima che causino un’interruzione prolungata o un incidente di sicurezza.
Questo processo riguarda il funzionamento attuale. Il Sophos Firewall Health Check, invece, verifica se determinate configurazioni rispettano le raccomandazioni Sophos e CIS. I due controlli si completano, ma non si sostituiscono.
Il controllo in dieci minuti
Per la panoramica quotidiana è sufficiente una procedura fissa:
- Nel Control Center, annotare modello, versione firmware e build, aprire i nuovi messaggi e fare clic sulle icone di stato di servizi, WAN, interfacce e VPN.
- In Diagnostics > System graphs, confrontare CPU, memoria, load average, disco e interfacce importanti con la baseline abituale.
- Controllare i dashboard di sicurezza e i report utilizzati per l’ultimo periodo completamente disponibile alla ricerca di nuovi eventi IPS, web, applicazioni, zero-day o Active Threat Response.
- Aprire il Log Viewer in alto a destra, selezionare modulo e intervallo temporale e controllare gli accessi amministrativi non riusciti, le origini insolite e i servizi associati.
- In HA, considerare il nodo che ha elaborato il traffico e, per il reporting centrale, l’origine dati prevista.
- Documentare ogni deviazione rilevante con ora, firmware, nodo, origine, servizio interessato e passo successivo.
- Non riavviare servizi, eliminare log o ampliare regole a causa di un singolo picco. Correlare prima la tendenza, i log e il funzionamento reale.
Questo breve controllo non deve generare una modifica alla configurazione ogni mattina. Il suo valore consiste nel riconoscere presto i cambiamenti e decidere chiaramente se servano osservazione, diagnosi o escalation.
Quattro viste, quattro indicazioni diverse
Le viste principali non mostrano la stessa cosa:
- Control Center: panoramica attuale di sistema, servizi, WAN, interfacce, VPN, uptime e messaggi che richiedono un intervento.
- System graphs: andamento temporale di CPU, memoria, load average, disco, trasferimento WAN e contatori delle interfacce.
- Reports: valutazione consolidata di un periodo concluso. Alcuni widget e dati dei report non vengono aggiornati in tempo reale.
- Log Viewer: singoli eventi con ora, modulo, azione, informazioni su origine e destinazione e, in base al tipo di log, Rule ID o altri dettagli.
Un widget rosso è un segnale, non ancora una diagnosi completa. Allo stesso modo, uno stato verde attuale non dimostra che durante la notte non si sia verificato un breve errore. Solo la combinazione di stato attuale, andamento, report e singolo evento offre un quadro affidabile.
Controllare stato e disponibilità del sistema
Leggere prima il Control Center
Nel Control Center, il controllo inizia dai nuovi messaggi. Sophos mostra, tra gli altri, problemi di registrazione, licenza, reporting, WAN o aggiornamento. Alcuni messaggi scompaiono automaticamente dopo la correzione e non possono essere semplicemente eliminati manualmente. Ogni messaggio rilevante necessita quindi di un responsabile e di un passo successivo tracciabile.
Il colore va sempre interpretato insieme ai dettagli. Per Services, Warning indica che almeno un servizio si è arrestato, mentre Alert indica che almeno un servizio non è riuscito ad avviarsi. Per WAN e VPN, Warning indica che non è disponibile fino alla metà delle connessioni configurate, Alert che non ne è disponibile più della metà. Questi conteggi non considerano l’importanza aziendale. Un solo tunnel principale inattivo può quindi essere più urgente di più connessioni intenzionalmente inattive. Fare clic sull’icona corrispondente per visualizzare gli elementi interessati.
Successivamente si confrontano i servizi, le connessioni WAN, le interfacce e le VPN effettivamente utilizzati con lo stato previsto. Un’interfaccia rossa non indica automaticamente un guasto: una porta inutilizzata senza indirizzo IP o un’interfaccia fisica parent di una VLAN può apparire rossa come previsto. Conta la deviazione dal design documentato.
Il widget Messages va trattato come un elenco di azioni, non come un feed generale degli eventi. Se richiede di creare la Secure Storage Master Key, crearla per fornire una protezione aggiuntiva ai dati sensibili, come le password. Un messaggio di accesso WAN indica che WebAdmin (HTTPS) e CLI (SSH) sono raggiungibili dalla zona WAN: se è necessaria l’amministrazione remota, usare una VPN o una Local Service ACL Exception limitata a host o reti di gestione specifici, anziché lasciare un accesso WAN esteso. Per un messaggio relativo al disco dei report, ridurre l’utilizzo al di sotto della soglia inferiore; scendere soltanto sotto quella superiore non è sufficiente. I messaggi legati a un requisito scompaiono quando questo viene soddisfatto e non possono essere eliminati manualmente.
Active threat response si legge per feed e azione. MDR e Sophos X-Ops mostrano il numero di minacce bloccate, NDR Essentials le minacce monitorate e i feed di terze parti sia lo stato di sincronizzazione sia le minacce bloccate. Configure apre la configurazione della protezione, Reports il report associato e More details espande il widget. L’azione Reports non compare sui modelli senza reporting locale. Una minaccia monitorata non equivale a una minaccia bloccata e un problema di sincronizzazione di terze parti va distinto dal numero di minacce.
Il widget Reports è un collegamento a un massimo di cinque report critici selezionati in base ai moduli sottoscritti, non un elenco completo di eventi live. La mappatura è:
- High-risk applications — Web Protection
- Objectionable websites — Web Protection
- Web users — Web Protection
- Intrusion attacks — Network Protection
- Web server protection — Web Server Protection
- Email usage — Email Protection
- Email protection — Email Protection
- Traffic dashboard — Web Protection o Network Protection
- Security dashboard — Web Protection o Network Protection
High-risk applications, Objectionable websites, Intrusion attacks, Web server protection ed Email protection si riferiscono a ieri; Web users classifica i dieci utenti con il maggior numero di byte web trasferiti ieri. Email usage mostra i byte e-mail trasferiti, mentre Traffic dashboard e Security dashboard riepilogano le categorie di traffico e le attività negate. L’assenza di un riquadro può quindi dipendere dalla sottoscrizione e non da un’attività pari a zero. Fare clic sul nome per aprire il report o sull’icona di download per conservarlo. Per i diversi intervalli temporali e drill-down dei segnali endpoint, utente, Zero-day, TLS e sessione, consultare Interpretare User & Device Insights.
Traffic insight riepiloga il traffico elaborato nelle ultime 24 ore. Web activity mostra l’andamento e i byte medi e massimi trasferiti; Cloud applications presenta le applicazioni rilevate e i byte in ingresso e in uscita, con i dettagli New, Sanctioned, Unsanctioned e Tolerated al passaggio del mouse. Gli altri grafici classificano le prime cinque categorie applicative e web consentite per byte, le categorie applicative bloccate per hit e gli host a cui è stato negato l’accesso alla rete per il loro stato di sicurezza. Fare clic su un grafico cloud o sulla barra di una categoria apre la pagina Cloud applications o il report filtrato corrispondente; eseguire questo drill-down prima di considerare un picco o una voce tra le prime cinque come incidente.
Un controllo quotidiano comprende almeno:
- servizi arrestati o degradati in modo inatteso;
- collegamenti WAN down o che cambiano ripetutamente stato;
- interfacce di produzione con nuovi errori, drop o collisioni;
- connessioni VPN importanti disconnesse in contrasto con il piano operativo;
- un riavvio inatteso o un uptime insolitamente breve;
- nuovi messaggi senza responsabile o ticket.
Leggere i System graphs rispetto a una baseline
In Diagnostics > System graphs si cercano pattern, non solo singoli picchi. CPU, memoria e load average vengono valutati insieme al numero di core, al traffico e al periodo interessato. Un breve picco durante backup, reporting o aggiornamento dei pattern ha un significato diverso da un carico costantemente elevato con traffico normale.
Per Disk Usage conta soprattutto la tendenza. Un’occupazione elevata occasionale e una crescita continua rappresentano problemi diversi. Per le interfacce, traffico, errori, drop e collisioni aiutano a distinguere il carico della firewall da un problema di collegamento, duplex, cavo o switch.
Per ottenere prove confrontabili, registrare il tipo di grafico e l’intervallo temporale e usare lo stesso intervallo nel ticket. I grafici delle interfacce mostrano un grafico separato solo per le VLAN nella zona WAN. SFOS aggrega i dati delle VLAN nelle altre zone nel grafico della relativa interfaccia fisica padre. Non ci si può quindi aspettare un grafico LAN VLAN separato e senza anomalie quando SFOS non lo fornisce.
L’analisi dettagliata di load average, offloading, TLS Inspection e System graphs è disponibile in Interpretare correttamente le prestazioni di Sophos Firewall. Per i limiti di storage e il reporting on-box, consultare Controllare storage e report di Sophos Firewall.
⚠️ Un singolo valore elevato non giustifica ancora il riavvio di un servizio. Ora, durata, ricorrenza, traffico interessato e log devono prima essere correlati. Prima di un riavvio si salvano i log rilevanti e, durante un incidente, un CTR.
Controllare eventi di sicurezza e accessi amministrativi
Leggere i report alla ricerca di cambiamenti
La revisione quotidiana della sicurezza si concentra su pattern nuovi o chiaramente cambiati. In base alle funzioni attive, sono particolarmente rilevanti queste aree:
- Reports > Dashboards > Security dashboard per la panoramica consolidata;
- Reports > Network & threats > Intrusion attacks per gli eventi IPS;
- Reports > Network & threats > Active threat response per gli IoC bloccati;
- Reports > Applications & web per l’uso web e applicativo rischioso, indesiderato o bloccato;
- report zero-day, Security Heartbeat o Wireless se queste funzioni vengono utilizzate in produzione.
Nel report selezionato, impostare prima l’intervallo di date e quindi fare clic su Generate. Con Filter si possono limitare i risultati all’origine, all’azione o alla regola rilevante. I formati di download disponibili conservano i dati visualizzati come prova per il ticket. Registrare intervallo temporale e fuso orario insieme all’esportazione, affinché un confronto successivo non usi due finestre diverse.
Non ogni evento è un incidente. Sono determinanti origine, destinazione, utente, regola, azione, frequenza e relazione temporale. Un singolo accesso da un Paese non giustifica il blocco generalizzato dell’intero Paese. Gli attacchi ripetuti contro un servizio esposto o un nuovo traffico ad alto rischio consentito richiedono invece un’indagine specifica.
Per valutare in sicurezza origini e Paesi, consultare Bloccare indirizzi IP e Paesi dannosi. Se un pacchetto è stato scartato, Analizzare i pacchetti scartati su Sophos Firewall conduce dal Log Viewer e dalla Rule ID alla causa effettiva del drop.
Valutare gli accessi amministrativi non riusciti
Gli accessi amministrativi non riusciti vengono controllati per ora, IP di origine, servizio di destinazione, nome utente e ripetizione. Un errore di digitazione dalla rete di gestione richiede un trattamento diverso da tentativi distribuiti da Internet o accessi ripetuti a un account disattivato.
Il Log Viewer si apre dall’angolo superiore destro di qualsiasi pagina WebAdmin, in una nuova finestra a schermo intero. Selezionare il modulo corretto, impostare il periodo con Timer filter e specificare campo, condizione e valore con Add filter. La ricerca a testo libero è utile per indirizzi IP, nomi utente, porte o regole. Prima di apportare altre modifiche, conservare le voci filtrate in formato CSV con Export; Reset rimuove poi tutti i filtri. L’assenza di una voce di sessione non dimostra sempre che non ci sia stato traffico, perché normalmente le regole firewall registrano le sessioni solo quando il firewall riceve l’evento di chiusura della connessione.
Per i tentativi sospetti si controllano prima esposizione e identità:
- WebAdmin, SSH, User Portal o VPN Portal devono essere raggiungibili dalla zona interessata?
- L’origine proviene da una rete di gestione autorizzata o da una Local Service ACL Exception mirata?
- MFA è attivo per l’accesso amministrativo interessato?
- CAPTCHA, il timeout della sessione e Block login funzionano come previsto?
- Esistono modifiche di configurazione contemporanee o accessi riusciti dello stesso account?
L’accesso di rete si controlla in Device Access e Local Service ACL su Sophos Firewall. Per account, profili e offboarding, consultare Amministratori locali e profili di accesso al dispositivo, e per il secondo fattore Attivare MFA su Sophos Firewall.
⚠️ Block login può bloccare l’IP di origine per più servizi dopo tentativi non riusciti. Non rendere aggressivamente più severi i valori durante un incidente finché non esiste un percorso alternativo e verificato di amministrazione e ripristino.
Comprendere i limiti di HA, reporting e modelli
In un cluster HA ogni nodo memorizza solo i log e i report del traffico che ha elaborato. Per un evento si identifica quindi il nodo attivo o che stava elaborando il traffico in quel momento. Un report locale vuoto su un nodo non dimostra che nel cluster non si sia verificato alcun evento.
Sophos Central Firewall Reporting può fornire una vista consolidata e una conservazione più lunga. Le viste locale e centrale non vengono tuttavia considerate fonti identiche in tempo reale. Attivare e utilizzare Central Firewall Reporting spiega selezione, arrivo e conservazione dei log.
Ulteriori limiti:
- I report del Control Center vengono aggiornati periodicamente e non sono una vista degli eventi in tempo reale.
- Dopo l’aggiornamento da SFOS 20.0 o versioni precedenti a SFOS 21.0 o successive, il widget Reports può mostrare zero o un valore inferiore fino al successivo aggiornamento di 24 ore, perché Sophos archivia i report precedenti e successivi all’aggiornamento in database separati.
- XGS 87/87w e XGS 88/88w non supportano i report on-appliance. Su questi modelli diventano quindi più importanti log centralizzati, SIEM e monitoraggio.
- I dati mancanti possono dipendere da logging, periodo del report, licenza, conservazione, disk watermark o nodo HA errato. Non dimostrano automaticamente l’assenza di traffico.
Confrontare la build del firmware con i problemi noti
Quando quanto osservato non corrisponde allo stato atteso, seguire il runbook Avanet per le decisioni sul firmware. Confrontare la build installata esatta e il sintomo specifico, non solo la versione principale. Registrare nel ticket l’ID del problema, le build interessate e corrette e qualsiasi workaround, quindi correlare il risultato con i dettagli del Control Center, i System graphs, i log e un test funzionale prima di modificare il sistema. Esempi per il controllo giornaliero:
- NC-181971: su SFOS 22.0 GA e versioni successive, in rare circostanze il servizio IPS può passare allo stato Dead e non riavviarsi. Sophos non pubblica una soluzione self-service e invita a contattare il Supporto per applicare il workaround.
- NC-181748: su SFOS 22.0 GA Build 411, non vengono generate e-mail Web Instant Alert per le categorie bloccate dalle policy web. Su questa build, l’assenza di un avviso non dimostra quindi l’assenza di un blocco.
- NC-180066, NC-180110, NC-178745 e NC-172912: le note di rilascio elencano in SFOS 22.0 MR2 Build 546 correzioni per servizi antivirus arrestati, modalità failsafe causata dal daemon di logging, riavvii HA dovuti a memoria insufficiente e System graphs intermittenti. Se il sintomo coincide su una build precedente, registrare nel ticket l’ID e il percorso di aggiornamento. Aggiornare il firmware solo in una finestra di manutenzione approvata, con backup e percorso di rollback.
I problemi noti possono cambiare indipendentemente da questo articolo. Prima dell’escalation, riaprire la voce e conservarne lo stato attuale. Un ID corrispondente può spiegare un sintomo, ma non sostituisce la valutazione dell’impatto né la verifica funzionale.
Documentare ed eseguire l’escalation delle deviazioni
Un controllo quotidiano è completo solo quando le deviazioni rilevanti hanno un passo successivo. Per un ticket o un registro operativo sono generalmente sufficienti questi campi:
- data, ora e fuso orario;
- nome della firewall, modello, versione SFOS e build;
- in HA: nodo, ruolo e ultimo cambio di stato;
- funzione, zona, interfaccia, VPN o regola interessata;
- stato osservato e stato previsto;
- screenshot, periodo del report, filtro dei log o Rule ID;
- impatto su utenti o servizi;
- responsabile, priorità, controllo successivo e percorso di escalation.
Prima di qualsiasi azione che modifichi lo stato, conservare lo stato dettagliato del Control Center, il grafico con l’intervallo visibile e le righe di log filtrate o l’esportazione CSV. Per un caso di supporto, accedere a Diagnostics > Tools > Consolidated troubleshooting report e creare un CTR con System snapshot e i file di log necessari: inserire il motivo, selezionare Generate e scaricare il file crittografato al termine. La modalità debug e la rimozione dei log non fanno parte del controllo giornaliero: modificano lo stato diagnostico o distruggono le prove e vanno usate in modo mirato solo su indicazione del Supporto.
Un’escalation immediata è appropriata se un collegamento WAN di produzione o un percorso VPN critico si interrompe inaspettatamente, un servizio di protezione è fermo, l’occupazione del disco continua a crescere, il carico rimane elevato, ripetuti attacchi amministrativi coincidono con un accesso riuscito o un nuovo evento di sicurezza corrisponde a traffico dannoso consentito.
L’osservazione è più adatta a un picco breve e spiegabile, a un’interfaccia intenzionalmente inutilizzata o a un evento già noto con responsabile documentato e verifica funzionale stabile.
Scegliere una frequenza di controllo utile
Sophos non prescrive una frequenza quotidiana universale per ogni vista. La frequenza segue quindi il rischio, gli orari operativi e il monitoraggio esistente:
- Ogni giorno o per turno: nuovi messaggi, servizi arrestati, WAN/VPN/HA, uptime, eventi di sicurezza critici e accessi amministrativi non riusciti.
- Ogni settimana: tendenze dei grafici, errori delle interfacce, crescita del disco, pattern dei report, origini ricorrenti e ticket aperti.
- Dopo modifiche, aggiornamenti o failover: verificare nuovamente la funzione interessata, i log, i report, il percorso degli avvisi e il traffico reale.
- Regolarmente al di fuori del controllo breve: Health Check, revisione delle regole, test di ripristino del backup, scadenza di licenze e certificati e pianificazione della capacità.
Le notifiche e-mail o il monitoraggio riducono il tempo di risposta, ma non sostituiscono la revisione. Un percorso di allerta è affidabile solo dopo aver testato trasporto, selezione degli eventi, destinatario e reazione. Il processo completo è disponibile in Configurare e testare le notifiche e-mail di Sophos Firewall.
Checklist operativa
- Controllare il Control Center per nuovi messaggi e cambiamenti di stato inattesi.
- Confrontare servizi, collegamenti WAN di produzione, interfacce, VPN e uptime con lo stato previsto.
- Leggere CPU, memoria, load average, disco e contatori importanti delle interfacce rispetto alla baseline.
- Controllare i report di sicurezza per l’ultimo periodo completamente disponibile.
- Impostare il periodo del report, selezionare Generate ed esportare i risultati rilevanti quando necessario.
- Nel Log Viewer, selezionare modulo, Timer filter e Add filter; correlare origine, destinazione, utente, azione e Rule ID e conservare le righe pertinenti in CSV.
- Valutare gli accessi amministrativi non riusciti per origine, servizio e ripetizione.
- In HA, considerare il nodo che ha elaborato il traffico e i log locali del nodo.
- Confrontare la build e il sintomo corrispondente con le note di rilascio e i problemi noti aggiornati; registrare l’ID nel ticket.
- Non avviare riavvii, eliminazioni di log o ampie modifiche alle regole senza conservare le prove e disporre di un percorso di ripristino.
- Documentare ogni deviazione rilevante con responsabile, priorità e passo successivo.
- Dopo una correzione, verificare di nuovo non solo lo stato, ma anche il funzionamento reale.