Configurar e testar o IPS do Sophos Firewall em segurança

O Intrusion Prevention System (IPS) verifica o tráfego à procura de padrões de ataque conhecidos, exploits e características de protocolo suspeitas. Para que o IPS proteja efetivamente, tem de estar ativo globalmente e a regra de firewall que processa o tráfego tem de ter uma política IPS adequada atribuída.

Não se deve aplicar indiscriminadamente a política mais rigorosa a todas as regras. Uma política ajustada ao percurso dos dados, uma implementação piloto e logs completos evitam interrupções desnecessárias sem reduzir irrefletidamente a proteção.

Ativar o IPS e atribuí-lo a uma regra de firewall

Pré-requisitos

Antes da configuração, têm de estar reunidas as seguintes condições:

• subscrição Network Protection ativa ou licença de avaliação
• assinaturas IPS disponíveis e atualizações de padrões funcionais
• regra de firewall conhecida que processe efetivamente o tráfego a verificar
• logging da regra ativo e um processo para falsos positivos

O IPS Protection está desativado por predefinição. Numa firewall online, as assinaturas IPS só são atualizadas com uma licença válida e o IPS ativo. As firewalls Air Gap licenciadas são a exceção documentada: podem receber assinaturas IPS através do processo de atualização previsto mesmo com o IPS desativado. Os detalhes encontram-se em Licenciamento Air Gap e atualizações de padrões.

Quando a subscrição Network Protection expira, o interruptor do IPS pode continuar a parecer ativo, embora a firewall já não imponha proteção IPS. Se o IPS for desativado manualmente, as assinaturas online deixam de ser atualizadas e já não é possível configurar políticas nem assinaturas próprias. Após 30 dias, a firewall elimina as assinaturas e regras IPS.

Depois de uma licença de avaliação expirar, o IPS desativa-se automaticamente. Durante os 30 dias seguintes, não impõe proteção, não transfere assinaturas e não permite configurar políticas; depois disso, as assinaturas e regras são eliminadas. Para conservar a configuração, é necessário exportá-la ou criar uma cópia de segurança antecipadamente.

Ativar o IPS globalmente

1. Abra Protect > Intrusion prevention > IPS policies. Dependendo da vista, o caminho abreviado é Intrusion prevention > IPS policies.
2. Ative IPS Protection.
3. Verifique o estado da licença e as atualizações de padrões.
4. Aguarde até as assinaturas estarem disponíveis.
5. Verifique as políticas predefinidas existentes.
6. Se for necessária uma política própria, use Add para clonar uma política predefinida adequada.

Após a ativação, não se deve verificar apenas o interruptor. Um estado de padrões atual e a primeira ocorrência no log demonstram muito melhor se toda a cadeia de proteção está realmente a funcionar.

Ativar ou desativar Firewall Acceleration ou PKI Acceleration reinicia o IPS ou a DPI Engine. Estas alterações devem ser feitas numa janela de manutenção e não durante uma análise de erros em curso.

Ativar o IPS na regra de firewall

1. Abra Rules and policies > Firewall rules.
2. Edite a regra que efetivamente corresponde ao tráfego.
3. Em Other security features, ative a opção Detect and prevent exploits (IPS).
4. Selecione uma política IPS adequada ao tráfego.
5. Ative o logging da regra, guarde e teste com tráfego real.

A ativação global, por si só, não é suficiente. Se o tráfego corresponder primeiro a outra regra sem política IPS, uma regra posterior não o protege. Nesse caso, consulte A regra do Sophos Firewall não corresponde: verificar as causas.

Para servidores publicados, isto significa que DNAT, uma regra de firewall estritamente limitada, política IPS, logging e gestão de patches têm de estar alinhados. Nos segmentos internos, também é necessário confirmar se o tráfego passa sequer pela firewall e pela regra esperada.

Escolher a política IPS adequada

A política depende da origem, do destino e da aplicação:

• Clientes para a Internet: use uma política de cliente ou LAN-to-WAN e coordene-a com Web Protection, Application Control e, se necessário, TLS Inspection. Os browsers, serviços de atualização e aplicações especializadas devem fazer parte do piloto; para transferências suspeitas, a Zero-Day Protection complementa a verificação de assinaturas.
• Internet para um servidor através de DNAT: ajuste uma política de servidor ou servidor Web estritamente ao sistema de destino e às portas publicadas. A proteção aplica-se aos serviços efetivamente disponibilizados, não indiscriminadamente a todas as tecnologias de servidor. O contexto de NAT e regras é explicado em Publicar um servidor através de DNAT; os endereços IP, domínios ou URLs maliciosos conhecidos também podem ser bloqueados através de Threat Feeds.
• VPN Site-to-Site ou Remote Access: escolha a política em função dos sistemas de origem e destino. As aplicações de produção, MTU/MSS, latência e débito têm de ser testados no percurso VPN real.
• VoIP: teste SIP/RTP com uma política específica e um plano de reversão. Uma política agressiva de cliente ou servidor pode interferir com a sinalização ou com o fluxo multimédia.
• Redes de gestão, cópia de segurança e infraestrutura: proteja-as de forma restritiva sem interromper as ligações necessárias de administração, monitorização ou cópia de segurança. Neste caso, regras estritas são geralmente mais valiosas do que uma seleção de assinaturas especialmente ampla.

