Sophos Firewall Risoluzione dei problemi CLI: comandi importanti

Durante la risoluzione dei problemi di Sophos Firewall, Log Viewer è spesso sufficiente per l’isolamento iniziale. Non appena un servizio non si avvia correttamente, le connessioni VPN sono instabili, i singoli pacchetti non arrivano o il supporto necessita di dati dettagliati, la CLI diventa importante.

Questa panoramica mostra i comandi più importanti per la vita di tutti i giorni: dove eseguirli, cosa mostrano e quando è meglio passare ad un articolo specializzato. Per un accesso sicuro tramite SSH, è necessario innanzitutto selezionare Connetti Sophos Firewall tramite SSH. Le chiavi pubbliche, i controlli delle chiavi host e la rigorosa approvazione dell’accesso ai dispositivi sono più importanti di un accesso rapido da qualsiasi luogo.

⚠️ Importante: i comandi CLI e Advanced Shell devono essere eseguiti solo da reti amministrative attendibili e con un obiettivo chiaro. In particolare, debug, tcpdump, operazioni sui file e comandi di servizio possono influire sullo spazio di archiviazione, sulle prestazioni o sulle connessioni in esecuzione.

Prima WebAdmin, poi CLI

La CLI non è sempre il modo più rapido per iniziare. Quando si tratta di corrispondenza delle regole, NAT o connessioni individuali, Log Viewer, Policy Test e Packet Capture nel WebAdmin spesso forniscono un risultato pulito più rapidamente.

Buone presentazioni:

• Quale regola firewall si applica? Primo utilizzo Log Viewer, Policy Test e Packet Capture. La CLI diventa necessaria solo quando Log Viewer mostra troppo pochi dettagli o sono richiesti registri in tempo reale.
• I pacchetti arrivano sul firewall? Primo utilizzo Packet Capture in WebAdmin. La CLI è utile quando è necessario un file Tight Capture o PCAP per il supporto.
• Un servizio ha un problema? Controlla innanzitutto il dashboard, Log Viewer e i registri del servizio. La CLI diventa importante quando è necessario controllare direttamente lo stato del servizio, i file di debug o di registro.
• È cambiato qualcosa? Prima controlla Audit Trail Logs. La CLI aiuta quindi a confrontare una differenza di configurazione con log o backup.

L’obiettivo non è saltare nel Advanced Shell il più rapidamente possibile. È meglio avere un processo comprensibile: prima controllare gli eventi visibili, quindi aprire o acquisire il file di registro appropriato.

Documenta i risultati della CLI in modo utilizzabile

L’output della CLI è utile solo se in seguito è chiaro a quale test appartiene. Singoli messaggi di errore copiati senza finestra temporale, indirizzi IP o funzione interessata spesso portano a domande e doppie analisi.

Di solito è sufficiente una breve nota per ogni test:

• Finestra temporale: Inizio, fine e fuso orario del test.
• Flusso di test: Origine IP, destinazione IP 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: Hit, messaggio di errore, voce di registro mancante, pacchetto visibile o pacchetto non visibile.
• Conclusione successiva: ad esempio problema con la regola, problema DNS, percorso di ritorno, errore di servizio o caso di supporto.

Prima di condividere con il supporto, Avanet o partner esterni, controlla se gli output contengono dati sensibili: IP pubblici, nomi host interni, nomi utente, parametri VPN, numeri di serie, token, indirizzi e-mail o identificatori dei clienti. Per un’analisi tecnica, i dati non devono essere distribuiti in modo arbitrario e ampio; Ciò che è importante è la sezione più piccola che dimostra la scoperta.

Prima del primo comando

La risoluzione dei problemi della CLI diventa molto più affidabile se il frame viene corretto prima del primo comando. In caso contrario si creano rapidamente estratti di log senza alcun riferimento temporale, acquisizioni troppo ampie o log di debug che nessuno può successivamente assegnare in modo chiaro. Prima di eseguire test CLI produttivi, dovresti notare:

