Troubleshooting CLI di Sophos Firewall: comandi essenziali

Per una prima analisi su Sophos Firewall, Log Viewer è spesso sufficiente. La CLI diventa importante quando un servizio non si avvia correttamente, le connessioni VPN sono instabili, alcuni pacchetti non arrivano oppure il supporto necessita di dati più dettagliati.

Questa panoramica illustra i comandi più utili nell’attività quotidiana: dove eseguirli, cosa mostrano e quando passare a un articolo specializzato. Prima di utilizzare SSH, consultare Come connettersi a Sophos Firewall tramite SSH. Una chiave pubblica, la verifica della chiave host e un’autorizzazione Device Access strettamente limitata sono più importanti di un accesso rapido da qualsiasi rete.

⚠️ Importante: Eseguire i comandi CLI e Advanced Shell solo da reti di amministrazione attendibili e con un obiettivo preciso. Il debug, tcpdump, le operazioni sui file e i comandi di servizio possono influire sullo spazio disco, sulle prestazioni o sulle connessioni attive.

Iniziare da WebAdmin, poi usare la CLI

La CLI non è sempre il punto di partenza più rapido. Per il matching delle regole, il NAT o le singole connessioni, Log Viewer, Policy Test e Packet Capture in WebAdmin forniscono spesso un risultato chiaro più velocemente.

Punti di partenza utili:

• Quale regola firewall esegue il match? Iniziare con Log Viewer, Policy Test e Packet Capture. Usare la CLI solo quando Log Viewer non mostra dettagli sufficienti o servono log in tempo reale.
• I pacchetti raggiungono il firewall? Iniziare con Packet Capture in WebAdmin. La CLI è utile quando il supporto richiede un’acquisizione con filtro preciso o un file PCAP.
• Un servizio presenta un problema? Controllare prima il dashboard, Log Viewer e i log del servizio. Usare la CLI quando occorre verificare direttamente lo stato del servizio, l’output di debug o i file di log.
• È stata effettuata una modifica? Controllare prima gli Audit Trail Logs. La CLI può quindi aiutare a correlare una differenza di configurazione con log o backup.

L’obiettivo non è aprire Advanced Shell il più rapidamente possibile. Seguire invece una procedura tracciabile: controllare prima gli eventi visibili, quindi aprire il file di log pertinente o avviare l’acquisizione appropriata.

Documentare i risultati CLI in modo utilizzabile

L’output della CLI è utile solo se in seguito può essere associato a un test preciso. Un messaggio di errore copiato senza intervallo temporale, indirizzi IP o funzione interessata genera normalmente ulteriori domande e analisi duplicate.

Di solito è sufficiente una breve nota per ogni test:

• Intervallo temporale: Inizio, fine e fuso orario del test.
• Flusso di test: Indirizzo IP sorgente, indirizzo IP di destinazione o FQDN, porta, utente o peer VPN.
• Strumento: Device Console, Advanced Shell, Log Viewer o Packet Capture.
• Comando o filtro: Comando eseguito, termine di ricerca grep o filtro di acquisizione utilizzato.
• Risultato: Corrispondenza, messaggio di errore, voce di log mancante, pacchetto visibile o non visibile.
• Conclusione successiva: Ad esempio, problema di regola, DNS, percorso di ritorno, servizio o caso di supporto.

Prima di condividere l’output con il supporto, Avanet o partner esterni, verificare se contiene dati sensibili: indirizzi IP pubblici, nomi host interni, nomi utente, parametri VPN, numeri di serie, token, indirizzi e-mail o identificativi dei clienti. Un’analisi tecnica non richiede una distribuzione ampia dei dati; condividere soltanto il più piccolo estratto che dimostri il risultato.

Prima del primo comando

Il troubleshooting tramite CLI è molto più affidabile quando il contesto viene definito prima del primo comando. Altrimenti si ottengono rapidamente estratti di log senza riferimenti temporali, acquisizioni troppo ampie o output di debug che nessuno riesce più ad associare con certezza al test.