Em limites de segmentos, como cliente para servidor ou VPN para servidor, o IPS também dificulta o movimento lateral após uma intrusão. No entanto, apenas complementa regras de firewall bem definidas. As definições de proteção contra spoofing e DoS separadas tratam de padrões simples de spoofing e flooding.

Criar uma política própria a partir de um modelo

Com Add, é possível clonar uma política predefinida e depois ajustá-la especificamente. Isto é mais compreensível do que uma coleção livre de assinaturas e mantém uma proteção de base razoável. O nome deve indicar a finalidade e o percurso dos dados, por exemplo IPS-Pilot-LAN ou IPS-DNAT-Webserver.

As regras da política são avaliadas de cima para baixo. Por isso, uma regra abrangente para todas as assinaturas de servidor pode sobrepor-se a uma regra especial situada abaixo para um único SID. Os ajustes específicos devem ser colocados acima das regras mais gerais; depois, uma ocorrência adequada no log tem de confirmar que a ação esperada foi aplicada.

Filtrar e avaliar assinaturas

As assinaturas podem ser filtradas por Category, Severity, Platform e Target. Também é possível criar assinaturas IPS próprias, mas estas só devem ser usadas para um caso de deteção claramente descrito e revistas posteriormente. Para logs, tickets e exceções, são essenciais as seguintes informações:

• SID: ID exclusivo da assinatura
• Category: área técnica, por exemplo DNS, browser ou malware
• Severity: nível de gravidade
• Platform: plataforma afetada, por exemplo Windows ou Linux
• Target: assinatura de cliente ou servidor
• Recommended action: ação recomendada pela Sophos

A Sophos atribui Critical a CVSS de 9 a 10, Major de 7 a menos de 9, Moderate de 4 a menos de 7 e Minor de 1 a menos de 4 ou a assinaturas-pai. Warning assinala tráfego suspeito como alerta. No entanto, a gravidade, por si só, não determina a avaliação: uma assinatura Major num servidor exposto deve ser avaliada de forma diferente de uma ocorrência Warning numa rede de teste. O sistema de destino, a acessibilidade, o nível de correções e a ação efetiva têm de fazer sempre parte da avaliação.

Compreender as ações do IPS

Uma regra da política pode substituir a ação recomendada pela Sophos:

• Recommended: ponto de partida adequado para regras de produção; é aplicada a recomendação correspondente da Sophos
• Allow packet: regista a ocorrência, mas permite o pacote; é adequado para um piloto, mas não impede o ataque detetado
• Drop packet: elimina apenas o pacote afetado; a aplicação pode continuar a funcionar ou responder com erros
• Drop session: termina toda a sessão após uma ocorrência; intervenção mais forte perante um risco de ataque confirmado
• Reset: repõe ativamente a sessão TCP; o utilizador ou a aplicação observa uma interrupção abrupta
• Disable: desativa a assinatura; deixa de existir proteção para esta deteção específica
• Bypass session: deixa de verificar o restante da sessão; o tráfego pode entrar em FastPath ou Offload e, assim, ficar fora da inspeção de forma mais abrangente do que o pretendido

As ações de pacotes aplicam-se a cada pacote. As ações de sessão verificam até à primeira ocorrência e depois afetam toda a ligação. Por isso, qualquer desvio de Recommended requer uma nota com a assinatura, política, regra de firewall, motivo, responsável e data de revisão.

Padrões PQC a partir do SFOS 22.0 MR2

O SFOS 22.0 MR2 deteta negociações ML-KEM puras e híbridas, incluindo ML-KEM-512, -768, -1024 e X25519 com ML-KEM-768. Os novos padrões PQC estão definidos como Disabled por predefinição, porque o PQC não é automaticamente suspeito. Para os avaliar, deve testar primeiro uma política piloto própria com Allow packet e logging e só depois da análise aplicar Drop session ou Reset. Para mais informações, consulte Sophos Firewall v22 MR2: controlo de PQC.

Implementar e testar de forma controlada

1. Escolha uma regra piloto: comece com uma rede de clientes de teste conhecida ou uma única regra DNAT. O tráfego esperado e a pessoa responsável têm de estar definidos antes do teste.
2. Teste aplicações reais: verifique inícios de sessão, transferências de ficheiros, atualizações, APIs e sessões prolongadas. Um ping breve não demonstra que a aplicação funciona de forma estável com IPS.
3. Analise as ocorrências: no Log viewer, verifique a origem, o destino, o serviço, a regra de firewall, a assinatura, o SID, a Severity, a ação e a hora. As ferramentas abaixo fornecem o contexto técnico.
4. Expanda gradualmente: só inclua mais regras depois de os testes serem estáveis. VoIP, ERP, protocolos industriais, VPN e aplicações antigas requerem uma janela de teste e um plano de reversão.