• Momento del problema: è possibile cercare i registri specificatamente per la finestra di test.
• Origine IP, Destinazione IP e Porta: grep, tcpdump e Packet Capture rimangono ristretti e leggibili.
• Utente o peer interessato: Autenticazione, VPN e corrispondenza utente sono meglio attribuibili.
• Modulo previsto: Cerca prima nel file di registro appropriato anziché in tutti i registri.
• Azione pianificata: Il debug, il controllo del servizio o l’acquisizione non diventeranno accidentalmente permanenti.
• Criteri di rollback o di terminazione: Il test viene terminato in caso di caricamento, memoria piena o effetti collaterali.
• Backup corrente per operazioni di modifica: è possibile eseguire il backup dei riavvii del servizio o delle modifiche alla configurazione in modo più pulito. Il primo passo dovrebbe essere la lettura, se possibile: controllare Log Viewer, visualizzare il file di registro appropriato, leggere service -S o avviare un’acquisizione ravvicinata. I riavvii, la modalità debug e le registrazioni ad ampio raggio rientrano solo in una finestra di test consapevole in seguito.

Per i cluster HA dovrebbe essere chiaro anche quale dispositivo è attualmente attivo. Log, debug e acquisizioni devono essere controllati sul nodo attraverso il quale viene effettivamente eseguito il traffico in questione.

Device Console o Advanced Shell?

Sophos Firewall ha due diverse aree della console. Molti errori si verificano perché un comando viene inserito nell’area sbagliata.

Le aree hanno compiti diversi:

• Device Console: Sophos CLI per comandi di rete, sistema e diagnostica. I comandi tipici sono ping, dnslookup, traceroute, tcpdump, drop-packet-capture e show.
• Advanced Shell: Shell simile a Linux per file, registri, processi e controlli del servizio. I comandi tipici sono cd /log, tail -f, grep, less, df -kh, service -S e conntrack.

Dopo aver effettuato l’accesso tramite SSH, il firewall mostra innanzitutto il menu della console. Per Device Console di solito si sceglie 4. Device Console. Per Advanced Shell utilizzare 5. Device Management > Advanced Shell.

La guida ufficiale della Sophos CLI supporta Tab e ? per il controllo della sintassi. Ciò è utile in Device Console perché non tutti i comandi sono strutturati allo stesso modo.

Soprattutto in Device Console, i comandi non dovrebbero essere eseguiti a metà o per tentativi. Sophos segnala che i comandi incompleti possono avere effetti collaterali. Prima visualizzare la sintassi, poi eseguire consapevolmente il comando completo.

Un comando speciale di emergenza è system appliance_access enable. Sovrascrive la configurazione di Device Access e consente l’accesso a tutti i servizi locali del firewall, inclusi servizi legacy come Telnet. Importante: finché questa modalità è attiva, il firewall non inoltra più il traffico in uscita verso internet. Non è un normale passaggio di troubleshooting, ma solo una misura per brevi emergenze. Una volta ripristinato l’accesso, lo stato deve essere annullato:

system appliance_access disable

Se un comando non viene riconosciuto, controllare prima l’area della console. È più probabile un intervallo sbagliato che un comando interrotto immediatamente.

Controlla i log in Advanced Shell

I file di registro più importanti si trovano in /log. Per un orientamento iniziale, passare a questa directory ed elencare i file.

cd /log
ls -lah

• Registro traccia in tempo reale: tail -f /log/strongswan.log. Buono per errori VPN riproducibili.
• Leggi file di registro: less /log/ips.log. All’interno di less è possibile effettuare la ricerca con /Suchbegriff.
• Controlla la presenza di errori: grep -i "error" /log/ips.log. -i non fa distinzione tra maiuscole e minuscole.
• Premi con il numero di riga: grep -n "192.0.2.10" /log/firewall_rule.log. Utile per file più lunghi.
• Mostra le ultime righe: tail -n 100 /log/syslog.log. Panoramica rapida senza modalità live.

