Criar e testar assinaturas IPS personalizadas na Sophos Firewall

Uma assinatura IPS personalizada é útil quando a Sophos não disponibiliza uma assinatura adequada para um padrão de rede ou aplicação claramente definido. Pode detetar uma string conhecida em texto simples, uma característica invulgar de protocolo ou uma combinação precisa de porta, direção e payload.

A assinatura, por si só, ainda não protege nada. Tem de ser utilizada numa IPS policy, essa policy tem de estar atribuída à regra de firewall que corresponde efetivamente e o fluxo de dados tem de ser visível para o IPS. Um padrão demasiado abrangente pode bloquear tráfego legítimo; um padrão demasiado restrito nunca corresponde.

Testar primeiro cada assinatura nova numa regra IPS piloto com Action: Allow packet. Mesmo que Recommended action já seja Allow packet, prevalece a ação da regra da IPS policy. Drop packet, Drop session, Reset e Bypass session alteram o tráfego de produção e só devem ser usados depois de testes reproduzíveis.

Um piloto controlado em seis passos

1. Descrever o caso de deteção com protocolo, direção, porta e um padrão inequívoco.
2. Em Intrusion prevention > Custom IPS signatures, criar uma assinatura restrita com Recommended action: Allow packet.
3. Adicionar a assinatura a uma regra própria numa IPS policy eliminável e escolher Action: Allow packet.
4. Atribuir esta IPS policy apenas à regra de firewall piloto prevista e ativar Log firewall traffic nessa regra.
5. Gerar um teste correspondente e outro deliberadamente não correspondente e comparar Log Viewer, ips.log e a correspondência da regra.
6. Alterar a ação da regra da IPS policy apenas depois de uma validação estável; restaurar a atribuição anterior se ocorrerem correspondências inesperadas.

Uma entrada guardada ou uma verificação de sintaxe bem-sucedida ainda não prova o funcionamento. O sucesso significa que o teste positivo corresponde exatamente à Custom Signature e à regra de firewall esperadas, que o teste negativo não gera uma ocorrência e que a aplicação de produção mantém o comportamento anterior.

Quando uma assinatura própria é adequada

As Custom Signatures são adequadas a uma característica estável e visível ao nível do pacote ou do stream. Pode tratar-se de um valor de protocolo proprietário, de um indicador claro de exploit ou de uma proteção temporária para uma vulnerabilidade interna conhecida. O percurso de dados esperado e a reação pretendida têm de estar definidos antes da criação.

Para endereços IP ou domínios variáveis, os hosts, serviços e grupos, os threat feeds ou regras de firewall restritas são normalmente mais adequados. Uma assinatura própria também não substitui a gestão de patches nem uma regra bem mantida pelo fabricante. Desenvolver uma assinatura permanente para um único evento no log raramente é proporcional.

O payload encriptado é um limite importante. O IPS só consegue detetar um padrão content num payload HTTPS se o conteúdo for efetivamente desencriptado e estiver visível para o motor no percurso de processamento escolhido. Sem uma TLS Inspection adequada, normalmente apenas estão disponíveis características não encriptadas ou visíveis de outra forma.

Verificar primeiro a licença e o ciclo de vida

As assinaturas próprias não podem ser configuradas se a versão trial do IPS tiver expirado ou se IPS Protection estiver desativado em Intrusion prevention > IPS policies. A Sophos recomenda voltar a ativar o IPS no prazo de 30 dias se for necessário conservar as Custom Signatures existentes. Por isso, um backup ou uma exportação faz parte do plano de rollback antes de alterações à licença, ao IPS ou a policies importantes.

Depois, o IPS tem de estar globalmente ativo e a regra de firewall que processa o tráfego necessita de uma IPS policy. A configuração de base completa está descrita em Configurar e testar o IPS da Sophos Firewall com segurança. Uma assinatura personalizada complementa este percurso de dados; não é um mecanismo de proteção paralelo.

Restringir conscientemente a sintaxe da regra

