Reiniciar serviços da Sophos Firewall em segurança

Reiniciar serviços individuais da Sophos Firewall pode ajudar quando um módulo deixa de responder corretamente, um log já não mostra novas entradas ou o Sophos Support pede um reinício direcionado. Mas não substitui troubleshooting limpo. Um reinício incorreto de serviço pode interromper brevemente túneis VPN, routing, WebAdmin, DNS, DHCP, reporting ou outras funções.

Este artigo explica como reiniciar serviços através do WebAdmin ou da Advanced Shell, verificar antes os logs adequados e validar depois se o serviço voltou a funcionar corretamente. Se primeiro não estiver claro que serviço técnico pertence a que módulo, a visão geral Sophos Firewall troubleshooting: serviços e logs ajuda. Para segurança básica na CLI, debug e tcpdump, também é adequado Sophos Firewall CLI troubleshooting: comandos importantes.

⚠️ Importante: Reinícios de serviços em ambientes produtivos devem ser planeados. Antes deve estar claro que serviço é afetado, que utilizadores ou túneis podem ser interrompidos e se existe acesso alternativo à firewall.

Quando um reinício de serviço faz sentido

Um reinício de serviço direcionado faz sentido quando um módulo concreto está afetado e o resto da firewall está basicamente estável.

Exemplos típicos:

• WebAdmin já não carrega, mas routing e regras de firewall continuam a funcionar.
• Um serviço VPN está bloqueado, enquanto outras funções da firewall não apresentam anomalias.
• Um log mostra erros atuais para um serviço específico.
• Sophos Support indica um serviço concreto que deve ser reiniciado.
• Um serviço não ficou ativo corretamente após uma alteração de configuração.

Não faz sentido reiniciar cegamente vários serviços só porque o problema ainda é pouco claro. Nesse caso, deve-se primeiro verificar logs, carga do sistema, espaço em disco, estado HA, routing e módulos afetados.

Quando não se devem reiniciar serviços

Um reinício de serviço é tentador porque atua rapidamente. Em algumas situações, porém, piora a análise ou cria interrupções adicionais.

• A causa ainda é totalmente incerta: O reinício altera o estado e pode esconder pistas importantes em logs ou saídas de estado.
• Vários serviços centrais falham ao mesmo tempo: Então muitas vezes o problema não é um serviço individual, mas carga do sistema, espaço em disco, base de dados, HA ou estado da plataforma.
• A firewall só está acessível exatamente através desse serviço: Um reinício pode fazer perder o último acesso remoto.
• Serviços produtivos de VPN, routing ou DHCP estão afetados: Utilizadores, sites ou leases existentes podem ser interrompidos brevemente.
• Debug já está ativo e o erro é reproduzível: Primeiro guardar os logs relevantes, depois reiniciar.
• O serviço já foi reiniciado várias vezes: Então é necessária análise da causa em vez de repetição.

Se ainda assim for necessário reiniciar, deve-se registar antes pelo menos o momento atual, utilizadores ou sites afetados, nome do serviço, ficheiro de log e impacto esperado.

Verificar antes do reinício

Antes de um reinício de serviço, deve-se documentar brevemente o que está afetado. Isto poupa tempo se o erro regressar ou se for necessário um caso de suporte.

Pré-verificação prática:

1. Delimitar o módulo afetado, por exemplo WebAdmin, IPsec, DNS, DHCP, IPS ou WAF.
2. Verificar se a firewall como um todo está estável ou se vários serviços falham.
3. Verificar se administradores, utilizadores VPN ou sites críticos estão ligados nesse momento.
4. Em clusters HA, verificar em que node se trabalha e que node está ativo.
5. Abrir o ficheiro de log adequado e guardar as últimas mensagens.
6. Verificar espaço em disco se debug, logs grandes ou ficheiros PCAP estiverem envolvidos.
7. Se necessário, exportar logs antes do reinício.
8. Definir critério de interrupção: quando é que o reinício é parado, adiado ou escalado?

Para ambientes HA, Compreender variantes de cluster HA da Sophos Firewall também é relevante. Se forem necessários logs para uma análise externa, Guardar logs da Sophos Firewall para suporte e análise é adequado.

Guardar evidências primeiro se o erro voltar

Um reinício de serviço pode resolver temporariamente um sintoma, mas também pode alterar o estado importante para a análise da causa. Se um problema se repetir, deve guardar uma pequena janela de evidências antes do próximo reinício.

