Riavviare la GUI WebAdmin di Sophos Firewall

Se la GUI WebAdmin di Sophos Firewall non risponde più, non è necessario riavviare immediatamente l’intero firewall. Finché routing, VPN e regole firewall continuano a funzionare e SSH o la console locale rimangono accessibili, è possibile controllare e riavviare in modo mirato i due servizi WebAdmin, tomcat e apache.

I comandi seguenti sono destinati a un firewall standalone. In un cluster HA, la modalità di sincronizzazione corretta dipende dal servizio, dal nodo, dalla build SFOS e dal problema specifico. Non utilizzare -ds nosync in HA senza aver prima verificato che sia appropriato.

⚠️ Il riavvio di un servizio modifica lo stato del sistema, termina le sessioni WebAdmin attive e può anche interrompere brevemente lo User Portal. Prima salvare i log pertinenti, informare gli altri amministratori e predisporre un accesso alternativo per le sedi remote.

Procedura rapida per un firewall standalone

Questa procedura è adatta quando WebAdmin mostra un Internal Server Error, un errore HTTP 503, una pagina di accesso incompleta o un’interfaccia che non risponde in modo permanente, mentre SSH e le altre funzioni del firewall rimangono disponibili.

1. Accedere come admin tramite SSH o dalla console locale. Se SSH non è ancora configurato, Connettersi a Sophos Firewall tramite SSH spiega come predisporre un accesso sicuro.
2. Aprire 5. Device Management > 3. Advanced Shell.
3. Visualizzare gli ultimi errori di WebAdmin e copiare gli output rilevanti per la documentazione della modifica o per un caso di supporto:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

4. Controllare lo stato corrente dei servizi:

service -S | grep -iE 'tomcat|apache'

5. Se un servizio mostra STOPPED, eseguire soltanto il comando di avvio corrispondente:

# Se tomcat è STOPPED:
service tomcat:start -ds nosync

# Se apache è STOPPED:
service apache:start -ds nosync

6. Se un servizio mostra DEAD, riavviare soltanto quel servizio. Se entrambi mostrano RUNNING ma WebAdmin rimane inutilizzabile, iniziare da tomcat:

service tomcat:restart -ds nosync

Provare nuovamente WebAdmin. Solo se apache mostra DEAD o se il problema persiste dopo il riavvio di tomcat, eseguire:

service apache:restart -ds nosync

7. Attendere alcuni secondi, riaprire WebAdmin dalla rete di amministrazione prevista e controllare nuovamente lo stato dei servizi:

service -S | grep -iE 'tomcat|apache'

Entrambi i servizi dovrebbero mostrare RUNNING. Tuttavia, è il test funzionale a essere decisivo: accesso, dashboard, Log Viewer e una pagina di configurazione non critica devono caricarsi in modo stabile. Un processo in esecuzione non dimostra da solo che WebAdmin funzioni correttamente.

Le sessioni SSH inattive vengono chiuse dopo 15 minuti. È quindi opportuno preparare il controllo dei log, il riavvio e la verifica prima di entrare in Advanced Shell, in modo che una sessione scaduta non interrompa la procedura.

Verificare se il riavvio di un servizio è appropriato

Dietro il nome di servizio tomcat opera il server di applicazioni web Jetty; apache è il server HTTP Apache. Entrambi i componenti vengono utilizzati da WebAdmin e dallo User Portal. I relativi log si trovano in Advanced Shell:

• Server applicativo: /log/tomcat.log
• Server web: /log/apache.log e /log/apache_access.log
• Altri errori del server web: /log/error_log.log

Non tutti i problemi di WebAdmin hanno origine in questi servizi. Il tipo di errore determina il passaggio successivo:

• Internal Server Error, HTTP 503 o pagina di accesso incompleta: Controllare tomcat, apache e i log indicati. In questo caso un riavvio mirato è appropriato.
• Avviso relativo al certificato: Controllare il nome, la validità e la catena di attendibilità del certificato. Il riavvio di un servizio non corregge un certificato errato.
• Timeout o accesso non riuscito da una sola rete: Controllare la route, la rete di amministrazione e Administration > Device access. I servizi locali del firewall vengono autorizzati tramite Device Access, non con una normale regola firewall. Device Access e Local Service ACL spiega la configurazione sicura.
• È interessato un solo browser: Provare una sessione privata, un secondo browser o un altro client di amministrazione prima di intervenire sul firewall.
• WebAdmin, SSH, VPN o altri servizi non funzionano contemporaneamente: Questo indica piuttosto un problema di carico del sistema, spazio di archiviazione, database, HA o un problema generale del sistema. Non riavviare servizi a caso.

