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:
- No Control Center, verificar novas mensagens e o estado dos serviços, WAN, interfaces, VPN e uptime.
- Em Diagnostics > System graphs, comparar CPU, memória, load average, disco e interfaces importantes com a baseline habitual.
- 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.
- No Log Viewer, verificar logins administrativos sem êxito, origens invulgares e os serviços associados.
- Em HA, considerar o nó que processou o tráfego e, no reporting central, a origem de dados esperada.
- Documentar cada desvio relevante com hora, firmware, nó, origem, serviço afetado e passo seguinte.
- 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.
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.
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.
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.
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.
Em tentativas suspeitas, verificam-se primeiro a exposição e a identidade:
- Está previsto que WebAdmin, SSH, User Portal ou VPN Portal estejam acessíveis a partir da zona afetada?
- A origem provém de uma rede de gestão autorizada ou de uma Local Service ACL Exception específica?
- O MFA está ativo para o acesso administrativo afetado?
- CAPTCHA, Session Timeout e Block login funcionam conforme planeado?
- 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 Sophos Central Firewall Reporting 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 de uma versão anterior ao SFOS 21, os widgets de relatórios podem inicialmente mostrar poucos ou nenhuns dados até que a nova base de dados de relatórios seja atualizada.
- 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.
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.
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.
- Correlacionar eventos suspeitos no Log Viewer com origem, destino, utilizador, ação e Rule ID.
- 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ó.
- 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.