Dados mínimos úteis:

• hora exata com fuso horário
• serviço afetado e função afetada
• últimas mensagens relevantes do ficheiro de log correspondente
• saída de estado do serviço antes do reinício
• carga do sistema, espaço em disco ou indícios de reports/base de dados se a GUI estiver lenta
• utilizadores, túneis, interfaces, regras ou locais afetados
• última alteração de configuração, firmware, hotfix ou evento HA

Isto é especialmente importante se o mesmo serviço já foi reiniciado várias vezes. Nesse caso, o reinício é apenas uma medida imediata. O trabalho real é perceber porque o serviço bloqueia, falha, fica preso ou deixa de escrever novos logs.

Documentar o reinício em caso de suporte

Se um reinício de serviço fizer parte de um caso de suporte, de uma janela de manutenção ou de um problema recorrente, a ação deve ser documentada de forma breve. Não precisa de ser um relatório longo. O importante é que mais tarde continue claro que serviço foi reiniciado, quando, porquê e com que resultado.

Modelo de nota prático:

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

Esta nota é especialmente útil se um erro voltar após algumas horas ou dias. Assim vê-se de imediato se é sempre o mesmo serviço que está afetado, se o reinício ajuda apenas a curto prazo ou se um problema mais profundo, como espaço em disco, estado da base de dados, comportamento HA ou erro de produto, se torna mais provável.

Reiniciar serviços pelo WebAdmin

Alguns serviços podem ser reiniciados diretamente pelo WebAdmin. Este é o caminho mais simples se a GUI ainda estiver acessível e o serviço pretendido estiver visível aí.

O caminho de menu oficial é System services > Services. Aí é possível iniciar, parar e reiniciar serviços. Se um serviço não estiver configurado, o botão em Manage fica desativado.

O WebAdmin oferece sobretudo serviços claramente delimitados, por exemplo Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot e Packet capture and Live connections. Antes de clicar deve estar claro se o serviço está diretamente no data path, se há utilizadores ativos afetados e como o resultado será verificado depois.

Dois detalhes são importantes em operação: Anti-spam só pode ser iniciado quando existe uma inbound ou outbound spam policy. Se Packet capture and Live connections for parado, não só as capturas em curso param, como também as live connections deixam de ser apresentadas.

Para uma primeira avaliação, Control Center > System também é útil. O estado dos serviços mostra aí se todos os serviços estão a funcionar normalmente ou se existe um warning ou alert. Um clique no ícone mostra os serviços afetados. Isto não substitui um teste funcional, mas ajuda a distinguir um problema de um único serviço de um estado mais amplo do sistema.

Para troubleshooting mais profundo, análise de logs ou serviços sem ação na GUI, é necessária a Advanced Shell.

Se apenas a própria GUI do WebAdmin já não responder, este artigo geral não deve ser o primeiro passo. Para isso existe o guia direcionado Reiniciar a WebAdmin GUI da Sophos Firewall.

Abrir a Advanced Shell

Para comandos de serviço é necessária a Advanced Shell. O acesso é normalmente feito por SSH com o utilizador admin.

Se SSH ainda não estiver preparado, Ligar à Sophos Firewall por SSH ajuda. O acesso SSH deve ser permitido apenas a partir de redes administrativas confiáveis. Antes do login, deve-se verificar o fingerprint SSH, especialmente após reimage, substituição de hardware ou alteração de IP. O hardening adequado está em Device Access e Local Service ACL na Sophos Firewall.

A Sophos fecha sessões SSH inativas após 15 minutos. Em análises mais longas, devem ser planeados conscientemente comandos em execução, vistas de log abertas e possíveis interrupções.

Após o login, abre-se a Advanced Shell através de:

5. Device Management > Advanced Shell

A Advanced Shell oferece acesso amplo ao sistema. Comandos só devem ser executados aí quando o serviço afetado e o impacto esperado forem claros.

Se o objetivo for apenas verificar o estado ou ler um ficheiro de log, deve-se começar por comandos de leitura. Reinícios, Stop/Start e debug são intervenções e pertencem a uma janela de análise consciente.

Listar serviços

Uma lista dos serviços disponíveis é apresentada por:

service -S

Se se procura um serviço específico, a saída pode ser filtrada:

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

Nomes técnicos de serviços nem sempre são autoexplicativos. Antes de reiniciar, deve-se comparar o nome do serviço com a área funcional afetada.

