Sophos Firewall Hardening: melhores práticas para uma configuração segura

O hardening do Sophos Firewall significa reduzir conscientemente a superfície de ataque desnecessária em torno da própria firewall e dos serviços publicados através dela. Não é uma única definição mágica, mas um processo operacional repetível: limitar o acesso administrativo, impor MFA, manter o firmware atualizado, rever regras, ativar funções de proteção e analisar logs.

Este artigo é o ponto de entrada central. Não substitui os guias detalhados, mas organiza as melhores práticas mais importantes e liga aos artigos adequados da Avanet KB.

O que verificar primeiro

No hardening, a ordem importa. Uma política IPS perfeitamente ajustada ajuda pouco se o WebAdmin estiver acessível globalmente via WAN ou se um portal VPN antigo estiver exposto sem MFA.

Verificações imediatas mais importantes:

• O WebAdmin está acessível a partir da zona WAN?
• SSH só é permitido a partir de redes de gestão confiáveis?
• MFA está ativo para administradores, VPN Portal e Remote Access?
• Firmware, hotfixes e pattern updates estão atualizados?
• Existem acessos DNAT, WAF ou VPN que já não são necessários?
• Serviços publicados têm IPS, WAF, Threat Feeds, logging e responsabilidade clara?
• Os logs de segurança são conservados independentemente da firewall e monitorizados, com responsável e prazo de conservação definidos?
• Existe um backup atual e testado, incluindo o Secure Storage Master Key?

Proteger o acesso administrativo

A área de hardening mais importante é o acesso à própria firewall. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal e serviços locais não são regras de firewall normais, mas serviços locais da firewall. Devem ser limitados conscientemente por Device Access e Local Service ACL.

Device Access e Local Service ACL

Em Administration > Device access, define-se por zona quais serviços locais estão acessíveis. Para a zona WAN, só deve estar ativo o que é realmente necessário. Acesso admin e SSH normalmente não devem ser expostos amplamente à Internet.

Se a administração remota for necessária, estas variantes são mais limpas:

• Gestão através do Sophos Fusion (anteriormente Sophos Central).
• Acesso através de uma rede de gestão dedicada.
• Acesso através de VPN ou ZTNA.
• Local Service ACL Exception Rules restritas a endereços IP de origem administrativos fixos.

A implementação concreta está descrita em Proteger acesso ao Sophos Firewall: configurar Device Access corretamente. Se SSH for necessário, Ligar ao Sophos Firewall via SSH também ajuda.

Ao criar uma exceção WAN, é preciso evitar perder o próprio acesso. Primeiro, iniciar sessão e testar um caminho de recuperação independente através da consola, da LAN de gestão, de uma VPN administrativa ou do Sophos Fusion. Depois, em Administration > Device access, clicar em Add sob Local service ACL exception rule. Um exemplo adaptável é WAN-Admin-203.0.113.10 com Rule position Top, IP version IPv4, Source zone WAN, o IP público fixo do administrador como Source network / host, a interface WAN da firewall como Destination host, Services HTTPS e SSH apenas se necessário, e Action Accept. 203.0.113.10 é um endereço de documentação e deve ser substituído pelo IP administrativo fixo real. Manter a sessão existente aberta, testar o acesso numa segunda sessão a partir dessa origem e só então remover a permissão WAN mais ampla para HTTPS ou SSH em Local service ACL. Se o teste falhar, o acesso anterior permanece inalterado; corrigir a exceção antes de alterar a permissão da zona.

MFA, funções e segurança de login

