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

O sistema de prevenção de intrusões (Intrusion Prevention System — IPS) verifica o tráfego de rede em busca de padrões de ataque conhecidos, exploits e características de protocolo anómalas. Para que o IPS ofereça proteção efetiva, tem de estar globalmente ativo. Além disso, a regra de firewall que processa o fluxo de dados tem de utilizar uma política IPS adequada.

O procedimento seguro e conciso consiste em verificar a licença e os padrões, ativar o IPS, selecionar uma política em função do sistema a proteger, atribuí-la à regra de firewall correta e validar o percurso dos dados com um pequeno grupo-piloto. Aplicar a política mais rigorosa a todas as regras não proporciona automaticamente a melhor proteção. Uma seleção inadequada gera deteções, carga ou perturbações desnecessárias e dificulta a análise dos eventos relevantes.

Verificar os pré-requisitos e o estado da licença

Antes da configuração, são necessários:

• uma subscrição Network Protection ativa ou uma licença de avaliação;
• assinaturas IPS disponíveis e um processo funcional de atualização dos padrões;
• a Firewall Rule ID da regra que efetivamente processa o tráfego pretendido;
• o registo do tráfego da regra para correlacionar a sessão, a regra de firewall e o evento IPS;
• uma pessoa responsável, testes definidos e um procedimento de reversão para falsos positivos.

Por predefinição, a IPS Protection está desativada. Numa firewall online, as assinaturas IPS só são atualizadas com uma licença válida e o IPS ativado. As firewalls air gap licenciadas constituem a exceção documentada: podem receber assinaturas IPS através do processo de atualização previsto, mesmo com o IPS desativado. As diferenças são explicadas em Licenciamento air gap e atualizações de padrões.

Após o termo de uma subscrição Network Protection, o seletor do IPS pode continuar a parecer ativo, embora a firewall já não imponha a proteção IPS. A licença de avaliação tem um comportamento diferente: quando expira, o IPS é automaticamente desativado. Com o IPS desativado, deixam de ser descarregadas assinaturas online e já não é possível configurar políticas nem assinaturas próprias. Após 30 dias neste estado, o SFOS elimina as assinaturas e regras IPS. Caso seja necessário preservar a configuração, deve criar-se previamente uma exportação ou cópia de segurança.

Mesmo com o IPS desativado, as políticas IPS existentes podem continuar a ser atribuídas a regras de firewall. Esta atribuição não comprova que exista inspeção ativa ou proteção efetiva. Se a subscrição paga tiver expirado e o IPS estiver desativado, ou se uma licença de avaliação expirada tiver desativado automaticamente o IPS, é necessário ativar primeiro uma subscrição Network Protection antes de ser possível voltar a ativar o IPS. Após a ativação, verificar novamente o seletor do IPS e as assinaturas.

Mesmo uma subscrição válida não oferece proteção ilimitada sem contacto com o serviço de licenciamento. Normalmente, as firewalls online sincronizam as licenças a cada 24 horas. Se a sincronização falhar durante 90 dias consecutivos, o SFOS desativa as Security Subscriptions; no caso de uma licença air gap, este prazo é de 180 dias. Os inícios de sessão e o tráfego podem continuar a funcionar, mas sem a proteção das subscrições desativadas. Por isso, o estado da licença deve fazer parte do diagnóstico quando o IPS aparenta estar configurado, mas não produz efeito.

Em Backup & firmware > Pattern updates, o SFOS apresenta, entre outros, os estados Ready to install, Downloading, Success e Failed. Update pattern now inicia uma atualização das definições de padrões normais. Uma entrada bem-sucedida para Application Signatures não comprova que as assinaturas IPS também tenham sido carregadas: nos sistemas online, estas continuam a exigir uma licença e o IPS ativado.

Ativar o IPS e definir o percurso dos dados

1. Abrir Intrusion prevention > IPS policies.
2. Ativar IPS Protection.
3. Em Backup & firmware > Pattern updates, verificar a data e hora e o estado dos padrões IPS.
4. Documentar o estado anterior de IPS Protection, a Firewall Rule ID do fluxo-piloto, a política IPS anterior, Log firewall traffic e as exceções existentes.

Ativar ou desativar Firewall Acceleration ou PKI Acceleration reinicia o IPS ou o motor DPI. Estas alterações não fazem parte deste procedimento de ativação. Se um problema reproduzível estiver relacionado com uma definição global do motor, Verificar as definições globais do IPS em segurança descreve quais as alterações que entram imediatamente em vigor, quais exigem a aplicação ou um reinício e como preservar o valor inicial.