Prima di eseguire test CLI in produzione, annotare:

• Ora del problema: Consente di cercare nei log all’interno dell’intervallo pertinente.
• Indirizzo IP sorgente, destinazione e porta: grep, tcpdump e Packet Capture rimangono mirati e leggibili.
• Utente o peer interessato: Autenticazione, VPN e User Matching possono essere correlati con maggiore affidabilità.
• Modulo previsto: Iniziare dal file di log pertinente invece di cercare in tutti i log.
• Azione pianificata: Il debug, il controllo di un servizio o un’acquisizione non devono rimanere attivi per errore.
• Condizione di rollback o interruzione: Interrompere il test se il carico, l’uso del disco o gli effetti collaterali diventano inaccettabili.
• Backup aggiornato per le modifiche: I riavvii dei servizi e le modifiche alla configurazione sono più sicuri con un punto di ripristino recente.

Il primo passaggio dovrebbe essere in sola lettura, quando possibile: controllare Log Viewer, aprire il file di log pertinente, leggere service -S o avviare un’acquisizione con filtro preciso. Riavvii, modalità debug e acquisizioni ampie devono essere riservati a una finestra di test pianificata.

In un cluster HA, determinare inoltre quale appliance è attualmente attiva. Log, output di debug e acquisizioni devono essere controllati sul nodo che elabora realmente il traffico interessato.

Eseguire un riavvio completo solo come azione pianificata

Un riavvio completo non è un comando diagnostico. Prima si conservano i log pertinenti, l’ora di sistema, l’uptime, i ruoli HA e lo stato attuale del problema. Se è interessato solo WebAdmin o un singolo servizio, si verifica se sia sufficiente un riavvio mirato di WebAdmin o un riavvio del servizio.

SFOS 22 documenta la seguente sintassi nella Device Console:

system restart [all]

Le parentesi quadre non fanno parte del comando, ma indicano l’argomento facoltativo all. Prima si controlla la forma offerta dal build installato con system restart ?. Il comando riavvia il firewall e interrompe sessioni, tunnel VPN e accesso di gestione. Dopo l’esecuzione non esiste un rollback CLI; la finestra di manutenzione, l’accesso console e un percorso di ritorno alla gestione verificato devono quindi essere pronti prima della conferma.

Secondo Sophos, system restart provoca un failover in un cluster HA. Questo non garantisce connessioni senza interruzioni. Peer, sincronizzazione, ruoli e collegamento HA devono essere prima stabili. Dopo il riavvio si controllano entrambi i nodi, ruoli, sincronizzazione, uptime, WAN, routing, DNS, VPN, servizi pubblicati e un flusso applicativo reale. Un avvio riuscito non dimostra che la causa originale sia stata risolta.

Spegnere solo con un percorso di riaccensione preparato

Per uno spegnimento controllato si usa esattamente questo comando nella Device Console:

system shutdown

Sophos non documenta opzioni per questo comando. Non si devono quindi aggiungere all, un nome di nodo o un ipotetico modificatore HA alla sintassi. Prima della conferma si conservano log e configurazione, si informano i team dipendenti e si chiarisce come riaccendere l’appliance tramite accesso fisico, gestione remota o piattaforma di virtualizzazione. La pagina shutdown non garantisce alcun comportamento HA; un nodo del cluster viene quindi spento solo secondo la procedura di manutenzione HA prevista e il peer viene poi controllato esplicitamente.

Device Console o Advanced Shell?

Sophos Firewall offre due ambienti console distinti. Molti errori si verificano semplicemente perché un comando viene eseguito nell’ambiente sbagliato.

I due ambienti hanno scopi differenti:

• Device Console: CLI Sophos per comandi di rete, sistema e diagnostica. I comandi tipici includono ping, dnslookup, traceroute, tcpdump, drop-packet-capture e show.
• Advanced Shell: shell simile a Linux con accesso completo ai componenti di sistema. Questo articolo la limita ai comandi diagnostici documentati da Sophos: cd /log, tail, grep, less e service -S.

