Riavviare in sicurezza i servizi Sophos Firewall
Il modo più sicuro per riavviare un singolo servizio Sophos Firewall è utilizzare System services > Services. Se il servizio non è presente, non è un motivo per eseguire un comando shell qualsiasi: usare Advanced Shell solo con istruzioni Sophos aggiornate e specifiche per il servizio o nell’ambito di un caso di supporto. Prima occorre identificare il servizio interessato e stabilire quali connessioni potrebbero essere interrotte dal riavvio.
⚠️ Importante: Il riavvio di un servizio modifica lo stato del sistema e può interrompere VPN, routing, DNS, DHCP, accessi web o l’accesso amministrativo. Salvare prima lo stato e i log e predisporre un accesso alternativo per le sedi remote.
Riavviare un servizio tramite WebAdmin
Prima di fare clic, annotare lo stato attuale, l’ora esatta dell’errore e il test funzionale che non riesce. I file pertinenti si possono scaricare singolarmente da Diagnostics > Tools > Troubleshooting logs. Per un caso di supporto, un Consolidated troubleshooting report (CTR) include anche stato del sistema, processi e utilizzo delle risorse. Per una sede remota, il controllo preliminare deve comprendere anche finestra di manutenzione e accesso alternativo.
- Aprire System services > Services.
- Controllare il servizio interessato e il suo stato attuale. Non avviare un servizio intenzionalmente arrestato o non configurato.
- In Manage, fare clic su Restart.
- Attendere che il servizio torni allo stato precedente
Running, quindi verificare la funzione interessata.
WebAdmin mostra, tra gli altri, Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot e Packet capture and Live connections. Se un servizio non è configurato, il pulsante rimane disattivato. Anti-spam richiede una spam policy in entrata o in uscita. Arrestando Packet capture and Live connections, le acquisizioni in corso terminano e la vista Live Connections non è più disponibile. Se Packet Capture non si avvia anche con l’interruttore attivo, Sophos indica espressamente questo riavvio tramite WebAdmin come passaggio di ripristino.
Il riavvio di un servizio non dispone di un rollback che ripristini le sessioni attive. Lo stato da preservare è quindi quello annotato in precedenza. Se un servizio prima attivo non torna a Running, non fare clic ripetutamente su Restart: registrare un nuovo timestamp, scaricare il log o il CTR e analizzare l’errore oppure coinvolgere Sophos Support.
In Control Center > System, lo stato dei servizi indica se un servizio è arrestato o non è riuscito ad avviarsi. È un buon punto di partenza, ma non sostituisce un test funzionale. Se non risponde solo l’interfaccia WebAdmin, seguire la guida specifica Riavviare la GUI WebAdmin di Sophos Firewall.
Servizio antivirus arrestato dopo aggiornamenti dei pattern non riusciti
Se il servizio Antivirus rimane arrestato dopo il fallimento degli aggiornamenti dei pattern SAVI e AVIRA, non fare clic più volte su Restart. Salvare prima la versione e la build del firmware, l’ora dell’errore e i relativi file avd.log e up2date_av.log. In Backup & firmware > Pattern updates annotare inoltre l’ultimo aggiornamento riuscito e lo stato attuale: Ready to install, Downloading, Success o Failed. La procedura generale per verificare questi stati è descritta in Configurare e verificare i pattern di Sophos Firewall.
Sophos identifica il problema come NC-180066; è stato corretto in SFOS 22.0 MR2 Build 546. Se i sintomi corrispondono su una build SFOS 22 precedente, verificare il percorso supportato con la guida alla preparazione dell’aggiornamento firmware e aggiornare prima a MR2 Build 546 o a una versione successiva approvata. In generale è possibile eseguire un singolo riavvio in System services > Services, ma Sophos non lo documenta né come workaround né come correzione per NC-180066 e non sostituisce l’aggiornamento firmware.
Solo dopo l’aggiornamento firmware, fare clic su Update pattern now in Backup & firmware > Pattern updates. L’aggiornamento del pattern Antivirus interessato deve raggiungere lo stato Success e il servizio Antivirus deve rimanere attivo. Lo stato visualizzato del servizio non è sufficiente: anche l’aggiornamento del pattern deve concludersi correttamente. Se il problema si ripresenta su MR2 Build 546 o versioni successive, fornire a Sophos Support i log e gli orari salvati invece di continuare a presumere che si tratti di NC-180066.
Riavviare IPsec tramite VPN Management
Il menu principale della CLI offre in 6. VPN Management > Restart VPN Service un riavvio supportato del daemon del servizio VPN. Sophos avverte che l’operazione interrompe tutti i tunnel VPN. Se occorre ristabilire una sola connessione VPN, usare invece la relativa azione in WebAdmin. Prima del riavvio salvare stato dei tunnel, ora esatta e strongswan.log; dopo verificare nuovamente Child SA, peer e traffico applicativo reale. Il riavvio non risolve errori di proposal, routing o NAT.
Nello stesso menu è possibile rigenerare la coppia di chiavi RSA utilizzata per l’autenticazione IPsec. Non si tratta di un riavvio del servizio, ma di un cambio delle chiavi. Per le connessioni con RSA key, i peer necessitano quindi della nuova chiave pubblica; gli utenti di accesso remoto devono scaricare nuovamente la configurazione VPN. Sophos non documenta un ripristino con un clic della vecchia coppia di chiavi. Usare questa azione solo come rotazione pianificata, con inventario completo dei tunnel, finestra di manutenzione e accesso amministrativo alternativo, non come passaggio generico di troubleshooting. Non risolve neppure problemi di PSK o certificati.
Riavviare un servizio tramite Advanced Shell
Usare Advanced Shell solo quando istruzioni Sophos aggiornate indicano il servizio e il comando esatti oppure Sophos Support li fornisce. Per l’accesso SSH e la verifica della chiave host, seguire Connettersi a Sophos Firewall tramite SSH. SSH dovrebbe essere consentito solo da reti amministrative attendibili; le impostazioni appropriate sono descritte in Device Access e Local Service ACL. Le sessioni SSH inattive vengono chiuse dopo 15 minuti.
Dopo l’accesso, aprire:
5. Device Management > 3. Advanced Shell
La Device Console, nell’opzione 4 del menu, convalida i comandi documentati ed è destinata alla diagnostica di rete e di sistema supportata. Advanced Shell, in 5. Device Management > 3. Advanced Shell, è invece una shell Linux con accesso completo a database e servizi di sistema. Le modifiche alla configurazione effettuate da questa shell non sono persistenti e non vengono incluse nei backup. Eseguire prima controlli in sola lettura e avviare il riavvio solo dopo aver verificato il nome del servizio, l’impatto, la finestra di manutenzione e l’accesso di recovery.
1. Controllare il nome e lo stato del servizio
Per visualizzare i servizi conosciuti e il loro stato attuale:
service -S
È possibile filtrare l’output in base al servizio sospetto. Per IPsec, ad esempio:
service -S | grep -i strongswan
RUNNING indica che il servizio è in esecuzione. STOPPED, UNREGISTERED o UNTOUCHED non indicano automaticamente un guasto: a seconda del firmware e della configurazione, un servizio può essere intenzionalmente inattivo o non registrato. Verificare prima se la funzione, la policy o la licenza associata viene effettivamente utilizzata.
Se il nome tecnico del servizio non è chiaro, consultare Troubleshooting di Sophos Firewall: servizi e log, che associa le aree funzionali ai relativi file di log.
2. Controllare i log prima dell’intervento
Un riavvio può nascondere indizi importanti sulla causa. Per IPsec, leggere prima strongswan.log e salvare i messaggi pertinenti:
less /log/strongswan.log
Premere q per uscire da less. Per analisi più ampie, esportare prima i log come descritto in Salvare i log di Sophos Firewall per il supporto e l’analisi. Nei cluster HA, ogni nodo conserva solo i log del traffico che elabora; potrebbe essere necessario controllare separatamente entrambi i nodi.
3. Riavviare il servizio su un firewall standalone
L’esempio seguente presuppone un firewall standalone. Prima dell’esecuzione, service -S | grep -i strongswan deve confermare il servizio. Il riavvio può interrompere le connessioni IPsec site-to-site e di accesso remoto. Controllare prima i tunnel, i peer remoti e la finestra di manutenzione.
Sophos documenta questo schema:
service <service>:restart -ds nosync
Un esempio completo per il servizio IPsec è:
service strongswan:restart -ds nosync
La sintassi generica e service -S sono documentati nella guida attuale di SFOS 22, dove strongswan è associato al servizio IPsec. Questo esempio non è stato eseguito su un firewall e pertanto non viene presentato come testato in laboratorio. Non dedurre mai da un elenco il nome di un altro servizio.
Per proseguire l’analisi, consultare Troubleshooting IPsec su Sophos Firewall.
⚠️ Cluster HA: Non applicare il comando per un firewall standalone senza verificarlo. A seconda del servizio e della situazione, le istruzioni Sophos utilizzano
synconosync; la documentazione pubblica non fornisce una regola generale sufficiente. Servizio, nodo, build SFOS e modalità di sincronizzazione devono provenire da istruzioni Sophos aggiornate e specifiche per il servizio o da un caso di supporto.
I comandi stop e start separati devono essere utilizzati solo quando Sophos Support lo richiede per il servizio specifico. Tra i due comandi, il servizio rimane completamente arrestato.
Anche questo riavvio non offre un rollback che preservi lo stato: le Security Association e le sessioni interrotte non possono essere ripristinate. Il criterio di arresto sicuro è il confronto con il controllo preliminare. Se strongswan non torna allo stato precedente o i tunnel non si ristabiliscono, non avviare un secondo riavvio. Salvare log e CTR e procedere con l’escalation.
4. Convalidare il risultato
Dopo il riavvio, controllare lo stato, il log e la funzione effettiva:
service -S | grep -i strongswan
tail -f /log/strongswan.log
grep -i 'error' /log/strongswan.log
tail -f mostra continuamente i nuovi messaggi e si interrompe con Ctrl+C. Confrontare i messaggi con l’ora annotata prima del riavvio; un grep senza filtro può mostrare anche errori precedenti. Controllare quindi i tunnel IPsec e testare un host nella sede remota. Lo stato RUNNING da solo non dimostra che la connessione funzioni di nuovo.
Se il riavvio non riesce, controllare anche csc.log. Per problemi HA, a seconda dei sintomi possono essere rilevanti anche ha.log, msync.log e applog.log.
Servizi comuni e test funzionali appropriati
Il nome esatto del servizio deve essere confermato sul firewall interessato con service -S. Le associazioni più importanti sono:
strongswan: IPsec site-to-site e di accesso remoto. Controllare quindi lo stato dei tunnel,strongswan.loge la raggiungibilità della sede remota.dnsd: Servizio DNS. Testare quindi la risoluzione dei nomi interna ed esterna,dnsd.loge le eventuali DNS Request Routes.dhcpd: Server DHCP. Durante un riavvio, i client nuovi o che rinnovano il lease potrebbero non ricevere risposta. Testare quindi l’assegnazione dei lease edhcpd.log.awed: Comunicazione tra firewall e dispositivi AP/APX. Controllare quindi lo stato di connessione degli access point eawed.log.zebra: Installa route dinamiche e statiche nel kernel. Un riavvio è quindi invasivo e deve essere eseguito solo con istruzioni Sophos specifiche; testare poi la tabella di routing, i gateway e i percorsi reali.smtpd: Proxy SMTP in modalità MTA. Il proxy trasparente legacy utilizza un servizio diverso; prima di intervenire, controllare la modalità operativa e i logsmtpd_*. Testare quindi in modo controllato l’invio e la ricezione delle e-mail.
Per WAF, Web proxy, IPS, Authentication e i servizi disponibili in WebAdmin, il riavvio tramite System services > Services è in genere più chiaro di un comando shell.
Quando non è opportuno riavviare un servizio
Il riavvio di un singolo servizio è appropriato quando è interessato un modulo specifico e il resto del firewall è stabile. Non riavviare servizi alla cieca quando:
- la causa o il servizio interessato non è ancora chiaro;
- più servizi centrali non funzionano contemporaneamente;
- quel servizio fornisce l’ultimo accesso remoto disponibile;
- l’errore è riproducibile e i log non sono ancora stati salvati;
- lo stesso servizio è già stato riavviato più volte;
- il ruolo HA, il nodo o la modalità di sincronizzazione necessaria non sono chiari.
Se sono interessati più servizi, controllare prima il carico del sistema, lo spazio di archiviazione, lo stato del database, HA e le ultime modifiche alla configurazione o al firmware. I riavvii ripetuti spesso nascondono soltanto la causa.
Un reboot completo è più invasivo e va preso in considerazione solo se il firewall rimane complessivamente instabile, se richiesto da un processo firmware o hotfix oppure da Sophos Support. Nella Device Console, system restart riavvia il firewall; in un cluster HA il comando provoca un failover. system shutdown, invece, lo arresta soltanto. Prima di entrambe le azioni, verificare il dispositivo e il nodo HA di destinazione, il backup, la finestra di manutenzione e l’accesso locale o out-of-band; in caso di arresto, tale metodo di recovery deve consentire realmente la riaccensione del dispositivo. Dopo il riavvio, controllare ruolo e sincronizzazione HA, stato dei servizi e percorsi dati interessati. Le sessioni interrotte non possono essere ripristinate. Se il dispositivo non torna online, non ripetere il comando: usare l’accesso di recovery predisposto e coinvolgere Sophos Support se necessario. Consultare Pianificare correttamente backup e ripristino di Sophos Firewall.
Documentare brevemente l’intervento
Per problemi ricorrenti o un caso di supporto è sufficiente una breve nota. In seguito permette di capire se il riavvio ha risolto il problema in modo duraturo o ha soltanto nascosto un sintomo:
Date/time and time zone:
Firewall / HA node:
Service and command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:
Prima dell’intervento, registrare l’ora, la funzione interessata e i messaggi di log pertinenti. In seguito, annotare lo stato del servizio, il test funzionale e l’azione successiva. Rimuovere le regole SSH o Device Access temporanee e disattivare le modalità di debug al termine dell’analisi.