Riavviare in sicurezza i servizi Sophos Firewall

Il riavvio di singoli servizi Sophos Firewall può aiutare quando un modulo non reagisce più correttamente, un log non mostra più nuove voci o Sophos Support richiede un riavvio mirato. Non sostituisce però un troubleshooting pulito. Un riavvio del servizio sbagliato può interrompere brevemente tunnel VPN, routing, WebAdmin, DNS, DHCP, reporting o altre funzioni.

Questo articolo spiega come riavviare i servizi tramite WebAdmin o Advanced Shell, controllare prima i log adatti e poi verificare se il servizio funziona di nuovo correttamente. Se all’inizio non è chiaro quale servizio tecnico appartenga a quale modulo, aiuta la panoramica Troubleshooting Sophos Firewall: servizi e log. Per sicurezza CLI di base, debug e tcpdump è utile anche Troubleshooting CLI Sophos Firewall: comandi importanti.

⚠️ Importante: i riavvii dei servizi in ambienti produttivi dovrebbero essere pianificati. Prima deve essere chiaro quale servizio è interessato, quali utenti o tunnel possono essere interrotti e se esiste un accesso alternativo al firewall.

Quando un riavvio del servizio è sensato

Un riavvio mirato del servizio è sensato quando è interessato un modulo concreto e il resto del firewall è sostanzialmente stabile.

Esempi tipici:

• WebAdmin non si carica più, ma routing e regole firewall continuano a funzionare.
• Un servizio VPN è bloccato, mentre le altre funzioni firewall sono normali.
• Un log mostra errori attuali per un servizio specifico.
• Sophos Support indica un servizio concreto da riavviare.
• Un servizio non si è attivato correttamente dopo una modifica di configurazione.

Non è sensato riavviare alla cieca più servizi solo perché il problema è ancora poco chiaro. In quel caso bisogna prima controllare log, carico di sistema, spazio disco, stato HA, routing e moduli interessati.

Quando non bisognerebbe riavviare servizi

Un riavvio del servizio è invitante perché sembra rapido. In alcune situazioni però peggiora l’analisi o crea interruzioni aggiuntive.

• La causa è ancora del tutto poco chiara: Il riavvio cambia lo stato e può nascondere tracce importanti nei log o negli output di stato.
• Più servizi centrali falliscono contemporaneamente: Spesso il problema non è un singolo servizio, ma carico di sistema, spazio disco, database, HA o stato della piattaforma.
• Il firewall è raggiungibile solo tramite esattamente questo servizio: Un riavvio può far perdere l’ultimo accesso remoto.
• Sono interessati servizi VPN, routing o DHCP produttivi: Utenti, sedi o lease esistenti possono essere interrotti brevemente.
• Il debug è già attivo e l’errore è riproducibile: Prima salvare i log rilevanti, poi riavviare.
• Il servizio è già stato riavviato più volte: Serve analisi della causa invece di ripetizione.

Se il riavvio è comunque necessario, bisognerebbe annotare almeno ora attuale, utenti o sedi interessati, nome servizio, file di log e impatto atteso.

Verificare prima del riavvio

Prima di un riavvio del servizio conviene documentare brevemente cosa è interessato. Questo fa risparmiare tempo se l’errore ritorna o serve un caso di supporto.

Controllo preliminare pratico:

1. Delimitare il modulo interessato, per esempio WebAdmin, IPsec, DNS, DHCP, IPS o WAF.
2. Verificare se il firewall nel complesso è stabile o se falliscono più servizi.
3. Verificare se sono connessi admin, utenti VPN o sedi critiche.
4. Nei cluster HA controllare su quale node si sta lavorando e quale node è attivo.
5. Aprire il file di log adatto e salvare gli ultimi messaggi.
6. Controllare lo spazio disco se sono coinvolti debug, log grandi o file PCAP.
7. Se necessario, esportare i log prima del riavvio.
8. Definire un criterio di stop: quando il riavvio viene fermato, rinviato o escalato?

Per ambienti HA è rilevante anche Comprendere le varianti di cluster HA Sophos Firewall. Se servono log per un’analisi esterna, è adatto Salvare i log Sophos Firewall per supporto e analisi.

Conservare prima le prove se l’errore ritorna