Dopo l’accesso tramite SSH, il firewall mostra innanzitutto il menu della console. Selezionare 4. Device Console per Device Console. Aprire Advanced Shell tramite 5. Device Management > 3. Advanced Shell.

La Device Console raggruppa in advanced-firewall i parametri globali per ispezione dei pacchetti, TCP, UDP, accesso WAN e percorsi speciali. Effetti e procedura di modifica sicura sono descritti in Verificare in sicurezza le Advanced Firewall Settings.

Il test DNS mostra bene perché l’ambiente console è importante. In Device Console, il comando documentato ufficialmente è:

dnslookup host example.com

example.com è un valore di documentazione sicuro; per un test reale, sostituirlo con il FQDN interessato. La risposta conferma solo la risoluzione dal punto di vista del firewall. Per un errore del client, verificare anche server DNS, risposta e percorso di rete del client.

La guida integrata della CLI Sophos supporta Tab e ? per controllare la sintassi. Questa funzione è utile in Device Console, perché la struttura varia a seconda del comando.

Non tentare comandi incompleti in Device Console. Sophos avverte che un comando incompleto può bloccare access_server. Utilizzare Tab o ? per visualizzare la sintassi prima di eseguire consapevolmente il comando completo.

Le modifiche alla configurazione eseguite direttamente in Advanced Shell non sono persistenti e non vengono incluse nei backup. Questa guida usa quindi Advanced Shell esclusivamente per i comandi di diagnostica.

Prima dell’accesso di emergenza: Ottenere un’approvazione esplicita per scopo, persona responsabile, appliance interessata e una breve finestra di emergenza con orario di fine e criterio di interruzione; prevedere l’interruzione dell’inoltro verso Internet. Aprire realmente prima un percorso di recupero indipendente e verificare l’accesso amministrativo, ad esempio tramite una console locale, la console della piattaforma di virtualizzazione o la gestione fuori banda. Questo accesso non deve dipendere dal percorso di rete guasto o dalla modalità di emergenza e deve rimanere disponibile per disattivarla. Non attivare senza approvazione o senza un percorso di recupero indipendente funzionante; concordare prima il recupero con la persona responsabile o Sophos Support.

system appliance_access enable è un comando speciale di emergenza. Sovrascrive le impostazioni Device Access e consente l’accesso a tutti i servizi locali del firewall, inclusi i servizi legacy come Telnet. Importante: mentre questa modalità è attiva, il firewall interrompe l’inoltro del traffico in uscita verso Internet. Non è una normale operazione di troubleshooting e deve essere utilizzata solo brevemente in caso di emergenza. Controllare lo stato prima di attivarla:

Il default documentato è Disable. Con enable, tutte le porte accettano connessioni in entrata e la normale limitazione di raggiungibilità di Device Access viene temporaneamente rimossa. L’autenticazione del singolo servizio rimane un controllo separato, ma non rende innocua questa ampia esposizione.

system appliance_access show

Non appena l’accesso amministrativo completo previsto è stato ripristinato, disattivare subito la modalità di emergenza in 4. Device Console e controllare nuovamente lo stato; non attendere la fine di ulteriori diagnostiche. Disattivarla anche tramite il percorso di recupero indipendente preparato se la procedura viene interrotta o si raggiunge l’orario di fine approvato:

system appliance_access disable
system appliance_access show

Successivamente, show deve confermare Disable. Verificare inoltre un nuovo accesso WebAdmin o SSH dalla rete amministrativa prevista con le normali regole Device Access e assicurarsi che gli accessi precedentemente bloccati rimangano bloccati. Da un client interessato dietro il firewall, provare una connessione reale in uscita verso Internet, ad esempio una richiesta HTTPS a una destinazione approvata, e verificare una risposta riuscita; un ping dal firewall o il solo show non dimostrano che l’inoltro sia stato ripristinato. Se i controlli falliscono o lo stato non è chiaro, non chiudere il caso come risolto: mantenere aperto il percorso di recupero indipendente, conservare la risposta CLI e i risultati del test e coordinarsi con la persona responsabile o Sophos Support anziché riattivare l’accesso di emergenza esteso come soluzione permanente.