O formulário separa Protocol e Custom rule. A regra combina palavras-chave individuais, os respetivos valores e pontos e vírgulas. Exigir a correspondência de várias características independentes reduz geralmente as ocorrências acidentais. Ao mesmo tempo, a assinatura não deve tornar-se tão específica que uma alteração inofensiva do protocolo a torne ineficaz.

Para um teste de texto simples exclusivamente controlado, pode selecionar-se TCP como protocolo e utilizar, por exemplo, este padrão restrito de payload:

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT é um valor de documentação deliberadamente evidente. A regra de firewall piloto correspondente é adicionalmente limitada ao serviço de teste, por exemplo à porta TCP 8080. O token, a direção e a porta devem ser substituídos por valores presentes no fluxo real visível para o IPS. Este exemplo não é uma assinatura universal de ataque e não deve ser aplicado sem alterações a regras de produção abrangentes.

Payload e janela de pesquisa

content procura uma sequência de caracteres ou bytes; os valores binários são colocados entre barras verticais. nocase ignora maiúsculas e minúsculas numa correspondência content, enquanto rawbytes trabalha com os dados em bruto. depth e offset limitam a pesquisa de forma absoluta no payload; distance e within atuam relativamente à correspondência anterior. uricontent, isdataat e pcre abrangem casos mais específicos de URI, posição e expressões regulares.

Uma janela de pesquisa restrita reduz ocorrências acidentais e carga de processamento. Em especial, pcre, janelas grandes ou vários padrões content abrangentes só devem ser introduzidos com pacotes realistas e sob carga observada. Se depth for menor do que o padrão content pesquisado, a assinatura nunca poderá corresponder.

Cabeçalhos, streams e valores estruturados

A origem, o destino e a porta podem ser restringidos com srcaddr, dstaddr, srcport e dstport. Para os cabeçalhos IP estão disponíveis, entre outros, ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto e samip. As características TCP são descritas com flags, flow, seq, ack e window; itype, icode, icmp_id e icmp_seq aplicam-se a ICMP. rpc, byte_test e byte_jump destinam-se a protocolos estruturados ou binários.

Para regras complexas, utilizar a sintaxe IPS personalizada suportada pelo SFOS 22 e descrita acima. Não devem ser adotadas sem verificação palavras-chave Snort não documentadas nem regras copiadas de outros motores.

Criar a assinatura e atribuí-la a uma policy

Em Intrusion prevention > Custom IPS signatures > Add, são definidos Name, Protocol, Custom rule, Severity e Recommended action. Um nome como PILOT-TCP-8080-AVANET-TOKEN torna visíveis a finalidade e o limite do teste. Severity descreve a avaliação de risco própria; não prova que o padrão seja malicioso.

Na primeira execução, Recommended action permanece em Allow packet. Importante: a ação da regra da IPS policy substitui esta recomendação; a regra piloto também deve usar Allow packet. As outras ações têm consequências muito mais fortes:

• Drop packet elimina apenas o pacote correspondente.
• Drop session termina a sessão depois da ocorrência.
• Reset termina uma sessão TCP e envia um reset à origem.
• Bypass session permite o tráfego e deixa de analisar o resto da sessão.

Nas ações baseadas na sessão, o SFOS só verifica até ao primeiro pacote correspondente. Antes de substituir Allow packet por uma destas ações, deve confirmar-se que essa primeira ocorrência pertence à sessão pretendida.

Ao guardar, o SFOS reconfigura o motor IPS. Isto acontece sem interrupção se existir RAM livre suficiente. Com pouca RAM livre, o motor pode reiniciar e causar uma breve interrupção. Mesmo uma alteração aparentemente pequena deve, portanto, ser feita numa janela monitorizada. Depois de guardar, verificam-se o estado do IPS e ips.log quanto a um reinício ou erros antes de prosseguir com o piloto.

Segue-se a segunda parte, muitas vezes esquecida: em Intrusion prevention > IPS policies, abrir uma policy eliminável destinada ao piloto, adicionar uma regra, escolher Custom signature, selecionar a assinatura e colocar a regra específica acima das regras mais abrangentes. O SFOS avalia estas regras de cima para baixo. Depois, atribuir a policy em Rules and policies > Firewall rules > [regra piloto] > Detect and prevent exploits (IPS).

