Verificar a Sophos Firewall diariamente: checklist operacional

Uma Sophos Firewall pode continuar tecnicamente acessível e, ainda assim, apresentar sinais de alerta: uma ligação WAN oscila, a utilização do disco aumenta, um serviço comunica um erro ou acumulam-se logins administrativos sem êxito. Uma verificação operacional curta e repetível torna estas alterações visíveis antes de causarem uma interrupção prolongada ou um incidente de segurança.

Este procedimento trata do funcionamento atual. O Sophos Firewall Health Check, por outro lado, verifica se determinadas configurações cumprem as recomendações da Sophos e do CIS. As duas verificações complementam-se, mas não se substituem.

A verificação de dez minutos

Para a visão geral diária é suficiente um procedimento fixo:

1. No Control Center, anotar o modelo, a versão do firmware e a build, abrir as novas mensagens e clicar nos ícones de estado de serviços, WAN, interfaces e VPN.
2. Em Diagnostics > System graphs, comparar CPU, memória, load average, disco e interfaces importantes com a baseline habitual.
3. Verificar os dashboards de segurança e os relatórios utilizados no último período totalmente disponível quanto a novos eventos IPS, web, de aplicações, zero-day ou Active Threat Response.
4. Abrir o Log Viewer no canto superior direito, selecionar o módulo e o período e verificar logins administrativos sem êxito, origens invulgares e os serviços associados.
5. Em HA, considerar o nó que processou o tráfego e, no reporting central, a origem de dados esperada.
6. Documentar cada desvio relevante com hora, firmware, nó, origem, serviço afetado e passo seguinte.
7. Não reiniciar serviços, eliminar logs nem alargar regras devido a um único pico. Correlacionar primeiro a tendência, os logs e o funcionamento real.

Esta verificação curta não pretende provocar uma alteração de configuração todas as manhãs. O seu valor está em reconhecer cedo as mudanças e decidir claramente se é necessária observação, diagnóstico ou escalamento.

Quatro vistas, quatro afirmações diferentes

As vistas mais importantes não mostram o mesmo:

• Control Center: visão atual do sistema, serviços, WAN, interfaces, VPN, uptime e mensagens que exigem ação.
• System graphs: evolução temporal de CPU, memória, load average, disco, transferência WAN e contadores das interfaces.
• Reports: avaliação consolidada de um período concluído. Alguns widgets e dados dos relatórios não são atualizados em tempo real.
• Log Viewer: eventos individuais com hora, módulo, ação, informações de origem e destino e, conforme o tipo de log, Rule ID ou outros detalhes.

Um widget vermelho é um sinal, não um diagnóstico completo. Da mesma forma, um estado verde atual não prova que não tenha ocorrido um erro breve durante a noite. Apenas a combinação entre estado atual, evolução, relatório e evento individual oferece uma imagem fiável.

Verificar o estado e a disponibilidade do sistema

Ler primeiro o Control Center

No Control Center, a verificação começa pelas novas mensagens. A Sophos apresenta aí, entre outros, problemas de registo, licenciamento, reporting, WAN ou atualização. Algumas mensagens desaparecem automaticamente depois da correção e não podem simplesmente ser eliminadas manualmente. Por isso, cada mensagem relevante necessita de um responsável e de um passo seguinte rastreável.

Uma mensagem Registration aparece quando a Sophos Firewall não está registada. Uma mensagem Licenses aparece quando há módulos da firewall sem licença.

Alguns contadores dos widgets do Control Center são repostos a zero após um reinício da firewall. Por isso, uma contagem baixa após o reinício não prova que não tenham ocorrido eventos anteriormente. Para a interpretar, correlacionar o uptime com os logs conservados de forma duradoura para o período afetado, como exportações CSV ou logs centrais dentro do respetivo período de retenção. A consola de administração web não apresenta informações de temperatura.

Messages também mostra o tempo decorrido desde a criação de uma mensagem. Conforme o tipo ou a gravidade, este widget utiliza os indicadores Alert, Warning e Available firmware versions. Registar em conjunto o indicador, o tempo decorrido e o texto da mensagem; as contagens de Services e WAN/VPN descritas abaixo não se aplicam a Messages.