Se un comando non viene riconosciuto, controllare prima l’ambiente console. È più probabile che sia stato scelto l’ambiente sbagliato anziché che il comando sia guasto.

Controllare i log in Advanced Shell

I principali file di log si trovano in /log. Sophos documenta innanzitutto il passaggio a questa directory in Advanced Shell:

cd /log

Comandi di base utili:

• Seguire un log in tempo reale: tail -f ips.log. Mantenere aperto l’output continuo solo durante la finestra di test documentata.
• Leggere un file di log: less ips.log. Le righe vengono mostrate per sezioni.
• Cercare un termine: grep error ips.log. Adattare termine e file al problema.

Troubleshooting di Sophos Firewall: servizi e log associa i moduli ai relativi file di log.

Mantenere brevi i test con log in tempo reale e annotare l’ora. Questa precauzione è particolarmente importante quando un archivio verrà in seguito fornito al supporto Sophos o ad Avanet.

Usare Device Console per controlli di rete rapidi

Device Console è adatta ai test rapidi dal punto di vista del firewall. Consente di verificare il funzionamento del DNS, del routing o della connettività di base.

Controlli rapidi:

• Raggiungere un host: ping 192.0.2.10 count 4 verifica la connettività ICMP.
• Controllare il DNS in Device Console: dnslookup host example.com verifica la risoluzione dei nomi dal firewall.
• Controllare il percorso: traceroute 192.0.2.10 mostra il percorso verso la destinazione.
• Controllare lo stato delle interfacce: show interfaces mostra le informazioni sulle interfacce.
• Avviare un’acquisizione dei pacchetti scartati: drop-packet-capture 'host 192.0.2.10' mostra i pacchetti scartati dalle regole firewall.
• Avviare un’acquisizione dei pacchetti: tcpdump 'host 192.0.2.10 and port 443' verifica se i pacchetti sono visibili sul firewall.

I comandi IPv6 equivalenti sono ping6, dnslookup6 e traceroute6.

tcpdump e drop-packet-capture continuano finché non vengono interrotti con Ctrl+C. Definire prima il filtro e la finestra di test, osservare l’output e arrestare subito dopo la cattura. Questi comandi non modificano la configurazione, ma il loro carico dipende dal volume di traffico, dall’ampiezza del filtro e dalla durata.

drop-packet-capture è particolarmente utile quando non è chiaro se il firewall stia scartando attivamente i pacchetti. Non sostituisce l’analisi a livello applicativo. Se un server risponde ma l’applicazione continua a non funzionare, controllare anche Log Viewer, NAT, Packet Capture e i log dell’applicazione.

Per acquisizioni più lunghe e file PCAP, consultare Sophos Firewall: raccogliere log con tcpdump per l’analisi. L’articolo spiega inoltre come limitare la dimensione del file, scegliere una posizione di archiviazione e trasferire l’acquisizione in modo sicuro.

Controlli di rete in WebAdmin senza CLI

Le stesse domande di base possono essere verificate senza accesso alla console in Diagnostics > Tools. Ping permette di selezionare IPv4 o IPv6, l’interfaccia di uscita e la dimensione del pacchetto. Sophos usa 32 byte per impostazione predefinita e consente valori da 1 a 65.507 byte. Un ping riuscito conferma la raggiungibilità ICMP dall’interfaccia firewall selezionata, ma non il funzionamento di un servizio applicativo.

Per Ping in SFOS 22 e SFOS 23, IP address or hostname può contenere un indirizzo IPv4, un indirizzo IPv6 o un FQDN. IP family definisce la famiglia di indirizzi, Interface l’interfaccia di uscita e Size la dimensione del pacchetto. Con un FQDN è necessaria anche la risoluzione dei nomi; per circoscrivere un problema DNS, confrontare lo stesso test anche con l’indirizzo IP previsto.