Quale file di registro appartiene a quale modulo è riepilogato in Risoluzione dei problemi Sophos Firewall: Services e registri.

Con i registri in tempo reale, dovresti mantenere breve il periodo di prova e annotare l’ora. Ciò è particolarmente importante se un archivio di log viene successivamente fornito al supporto Sophos o ad Avanet.

Device Console per controlli rapidi della rete

Il Device Console è adatto per test rapidi dal punto di vista del firewall. Ciò ti consente di verificare se DNS, routing o accessibilità funzionano sostanzialmente.

Controlli rapidi:

• Raggiungi l’host: ping 192.0.2.10 count 4 controlla la raggiungibilità ICMP.
• Controlla DNS: dnslookup example.com controlla la risoluzione dei nomi dal punto di vista del firewall.
• Controlla percorso: traceroute 192.0.2.10 mostra il percorso verso la destinazione.
• Visualizza stato interfaccia: show interfaces mostra le informazioni sull’interfaccia.
• Avvia Drop Capture: drop-packet-capture 'host 192.0.2.10' mostra i pacchetti rilasciati dalle regole del firewall.
• Avvia acquisizione pacchetti: tcpdump 'host 192.0.2.10 and port 443' controlla se i pacchetti sono visibili sul firewall. drop-packet-capture è particolarmente utile quando non è chiaro se il firewall stia rilasciando attivamente i pacchetti. Tuttavia, non sostituisce l’analisi dell’applicazione. Se un server risponde ma l’applicazione continua a non funzionare, è necessario anche il controllo Log Viewer, NAT, Packet Capture o i registri dell’applicazione.

Per registrazioni di pacchetti più lunghe e file PCAP, l’articolo separato Sophos Firewall: Raccogliere registri con TCPDump per l’analisi è più adatto. Dovresti anche pianificare quanto può essere grande il file, dove verrà archiviato e come verrà trasferito in modo sicuro.

Controlla le connessioni e il flusso dei pacchetti nel Advanced Shell

Se Log Viewer e Device Console non forniscono una risposta chiara, alcuni comandi shell avanzati ti aiuteranno a comprendere il flusso dei pacchetti.

Conntrack

conntrack mostra le connessioni attive di cui è a conoscenza il percorso del firewall con stato. Ciò è utile se vuoi verificare se una connessione appare anche nel monitoraggio della connessione.

conntrack -L | grep "192.0.2.10"

Se manca una voce, potrebbe indicare routing, NAT, origine errata, regola firewall mancante o test sul percorso sbagliato. Se esiste una voce ma l’applicazione non funziona, è necessario effettuare un ulteriore controllo per verificare se vengono restituiti pacchetti di risposta e se NAT, la policy o l’applicazione funzionano correttamente.

tcpdump nel file Advanced Shell

Per test rapidi dal vivo, il tcpdump può essere utilizzato anche nel Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

Per analisi produttive, il filtro dovrebbe essere il più stretto possibile. Registrazioni ampie come tcpdump -i any senza host, porta o conteggio producono rapidamente molto output e sono poco pratiche su firewall occupati.

Un inizio sicuro è una breve registrazione con limite di host, porta e pacchetto:

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

Se sono necessari più dati, è necessario verificare preventivamente lo spazio di archiviazione e scegliere deliberatamente una posizione di archiviazione PCAP.

Controlla lo spazio di archiviazione e l’integrità del sistema

Prima della registrazione del debug, di archivi di log di grandi dimensioni o di registrazioni di pacchetti più lunghe, è necessario controllare lo spazio di archiviazione libero.

df -kh
df -h /var

Altri controlli rapidi:

uptime
top
service -S
service -S | grep strongswan

service -S mostra lo stato di molti servizi. I nomi dei singoli servizi non sono sempre autoesplicativi. Dovresti quindi confrontare il servizio con il file di registro appropriato prima di attivare i riavvii o il debug.