A cor deve ser sempre interpretada em conjunto com os detalhes. Em Services, Warning significa que pelo menos um serviço parou, enquanto Alert significa que pelo menos um serviço não conseguiu iniciar. Em WAN e VPN, Warning indica que até metade das ligações configuradas está down, e Alert que mais de metade está down. Estas contagens não têm em conta a importância para o negócio. Um único túnel principal em baixo pode, por isso, ser mais urgente do que várias ligações intencionalmente inativas. Clicar no ícone correspondente mostra os elementos afetados.

Em seguida, comparam-se os serviços, ligações WAN, interfaces e VPN efetivamente utilizados com o estado esperado. Uma interface vermelha não significa automaticamente uma falha: uma porta não utilizada sem endereço IP ou uma interface física parent de uma VLAN pode aparecer a vermelho como previsto. O que importa é o desvio em relação ao design documentado.

Se forem utilizados LAGs, em SFOS 23, abrir o ícone Interfaces e verificar também se há cabos desligados nos membros individuais dos LAGs. A ajuda do SFOS 23 menciona expressamente esta vista detalhada; a ajuda correspondente do SFOS 22 não o faz. Em termos operacionais, um agregado que continua acessível não comprova que todos os membros e, por conseguinte, a redundância e a capacidade previstas estejam disponíveis. Registar no ticket o membro afetado e o desvio em relação ao estado esperado.

Se forem utilizados túneis RED e Wireless APs, comparar os widgets de estado da ligação com o estado esperado: RED apresenta o número de túneis estabelecidos face aos configurados, e Wireless APs o número de pontos de acesso ativos face aos configurados. Os APs pendentes aparecem adicionalmente entre parênteses vermelhos e não devem ser contabilizados como APs ativos. RED abre a lista de túneis, e Wireless APs abre Wireless > Access points. Connected remote users contabiliza os utilizadores ligados através de SSL VPN e abre Current activities > Remote users; Live users, por sua vez, contabiliza todos os utilizadores atuais e abre Current activities > Live users. Estas contagens de utilizadores não substituem uma verificação da disponibilidade dos túneis RED ou dos APs.

Se estiver prevista a utilização de DNS Protection, verificar o respetivo estado de configuração no widget System. A ajuda do SFOS 22 indica cinco estados: Not subscribed significa que não existe licença; é necessário Xstream Protection. Not configured remete para a introdução dos endereços IP de DNS Protection. No caso de Unrecognized source, verificar o IP público da firewall e a sua associação a uma localização no Sophos Fusion. Active indica que DNS Protection está ativo; um ícone de informação assinala a falta de registo no Fusion. No caso de IP address conflict, verificar o IP introduzido na localização e encaminhar para o suporte da Sophos qualquer conflito que não seja possível resolver.

A ajuda do SFOS 23 indica Not subscribed, Not configured e Active e, quando falta a configuração, remete para Configure DNS servers; para o ícone de informação de Active, menciona o registo no Sophos Central. Isto não permite concluir que os dois estados adicionais documentados no SFOS 22 tenham sido removidos em tempo de execução. O procedimento de configuração e resolução de problemas adequado à versão é descrito em Configurar DNS Protection com Sophos Firewall: não aplicar sem alterações o procedimento de DNS tradicional/localização do SFOS 22 ao procedimento integrado do SFOS 23.

Para consultar eventos de DNS Protection no Log Viewer, selecionar o módulo System e filtrar por DNS Protection. Guardar no ticket a versão, o estado do widget e as linhas de registo relevantes. Esta verificação da configuração e dos eventos não substitui nem a verificação funcional da resolução de nomes e da eficácia da filtragem, nem os relatórios de DNS Protection; os relatórios gerais de segurança, por si só, não comprovam que DNS Protection esteja operacional.