L’output di Ping mostra se arrivano risposte, quanti pacchetti sono stati inviati e ricevuti, la perdita di pacchetti e la Round-Trip Time (RTT). La RTT è il tempo complessivo di richiesta e risposta, non il tempo di percorrenza in una sola direzione. Se non arriva alcuna risposta, viene mostrata una perdita di pacchetti del 100 percento. Questo da solo non dimostra che l’host sia spento: controllare l’indirizzo di destinazione, l’interfaccia selezionata, il routing e se ICMP è consentito e, se necessario, usare un Packet Capture con filtro preciso. Anche un test riuscito deve comunque corrispondere al flusso applicativo reale.

Traceroute accetta anche IPv4, IPv6 o un FQDN e un’interfaccia di uscita scelta consapevolmente. La mancata risposta di singoli hop non dimostra un’interruzione se rispondono hop successivi o la destinazione. Per una domanda sul percorso si considerano quindi insieme la raggiungibilità della destinazione, l’ultimo hop che risponde e il flusso di pacchetti misurato in parallelo.

In WebAdmin, sotto Diagnostics > Tools > Traceroute, impostare la destinazione in IP address or hostname, la famiglia di indirizzi in IP version e l’interfaccia di uscita in Interface; avviare la query con Traceroute. Per SFOS 22 e SFOS 23, Sophos descrive l’output indicando i router attraversati, il numero massimo di hop e il tempo totale di ritorno del pacchetto in millisecondi. Il numero massimo di hop limita la ricerca del percorso; non dimostra che la destinazione sia stata raggiunta. I valori temporali descrivono le risposte diagnostiche e non dimostrano il throughput applicativo. In 4. Device Console, traceroute6 2001:db8::10 integra l’esempio IPv4 riportato sopra; sostituire l’indirizzo di documentazione con l’indirizzo IPv6 di destinazione effettivo.

Le denominazioni seguenti Name lookup e Lookup using all configured servers si applicano a SFOS 22. Le denominazioni modificate di SFOS 23, DNS lookup e All configured servers, nonché le opzioni aggiuntive per i server e i relativi prerequisiti, sono spiegate in Confrontare i singoli resolver in Diagnostics.

Name lookup interroga un server DNS selezionato. Lookup using all configured servers confronta tutti i server DNS configurati sul firewall e i relativi tempi di risposta. Un singolo risultato rapido non è ancora un motivo per cambiare la priorità DNS; devono essere corretti anche il contenuto della risposta, l’affidabilità e il percorso del client interessato.

Route lookup mostra tramite quale interfaccia il firewall instraderebbe una destinazione IPv4 o IPv6. Non dimostra né la regola firewall, né NAT, né la decisione SD-WAN, né un percorso di ritorno funzionante. La verifica prosegue quindi con una connessione reale, Connection List o Packet Capture.

Controllare le connessioni senza modificarne lo stato

Filtrare le connessioni IPv4 e IPv6 attuali in Current activities > Live connections e Diagnostics > Connection list. Connection list mostra, tra l’altro, interfacce in entrata e in uscita, sorgente e destinazione, Rule ID, NAT ID, indirizzi tradotti, stato e contatori Rx/Tx. È un punto di partenza migliore rispetto a uno strumento Advanced Shell non documentato.

In Device Console è documentata anche questa utility per le connessioni:

system diagnostics utilities connections

Controllare gli argomenti disponibili prima dell’esecuzione con system diagnostics utilities connections ?. Poiché Connection list è un’istantanea, riprodurre il flusso di test aggiornando la vista. Se la connessione resta assente, eseguire un Packet Capture preciso; se compare, proseguire con Rule ID, NAT ID, interfacce, traduzione e contatori di risposta.

Controllare lo spazio disco e lo stato del sistema

Prima di attivare il debug, creare grandi archivi di log o eseguire acquisizioni più lunghe, controllare lo spazio disco disponibile.

Device Console offre i seguenti controlli di sistema ufficiali in sola lettura:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