Un riavvio del servizio può risolvere temporaneamente un sintomo, ma può anche modificare lo stato importante per l’analisi della causa. Se un problema si ripete, prima del prossimo riavvio conviene salvare una piccola finestra di evidenze.

Dati minimi utili:

• ora esatta con fuso orario
• servizio interessato e funzione interessata
• ultimi messaggi rilevanti dal file di log corretto
• output dello stato del servizio prima del riavvio
• carico di sistema, spazio disco o indicazioni report/database se la GUI è lenta
• utenti, tunnel, interfacce, regole o sedi interessati
• ultima modifica di configurazione, firmware, hotfix o evento HA

È particolarmente importante se lo stesso servizio è già stato riavviato più volte. In quel caso il riavvio è solo una misura immediata. Il vero lavoro è capire perché il servizio si blocca, va in crash, rimane fermo o non scrive più nuovi log.

Documentare il riavvio in un caso di supporto

Se un riavvio del servizio fa parte di un caso di supporto, di una finestra di manutenzione o di un problema ricorrente, l’azione dovrebbe essere documentata brevemente. Non serve un report lungo. È importante che in seguito resti chiaro quale servizio è stato riavviato, quando, perché e con quale risultato.

Modello pratico di nota:

Date/time and time zone:
Firewall / HA node:
Service:
Command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Questa nota è particolarmente utile quando un errore ritorna dopo alcune ore o giorni. Si vede subito se è sempre interessato lo stesso servizio, se il riavvio aiuta solo per poco o se diventa più probabile un problema più profondo come spazio disco, stato database, comportamento HA o un difetto di prodotto.

Riavviare servizi tramite WebAdmin

Alcuni servizi possono essere riavviati direttamente tramite WebAdmin. È il modo più semplice se la GUI è ancora raggiungibile e il servizio desiderato è visibile lì.

Il menu esatto dipende da versione e vista. Il punto decisivo è: WebAdmin è adatto solo per i servizi che vengono davvero offerti lì. Per troubleshooting più profondo, analisi dei log o servizi senza azione GUI serve la Advanced Shell.

Se solo la WebAdmin GUI non reagisce più, questo articolo generale non dovrebbe essere il primo passo. Per questo esiste la guida mirata Riavviare la GUI WebAdmin Sophos Firewall.

Aprire Advanced Shell

Per i comandi sui servizi è necessaria la Advanced Shell. L’accesso avviene di solito tramite SSH con l’utente admin.

Se SSH non è ancora preparato, aiuta Collegarsi a Sophos Firewall tramite SSH. L’accesso SSH dovrebbe essere consentito solo da reti admin affidabili. Prima del login bisognerebbe verificare l’SSH fingerprint, soprattutto dopo reimage, sostituzione hardware o cambio IP. L’hardening adatto si trova in Device Access e Local Service ACL su Sophos Firewall.

Dopo il login, aprire Advanced Shell tramite:

5. Device Management > Advanced Shell

La Advanced Shell offre accesso di sistema esteso. I comandi dovrebbero essere eseguiti lì solo se il servizio interessato e l’impatto atteso sono chiari.

Se bisogna solo verificare lo stato o leggere un file di log, inizialmente ci si dovrebbe limitare a comandi in lettura. Riavvii, Stop/Start e debug sono interventi e appartengono a una finestra di analisi consapevole.

Elencare i servizi

Una lista dei servizi disponibili viene mostrata con:

service -S

Se si cerca un servizio specifico, si può filtrare l’output:

service -S | grep strongswan
service -S | grep zebra
service -S | grep dns

I nomi tecnici dei servizi non sono sempre autoesplicativi. Prima di un riavvio, il nome del servizio va quindi confrontato con l’area funzionale interessata.

• strongswan: IPsec site-to-site e IPsec Remote Access; stato dei tunnel, peer remoto, interruzione pianificata, strongswan.log
• zebra: routing e rotte statiche; tabella di routing, stato SD-WAN/gateway, sedi interessate
• dnsd: servizio DNS della firewall; DNS Request Routes, test client, dnsd.log
• dhcpd: assegnazione lease DHCP; zona interessata, intervallo lease, client di test, dhcpd.log
• awed: Wireless Controller; Access Points interessati, gestione Central o locale, log wireless