O widget Messages deve ser tratado como uma lista de ações, não como um feed geral de eventos. Quando for solicitada a criação da Secure Storage Master Key, esta deve ser criada para dar proteção adicional a dados sensíveis, como palavras-passe. Uma mensagem de acesso WAN significa que WebAdmin (HTTPS) e CLI (SSH) estão acessíveis a partir da zona WAN: se a administração remota for necessária, deve utilizar-se uma VPN ou uma Local Service ACL Exception limitada a hosts ou redes de gestão específicos, em vez de manter acesso WAN amplo. Perante uma mensagem sobre o disco de relatórios, a utilização deve ser reduzida para um valor inferior ao limite mais baixo; ficar apenas abaixo do limite superior não basta. As mensagens associadas a um requisito desaparecem quando este é cumprido e não podem ser eliminadas manualmente.

Perante uma mensagem de falha de atualização em firewalls de software, virtuais e cloud, verificar primeiro se a firewall já foi reivindicada no Sophos Central (Claim). A reivindicação é um pré-requisito antes da atualização, não apenas uma medida após uma falha. A documentação do SFOS 22 chama ao portal «Sophos Fusion (previously Sophos Central)», enquanto a do SFOS 23 indica «Sophos Central»; o pré-requisito mantém-se. Registar o estado da reivindicação e a mensagem de falha no ticket antes de planear outra tentativa através do runbook de firmware.

Active threat response deve ser interpretado por feed e ação. MDR e Sophos X-Ops mostram o número de ameaças bloqueadas, NDR Essentials as ameaças monitorizadas e os feeds de terceiros tanto o estado de sincronização como as ameaças bloqueadas. Configure abre a configuração da proteção, Reports o relatório associado e More details expande o widget. A ação Reports não aparece nos modelos sem reporting local. Uma ameaça monitorizada não equivale a uma ameaça bloqueada, e um problema de sincronização de terceiros deve ser distinguido do número de ameaças.

O widget Reports é um atalho para um máximo de cinco relatórios críticos selecionados de acordo com os módulos subscritos, não uma lista completa de eventos em tempo real. A correspondência é:

• High-risk applications — Web Protection
• Objectionable websites — Web Protection
• Web users — Web Protection
• Intrusion attacks — Network Protection
• Web server protection — Web Server Protection
• Email usage — Email Protection
• Email protection — Email Protection
• Traffic dashboard — Web Protection ou Network Protection
• Security dashboard — Web Protection ou Network Protection

High-risk applications, Objectionable websites, Intrusion attacks, Web server protection e Email protection referem-se ao dia anterior; Web users ordena os dez utilizadores com mais bytes web transferidos no dia anterior. Email usage mostra os bytes de e-mail transferidos, enquanto Traffic dashboard e Security dashboard resumem as categorias de tráfego e a atividade recusada. A ausência de um mosaico pode, portanto, refletir a subscrição em vez de atividade nula. Clicar no nome abre o relatório e o ícone de download permite guardá-lo. Para os períodos e drill-downs separados dos sinais de endpoint, utilizador, Zero-day, TLS e sessão, consultar Como interpretar User & Device Insights.

Traffic insight resume o tráfego processado nas últimas 24 horas. Web activity mostra a tendência e os valores médio e máximo de bytes transferidos; Cloud applications apresenta as aplicações detetadas e os bytes de entrada e saída, mostrando ao passar o cursor os estados New, Sanctioned, Unsanctioned e Tolerated. Os restantes gráficos ordenam as cinco principais categorias de aplicações e web permitidas por bytes, as categorias de aplicações bloqueadas por hits e os hosts cujo acesso à rede foi recusado por motivos de estado de segurança. Clicar num gráfico cloud ou numa barra de categoria abre a página Cloud applications ou o relatório filtrado correspondente; este drill-down deve ser feito antes de tratar um pico ou uma entrada do top cinco como incidente.

Uma verificação diária inclui, no mínimo:

• serviços inesperadamente parados ou degradados;
• ligações WAN down ou que mudam repetidamente de estado;
• interfaces de produção com novos errors, drops ou collisions;
• ligações VPN importantes desligadas contra o plano operacional;
• um reinício inesperado ou um uptime invulgarmente curto;
• novas mensagens que ainda não têm responsável ou ticket.

Ler System graphs em relação a uma baseline