system diagnostics show version-info mostra anche numero di serie e Device ID. Oscurare questi identificativi prima di condividere output o screenshot.

Ulteriori destinazioni di sola lettura sono interrupts, syslog, sysmsg, subsystem-info e ctr-log-lines. Rispondono a domande diverse e non devono essere considerate valori di stato intercambiabili:

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

Sugli XGS Appliances è disponibile anche system diagnostics selftest per test di base della scheda di rete. Il comando non si applica ad altre piattaforme e non sostituisce un test del cavo, una misurazione del throughput o una cattura dei pacchetti. Poiché Sophos non indica nella pagina del comando l’impatto sul traffico di produzione, il test viene eseguito solo come attività pianificata o su indicazione del supporto e viene confrontato con stato del link, contatori dell’interfaccia e traffico reale.

In system diagnostics utilities, SFOS raggruppa altri strumenti per ARP, larghezza di banda, connessioni, DNS, cattura dei pacchetti scartati, configurazione di rete, ping, processi, route e traceroute, comprese le varianti IPv6 dove offerte da Sophos. La sintassi esatta viene verificata sulla build installata tramite completamento con Tab. Alcuni strumenti leggono soltanto lo stato, mentre altri generano traffico di prova o avviano un output continuo.

Per un ulteriore controllo di sola lettura, Sophos documenta in Advanced Shell:

service -S
service -S | grep ips

La prima variante mostra molti stati dei servizi; la seconda usa l’esempio IPS documentato da Sophos. Nessun risultato non autorizza un riavvio: correlare prima nome del servizio e file di log con l’elenco Sophos aggiornato.

Se lo spazio disco è già insufficiente, non attivare il debug e non avviare un’acquisizione lunga. Stabilire innanzitutto quali log o report possano essere salvati e ripuliti in modo sicuro.

Raccogliere log di debug solo con un ritorno confermato

Per SFOS 22 e SFOS 23, l’attivazione e la disattivazione del debug dei sottosistemi di servizio mostrato qui sono documentate in Device Console, non in WebAdmin. Pktcapd è l’esempio documentato, non un comando universale per tutti i servizi. Prima del test, annotare la build installata, il nodo HA interessato, lo spazio disponibile, l’orario del test e la procedura di disattivazione appropriata; verificare la sintassi e il sottosistema disponibile con ? o Tab. Il debug aumenta le dimensioni dei file di log e rimane attivo fino alla disattivazione. Attivarlo solo per una breve finestra di analisi concordata:

Prima di debug on: Determinare e documentare lo stato di debug esistente per questo specifico sottosistema su questo specifico nodo HA mediante un metodo di sola lettura supportato dalla build installata oppure con Sophos Support. Chiarire inoltre chi è responsabile di un’eventuale diagnostica esistente e se è in corso una raccolta. system diagnostics show subsystem-info è solo un controllo di sistema supplementare; la sintassi documentata non garantisce né un campo uniforme per lo stato di debug né una prova affidabile che il debug sia disattivato.

Fermarsi se il debug è attivo o se lo stato iniziale o la responsabilità non sono chiari: Non eseguire questa procedura On/Off e, in particolare, non usare preventivamente debug off per stabilire uno stato iniziale. Concordare prima con il responsabile della diagnostica oppure con Sophos Support lo scopo, la responsabilità e la procedura di ripristino; proseguire solo con uno stato iniziale inattivo esplicitamente approvato e confermato. Una finestra di test concordata, da sola, non autorizza a terminare un’altra raccolta diagnostica in corso. Solo a quel punto attivare il debug ex novo per questa procedura e documentare la propria responsabilità per l’attivazione e la disattivazione:

system diagnostics subsystems Pktcapd debug on