L’associazione più dettagliata si trova in Troubleshooting Sophos Firewall: servizi e log.

Riavviare un servizio

Lo schema di base per un riavvio è:

service <service>:restart -ds nosync

Esempio per il servizio di routing zebra:

service zebra:restart -ds nosync

È importante la sintassi con spazio: -ds nosync. Varianti come -dsnosync non sono la stessa cosa e non dovrebbero essere riprese da vecchie note.

Durante un riavvio, il servizio viene fermato e riavviato. A seconda del servizio, questo può interrompere connessioni attive. Per routing, VPN, DNS, DHCP, Web Proxy, WAF o Wireless bisogna quindi valutare prima chi può essere interessato.

Se il servizio appartiene a un modulo rilevante per la sicurezza, dopo il riavvio non basta controllare lo stato. È decisivo se la funzione di protezione o connessione attesa lavora di nuovo e se nel log compaiono nuovi errori.

Fermare e avviare un servizio

Se un servizio non reagisce correttamente a restart o Sophos Support lo richiede così, si possono eseguire Stop e Start separatamente:

service zebra:stop -ds nosync
service zebra:start -ds nosync

Tra Stop e Start non bisogna attendere inutilmente a lungo se il servizio è richiesto in produzione. Dopo va controllato lo stato ed eseguito un test funzionale.

Controllare lo stato del servizio

service zebra:status -ds nosync

Inoltre va controllato il file di log adatto. Per il routing, per esempio:

tail -n 80 /log/zebra.log

Uno stato riuscito non basta sempre. È decisivo se la funzione interessata lavora di nuovo: i tunnel VPN si connettono, DNS risponde, DHCP assegna lease, WebAdmin si carica o il routing funziona.

Esempi di servizi frequenti

Gli esempi seguenti mostrano riavvii tipici dei servizi e non sostituiscono l’analisi della causa.

Riavviare Wireless Controller

service awed:restart -ds nosync

Riavviare SMTP Service

service smtpd:restart -ds nosync

Riavviare VPN IPsec Service

service strongswan:restart -ds nosync

Riavviare DNS Service

service dnsd:restart -ds nosync

Per problemi IPsec bisognerebbe usare anche Troubleshooting IPsec Sophos Firewall. Per problemi DNS sono spesso più rilevanti Configurare DNS Request Routes su Sophos Firewall oppure l’associazione DNS/DHCP in Troubleshooting Sophos Firewall: servizi e log rispetto a un semplice riavvio del servizio.

Trattare consapevolmente le aree di servizio sensibili

Non ogni riavvio del servizio ha lo stesso impatto. Alcuni servizi riguardano solo un’interfaccia di amministrazione, altri si trovano direttamente nel datapath o controllano autenticazione, VPN, routing o servizi locali. Più un servizio è vicino al traffico produttivo, più sono importanti finestra di manutenzione, controllo log e piano di fallback.

• IPsec / SSL VPN: Tunnel o sessioni Remote Access possono cadere; Informare prima utenti e sedi, poi controllare attivamente i tunnel
• DNS / DHCP: Risoluzione nomi o assegnazione lease può essere disturbata brevemente; Pianificare test client e controllo log dopo il riavvio
• Routing / SD-WAN: Percorsi, gateway monitoring o collegamenti di sede possono essere interessati; Verificare tabella di routing, stato gateway e raggiungibilità
• Web Proxy / IPS / TLS Inspection: Accessi web o inspection possono essere influenzati brevemente; Controllare Log Viewer e policy interessate dopo il riavvio
• WAF / Reverse Proxy: Applicazioni pubblicate possono essere brevemente non raggiungibili; Testare URL esterno e raggiungibilità backend
• WebAdmin: L’accesso admin viene interrotto brevemente; Tenere pronto accesso alternativo tramite SSH o console locale
• Reporting / database / storage: Analisi, report o stabilità GUI possono essere interessati; non riavviare alla cieca, prima controllare spazio disco e log

Se un’area servizio non è chiara, bisognerebbe prima consultare Troubleshooting Sophos Firewall: servizi e log prima di eseguire un riavvio. Per temi database, storage o reporting, un riavvio non mirato è raramente la migliore prima misura.