O sistema a proteger determina a política

Target designa o lado cujo software vulnerável é protegido por uma assinatura. Não corresponde simplesmente à Source Zone ou à Destination Zone. Por exemplo, no caso de um browser que recebe uma resposta manipulada, o Target pode ser Client; no caso de um servidor Web publicado que recebe um pedido malicioso, pode ser Server.

A seleção é feita respondendo a três perguntas:

1. Qual é o sistema a proteger no fluxo em análise: o cliente ou o servidor?
2. Que plataformas, protocolos e serviços são efetivamente utilizados nesse sistema?
3. Existe uma política que cubra este âmbito sem incluir grupos de assinaturas alheios à finalidade?

Para um percurso normal entre um cliente e a Internet, o ponto de partida é uma política de cliente ou LAN-to-WAN adequada. Numa publicação DNAT, deve escolher-se uma política de servidor ou de servidor Web compatível com o sistema operativo e com as portas efetivamente publicadas. Num fluxo de VPN ou de segmentação, a aplicação protegida também é determinante, não apenas o nome da zona de origem. A MTU, o MSS, a latência e o débito são então verificados através do percurso VPN real.

O VoIP exige um teste funcional específico da sinalização SIP e dos fluxos multimédia RTP, bem como um regresso preparado à política anterior. Para redes de gestão, cópias de segurança e infraestruturas, regras restritas são geralmente mais valiosas do que uma seleção de assinaturas particularmente abrangente. O IPS também pode dificultar ataques laterais nos limites entre segmentos internos; contudo, os limites de spoofing e flooding continuam a ser uma função distinta das definições de spoofing e DoS.

Uma política própria é apropriada quando se pretende delimitar melhor o percurso dos dados, quando uma SID individual requer uma exceção documentada ou quando uma ação se desvia intencionalmente de Recommended. Para isso, em Intrusion prevention > IPS policies > Add, atribui-se um nome inequívoco, como IPS-Pilot-LAN ou IPS-DNAT-Webserver, e clona-se uma política existente adequada como ponto de partida. Primeiro, guardar a política nova ou clonada com Save; este passo ainda não cria uma nova regra da política. Em seguida, ajustam-se as regras na cópia; as assinaturas fornecidas não podem ser editadas.

Filtrar assinaturas e ordenar as regras da política

Ao adicionar uma regra, podem selecionar-se assinaturas individuais, assinaturas próprias ou Select all. O Smart Filter aceita termos de pesquisa e critérios como Category, Severity, Platform e Target; depois de introduzir os dados, prima Enter para aplicar o filtro.

O editor de regras é aberto separadamente da criação da política: em Intrusion prevention > IPS policies, selecionar Edit na política pretendida, já guardada, depois Add e introduzir um nome inequívoco para a regra. Em seguida, selecionar as assinaturas necessárias: Select individual signature para assinaturas individuais ou Custom signature para assinaturas próprias. Para pesquisar através de Smart filter, selecionar primeiro Select all, introduzir o termo de pesquisa e premir Enter para aplicar.

As categorias ajudam a delimitar tecnicamente a seleção. A tabela completa abaixo explica as designações apresentadas pelo SFOS. Category é uma ajuda de consulta, não uma avaliação do risco; em conjunto com Platform e Target, permite ao Smart Filter selecionar apenas as assinaturas relevantes.

As categorias abrangentes de indicadores devem ser primeiro utilizadas num piloto de observação. Em particular, indicator-compromise pode gerar falsos positivos; a categoria, por si só, não justifica um bloqueio nem uma exceção.

Após a seleção das assinaturas, definir deliberadamente a Action; as diferenças são explicadas na secção sobre Severity e ação. Guardar a regra com Save no editor de regras. Este passo é distinto da gravação inicial da política. No procedimento DDoS, a política que contém a regra é depois também guardada com Save.

Depois de guardar, inicie uma nova sessão de teste e confirme ips_policy_id ou idp_policy_id, bem como fw_rule_id; se houver uma deteção, compare também signature_id, classification e log_subtype com a regra e a ação pretendidas. A ausência de deteções, por si só, não comprova que o filtro ou a política foram aplicados.

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 uma única SID. As exceções específicas ou ações divergentes devem ficar acima da regra mais geral. Uma deteção subsequente tem de apresentar a política, a Rule ID e a ação esperadas.

As assinaturas IPS próprias destinam-se a casos de deteção claramente descritos, não a substituir uma seleção predefinida inadequada. O procedimento que abrange a sintaxe, uma política-piloto restrita e os testes positivo e negativo encontra-se em Criar e testar assinaturas IPS próprias.