Se lo spazio di archiviazione è già limitato, la registrazione del debug e la registrazione dei pacchetti lunghi non dovrebbero essere avviate. Innanzitutto, chiarire quali registri o report possono essere sottoposti a backup e ripuliti in modo sicuro.

Attiva il registro di debug in modo specifico

La registrazione del debug può aiutare con errori complessi, ma dovrebbe essere attiva solo per un breve periodo e solo per il servizio interessato. Il debug genera molti più dati di registro e può consumare spazio di archiviazione se viene eseguito per un lungo periodo.

Esempio di debug IPS:

service ips:debug -ds nosync

Riproduci il problema, annota l’ora rilevante e quindi disattiva nuovamente il debug:

service ips:debug -ds nosync off

Prima di riavviare un servizio è necessario verificare quale funzione è interessata e se al momento è in corso traffico produttivo. Il riavvio di VPN, IPS, servizi Web o di autenticazione può influire sulle sessioni attive o sugli accessi degli utenti.

Consegna i log in modo sicuro

Spesso i singoli estratti di log non sono sufficienti per i casi complessi. Per il supporto Sophos, Avanet o analisi esterne, in genere è più utile un archivio di log completo. Invece di scrivere i dati di accesso FTP nei comandi, dovresti trasferire i log in modo sicuro e tracciabile, ad esempio tramite scp sul tuo server o tramite un portale di supporto. Le istruzioni appropriate sono disponibili all’indirizzo Sophos Firewall Backup dei registri per supporto e analisi.

I file di registro possono contenere informazioni sensibili: indirizzi IP interni, IP pubblici, nomi host, nomi utente, parametri VPN e messaggi di errore. Prima di condividerli, dovrebbe essere chiaro chi riceverà i dati e per quanto tempo verranno conservati.

Errori tipici di risoluzione dei problemi della CLI

• Comando nell’area della console errata: Device Console e Advanced Shell supportano una sintassi diversa. Controlla prima la zona.
• Lascia il debug attivo dopo l’analisi: i log crescono inutilmente e possono consumare spazio di archiviazione. Disattiva nuovamente il debug immediatamente.
• tcpdump ampio senza filtro: molto output, carico elevato e dati difficili da valutare. Limita host, porta, interfaccia o conteggio.
• Credenziali FTP nella cronologia della shell: le credenziali possono finire nei registri, negli screenshot o nella cronologia. Utilizza il trasferimento sicuro e le credenziali temporanee.
• Controlla un solo file di registro: Molti problemi interessano più moduli. Combina Log Viewer, registri di servizio corrispondenti e Packet Capture.
• Non documentare l’ora: Il supporto deve cercare aree di registro inutilmente grandi. Annotare l’ora, l’azione di test e gli IP coinvolti.
• Non pulire dopo il test: Il debug, i file temporanei o gli accessi ampi rimangono attivi. Disattiva il debug, controlla i file e rimuovi le condivisioni temporanee SSH.

Lista di controllo

• Accesso SSH consentito solo da reti amministrative attendibili.
• Impronta digitale SSH e accesso admin controllati prima dell’analisi.
• Gamma di console corretta selezionata: Device Console o Advanced Shell.
• Ora del problema, origine IP, destinazione IP, porta e utente documentati.
• Risultati CLI documentati con finestra temporale, comando, filtro e risultato.
• Leggi i comandi utilizzati prima del debug, del riavvio del servizio o dell’avvio di acquisizioni più lunghe.
• Log Viewer controllato per primo.
• File di registro corrispondente identificato in /log.
• tail, grep o less utilizzati con il termine di ricerca ristretto.
• Utilizzato specificamente per problemi di rete ping, dnslookup, traceroute, drop-packet-capture o tcpdump.
• Il debug è stato attivato solo brevemente e nuovamente disattivato.
• Spazio su disco controllato prima del debug o PCAP.
• Trasferisci in modo sicuro l’archivio dei registri e rimuovi i file temporanei.
• Accesso temporaneo al dispositivo o eccezioni SSH rimosse dopo il caso di supporto.

Domande frequenti