Riavviare in sicurezza i servizi Sophos Firewall

Il modo più semplice per riavviare un singolo servizio Sophos Firewall è utilizzare System services > Services. Se il servizio non è presente, è possibile usare Advanced Shell. Prima, tuttavia, 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

1. Aprire System services > Services.
2. Controllare il servizio interessato e il suo stato attuale.
3. In Manage, fare clic su Restart.
4. Verificare quindi lo stato e la funzione interessata.

WebAdmin mostra, tra gli altri, Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, 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.

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.

Riavviare un servizio tramite Advanced Shell

Advanced Shell è utile quando il servizio non è disponibile in WebAdmin o Sophos Support fornisce un comando specifico. 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

Advanced Shell offre un accesso esteso al sistema. Eseguire quindi prima controlli in sola lettura e solo successivamente avviare un riavvio.

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

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 sync o nosync; 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.

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. 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.log e la raggiungibilità della sede remota.
• dnsd: Servizio DNS. Testare quindi la risoluzione dei nomi interna ed esterna, dnsd.log e 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 e dhcpd.log.
• awed: Comunicazione tra firewall e dispositivi AP/APX. Controllare quindi lo stato di connessione degli access point e awed.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 log smtpd_*. 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. Prima di riavviare un firewall remoto, verificare backup, finestra di manutenzione e percorso di ripristino, ad esempio un contatto locale, accesso out-of-band o un peer HA funzionante. 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.