Avaliar separadamente a Severity e a ação

Para os registos, pedidos de suporte e exceções, são importantes SID, Category, Severity, Platform, Target e Recommended action. A Sophos classifica como Critical uma pontuação 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 assinaturas-pai. Warning identifica um determinado tipo de tráfego e gera um alerta. A Severity, por si só, não determina o risco: a acessibilidade, o sistema de destino, o estado das correções e a ação efetiva também fazem parte da avaliação.

Esta correspondência CVSS tem exceções: a Sophos descreve casos cuja classificação de Severity não se enquadra nas fórmulas indicadas. Daqui não se pode inferir uma função documentada do WebAdmin para substituir a Severity, nem um procedimento de reclassificação; verificar a Severity efetivamente apresentada para a assinatura.

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

• Recommended aplica a ação recomendada pela Sophos para cada assinatura e constitui o ponto de partida habitual para regras em produção.
• Allow packet regista a deteção, 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 apresentar um erro.
• Drop session termina toda a sessão após uma deteção.
• Reset termina ativamente uma sessão TCP, enviando um pacote RST ao iniciador.
• Disable desativa apenas esta assinatura; a deteção associada deixa de ser efetuada.
• Bypass session deixa de inspecionar o resto da sessão. Consequentemente, o tráfego pode entrar no FastPath ou em Offload e ficar excluído da inspeção de forma mais abrangente do que se pretendia.

As ações de pacote aplicam-se a cada pacote. As ações de sessão inspecionam até à primeira deteção e, depois, atuam sobre toda a ligação. Por conseguinte, qualquer desvio de Recommended deve ser justificado, indicando a assinatura, a política, a regra de firewall, a pessoa responsável e a data de revisão.

Selecionar a política IPS na regra de firewall

1. Abrir Rules and policies > Firewall rules.
2. Editar a regra cuja Rule ID foi confirmada no fluxo-piloto.
3. Em Other security features, definir a política IPS selecionada em Detect and prevent exploits (IPS).
4. Ativar Log firewall traffic, guardar e iniciar uma nova sessão para o teste.

A ativação global, por si só, não é suficiente. Se o tráfego corresponder primeiro a outra regra sem uma política IPS, uma regra posterior não oferece proteção. A regra do Sophos Firewall não é aplicada: verificar as causas ajuda a analisar a correspondência das regras.

As regras de firewall limitam o tráfego permitido. O IPS deteta padrões de ataque no fluxo de dados visível. A Web Protection controla conteúdos e categorias Web, o Application Control classifica aplicações, a TLS Inspection torna visíveis os conteúdos encriptados quando necessário e a Zero-Day Protection analisa ficheiros suspeitos. Os Threat Feeds, como os feeds mantidos pela Cybora, complementam esta proteção ao bloquear endereços IP, domínios ou URL maliciosos conhecidos. Estes módulos complementam-se; nenhum substitui uma regra de firewall restrita, a gestão de correções ou a seleção da política correta.

Validar um piloto controlado

Antes do início, definem-se a duração do teste, a pessoa responsável, a base de comparação e os critérios de interrupção. A linha de base inclui a data e hora dos padrões, a Firewall Rule ID, as políticas IPS anterior e nova, as exceções conhecidas, a CPU e a memória, bem como pelo menos uma ligação de controlo inalterada. Para VoIP, ERP, protocolos industriais, VPN e aplicações antigas, o teste requer uma janela de manutenção.

1. Confirmar a atribuição da política: iniciar uma nova sessão e verificar no Packet Capture ou no registo da firewall a Firewall Rule ID e a IPS Policy ID esperadas. Isto comprova a atribuição, mas ainda não uma deteção de assinatura. O procedimento conjunto para o Log Viewer e o Packet Capture pode ser aplicado diretamente à ligação de teste.
2. Testar fluxos de trabalho reais: executar o início de sessão, a transferência de ficheiros, atualizações, API e sessões prolongadas. Um ping não substitui estes testes.
3. Analisar os eventos: em caso de deteção, registar a ID e o nome da assinatura, a política, a regra de firewall, a origem, o destino, as portas e a ação efetiva. Não se deve gerar um ataque real apenas para testar o funcionamento. Para uma deteção inofensiva e determinística, utiliza-se o piloto controlado de assinaturas próprias.
4. Comparar a ligação de controlo: uma ligação permitida dentro do mesmo âmbito deve continuar a apresentar a regra e a aplicação esperadas. Se houver perda de pacotes, a análise separada dos pacotes eliminados ajuda a delimitar a causa.
5. Só depois alargar o âmbito: adicionar outros hosts ou regras apenas se não existirem bloqueios por esclarecer e se forem respeitados os limites de carga, latência e aplicação previamente definidos.

