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.

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 per file, log, processi e controlli dei servizi. I comandi tipici includono cd /log, tail -f, grep, less, df -kh, service -S e conntrack.

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 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.

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:

system appliance_access show

Dopo il test, disattivare l’accesso di emergenza e verificare nuovamente lo stato:

system appliance_access disable
system appliance_access show

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. Accedere a questa directory ed elencarne il contenuto per ottenere una prima panoramica.

cd /log
ls -lah

Comandi di base utili:

• Seguire un log in tempo reale: tail -f /log/strongswan.log. Utile per errori VPN riproducibili.
• Leggere un file di log: less /log/ips.log. In less, cercare con /termine-ricerca.
• Cercare errori: grep -i "error" /log/ips.log. -i ignora maiuscole e minuscole.
• Mostrare le corrispondenze con il numero di riga: grep -n "192.0.2.10" /log/firewall_rule.log. Utile per i file più lunghi.
• Mostrare le ultime righe: tail -n 100 /log/syslog.log. Fornisce una rapida panoramica senza modalità live.

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: 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.

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.

Controllare connessioni e flusso dei pacchetti in Advanced Shell

Se Log Viewer e Device Console non forniscono ancora una risposta chiara, alcuni comandi Advanced Shell possono aiutare ad analizzare il flusso dei pacchetti.

Controllare le connessioni

In Device Console, system diagnostics utilities connections è uno strumento ufficialmente documentato per la diagnostica delle connessioni. Utilizzare prima ? per controllare le opzioni disponibili e il formato dell’output.

conntrack è uno strumento Advanced Shell orientato alle attività di supporto. Mostra le connessioni attive conosciute dal percorso stateful del firewall. La disponibilità può dipendere dalla versione del firmware.

conntrack -L | grep "192.0.2.10"

L’assenza di un risultato è solo un’indicazione: il momento del test, la direzione del filtro o FastPath possono influire sulla visibilità. Confrontare il risultato con Log Viewer e Packet Capture. Se la connessione è presente ma l’applicazione continua a non funzionare, verificare anche l’arrivo dei pacchetti di risposta e il comportamento di NAT, policy e applicazione.

tcpdump in Advanced Shell

Advanced Shell può eseguire tcpdump anche per rapidi controlli in tempo reale.

tcpdump -i any -nn host 192.0.2.10

In produzione, mantenere il filtro il più preciso possibile. Acquisizioni ampie come tcpdump -i any senza host, porta o limite di pacchetti generano rapidamente grandi quantità di output e sono poco pratiche su firewall molto utilizzati.

Un punto di partenza sicuro è un’acquisizione breve limitata per host, porta e numero di pacchetti:

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

Se servono più dati, controllare prima lo spazio disco e scegliere consapevolmente dove archiviare il file PCAP.

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

I seguenti strumenti di Advanced Shell forniscono informazioni aggiuntive; la loro disponibilità può dipendere dalla versione del firmware:

df -kh
df -h /var

Altri controlli rapidi:

uptime
top
service -S
service -S | grep strongswan

service -S mostra lo stato di numerosi servizi. I nomi dei servizi non sono sempre autoesplicativi; confrontare quindi il servizio con il file di log pertinente prima di riavviarlo o attivare il debug.

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.

Attivare il debug in modo controllato

Il debug può essere utile per i problemi complessi, ma deve essere attivato solo brevemente e per il servizio interessato. L’output di debug cresce rapidamente e può occupare una quantità significativa di spazio disco.

Per una procedura on/off esplicita, utilizzare un sottosistema supportato in Device Console. Eseguire prima system diagnostics subsystems ? per visualizzare i nomi disponibili. Sophos documenta il seguente esempio per Pktcapd:

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

Sophos documenta inoltre questo comando di debug IPS per Advanced Shell:

service ips:debug -ds nosync

Per questa variante non è documentato alcun comando Advanced Shell distinto con off aggiunto. Utilizzarlo soltanto se il supporto Sophos ha confermato la procedura esatta di ripristino per la build installata.

L’immagine mostra come, in SFOS 20.0.1, lo stesso comando attivi e disattivi la modalità debug IPS e come service -S | grep ips confermi lo stato prima e dopo il test. Non presumere che questo toggle si comporti allo stesso modo nelle versioni attuali senza una verifica.

Per riavviare e identificare i servizi, consultare anche Come riavviare i servizi Sophos Firewall. Nei casi di supporto, annotare l’intervallo temporale esatto del debug.

Prima di riavviare un servizio, determinare quale funzione interessa e se il traffico di produzione dipende attualmente da essa. Il riavvio dei servizi VPN, IPS, web o di autenticazione può interrompere le sessioni attive o gli accessi degli utenti.

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.

Non inserire credenziali FTP nei comandi shell. Trasferire i log con un metodo sicuro e tracciabile, ad esempio tramite scp verso un server interno o mediante un portale di supporto. Seguire 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 il debug attivo dopo il test: I log crescono inutilmente e possono saturare il disco. Disattivare il debug subito dopo l’analisi.
• 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 ripulire dopo il test: Debug, file temporanei o accessi troppo ampi rimangono attivi. Disattivare il debug, controllare i file temporanei e rimuovere gli accessi SSH provvisori.

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.
• ping, dnslookup, traceroute, drop-packet-capture o tcpdump è stato utilizzato in modo mirato per i problemi di rete.
• Il debug è stato attivato solo brevemente e disattivato con il comando di disattivazione documentato per il sottosistema scelto.
• 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