VPN Portal não serve apenas para downloads: Os clientes VPN e as configurações alteradas são distribuídos através do VPN Portal. O SSO também exige manter a acessibilidade WAN necessária: Microsoft Entra ID SSO no SFOS 22 e OpenID Connect SSO no SFOS 23. Não fechar um caminho SSO ainda necessário após os downloads. User Portal permanece desativado na WAN; o acesso remoto faz-se por VPN. Proteger VPN Portal com ACL adequadas e tão restritas quanto possível, um certificado válido e monitorização de ataques de força bruta. Para OIDC, impor MFA no IdP, não através de OTP adicional da firewall. Os passos OTP locais abaixo aplicam-se à autenticação clássica, não a OIDC. A configuração está em Entra VPN SSO e Google Workspace OIDC. Após alterações de ACL ou autenticação, testar um novo início de sessão e o túnel VPN real a partir da rede externa prevista; se falhar, verificar ACL, certificado e associação de redirecionamentos em vez de abrir amplamente a WAN.

MFA deve ser obrigatório para administradores e utilizadores Remote Access. Contas admin locais, VPN Portal, User Portal e Remote Access VPN são particularmente críticos. MFA é apenas uma parte do hardening de login. Contas admin nominais, funções claras, políticas de password fortes, tentativas de login limitadas e session timeouts curtos são igualmente importantes.

Manter CAPTCHA ativado por predefinição, sobretudo nas páginas de início de sessão acessíveis pela WAN ou por redes não confiáveis. Não substitui MFA nem Block login; um CAPTCHA incorreto não conta como início de sessão falhado para esse bloqueio. Alterar e repor CAPTCHA de forma seletiva descreve uma exceção VPN justificada e aprovada para WebAdmin ou User Portal. Registar primeiro o âmbito, o alvo e o valor inicial, verificar acesso e MFA e depois confirmar com show e um novo início de sessão pelo percurso VPN previsto. A reversão repõe exatamente o valor registado; o regresso deliberado à predefinição ativada usa enable. A desativação global não é hardening nem uma solução para a limitação do SFOS 22.0 GA descrita nesse guia. Os comandos de exceção não afetam VPN Portal ou SPX Portal.

No SFOS 22, a configuração de utilizadores está em Authentication > Multi-factor authentication (MFA). Em One-time password (OTP), selecionar All users ou Specific users and groups, ativar Generate OTP token with next sign-in para tokens baseados em aplicações e marcar cada serviço realmente utilizado em Require MFA for. A conta integrada admin é protegida separadamente em Administration > Device access > MFA for default admin. Antes de impor MFA, pelo menos uma conta de administrador nominal deve ter registado o seu token; verificar a emissão em Issued tokens. Depois, testar um novo login mantendo uma sessão admin existente aberta como caminho de recuperação.

A configuração prática está em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Remote Access. A forma como contas locais pessoais, perfis Device Access, origens de login e offboarding funcionam em conjunto é explicada em Configurar administradores e perfis Sophos Firewall em segurança. Para cenários WAF com login de utilizador, Proteger Sophos Firewall WAF com MFA é adequado.

Verificar a autorização de VPN de acesso remoto

Conceder acesso VPN apenas aos utilizadores e grupos que dele precisam e somente aos recursos necessários. Não selecionar para este efeito o grupo de fallback predefinido Open group. Os utilizadores sem associação a um grupo adequado podem ficar nesse grupo, por exemplo durante a sincronização AD. Rever regularmente os membros e atribuí-los aos grupos corretos. Este grupo predefinido não é uma regra firewall de fallback nem o grupo de fallback IdP deliberadamente restrito do guia SSO ligado. A associação específica do fornecedor continua descrita nesse guia. Para a aceitação, testar um utilizador autorizado, um de fallback/não atribuído e um recurso negado: só deve funcionar o acesso previsto. Se um teste tiver êxito inesperadamente, corrigir associações de grupos e permissões VPN/firewall e repetir o teste.

Firmware, hotfixes e recovery

Uma firewall é um sistema de borda. Atualizações atrasadas não são um detalhe menor, mas uma janela real de ataque. Ao mesmo tempo, atualizações não devem ser feitas às cegas, porque sites remotos, clusters HA, VPNs e regras NAT produtivas podem ser afetados.

Tornar atualizações planeáveis