O sucesso não implica necessariamente que tenha sido acionada uma assinatura de ataque. O que importa é comprovar a atribuição da política, o funcionamento dos fluxos de teste e de controlo, a ausência de bloqueios por esclarecer e valores de recursos aceitáveis. Se um processo empresarial crítico falhar, ocorrer um bloqueio inexplicado ou for excedido um limite de desempenho acordado, repõem-se os valores iniciais documentados da atribuição da política e do registo do tráfego da regra. Uma política-piloto criada especificamente para o efeito só deve ser eliminada quando já não estiver atribuída a nenhuma regra e as respetivas exceções tiverem sido documentadas. Se o IPS estava globalmente desativado antes do piloto, esse estado inicial só deve ser reposto depois de se verificar quais as outras regras de firewall que perderão assim a sua proteção IPS.

Interpretar corretamente os registos, o Packet Capture e os relatórios

As ferramentas respondem a perguntas diferentes:

• Registo da firewall: ips_policy_id mostra a política associada ao fluxo. Esta informação também é útil sem uma deteção de assinatura.
• Evento IPS: log_type=IDP, signature_id, signature_msg, idp_policy_id, fw_rule_id, classification e log_subtype relacionam a assinatura, a política, a regra e o resultado. O valor de detection_severity no registo não corresponde necessariamente à apresentação categórica da Severity na política.
• Packet Capture: apresenta, entre outros elementos, a Firewall Rule ID, a NAT ID e a IPS Policy ID no fluxo de pacotes.
• ips.log: fornece indicações mais detalhadas sobre as decisões do IPS, DPI, Application Control e Active Threat Response.
• sig_upgrade.log e sigmigration.log: mostram, respetivamente, a atualização e a migração das assinaturas.
• Reports > Network & threats > Intrusion attacks: é adequado para análises retrospetivas; o Log Viewer continua a ser mais indicado para eventos atuais individuais.

A correspondência de outros ficheiros de registo e serviços é explicada em Serviços e registos do Sophos Firewall. Quando estão ativos vários módulos de proteção, deve comparar-se o mesmo momento nos registos da firewall, do IPS, da Web, do Application Control e da inspeção SSL/TLS. Uma regra de firewall pode permitir tráfego que um módulo subsequente venha a bloquear.

Verificar o desempenho sob uma carga comparável

Consoante o modelo, o tráfego, as assinaturas, a TLS Inspection, o Application Control, a VPN e o tamanho dos pacotes, o IPS utiliza diferentes quantidades de recursos. Antes e depois da ativação, devem registar-se, sob uma carga comparável, a CPU, a memória, o débito, a latência, as retransmissões de aplicações críticas e o volume de eventos do IPS/DPI e do Syslog.

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

Decidir sobre falsos positivos em vez de simplesmente os permitir

Uma deteção IPS pode ser um falso positivo, uma aplicação inesperada ou uma verdadeira tentativa de exploit. Em primeiro lugar, devem registar-se a ID e o nome da assinatura, a origem, o destino, o serviço, a regra de firewall, a data e hora, a frequência, a aplicação afetada e o estado das correções. Em seguida, toma-se a decisão:

1. Reproduzir o fluxo legítimo e confirmar que é exatamente esta SID que o deteta.
2. Verificar o estado das correções, as indicações do fabricante e a acessibilidade do sistema protegido.
3. Avaliar o risco caso a deteção seja permitida. Um resultado inconclusivo ou não reproduzível não justifica uma exceção permanente.
4. Escolher a medida reversível mais restrita: de preferência, aplicar a correção ou restringir o percurso dos dados; em alternativa, definir temporariamente uma única SID como Allow packet numa política utilizada apenas nesse percurso. Disable ou Bypass session removem mais proteção e exigem uma justificação mais sólida.
5. Voltar a testar o fluxo positivo legítimo e um fluxo negativo ou de controlo.
6. Documentar a exceção, a pessoa responsável e a data de revisão e reavaliar após uma atualização da aplicação, dos padrões, do firmware ou do sistema.

Se várias assinaturas interferirem com a mesma aplicação, uma política própria e restrita ou uma melhor segmentação é uma solução mais correta do que um conjunto de exceções globais permanentes. Desativar globalmente o IPS não é uma reversão adequada para uma única SID.

Resolução de problemas por sintoma

Não são apresentados eventos IPS