Validare dopo il riavvio

Dopo un riavvio del servizio non bisogna solo verificare se il comando torna senza messaggi di errore. È importante il test funzionale.

Check sensati:

• Controllare lo stato del servizio con service <service>:status -ds nosync.
• Controllare il file di log adatto in /log per nuovi errori.
• Validare la funzione interessata con un test reale.
• Controllare Log Viewer se sono interessati regole firewall, NAT, web, IPS o VPN.
• Nei cluster HA verificare se il node attivo continua a lavorare come previsto.
• Disattivare il debug se era stato attivato prima o durante il riavvio.
• Rimuovere aperture SSH o Device Access temporanee se erano state impostate solo per il caso di supporto.
• In caso di errori ricorrenti salvare i log e analizzare la causa invece di riavviare ripetutamente i servizi.

A seconda del servizio è utile un test funzionale diverso:

• IPsec / strongswan: stato tunnel, Log Viewer, strongswan.log, raggiungibilità di un host sul lato opposto
• DNS / dnsd: risoluzione nomi interna ed esterna, DNS Request Routes, dnsd.log
• Routing / zebra: tabella di routing, gateway monitoring, ping o traceroute attraverso il percorso interessato
• WAF / Reverse Proxy: testare URL pubblicato dall’esterno, reverseproxy.log, raggiungibilità backend
• WebAdmin / tomcat e apache: controllare login, dashboard, Log Viewer e tomcat.log
• DHCP / dhcpd: verificare assegnazione lease con client di test e dhcpd.log

Quando un reboot è migliore

Un reboot completo è più invasivo di un riavvio del servizio, ma può diventare sensato quando più servizi centrali sono bloccati, sono stati risolti problemi di storage o database, Sophos Support lo richiede o il firewall resta instabile dopo riavvii mirati.

La decisione non dovrebbe essere presa d’istinto. Un riavvio del servizio è meglio quando un singolo modulo è chiaramente interessato e il firewall per il resto lavora in modo stabile. Un reboot è più adatto quando lo stato complessivo del sistema è poco chiaro o resta danneggiato dopo un riavvio mirato.

• Singolo servizio bloccato: Sì, se servizio e impatto sono chiari; Solo se il riavvio non aiuta
• Più servizi mostrano errori: Prima controllare log e spazio disco; Sì, se lo stato complessivo del sistema è instabile
• Finestra firmware o hotfix in corso: Non come sostituto di un riavvio pianificato; Sì, se il processo di update lo prevede
• Cluster HA instabile: Solo dopo verifica ruoli e approvazione supporto; Solo con finestra di manutenzione e piano HA
• Spazio disco o database ripulito: Solo per il servizio interessato; Sì, se Sophos Support lo richiede come chiusura
• Accesso remoto incerto: Prudente, l’ultimo accesso può cadere; Solo con accesso locale o alternativo

Prima di un reboot devono essere noti backup, finestra di manutenzione, accesso alla sede, comportamento HA e impatto su VPN, RED, Wireless, routing e servizi pubblicati. Per sedi remote serve inoltre un percorso di ritorno se il firewall dopo il riavvio non torna online correttamente: contatto locale, accesso out-of-band, controparte HA funzionante o processo di supporto chiaro.

Dopo il reboot dovrebbe avvenire la stessa validazione di un riavvio del servizio, solo più ampia: stato HA, stato licenza, tunnel VPN, gateway SD-WAN, log centrali, WebAdmin, connessione Central e principali servizi pubblicati. Per temi recovery è utile anche Pianificare correttamente backup e restore di Sophos Firewall.

Checklist operativa

• Modulo interessato e nome servizio identificati.
• File di log adatto controllato prima del riavvio.
• Possibili impatti su utenti, VPN, routing o sedi valutati.
• Se necessario, finestra di manutenzione o contesto HA chiariti.
• Accesso SSH e verifica host key preparati in modo pulito se serve Advanced Shell.
• Servizio riavviato in modo mirato.
• Stato e file di log controllati dopo il riavvio.
• Funzione validata con un test reale.
• Debug e accessi temporanei rimossi dopo l’analisi.
• Errori ricorrenti documentati e non mascherati con riavvii ripetuti.

FAQ