Em Diagnostics > System graphs, procuram-se padrões e não apenas picos isolados. CPU, memória e load average são avaliados juntamente com o número de cores, o tráfego e o período afetado. Um pico breve durante um backup, reporting ou atualização de padrões tem um significado diferente de uma carga permanentemente elevada com tráfego normal.

Em Disk Usage, interessa sobretudo a tendência. Uma utilização pontualmente elevada e um crescimento contínuo são problemas diferentes. Nas interfaces, traffic, errors, drops e collisions ajudam a distinguir a carga da firewall de um problema de ligação, duplex, cabo ou switch.

Para obter provas comparáveis, registar o tipo de gráfico e o período e utilizar o mesmo período no ticket. Os gráficos de interfaces só mostram um gráfico separado para VLANs na zona WAN. O SFOS agrega os dados das VLANs noutras zonas no gráfico da respetiva interface física parent. Por isso, não se deve esperar um gráfico LAN VLAN separado e sem anomalias quando o SFOS não o disponibiliza.

A explicação detalhada de load average, offloading, TLS Inspection e System graphs encontra-se em Interpretar corretamente o desempenho da Sophos Firewall. Para limites de armazenamento e reporting on-box, consulte Verificar o armazenamento e os relatórios da Sophos Firewall.

⚠️ Um único valor elevado ainda não justifica o reinício de um serviço. Primeiro, a hora, a duração, o padrão recorrente, o tráfego afetado e os logs devem ser correlacionados. Antes de um reinício, guardam-se os logs relevantes e, num incidente, um CTR.

Verificar eventos de segurança e logins administrativos

Ler os relatórios à procura de alterações

A revisão diária de segurança concentra-se em padrões novos ou claramente alterados. Dependendo das funções ativas, as seguintes áreas são particularmente relevantes:

• Reports > Dashboards > Security dashboard para a visão consolidada;
• Reports > Network & threats > Intrusion attacks para eventos IPS;
• Reports > Network & threats > Active threat response para IoCs bloqueados;
• Reports > Applications & web para utilização web e de aplicações arriscada, indesejada ou bloqueada;
• relatórios zero-day, Security Heartbeat ou Wireless se estas funções forem utilizadas em produção.

No relatório selecionado, definir primeiro o intervalo de datas e depois clicar em Generate. Filter permite limitar os resultados à origem, ação ou regra relevante. Os formatos de download disponíveis preservam os dados apresentados como prova no ticket. Registar o período e o fuso horário com a exportação, para que uma comparação posterior não utilize duas janelas diferentes.

Nem todos os eventos são incidentes. São decisivos a origem, o destino, o utilizador, a regra, a ação, a frequência e a relação temporal. Um único acesso proveniente de um país não justifica o bloqueio generalizado desse país. Ataques repetidos contra um serviço exposto ou novo tráfego de alto risco permitido merecem, pelo contrário, uma investigação concreta.

Para uma avaliação segura das origens e dos países, consulte Bloquear endereços IP e países maliciosos. Se um pacote tiver sido descartado, Analisar pacotes descartados na Sophos Firewall conduz do Log Viewer e da Rule ID até à causa real do drop.

Avaliar logins administrativos sem êxito

Os logins administrativos sem êxito são verificados por hora, IP de origem, serviço de destino, nome de utilizador e repetição. Um erro de digitação proveniente da rede de gestão deve ser tratado de forma diferente de tentativas distribuídas a partir da Internet ou de logins repetidos numa conta desativada.

O Log Viewer abre-se no canto superior direito de qualquer página WebAdmin, numa nova janela de ecrã inteiro. Selecionar o módulo adequado, definir o período com Timer filter e especificar campo, condição e valor com Add filter. A pesquisa de texto livre é útil para endereços IP, nomes de utilizador, portas ou regras. Antes de efetuar outras alterações, preservar as entradas filtradas em CSV com Export; Reset remove depois todos os filtros. A ausência de uma entrada de sessão nem sempre prova que não houve tráfego, porque as regras de firewall normalmente só registam sessões quando a firewall recebe o evento de destruição da ligação.