Atualizações de firmware devem ser preparadas com backup, janela de manutenção, revisão de release notes, planeamento HA e critérios de rollback. Verificar regularmente as maintenance releases disponíveis e instalá-las atempadamente após aprovação. Nas versões atuais do SFOS 22, a página WebAdmin Backup & Firmware > Firmware já não mostra uma secção Hotfix separada. A função hotfix continua a existir: a Sophos instala hotfixes automaticamente por padrão e recomenda não alterar esta configuração. Se for necessário verificar o estado, usar system hotfix show na Device Console. Hotfixes não substituem um processo regular de update. O processo está descrito em Sophos Firewall firmware update: preparação e melhores práticas.

A página mantém no máximo duas versões de firmware. Um rollback inicia a versão anterior com a respetiva configuração anterior; as alterações efetuadas desde a mudança de versão são perdidas. Desde o SFOS 19.0 MR1, mudar de firmware após três atualizações gratuitas requer Enhanced Support ou Enhanced Plus; os hotfixes não requerem esta subscrição de suporte. Por isso, verificar o firmware esperado, a acessibilidade administrativa, as VPNs e as publicações críticas antes de fazer mais alterações de configuração após a atualização.

Para saltos maiores de versão, verificar também caminho de upgrade, licença, plataforma e limitações conhecidas. Verificar Sophos Firewall antes do upgrade SFOS 22 é adequado.

Verificar backup e restore

Hardening não termina na prevenção. Uma firewall endurecida também tem de ser recuperável. Isto inclui um backup atual, a password do backup, o Secure Storage Master Key, um caminho de acesso documentado após restore e um teste de aceitação.

Os detalhes estão em Criar ou restaurar backup do Sophos Firewall. Um pacote de recovery completo é obrigatório especialmente antes de firmware updates, migrações, reimage e substituição de hardware.

Uma migração de conformidade especial é o modo FIPS 140-3 na Sophos Firewall: A ativação executa um factory reset e exige uma reconstrução totalmente planeada com definições VPN e de certificados conformes com FIPS.

Reduzir a superfície de ataque nas regras

Muitos riscos não vêm de ataques exóticos, mas de regras demasiado amplas, exceções antigas e serviços publicados que já não têm um responsável claro.

NAT, WAF e serviços publicados

Cada serviço publicado por DNAT ou WAF é uma entrada aberta deliberadamente. Pode ser necessário, mas tem de ser planeado de forma restrita: source, destination, service, ordem NAT, regra firewall, política IPS/WAF, logging, teste e owner pertencem juntos.

Não publicar diretamente na Internet serviços RDP internos nem acessos administrativos. VPN ou ZTNA é o percurso preferido para acesso remoto a sistemas internos e administração remota. Os Threat Feeds não justificam a exposição pública. Dispositivos IoT sem uma arquitetura de proxy na nuvem que exigem acesso NAT de entrada direto precisam de isolamento, substituição ou desativação planeados, não de exposição WAN permanente. Um proxy na nuvem também não garante, por si só, a segurança. Antes de uma desativação aprovada, esclarecer com o responsável dependências, consequências operacionais e a continuidade de serviço necessária.

Numa revisão concreta, inventariar uma publicação RDP existente e um mapeamento NAT de IoT: host de destino, serviço, origens permitidas, IDs das regras firewall/NAT, responsável e necessidade real de acesso remoto. Planear a migração para VPN/ZTNA ou a retirada aprovada. Uma publicação existente inevitável continua apenas como exceção transitória explicitamente documentada e restrita, com política IPS adequada, correções atuais, logging, responsável e data de expiração; não equivale a VPN/ZTNA. Após a migração, testar novas ligações permitidas e acessos externos deliberadamente negados: o serviço necessário deve funcionar pelo percurso previsto e a acessibilidade pública indesejada deve desaparecer. Em caso de falha, verificar primeiro regras, NAT, routing e percurso substituto em vez de reabrir amplamente a WAN.