Para a análise, consulte Serviços e logs, use em conjunto o Log Viewer e o Packet Capture e analise os pacotes eliminados.

As ferramentas respondem a perguntas diferentes:

• ips.log: informações mais detalhadas sobre decisões de IPS, DPI e Application Control
• Packet Capture: fluxo e direção dos pacotes, Firewall Rule ID, NAT ID e IPS Policy ID
• Teste de regras: qual a regra de firewall que efetivamente processa o tráfego
• Syslog ou Central Reporting: retenção e correlação durante mais tempo

Quando estão ativos vários módulos de proteção, é necessário comparar a hora nos logs de firewall, IPS, Web, Application Control e SSL/TLS Inspection. Uma regra de firewall pode permitir tráfego que um módulo posterior acaba por bloquear.

Comparar o desempenho

O IPS utiliza uma quantidade de recursos variável consoante o modelo, o tráfego, as assinaturas, a TLS Inspection, o Application Control, a VPN e o tamanho dos pacotes. Por isso, antes e depois da ativação, devem ser registados os seguintes valores sob uma carga comparável:

• utilização do CPU e da memória
• débito nas interfaces afetadas
• latência e retransmissões de aplicações críticas
• volume de IPS/DPI e Syslog
• mensagens dos utilizadores e das aplicações

Desativar brevemente o IPS ainda não demonstra a causa. É possível obter comparações reproduzíveis com métricas de desempenho da firewall corretamente contextualizadas e um teste iPerf controlado.

Tratar falsos positivos e exceções

Quando é bloqueado tráfego legítimo, não se deve desativar imediatamente o IPS de forma global. Uma ocorrência pode ser um falso positivo, uma aplicação inesperada ou uma tentativa real de exploração. Comece por recolher:

• ID e nome da assinatura
• origem, destino, serviço e regra de firewall correspondente
• hora, frequência e aplicação afetada
• nível de correções do sistema de destino
• excerto relevante do log ou Packet Capture

Perguntas concretas ajudam: o erro ocorre apenas num host ou numa porta? É reproduzível? Desaparece após uma correção? O mesmo SID aponta repetidamente para o mesmo destino? Só estes factos justificam uma alteração à política.

Em seguida, limite a alteração tanto quanto possível:

• ajuste uma única assinatura em vez de uma categoria inteira
• use uma política IPS própria apenas na regra de firewall afetada
• verifique a ordem das regras da política
• restrinja melhor a origem, o destino e o serviço na regra de firewall
• documente o motivo, o responsável e a data de revisão
• após a alteração, confirme se apenas o tráfego esperado é afetado

Uma exceção temporária é geralmente melhor do que uma desativação permanente. Após uma atualização da aplicação, do firmware ou do sistema, deve ser novamente verificada. Se muitas assinaturas interferirem com a mesma aplicação, uma política própria ou uma melhor segmentação é uma solução mais adequada do que uma grande exceção global.

Resolução de problemas e operação

O IPS não produz efeito

Verifique pela seguinte ordem:

1. A subscrição Network Protection ou a licença de avaliação é válida?
2. O IPS Protection está ativado globalmente?
3. Os padrões IPS estão atualizados? Num cluster HA, a atualização é feita no Primary e sincronizada automaticamente com o Auxiliary.
4. O tráfego corresponde à regra de firewall esperada com política IPS e logging?
5. Uma regra de política abrangente sobrepõe-se a uma regra específica?
6. A política contém ações injustificadas, como Allow packet, Disable ou Bypass session?
7. A política é adequada para tráfego de cliente, servidor, VPN ou VoIP?
8. Foi usado tráfego real para confirmar que o Log Viewer e o ips.log apresentam eventos adequados?

As exceções sem responsável ou data de revisão são consideradas abertas e devem ser incluídas na próxima revisão operacional.

O serviço IPS está em DEAD

No SFOS 22.0 GA e versões posteriores, em casos raros podem faltar dados de configuração necessários da política Web. Nesse caso, o serviço de política Web não inicia, o IPS não consegue inicializar a sua política e permanece em DEAD; as atualizações de padrões também falham. Num cluster HA, cada nó pode ser afetado de forma independente.

Na CLI, 5 Device Management > 3 Advanced Shell conduz à shell necessária. O seguinte comando read-only mostra todas as linhas de serviço que contêm ips no nome:

service -S | grep -i ips

Apenas é relevante a linha cujo primeiro nome de serviço é exatamente ips; não se trata de ipsec-monitor. Num cluster HA, cada nó afetado tem de ser verificado separadamente.

Se o serviço estiver em DEAD, deve guardar a versão do SFOS, a hora, o nó, a saída de estado completa, bem como ips.log e sig_upgrade.log, e contactar o Sophos Support mencionando NC-181971. O comando, por si só, não comprova este erro. A Sophos continua sem publicar uma versão corrigida e apenas disponibiliza a solução alternativa através do suporte. Tentativas repetidas de reinício ou comandos de reparação não documentados não constituem uma solução adequada.

FAQ