Em tentativas suspeitas, verificam-se primeiro a exposição e a identidade:

1. Está previsto que WebAdmin, SSH, User Portal ou VPN Portal estejam acessíveis a partir da zona afetada?
2. A origem provém de uma rede de gestão autorizada ou de uma Local Service ACL Exception específica?
3. O MFA está ativo para o acesso administrativo afetado?
4. CAPTCHA, Session Timeout e Block login funcionam conforme planeado?
5. Existem alterações de configuração simultâneas ou logins bem-sucedidos da mesma conta?

O acesso de rede é verificado em Device Access e Local Service ACL na Sophos Firewall. Para contas, perfis e offboarding, consulte Administradores locais e perfis de acesso ao dispositivo, e para o segundo fator Ativar MFA na Sophos Firewall.

⚠️ Block login pode bloquear o IP de origem para vários serviços após tentativas sem êxito. Não tornar os valores agressivamente mais restritivos durante um incidente enquanto não existir um caminho alternativo e testado de administração e recuperação.

Compreender os limites de HA, reporting e modelos

Num cluster HA, cada nó armazena apenas os logs e relatórios do tráfego que ele próprio processou. Para um evento, identifica-se por isso o nó que estava ativo ou a processar o tráfego nesse momento. Um relatório local vazio num nó não prova que não tenha ocorrido qualquer evento no cluster.

O Central Firewall Reporting no Sophos Fusion (anteriormente Sophos Central) pode fornecer uma vista consolidada e uma retenção mais longa. No entanto, as vistas local e central não são tratadas como fontes idênticas em tempo real. Ativar e operar o Central Firewall Reporting explica a seleção, a chegada e a retenção dos logs.

Limites adicionais:

• Os relatórios do Control Center são atualizados periodicamente e não constituem uma vista de eventos em tempo real.
• Após uma atualização do SFOS 20.0 ou anterior para o SFOS 21.0 ou posterior, o widget Reports pode apresentar zero ou um valor inferior até à atualização seguinte de 24 horas, porque a Sophos guarda os relatórios anteriores e posteriores à atualização em bases de dados separadas.
• XGS 87/87w e XGS 88/88w não suportam relatórios on-appliance. Por isso, logs centrais, SIEM e monitorização são mais importantes nestes modelos.
• A ausência de dados pode dever-se a logging, período do relatório, licença, retenção, disk watermark ou ao nó HA errado. Não prova automaticamente que não existia tráfego.

Comparar a build do firmware com problemas conhecidos

Quando a observação não corresponde ao estado esperado, siga o runbook da Avanet para decisões de firmware. Compare a build exata instalada e o sintoma concreto, não apenas a versão principal. Registe no ticket o ID do problema, as builds afetadas e corrigidas e qualquer workaround, e correlacione o resultado com os detalhes do Control Center, os System graphs, os logs e um teste funcional antes de alterar o sistema. Exemplos para a verificação diária:

• NC-181971: no SFOS 22.0 GA e posteriores, o serviço IPS pode, em raras circunstâncias, entrar no estado Dead e não voltar a iniciar. A Sophos não publica uma solução self-service e indica o contacto com o Suporte para aplicar o workaround.
• NC-181748: no SFOS 22.0 GA Build 411, não são gerados e-mails Web Instant Alert para categorias bloqueadas por políticas web. Nesta build, a ausência de um alerta não prova que não ocorreu um bloqueio.
• NC-180066, NC-180110, NC-178745 e NC-172912: as notas de versão enumeram no SFOS 22.0 MR2 Build 546 correções para serviços antivírus parados, modo failsafe causado pelo daemon de logging, reinícios de HA por falta de memória e System graphs intermitentes. Se o sintoma corresponder numa build anterior, registar no ticket o ID e o caminho de atualização. Atualizar o firmware apenas numa janela de manutenção aprovada, com backup e caminho de rollback.

Os problemas conhecidos podem mudar independentemente deste artigo. Antes do escalamento, voltar a abrir a entrada e preservar o seu estado atual. Um ID correspondente pode explicar um sintoma, mas não substitui a avaliação do impacto nem a verificação funcional.