Para servidores publicados, ajudam Publicar servidor com DNAT no Sophos Firewall e Compreender NAT no Sophos Firewall. Quando se publicam servidores web, Sophos Firewall WAF: publicar servidores web em segurança é a melhor base.

Regras firewall e segmentação

Regras com Any em source, destination ou service não estão automaticamente erradas, mas precisam sempre de explicação. Para hardening, estas perguntas são importantes:

• A regra ainda é necessária?
• Logging está ativo?
• Existe source ou destination mais clara?
• A regra está corretamente posicionada antes de regras mais amplas?
• Redes admin, servidor, cliente, IoT, guest e backup estão bem separadas?

As bases estão em Compreender e configurar regras Sophos Firewall em segurança. Para testar uma regra concreta, Testar regras Sophos Firewall corretamente é adequado.

DMZ em vez da LAN principal: Os servidores acessíveis pela Internet devem estar num segmento separado e numa zona DMZ. Verificar a associação real em Network > Zones e Network > Interfaces; um nome de VLAN ou zona não impõe isolamento. Em Rules and policies > Firewall rules, negar DMZ para LAN por predefinição, com apenas exceções explicitamente necessárias e restritas. Um exemplo adaptável permite WAN para servidor web DMZ apenas por HTTPS e rede de gestão para DMZ apenas para o serviço administrativo aprovado, sem acesso geral da DMZ à LAN dos clientes. Substituir hosts e serviços pelos objetos próprios aprovados. Planear zonas e interfaces, secção Definir as direções de acesso antes das regras, explica o modelo. Testar o acesso permitido à aplicação e ligações DMZ para LAN negadas com novos fluxos, Rule ID esperado e Packet Capture quando necessário. Perante acesso inesperado, verificar primeiro ordem, zonas, objetos e permissões mais amplas. Antes de introduzir regras de bloqueio web em produção, respeitar a ressalva HTTP/HTTPS Drop por resolver em Action e logging no artigo das regras; não se promete aqui um bloqueio web universal.

Internet apenas para utilizadores LAN autenticados: Ativar Match known users na regra de clientes prevista e selecionar utilizadores/grupos autorizados após estabelecer uma associação fiável entre utilizador e tráfego. A secção Match known users explica autenticação e requisitos. Servidores, IoT e outro tráfego sem início de sessão precisam de regras separadas e restritas; a associação IP, por si só, não é autenticação. Nenhuma regra ampla de fallback deve permitir o mesmo tráfego de utilizadores sem verificar a identidade. Testar um utilizador autorizado e outro desconhecido/não autorizado, confirmando utilizador, grupo, Rule ID e acesso real face ao pretendido. Perante diferenças, verificar associação, ordem e fallback em vez de retirar o critério de utilizador.

Configurar Security Heartbeat conscientemente: O registo de gestão, por si só, não isola endpoints comprometidos. Synchronized Security Heartbeat explica os requisitos: Network Protection, Sophos Endpoint gerido com licença, a mesma conta de gestão na nuvem e Heartbeat ativado. Definir Minimum source HB permitted e, quando adequado para destinos internos, Minimum destination HB permitted nas regras afetadas; não usar Heartbeat de destino para WAN. Green permite apenas Green, Yellow permite Green ou Yellow e No restriction também permite Red e dispositivos sem Heartbeat. Verificar expressamente as opções separadas Block clients with no heartbeat e Block request to destination with no heartbeat: dispositivos que nunca enviaram Heartbeat são bloqueados apenas quando ambas estão ativadas. Dispositivos sem Sophos Endpoint e Web Exceptions que ignoram Policy checks impedem uma garantia geral de isolamento. Planear um piloto aprovado com casos definidos de estado/ausência de Heartbeat, novas ligações e logs; não provocar uma infeção em produção como teste. Se faltar a restrição esperada, verificar correspondência da regra, requisitos, estado e exceções e reverter apenas a última alteração. Estas verificações são passos de aceitação para o ambiente próprio, não testes realizados aqui num appliance.