• strongswan: IPsec site-to-site e IPsec Remote Access; estado dos túneis, peer remoto, interrupção planeada, strongswan.log
• zebra: routing e rotas estáticas; tabela de routing, estado SD-WAN/gateway, sites afetados
• dnsd: serviço DNS da firewall; DNS Request Routes, teste de cliente, dnsd.log
• dhcpd: atribuição de leases DHCP; zona afetada, intervalo de leases, cliente de teste, dhcpd.log
• awed: Wireless Controller; Access Points afetados, gestão Central ou local, logs wireless

A associação mais detalhada está em Sophos Firewall troubleshooting: serviços e logs.

Reiniciar serviço

O padrão básico para um reinício é:

service <service>:restart -ds nosync

Exemplo para o serviço de routing zebra:

service zebra:restart -ds nosync

Importante é a sintaxe com espaço: -ds nosync. Variantes como -dsnosync não são iguais e não devem ser copiadas de notas antigas.

Num reinício, o serviço é parado e novamente iniciado. Dependendo do serviço, isto pode interromper ligações ativas. Em routing, VPN, DNS, DHCP, Web Proxy, WAF ou Wireless, deve-se por isso avaliar previamente quem pode ser afetado.

Se o serviço pertencer a um módulo relevante para segurança, após o reinício não se deve verificar apenas o estado. O decisivo é saber se a função de proteção ou ligação esperada voltou a funcionar e se surgem novas mensagens de erro no log.

Parar e iniciar serviço

Se um serviço não reagir corretamente a restart ou se o Sophos Support o indicar assim, Stop e Start podem ser executados separadamente:

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

Entre Stop e Start, não se deve esperar desnecessariamente muito tempo se o serviço for necessário em produção. Depois deve ser verificado o estado e realizado um teste funcional.

Verificar estado do serviço

service zebra:status -ds nosync

Além disso, deve ser verificado o ficheiro de log adequado. Para routing, por exemplo:

tail -n 80 /log/zebra.log

Um estado bem-sucedido nem sempre é suficiente. O decisivo é saber se a função afetada volta a trabalhar: túneis VPN ligam, DNS responde, DHCP atribui leases, WebAdmin carrega ou routing funciona.

Exemplos de serviços frequentes

Os exemplos seguintes mostram reinícios típicos de serviços e não substituem uma análise da causa.

Reiniciar Wireless Controller

service awed:restart -ds nosync

Reiniciar SMTP Service

service smtpd:restart -ds nosync

Reiniciar VPN IPsec Service

service strongswan:restart -ds nosync

Reiniciar DNS Service

service dnsd:restart -ds nosync

Em problemas IPsec, deve ser usado adicionalmente Troubleshooting de IPsec na Sophos Firewall. Em problemas DNS, muitas vezes Configurar DNS Request Routes na Sophos Firewall ou a associação DNS/DHCP em Sophos Firewall troubleshooting: serviços e logs é mais relevante do que um simples reinício de serviço.

Tratar conscientemente áreas de serviço sensíveis

Nem todos os reinícios de serviço têm o mesmo impacto. Alguns serviços afetam apenas uma interface de administração, outros estão diretamente no caminho de dados ou controlam autenticação, VPN, routing ou serviços locais. Quanto mais próximo um serviço estiver do tráfego produtivo, mais importantes são janela de manutenção, verificação de logs e plano de retorno.

• IPsec / SSL VPN: Túneis ou sessões de Remote Access podem cair; Informar previamente utilizadores e sites, depois verificar túneis ativamente
• DNS / DHCP: Resolução de nomes ou atribuição de leases pode ser brevemente afetada; Planear teste de cliente e verificação de logs após o reinício
• Routing / SD-WAN: Caminhos, Gateway-Monitoring ou ligações entre sites podem ser afetados; Verificar tabela de routing, estado de gateway e acessibilidade
• Web Proxy / IPS / TLS Inspection: Acessos web ou Inspection podem ser brevemente influenciados; Controlar Log Viewer e policies afetadas após o reinício
• WAF / Reverse Proxy: Aplicações publicadas podem ficar brevemente indisponíveis; Testar URL externa e acessibilidade do backend
• WebAdmin: O acesso administrativo é brevemente interrompido; Manter acesso alternativo por SSH ou consola local disponível
• Reporting / base de dados / armazenamento: Análise, reports ou estabilidade da GUI podem ser afetados; Não reiniciar cegamente; verificar primeiro espaço em disco e logs