Documentar e escalar desvios

Uma verificação diária só termina quando os desvios relevantes têm um passo seguinte. Para um ticket ou diário operacional, geralmente são suficientes estes campos:

• data, hora e fuso horário;
• nome da firewall, modelo, versão SFOS e build;
• em HA: nó, função e última mudança de estado;
• função, zona, interface, VPN ou regra afetada;
• estado observado e estado esperado;
• captura de ecrã, período do relatório, filtro de logs ou Rule ID;
• impacto nos utilizadores ou serviços;
• responsável, prioridade, próxima verificação e caminho de escalamento.

Antes de qualquer ação que altere o estado, preservar o estado detalhado do Control Center, o gráfico com o período visível e as linhas de log filtradas ou a exportação CSV. Para um caso de suporte, aceder a Diagnostics > Tools > Consolidated troubleshooting report e criar um CTR com System snapshot e os ficheiros de log necessários: introduzir o motivo, selecionar Generate e descarregar o ficheiro encriptado quando estiver concluído. O modo de debug e a purga de logs não fazem parte da verificação diária: alteram o estado de diagnóstico ou destroem provas e só devem ser usados de forma direcionada sob orientação do Suporte.

O escalamento imediato é adequado se uma ligação WAN de produção ou um caminho VPN crítico falhar inesperadamente, um serviço de proteção estiver parado, a utilização do disco continuar a crescer, a carga permanecer elevada, ataques administrativos repetidos coincidirem com um login bem-sucedido ou um novo evento de segurança corresponder a tráfego malicioso permitido.

A observação é mais adequada para um pico breve e explicável, uma interface intencionalmente não utilizada ou um evento conhecido que já tenha um responsável documentado e uma verificação funcional estável.

Escolher uma frequência de verificação útil

A Sophos não prescreve uma frequência diária universal para todas as vistas. Assim, a frequência depende do risco, do horário operacional e da monitorização existente:

• Diariamente ou por turno: novas mensagens, serviços parados, WAN/VPN/HA, uptime, eventos críticos de segurança e logins administrativos sem êxito.
• Semanalmente: tendências dos gráficos, erros das interfaces, crescimento do disco, padrões dos relatórios, origens recorrentes e tickets abertos.
• Após alterações, atualizações ou failover: voltar a validar a função afetada, os logs, os relatórios, o caminho dos alertas e o tráfego real.
• Regularmente fora da verificação curta: Health Check, revisão de regras, teste de restauro de backups, validade de licenças e certificados e planeamento de capacidade.

As notificações por e-mail ou a monitorização reduzem o tempo de resposta, mas não substituem a revisão. Um caminho de alertas só é fiável depois de testados o transporte, a seleção de eventos, o destinatário e a reação. O procedimento completo encontra-se em Configurar e testar notificações por e-mail da Sophos Firewall.

Checklist operacional

• Verificar o Control Center quanto a novas mensagens e mudanças de estado inesperadas.
• Comparar serviços, ligações WAN de produção, interfaces, VPN e uptime com o estado esperado.
• Ler CPU, memória, load average, disco e contadores importantes das interfaces em relação à baseline.
• Verificar os relatórios de segurança do último período totalmente disponível.
• Definir o período do relatório, selecionar Generate e exportar resultados relevantes quando necessário.
• No Log Viewer, selecionar o módulo, Timer filter e Add filter; correlacionar origem, destino, utilizador, ação e Rule ID e preservar as linhas relevantes em CSV.
• Avaliar logins administrativos sem êxito por origem, serviço e repetição.
• Em HA, considerar o nó que processou o tráfego e os logs locais de cada nó.
• Comparar a build e o sintoma correspondente com as notas de versão e os problemas conhecidos atuais; registar o ID no ticket.
• Não provocar reinícios, eliminações de logs ou alterações amplas de regras sem preservar provas e dispor de um caminho de recuperação.
• Documentar cada desvio relevante com responsável, prioridade e passo seguinte.
• Após uma correção, voltar a testar não apenas o estado, mas também o funcionamento real.

FAQ