Ativar funções de proteção conscientemente

Funções de proteção só ajudam quando combinam com a regra, o tráfego e o processo operacional. Ativadas às cegas, geram falsos positivos, problemas de performance ou casos de suporte. Desativadas, deixam superfície de ataque desnecessária aberta.

IPS, Spoof Protection e DoS

IPS deve ser usado em tráfego de entrada não confiável e em transições internas relevantes. São importantes políticas IPS adequadas, logging, processo de falsos positivos e visão de performance. A implementação está em Configurar e testar Sophos Firewall IPS em segurança.

Spoof Protection e DoS Settings reduzem fontes não plausíveis e padrões simples de flooding. Devem ser testados com cuidado, especialmente com VoIP, VPN, carga elevada de pacotes ou designs especiais de routing. O artigo adequado é Verificar Sophos Firewall Spoof Protection e DoS Settings.

Threat Feeds para WAF e DNAT

Os Threat Feeds só complementam a proteção num módulo e percurso de tráfego estabelecidos. Desde SFOS 22 está documentada a correspondência do IPv4 de origem do tráfego de entrada encaminhado DNAT/WAF com MDR, NDR e Third-Party Threat Feeds. Para serviços locais como VPN Portal, a proteção adicional estabelecida é a correspondência do IPv4 de origem com Third-Party Feeds suportados; este percurso não passa por uma regra firewall de trânsito. Os indicadores de domínio/URL referem-se a correspondências adequadas do destino de saída, não ao IP de origem de um início de sessão de entrada. O percurso DNS/IPS/Application Classification ou web/inspeção TLS deve ser adequado; os caminhos URL HTTPS completos exigem desencriptação. As origens IPv6 não são abrangidas por esta proteção.

Limite X-Ops por resolver: O texto ATR e a matriz de tráfego SVG contradizem-se quanto a certas direções de correspondência X-Ops, sobretudo destino e origem local do tráfego de saída. Não transpor afirmações sobre MDR, NDR ou Third-Party Feeds para Sophos X-Ops, incluindo DNAT/WAF ou portais locais. Até haver esclarecimento fiável, não depender dos efeitos contestados: ACL restritivas, regras firewall/WAF, correções e MFA continuam necessárias independentemente do feed. Verificar módulo, direção, logs e efeito real apenas em testes autorizados e controlados. MDR Threat Feeds e o guia NDR ligado abaixo contextualizam este limite.

Monitor deteta e regista correspondências, mas não bloqueia; Block deve estar configurado para o percurso verificado. Uma correspondência, por si só, não prova bloqueio nem registo completo. Verificar o log ATR/firewall/WAF relevante juntamente com a ligação real; allowlist, tratamento de falsos positivos e responsabilidade continuam necessários. Os exemplos seguintes só se aplicam dentro destes limites de módulo e percurso.

São especialmente úteis para:

• servidores web públicos atrás de WAF ou DNAT,
• exceções transitórias RDP, SSH ou admin explicitamente aprovadas e limitadas no tempo durante a migração para VPN/ZTNA; apenas como proteção adicional no módulo/percurso estabelecido, não como recomendação de exposição pública,
• acessos VPN e portais com muito ruído da Internet,
• ambientes onde bloqueio por país é demasiado grosseiro,
• clientes que querem usar feeds de terceiros curados além do Sophos X-Ops.

A operação é decisiva: qualidade do feed, ação Monitor ou Block, allowlist, falsos positivos, logging e responsabilidade devem estar claros. A configuração está descrita em Configurar e operar Sophos Firewall Threat Feeds em segurança. Para feeds curados, Cybora pode ser um componente útil, especialmente quando serviços publicados devem ser protegidos de forma consistente contra fontes maliciosas conhecidas.

Web, DNS, TLS e Zero-Day Protection