Primeiro, deve iniciar-se uma nova sessão e verificar a Firewall Rule ID e o ips_policy_id no registo da firewall ou no Packet Capture. Se a Policy ID não estiver presente, o fluxo corresponde a outra regra ou a regra selecionada não tem uma política IPS atribuída. Se a política puder ser confirmada, mas não houver uma deteção de assinatura, isso pode ser normal para tráfego inofensivo. Para uma confirmação reproduzível, utiliza-se uma Custom Signature restrita num piloto isolado, não um exploit real.

Existe um evento, mas o tráfego não é bloqueado

No evento IPS, verificar signature_id, a política e log_subtype. Em seguida, confirmar a primeira regra correspondente da política e a respetiva ação efetiva. Allow packet, Disable ou Bypass session podem impedir um bloqueio esperado; uma regra abrangente situada acima pode sobrepor-se à regra específica. Após cada alteração, deve testar-se uma nova sessão.

Faltam assinaturas IPS ou a atualização de padrões falha

Verificar em conjunto o estado da licença, o seletor global do IPS e Backup & firmware > Pattern updates. O estado Failed ou uma data recente para Application Signatures não comprovam uma atualização IPS bem-sucedida. O ficheiro sig_upgrade.log mostra o percurso da atualização; em caso de problemas de licença, licensing.log fornece contexto adicional. Num cluster HA, o Primary atualiza os padrões IPS e sincroniza-os automaticamente com o Auxiliary.

O serviço IPS apresenta o estado DEAD

Em System services > Services, verificar e documentar o estado do serviço IPS. Se o Sophos Support também solicitar uma saída da shell específica do nó, 5 Device Management > 3 Advanced Shell permite efetuar esta verificação só de leitura:

service -S | grep -i ips

A linha relevante é aquela cujo primeiro nome de serviço é exatamente ips; não se trata de ipsec-monitor. Este comando da Advanced Shell não faz parte do procedimento publicado para o problema conhecido e só deve ser utilizado num diagnóstico coordenado com o suporte. Num cluster HA, o estado solicitado tem de ser registado separadamente em cada nó afetado.

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 no estado DEAD; as atualizações de padrões também falham. Num cluster HA, cada nó pode ser afetado de forma independente.

Registar a versão do SFOS, a data e hora, o nó, o estado do serviço, o ips.log e o sig_upgrade.log e contactar o Sophos Support, mencionando NC-181971. O estado, por si só, não comprova esta causa. Na lista atual de problemas conhecidos, a Sophos continua a não indicar uma versão que corrija o problema e disponibiliza a solução temporária através do suporte. Reinícios repetidos ou comandos de reparação não documentados não constituem um procedimento de diagnóstico adequado.

Pacote completo de assinaturas apenas para casos especiais comprovados

Durante uma atualização de padrões, o SFOS pode descarregar o pacote completo de assinaturas IPS em vez de um pacote parcial. Esta opção só se aplica a appliances com pelo menos 32 GB de RAM e, segundo a Sophos, pode afetar o desempenho. Não ativa o IPS nem atribui uma política a qualquer regra de firewall.

Um motivo válido é a ausência, no pacote parcial, de uma assinatura expressamente indicada pelo Sophos Support. A opção não deve ser ativada preventivamente apenas porque um maior número de assinaturas parece preferível. Primeiro, deve consultar-se o estado atual na Device Console:

system ips full-signature-pack show

A ajuda da Device Console não indica um valor predefinido. Depois de confirmados o limite de RAM e a necessidade concreta, pode ativar-se a transferência do pacote completo:

system ips full-signature-pack enable

Após a atualização de padrões seguinte, verificam-se a data e hora dos padrões, o sig_upgrade.log, a assinatura esperada, o estado do IPS, a CPU, a RAM e o tráfego afetado. Se o benefício esperado não se concretizar ou o funcionamento piorar, repõe-se o estado anteriormente consultado. Se o estado antes do teste era disable, o comando de reversão é:

system ips full-signature-pack disable

Deteção de PQC a partir do SFOS 22.0 MR2

O SFOS 22.0 MR2 consegue detetar e controlar métodos de troca de chaves pós-quânticos puros e híbridos baseados em ML-KEM. Os novos padrões IPS estão desativados por predefinição, uma vez que o PQC não é automaticamente suspeito. Quem necessitar de analisar estas ligações deve começar por utilizar uma política-piloto própria com Allow packet e registo de eventos. Apenas um caso de utilização definido e testes positivos e de controlo estáveis justificam Drop session ou Reset. Consulte o contexto em Sophos Firewall v22 MR2: controlo de PQC.

FAQ