Se a área de serviço não for clara, deve-se consultar primeiro Sophos Firewall troubleshooting: serviços e logs antes de executar um reinício. Em temas de base de dados, armazenamento ou reporting, um reinício não direcionado raramente é a melhor primeira medida.

Validar após o reinício

Após um reinício de serviço, não se deve verificar apenas se o comando regressa sem erro. O importante é o teste funcional.

Checks úteis:

• Verificar o estado do serviço com service <service>:status -ds nosync.
• Verificar o ficheiro de log adequado em /log quanto a novos erros.
• Validar a função afetada com um teste real.
• Verificar o Log Viewer se estiverem envolvidas regras de firewall, NAT, web, IPS ou VPN.
• Em clusters HA, verificar se o node ativo continua a trabalhar como esperado.
• Desativar debug caso tenha sido ativado antes ou durante o reinício.
• Remover liberações temporárias de SSH ou Device Access se foram definidas apenas para o caso de suporte.
• Em erros recorrentes, guardar logs e analisar a causa em vez de reiniciar serviços repetidamente.

Dependendo do serviço, outro teste funcional é adequado:

• IPsec / strongswan: Estado do túnel, Log Viewer, strongswan.log, acessibilidade de um host do outro lado
• DNS / dnsd: resolução de nomes interna e externa, DNS Request Routes, dnsd.log
• Routing / zebra: tabela de routing, Gateway-Monitoring, ping ou traceroute pelo caminho afetado
• WAF / Reverse Proxy: testar URL publicada externamente, reverseproxy.log, acessibilidade do backend
• WebAdmin / tomcat e apache: login, Dashboard, Log Viewer e tomcat.log
• DHCP / dhcpd: verificar atribuição de lease com cliente de teste e dhcpd.log

Quando um reboot é melhor

Um reboot completo é mais invasivo do que um reinício de serviço, mas pode tornar-se útil quando vários serviços centrais estão bloqueados, problemas de memória ou base de dados foram corrigidos, o Sophos Support o exige ou a firewall continua instável após reinícios direcionados.

A decisão não deve ser tomada por instinto. Um reinício de serviço é melhor quando um único módulo está claramente afetado e a firewall trabalha de resto de forma estável. Um reboot é mais adequado quando o estado é pouco claro a nível de sistema ou continua danificado após um reinício direcionado.

• Um único serviço está bloqueado: Sim, se serviço e impacto forem claros; Só se o reinício não ajudar
• Vários serviços mostram erros: Primeiro verificar logs e espaço em disco; Sim, se o estado geral do sistema for instável
• Janela de firmware ou hotfix em curso: Não como substituto de reinício planeado; Sim, se o processo de update o prevê
• Cluster HA está instável: Só após verificação de papéis e aprovação do suporte; Só com janela de manutenção e plano HA
• Espaço em disco ou base de dados foi limpo: Só para o serviço afetado; Sim, se Sophos Support o indicar como conclusão
• Acesso remoto é incerto: Com cuidado, o último acesso pode cair; Só com acesso local ou alternativo

Antes de um reboot, devem ser conhecidos backup, janela de manutenção, acesso ao site, comportamento HA e impactos em VPN, RED, Wireless, routing e serviços publicados. Em sites remotos, é necessário também um caminho de retorno caso a firewall não volte a ficar online corretamente após o reinício: contacto local, acesso out-of-band, par HA funcional ou processo de suporte claro.

Após o reboot, deve ser feita a mesma validação que após um reinício de serviço, mas mais ampla: estado HA, estado de licença, túneis VPN, gateways SD-WAN, logs centrais, WebAdmin, ligação ao Central e os serviços publicados mais importantes. Para temas de recovery, é também adequado Planear corretamente backup e restore da Sophos Firewall.

Checklist operacional

• Módulo afetado e nome do serviço identificados.
• Ficheiro de log adequado verificado antes do reinício.
• Impactos possíveis em utilizadores, VPN, routing ou sites avaliados.
• Se necessário, janela de manutenção ou contexto HA clarificado.
• Acesso SSH e verificação de host key preparados corretamente se a Advanced Shell for necessária.
• Serviço reiniciado de forma direcionada.
• Estado e ficheiro de log verificados após o reinício.
• Função validada com um teste real.
• Debug e acessos temporários revertidos após a análise.
• Erros recorrentes documentados e não escondidos por reinícios repetidos.

FAQ