Web Protection, DNS Protection, TLS Inspection e Zero-Day Protection aumentam visibilidade e bloqueio, mas exigem planeamento limpo. TLS Inspection não deve começar como projeto tudo-ou-nada. DNS Protection deve corresponder aos caminhos DNS usados. Zero-Day Protection só ajuda quando tipos de ficheiro e políticas relevantes estão bem integrados.

Artigos detalhados adequados são Criar Sophos Firewall Web Protection com Web Policies, Configurar Sophos DNS Protection com Sophos Firewall, Introduzir Sophos Firewall TLS Inspection corretamente e Compreender e operar Sophos Firewall Zero-Day Protection.

Deteção, logging e review

Hardening não é uma tarefa única. Regras, utilizadores, portais, exceções NAT e versões de firmware mudam. Por isso são necessárias revisões regulares e logs disponíveis antes de um incidente.

Health Check como ponto de partida

O Sophos Firewall Health Check é um bom ponto de partida porque torna visíveis configurações arriscadas. Findings não devem ser aplicados às cegas, mas avaliados por risco, impacto operacional e arquitetura local.

No SFOS 22, abrir o widget Firewall health check no Control Center ou ir a Monitor & analyze > Firewall health check. Os dados são atualizados quando uma configuração monitorizada muda. É importante saber que um finding pode ser marcado manualmente como compliant sem corrigir a sua causa. A validação deve, portanto, confirmar o requisito da policy, e não apenas o estado apresentado.

Bons momentos para um Health Check:

• após o setup inicial,
• após migrações,
• antes e depois de firmware upgrades,
• após grandes alterações de regras,
• antes de auditorias,
• trimestralmente em operação.

Avaliar separadamente a telemetria e o Sophos Assistant

Em Administration > Admin and user settings, Sophos Adaptive Learning controla os dados de utilização e de ameaças que a firewall envia para a Sophos. Isto inclui aplicações não classificadas e dados sobre alertas IPS, vírus detetados, spam e deteções do Active Threat Response. Além disso, o envio básico de dados de configuração e utilização está ativado por predefinição: o dispositivo envia periodicamente por HTTPS dados de configuração, funcionalidades, erros e utilização de recursos. A Sophos afirma que não recolhe informações específicas ou personalizadas dos utilizadores. Ainda assim, a decisão deve ser documentada conscientemente de acordo com os requisitos de privacidade e o modelo operacional, em vez de tratar a opção como uma função de proteção do tráfego local.

Turn on Sophos Assistant, por outro lado, afeta apenas textos de ajuda, smart tips e guias de configuração no WebAdmin. Depois de alterar a opção é necessário terminar a sessão e voltar a iniciá-la. Desativar o assistente não reduz a superfície de ataque da rede nem interrompe automaticamente a telemetria; as duas definições devem ser avaliadas separadamente. A utilização, a verificação das fontes e os limites dos procedimentos guiados são explicados em Utilizar o Sophos Assistant em segurança.

Logging, alertas e SIEM

Regras firewall sem logging são muitas vezes inúteis para troubleshooting e incident response. A base documentada é o reporting central no Sophos Fusion (anteriormente Sophos Central) mais uma solução SIEM escolhida. Definir classes de eventos, destinatários, responsável, prazo de conservação e monitorização com procedimento de resposta. Documentar explicitamente qualquer exceção arquitetural: deve oferecer um percurso equivalente, conservado independentemente da firewall e monitorizado; nem todas as arquiteturas precisam de destinos duplicados. A revisão regular do Log Viewer local, por si só, não basta. MDR, XDR e NDR não são arquivos de logs intercambiáveis. Com um evento de teste autorizado e inofensivo, verificar a entrega a cada destino previsto, a pesquisa nos logs conservados e o percurso de monitorização/alerta. Se a entrega falhar, corrigir seleção de eventos, conectividade e destinatários e repetir o teste. Verificar também conservação e permissões no destino.