Efetuar um teste positivo e um teste negativo

O teste positivo envia o padrão acordado pela porta e na direção previstas. No Log viewer, no canto superior direito do WebAdmin, seleciona-se o módulo IPS e filtra-se por hora do teste, origem e destino. A assinatura ou SID, a ação e a data/hora devem corresponder ao teste. ips.log fornece detalhes adicionais. Packet Capture em Diagnostics > Packet capture mostra também Firewall Rule ID e IPS Policy ID. Testar sistematicamente uma regra de firewall explica a relação entre regra, captura e módulo de segurança.

Após o piloto, o efeito pode ser analisado em Reports > Network & threats > Intrusion attacks. Este relatório permite comparar períodos, mas não substitui os testes imediatos no Log viewer.

Segue-se pelo menos um teste negativo: o mesmo serviço sem o token, outra porta ou uma direção diferente. A assinatura não deve corresponder. Num padrão content, os pedidos normais da aplicação também são importantes, porque strings curtas ou genéricas podem aparecer em payloads totalmente legítimos.

Só depois de ambos os testes estarem estáveis se define a ação de bloqueio planeada e se volta a testar. Uma assinatura de bloqueio só é validada quando para exatamente o caso positivo, o caso negativo continua e nenhuma outra regra de firewall ou IPS causa o efeito.

Verificar o número de assinaturas

O número pode ser consultado no WebAdmin sem utilizar a shell. Em Intrusion prevention > IPS policies, abre-se uma policy eliminável e adiciona-se uma nova regra de policy. Com Select all, o SFOS mostra o total acima de Action. A lista só é visível ao adicionar uma regra a uma policy eliminável; depois, fecha-se o diálogo sem guardar.

A Sophos também documenta duas consultas apenas de leitura em 5. Device management > 3. Advanced shell:

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

O primeiro comando conta as assinaturas predefinidas e o segundo as Custom Signatures. Estas consultas à base de dados não alteram dados, mas continuam a pertencer a uma sessão documentada de suporte ou diagnóstico. O número não prova qualidade nem funcionamento e pode mudar com atualizações de patterns.

Quando a assinatura não funciona como esperado

Não há ocorrência

Primeiro, verifica-se se o IPS está ativo, se o tráfego corresponde à regra de firewall esperada com a IPS policy correta e se a Custom Signature está realmente presente numa regra de policy avaliada. Depois analisam-se o protocolo, a direção, a porta, a encriptação e o payload real. Uma string apresentada no browser não aparece necessariamente inalterada no pacote de rede.

Um Packet Capture com filtro restrito ajuda a confirmar o conteúdo visível e a direção. Se o padrão já não estiver presente aí, uma alteração da regra IPS não o pode criar. Se os pacotes forem visíveis, verificam-se offset, depth, distance, within, o estado do stream e a ordem das regras da policy.

Correspondem demasiadas ligações

A assinatura permanece em Allow packet até a origem, o destino, a porta, a direção ou a janela de pesquisa terem sido restringidos. Palavras genéricas, sequências binárias curtas e expressões regulares sem limites são causas típicas. Uma regra de firewall abrangente torna o efeito ainda mais difícil de controlar.

Se a firewall mostrar um aumento de recursos ou um reinício do IPS depois de guardar, devem ser recolhidos a hora, o modelo, o firmware, os recursos livres e ips.log. Guardar repetidamente variantes diferentes deixa de ser um teste limpo; primeiro é necessário esclarecer a causa e uma janela de manutenção.

Efetuar rollback com segurança

Em caso de ocorrências inesperadas, remove-se primeiro a regra personalizada da policy piloto ou repõe-se a IPS policy anterior na regra de firewall. Depois, verificam-se novas sessões com os testes positivo e negativo. A Custom Signature só é eliminada quando não tiver outra utilização.

Antes de eliminar, deve ficar documentado que policy, regra de firewall e aplicação a utilizavam. Os logs, a versão testada da regra e o motivo do rollback fazem parte do registo da alteração. Desativar o IPS globalmente ou remover toda a policy de produção não é um rollback adequado para uma única assinatura defeituosa.

FAQ