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 com Allow packet e logging num pequeno percurso piloto. Drop packet, Drop session, Reset e Bypass session alteram o tráfego de produção e só devem ser usados depois de um teste positivo e de um teste negativo 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 Allow packet.
3. Adicionar a assinatura a uma regra própria numa IPS policy eliminável.
4. Atribuir esta IPS policy apenas à regra de firewall piloto prevista e ativar o logging.
5. Gerar um teste correspondente e outro deliberadamente não correspondente e comparar Log Viewer, ips.log e a correspondência da regra.
6. Definir a ação pretendida apenas depois de uma validação estável; remover a atribuição da policy ou a assinatura 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.

A referência completa da sintaxe IPS personalizada do SFOS 22 continua a ser vinculativa para regras complexas. 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. 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.

Ao guardar, o SFOS reconfigura o motor IPS. Segundo a Sophos, 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.

Segue-se a segunda parte, muitas vezes esquecida: em Intrusion prevention > IPS policies, abrir uma policy eliminável destinada ao piloto, adicionar uma regra, selecionar a Custom Signature e colocar a regra específica acima das regras mais abrangentes. Em seguida, atribuir esta policy em Rules and policies > Firewall rules à regra piloto que corresponde efetivamente.

Efetuar um teste positivo e um teste negativo

O teste positivo envia o padrão acordado pela porta e na direção previstas. Em simultâneo, são registados no Log Viewer Firewall Rule ID, IPS policy, nome da assinatura, origem, destino, ação e hora. ips.log fornece detalhes adicionais do motor; Testar sistematicamente uma regra de firewall explica a relação entre regra, Packet Capture e módulo de segurança.

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 na 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