Além disso, selecionar os eventos de sistema necessários para e-mail ou SNMP em System services > Notification list. Configurar primeiro o destino de e-mail em Administration > Notification settings, ou o agente SNMP e a comunidade ou o utilizador em Administration > SNMP. Após Save, um evento controlado e inofensivo deve chegar ao destinatário previsto; caso contrário, verificar primeiro o destino de e-mail ou SNMP, a conectividade e a classe de evento selecionada.

A configuração técnica de Syslog está descrita em Enviar Sophos Firewall Syslog em segurança para SIEM. Para relatórios centrais, Ativar e operar Sophos Firewall Central Reporting é adequado. Se NDR e Active Threat Response forem relevantes, Operar Sophos Firewall NDR e Active Threat Response ajuda.

Validar alterações e reverter em segurança

Aplicar o hardening em passos pequenos e rastreáveis. Antes de cada grupo de alterações, registar o valor atual, o owner e o caminho de recuperação previsto. Depois, alterar apenas uma área, por exemplo Device Access, uma regra firewall ou a ação de um Threat Feed. Testar tanto o caminho permitido esperado como um caminho deliberadamente negado e verificar os logs relevantes. Só então avançar para a área seguinte.

Para o rollback, repor apenas a última definição alterada no valor inicial documentado. Nas alterações de Device Access, manter disponíveis tanto a sessão admin existente como um caminho de gestão independente testado previamente. Não eliminar a regra anterior antes de a sua substituta mais restrita passar na validação. Iniciar os Threat Feeds com Monitor, analisar correspondências e possíveis falsos positivos e só depois mudar para Block; se o bloqueio causar problemas, voltar a Monitor e adicionar apenas exclusões verificadas. Um restore completo do backup não é um botão Undo conveniente, mas o caminho de recovery para falhas maiores.

Checklist compacta de hardening

Para uma primeira revisão, usar esta ordem:

1. Restringir acesso WAN a WebAdmin e SSH, manter User Portal desativado e preservar e testar VPN Portal para os downloads e SSO necessários.
2. Ativar MFA para admins e Remote Access.
3. Limpar contas admin locais, funções e políticas de password.
4. Verificar firmware, hotfixes, pattern updates e estado de suporte.
5. Documentar backup, SSMK, caminho de restore e teste de recovery.
6. Rever a necessidade de publicações DNAT, WAF e VPN; limitar grupos/recursos VPN, não autorizar Open group e testar acessos permitidos e negados.
7. Limpar regras com Any, sem logging ou sem owner claro.
8. Ativar IPS, Spoof Protection, DoS Settings e Threat Feeds de forma direcionada.
9. Introduzir Web, DNS, TLS e Zero-Day Policies por fases.
10. Estabelecer Health Check, logs conservados independentemente e monitorizados, testes de entrega, alertas e revisões regulares com responsável e prazo de conservação.

Erros frequentes

Acesso WAN fica aberto por conveniência

Acesso WebAdmin ou SSH é aberto para um caso de suporte e depois esquecido. Estas exceções temporárias devem ser documentadas com data de expiração, owner e verificação posterior.

Threat Feeds são ativados sem conceito operacional

Threat Feeds são fortes, mas não livres de manutenção. Sem monitorização, allowlist e processo de falsos positivos, um parceiro, fornecedor ou serviço cloud legítimo pode ser bloqueado. Primeiro testar com Monitor ou escopo limitado, depois mudar limpo para Block.

Falta logging em regras críticas

Se uma regra DNAT pública, WAF ou VPN não regista logs, durante um incidente vê-se pouco. Pelo menos entradas relevantes para segurança, acessos admin, regras deny e transições críticas de segmentos devem ser rastreáveis.

Health Check é tratado como tarefa única

Uma boa pontuação após setup não é estado permanente. Novas regras, novos utilizadores VPN, exceções temporárias e alterações de firmware podem mudar a situação. Hardening precisa de ritmo de review.

FAQ