Se è in corso un aggiornamento del firmware, di un hotfix o dei pattern, una sincronizzazione HA, una sessione di debug del supporto o un’attività Central, è necessario prima identificare e, se possibile, completare tale processo. Altrimenti sarà difficile stabilire in seguito se il problema derivava dall’aggiornamento, da Central, da HA o dal riavvio del servizio.

Conservare le evidenze prima dell’intervento

Un riavvio può rimuovere dal contesto visibile i messaggi di errore correnti. Per un problema ricorrente o un caso di supporto, è necessario registrare almeno l’ora, la build SFOS, il percorso di accesso interessato e gli ultimi messaggi di tomcat.log, apache.log e error_log.log.

Se WebAdmin funziona ancora parzialmente, è possibile scaricare singoli log o un Consolidated Troubleshooting Report in Diagnostics > Tools. Se è disponibile soltanto la shell, Salvare i log di Sophos Firewall per il supporto e l’analisi spiega la procedura. In un cluster HA, ogni nodo conserva i propri log; se necessario, controllare Primary e Auxiliary separatamente.

Prima di un riavvio in produzione, verificare inoltre:

• se sono interessati altri amministratori o una modifica in corso;
• se SSH, la console locale, Sophos Central o un’altra connessione di amministrazione offrono un percorso di ritorno;
• se WebAdmin è l’unico servizio interessato;
• se per un cluster HA sono disponibili il nodo corretto e istruzioni Sophos aggiornate specifiche per il servizio.

Riavviare in sicurezza i servizi di Sophos Firewall spiega la gestione generale dei nomi dei servizi, dello stato, dei log e dei limiti HA. Risoluzione dei problemi di Sophos Firewall: servizi e log contiene ulteriori corrispondenze tra funzioni e file di log.

Verificare il risultato e analizzare i problemi ricorrenti

Dopo il riavvio, leggere nuovamente i log. I nuovi errori visualizzati subito dopo l’avvio sono più utili dei vecchi messaggi senza un riferimento temporale:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

Aprire quindi dashboard, Log Viewer e una pagina non critica. Limitare nuovamente qualsiasi accesso SSH o Device Access consentito temporaneamente alle origini di amministrazione previste.

Se il problema si ripresenta, il riavvio del servizio è stato soltanto un ripristino temporaneo. L’analisi della causa deve quindi includere:

• spazio libero nelle partizioni, report locali e stato del database;
• utilizzo di CPU e RAM e log di sistema anomali;
• sessioni di amministrazione simultanee o uso intensivo della cattura dei pacchetti;
• attività Central in corso o non riuscite;
• ruolo HA, sincronizzazione e nodo interessato;
• modifiche a configurazione, certificato, interfaccia o Device Access immediatamente precedenti al problema.

Gestire lo spazio di archiviazione e i report di Sophos Firewall aiuta a risolvere i problemi di spazio e report. Le modifiche effettuate prima del guasto possono essere ricostruite tramite i log Audit Trail di Sophos Firewall.

Una breve nota operativa evita che un problema ricorrente venga affrontato soltanto con riavvii ripetuti:

Data, ora e fuso orario:
Firewall ed eventuale nodo HA:
Versione e build SFOS:
Sintomi:
Log controllati:
Comando eseguito:
Risultato e azione successiva:

Se WebAdmin non è ancora disponibile

Se un servizio rimane STOPPED o DEAD, il riavvio restituisce un errore o il problema si ripresenta immediatamente, salvare tomcat.log, apache.log, error_log.log, lo stato del sistema e il CTR per analizzarli con Sophos Support. Il riavvio casuale di altri servizi rischia soprattutto di compromettere le evidenze.

Se né WebAdmin né SSH sono accessibili, il percorso di ripristino dipende dall’ambiente: console locale tramite cavo console o Micro-USB sui modelli supportati, Sophos Central, una procedura di fallback HA predisposta o un riavvio pianificato. Nelle sedi remote, stabilire chi può ottenere l’accesso locale se il firewall non si avvia correttamente. In un cluster HA, non avviare un failover non verificato soltanto perché WebAdmin non risponde mentre il traffico di produzione continua a scorrere normalmente.

Un riavvio completo è più invasivo del riavvio dei servizi interessati. Va preso in considerazione solo se sono coinvolti più servizi centrali, il firewall rimane instabile, un processo di firmware o hotfix lo richiede oppure Sophos Support lo indica. Prima verificare il backup, la finestra di manutenzione e gli effetti su VPN, routing, RED, wireless e servizi pubblicati. Pianificare correttamente backup e ripristino di Sophos Firewall spiega la preparazione.