Riprodurre il problema una volta. Selezionare i singoli log in Diagnostics > Tools > Troubleshooting logs e scaricarli con Download come archivio compresso. Per un Consolidated troubleshooting report (CTR), invece, aprire Diagnostics > Tools > Consolidated troubleshooting report, selezionare le opzioni necessarie System snapshot e All log files, inserire il motivo e selezionare Generate, quindi Download. Il CTR viene scaricato in forma crittografata; System snapshot non richiede la modalità debug. Per alcuni log del CTR, l’impostazione CLI limita il numero di righe incluse, quindi un CTR non contiene automaticamente l’intera cronologia dei log.

Subito dopo il download, disattivare la modalità debug in 4. Device Console esclusivamente per i sottosistemi di servizio il cui debug è stato attivato ex novo da questa procedura a partire dallo stato iniziale inattivo confermato e rimane sotto la sua responsabilità. Lasciare invariato lo stato delle altre attività diagnostiche in corso. Per l’esempio attivato in questo modo, la procedura di ripristino è esattamente:

system diagnostics subsystems Pktcapd debug off

In caso di interruzione della riproduzione, download non riuscito, carico elevato o spazio di archiviazione insufficiente, terminare il test e disattivare esclusivamente il debug attivato ex novo da questa procedura a partire dallo stato iniziale inattivo confermato e ancora sotto la propria responsabilità, anziché attendere un’esportazione riuscita. Non terminare le raccolte diagnostiche in corso gestite da altri; se la responsabilità non è chiara, coordinarsi con il responsabile della diagnostica oppure con Sophos Support, senza disattivare sulla base di supposizioni. La chiusura di una sessione SSH o il download dei log non sostituiscono il proprio comando Off. Log e report non sono sincronizzati tra i nodi HA; eseguire la raccolta e la pulizia sul nodo su cui questa procedura ha attivato il debug ex novo.

Documentare i comandi di attivazione e disattivazione, l’orario, il nodo e la risposta CLI completa. Dopo il comando di disattivazione, verificare se la CLI conferma la disattivazione o segnala un errore; come controllo supplementare, confrontare l’output del controllo di sistema in sola lettura system diagnostics show subsystem-info con lo stato rilevato prima del test. La sintassi documentata non garantisce un campo uniforme per lo stato del debug su ogni build. In assenza di una conferma inequivocabile, non considerare il debug disattivato, ma chiarire l’output con Sophos Support. Se un comando viene rifiutato, verificare la sintassi con ? e non procedere con comandi ipotizzati per sottosistemi, riavvii o servizi. In particolare, non applicare la sintassi dei sottosistemi di servizio a CSC, il cui comando di debug è documentato diversamente. Il debug in Advanced Shell è intenzionalmente omesso, perché la sintassi generica dei servizi non offre un comando di disattivazione uniforme per ogni modalità di debug.

Per i riavvii dei servizi e i relativi effetti, consultare Come riavviare i servizi Sophos Firewall. Il riavvio dei servizi VPN, IPS, web o di autenticazione può interrompere sessioni o accessi attivi.

Fornire i log in modo sicuro

I singoli estratti di log spesso non sono sufficienti per i casi complessi. Un archivio completo è normalmente più utile per il supporto Sophos, Avanet o un’analisi esterna.

Anziché inserire credenziali nei comandi shell, raccogliere i file in WebAdmin: selezionare Diagnostics > Tools > Troubleshooting logs per i singoli file di log, quindi Download. Per creare un CTR, invece, aprire Diagnostics > Tools > Consolidated troubleshooting report, selezionare le opzioni necessarie System snapshot e All log files e inserire un motivo; quindi selezionare Generate e Download. Prima di condividere i dati, verificare che l’archivio o il report crittografato sia stato effettivamente scaricato e fornirlo solo tramite il portale di supporto concordato. Un’esportazione non riuscita non è un motivo per lasciare attivo il debug attivato ex novo da questa procedura a partire da uno stato iniziale inattivo confermato e ancora sotto la propria responsabilità; ciò non deve comportare la terminazione di un’altra raccolta diagnostica in corso. La procedura è descritta in Come raccogliere i log di Sophos Firewall per il supporto e l’analisi.

I file di log possono contenere informazioni sensibili, tra cui indirizzi IP interni e pubblici, nomi host, nomi utente, parametri VPN e messaggi di errore. Prima di condividerli, definire chi riceverà i dati e per quanto tempo verranno conservati.

Errori comuni nel troubleshooting tramite CLI

• Eseguire un comando nell’ambiente console sbagliato: Device Console e Advanced Shell utilizzano sintassi differenti. Controllare prima l’ambiente.
• Lasciare attivo il proprio debug dopo l’analisi: I log crescono inutilmente e possono consumare spazio di archiviazione. Disattivare subito soltanto il debug attivato ex novo da questa procedura a partire da uno stato iniziale inattivo confermato e ancora sotto la propria responsabilità; non terminare le raccolte diagnostiche gestite da altri.
• Eseguire un tcpdump ampio senza filtro: Genera troppo output, aumenta il carico e rende i dati più difficili da interpretare. Limitare l’host, la porta, l’interfaccia o il numero di pacchetti.
• Inserire credenziali FTP nella cronologia della shell: Le credenziali possono comparire nei log, negli screenshot o nella cronologia dei comandi. Utilizzare metodi di trasferimento sicuri e credenziali temporanee.
• Controllare un solo file di log: Molti problemi coinvolgono più moduli. Combinare Log Viewer, i log dei servizi pertinenti e Packet Capture.
• Non annotare l’ora: Il supporto deve quindi analizzare intervalli di log inutilmente ampi. Annotare l’ora, l’azione di test e gli indirizzi IP coinvolti.
• Non eseguire la pulizia dopo il test: Il debug, i file temporanei o gli accessi estesi rimangono attivi. Disattivare soltanto il debug attivato ex novo da questa procedura a partire da uno stato iniziale inattivo confermato e ancora sotto la propria responsabilità, controllare i file e rimuovere le autorizzazioni SSH temporanee; non terminare le raccolte diagnostiche gestite da altri.

Checklist

• L’accesso SSH è limitato alle reti di amministrazione attendibili.
• L’impronta SSH e l’accesso admin sono stati verificati prima dell’analisi.
• È stato selezionato l’ambiente corretto: Device Console o Advanced Shell.
• Sono stati annotati l’ora del problema, l’indirizzo IP sorgente, l’indirizzo IP di destinazione, la porta e l’utente.
• I risultati CLI includono l’intervallo temporale, il comando, il filtro e il risultato.
• Sono stati usati comandi in sola lettura prima di attivare il debug, riavviare servizi o avviare acquisizioni più lunghe.
• Log Viewer è stato controllato per primo.
• È stato identificato il file pertinente in /log.
• tail, grep o less è stato utilizzato con un termine di ricerca preciso.
• Per i problemi di rete sono stati usati in modo mirato dnslookup, ping, traceroute, drop-packet-capture o tcpdump in Device Console.
• Prima del debug dei sottosistemi di servizio in SFOS 22/23, chiariti lo stato esistente e il responsabile della diagnostica per lo specifico sottosistema e nodo HA, e confermato e documentato uno stato iniziale inattivo esplicitamente approvato; in caso di stato attivo o non chiaro, non eseguita la procedura On/Off, ma effettuato il coordinamento con il responsabile oppure con il supporto. Solo a partire da questo stato iniziale, attivato ex novo per breve tempo in 4. Device Console; nell’esempio, con system diagnostics subsystems Pktcapd debug on e poi system diagnostics subsystems Pktcapd debug off, disattivato esclusivamente il debug attivato ex novo da questa procedura e ancora sotto la propria responsabilità. Lasciate invariate le raccolte diagnostiche gestite da altri. Verificati la risposta Off e lo stato di sistema supplementare; chiarito con il supporto uno stato non chiaro, senza contrassegnarlo come disattivato.
• Lo spazio disco è stato controllato prima del debug o della raccolta PCAP.
• L’archivio dei log è stato trasferito in modo sicuro e i file temporanei sono stati rimossi.
• Le eccezioni temporanee Device Access o SSH sono state rimosse dopo il caso di supporto.

FAQ