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 de aplicação claramente definido. Pode, por exemplo, detetar uma cadeia de caracteres conhecida em texto simples, uma característica invulgar de um 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 política IPS, essa política tem de estar associada à regra de firewall efetivamente aplicada e o fluxo de dados tem de estar visível para o IPS. Um padrão demasiado abrangente pode bloquear tráfego legítimo; um padrão demasiado restrito pode não produzir correspondências.

Testar primeiro uma nova assinatura numa regra IPS piloto com Action: Allow packet. Mesmo que Recommended action já esteja definida como Allow packet, é a ação da regra da política IPS que prevalece. Drop packet, Drop session, Reset ou Bypass session alteram o tráfego de produção e só devem ser utilizados em produção após testes positivos e negativos reproduzíveis.

Um piloto controlado em seis passos

1. Descrever o caso a detetar, indicando o protocolo, a direção, a porta e um padrão inequívoco.
2. Em Intrusion prevention > Custom IPS signatures, criar uma assinatura com uma regra restrita e Recommended action: Allow packet.
3. Adicionar a assinatura a uma regra própria numa política IPS que possa ser eliminada e selecionar aí Action: Allow packet.
4. Atribuir esta política IPS apenas à regra de firewall prevista para o piloto e ativar aí Log firewall traffic.
5. Gerar um teste que corresponda ao padrão e outro que deliberadamente não corresponda, e comparar o Log Viewer, ips.log e a correspondência com a regra.
6. Alterar a ação da regra da política IPS apenas após uma validação estável; perante correspondências inesperadas, repor a atribuição anterior da política.

Uma entrada guardada ou uma verificação de sintaxe bem-sucedida ainda não comprovam o funcionamento. O sucesso significa que o teste positivo corresponde exatamente à assinatura personalizada e à regra de firewall esperadas, que o teste negativo não produz correspondências e que o comportamento da aplicação em produção se mantém inalterado.

Quando é adequada uma assinatura personalizada

As assinaturas personalizadas são adequadas para características estáveis e visíveis ao nível dos pacotes ou dos fluxos. Pode tratar-se de um valor de protocolo proprietário, de um indicador claro de exploração de uma vulnerabilidade ou de uma proteção temporária para uma vulnerabilidade conhecida internamente. O percurso de dados esperado e a reação pretendida têm de estar definidos antes de escrever a assinatura.

Para endereços IP ou domínios que mudam, são geralmente mais adequados os hosts, serviços e grupos, os Threat Feeds ou regras de firewall restritas. Além disso, uma assinatura personalizada não substitui a gestão de patches nem uma regra devidamente concebida pelo fabricante. Para uma ocorrência isolada no registo, manter um desenvolvimento próprio permanente raramente é proporcional.

Os dados de payload cifrados constituem uma limitação importante. O IPS só consegue detetar um padrão content no payload HTTPS se o conteúdo for efetivamente decifrado no percurso de processamento escolhido e estiver visível para o motor. Sem uma inspeção TLS adequada, normalmente só ficam disponíveis características não cifradas ou visíveis por outros meios.

Verificar previamente a licença e o ciclo de vida

Para ativar o IPS, é necessária uma subscrição Network Protection ativa ou uma licença de avaliação válida, bem como acesso de administrador à assinatura, à política e à regra de firewall. Antes do piloto, registam-se a atribuição atual da política, o ID da regra e uma cópia de segurança para recuperação. Os 30 dias referidos abaixo começam a contar a partir da expiração da licença ou da desativação manual do IPS, e não apenas na tentativa de configuração seguinte.

Não é possível configurar assinaturas personalizadas quando a licença de avaliação do IPS tiver expirado ou quando IPS Protection estiver desativada em Intrusion prevention > IPS policies. A Sophos recomenda voltar a ativar o IPS no prazo de 30 dias para preservar as assinaturas personalizadas existentes. Por isso, uma cópia de segurança ou uma exportação deve fazer parte do plano de recuperação antes de alterações à licença, ao IPS ou de alterações significativas às políticas.

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

Delimitar claramente a sintaxe das regras

Limitações da documentação para SFOS 22/23: A ajuda de sintaxe contém exemplos com formatação contraditória: distance: 4.within:4; não é um modelo fiável para copiar; no caso de byte_jump, o texto explicativo refere operandos de comparação que não constam do esquema de sintaxe. As designações dos bits TCP reservados também não são claras. Estes pontos não são interpretados como capacidades adicionais do motor. Os fragmentos explicados abaixo continuam a ser exemplos da documentação, e não regras testadas numa firewall. Se uma regra for rejeitada ou parecer ambígua, guardar a versão exata da compilação, a regra e a mensagem de erro e pedir esclarecimentos ao suporte da Sophos; até lá, não autorizar nenhuma ação de bloqueio em produção.

O formulário de introdução separa Protocol de Custom rule. Na regra, combinam-se palavras-chave individuais com os respetivos valores e um ponto e vírgula. Quanto mais características independentes tiverem de coincidir, menor será, em geral, o risco de correspondê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 exclusivamente controlado em texto simples, pode utilizar-se TCP como protocolo e, por exemplo, o seguinte padrão restrito de payload:

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

AVANET-IPS-PILOT é um valor de documentação deliberadamente distintivo. A regra de firewall piloto correspondente é também limitada ao serviço de teste, por exemplo à porta TCP 8080. O token, a direção e a porta são substituídos por valores que ocorram no fluxo de dados real e 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 abrangentes de produção.

Payload e janela de pesquisa

content procura uma sequência de caracteres ou de bytes; os valores binários são escritos entre caracteres de barra vertical. nocase ignora maiúsculas e minúsculas numa correspondência de conteúdo; rawbytes trabalha sobre os dados em bruto. depth e offset delimitam a pesquisa de forma absoluta no payload, enquanto distance e within trabalham relativamente à correspondência anterior. uricontent, isdataat e pcre abrangem verificações mais específicas de URI, posição e expressões regulares.

Uma área de pesquisa restrita reduz as correspondências acidentais e o esforço de processamento. Em particular, pcre, janelas grandes ou vários padrões de conteúdo abrangentes só devem ser introduzidos com pacotes realistas e sob monitorização da carga. Se depth for inferior ao comprimento do padrão de conteúdo procurado, a assinatura nunca poderá produzir uma correspondência.

Os modificadores nocase, rawbytes, depth, offset, distance e within pertencem a content; não são regras de deteção independentes. Sem depth, a pesquisa decorre desde offset até ao fim do payload. Sem within, a pesquisa de um segundo padrão de conteúdo também permanece aberta desde distance até ao fim. Por isso, um ponto de início, por si só, não basta para manter a janela de pesquisa restrita. uricontent pesquisa o URI normalizado do pedido, e não dados de payload arbitrários. isdataat verifica se existem dados numa posição indicada; com relative, essa posição é relativa ao fim da correspondência de conteúdo anterior.

Cabeçalhos, fluxos e valores estruturados

A origem, o destino e a porta podem ser delimitados 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 ao ICMP. rpc, byte_test e byte_jump destinam-se a protocolos estruturados ou binários.

flow aplica-se apenas ao TCP. Neste contexto, to_server e from_client são equivalentes, tal como to_client e from_server. bi_direction alarga a deteção a ambas as direções; quando existe uma restrição por porta, o teste negativo tem, por isso, de contemplar também o tráfego de retorno. A escolha entre no_stream e only_stream não deve ser confundida com uma verificação do tamanho dos pacotes: dsize verifica o tamanho do payload de um pacote e não produz correspondências em pacotes reconstituídos a partir de um fluxo. Por isso, uma combinação com only_stream não é adequada. Quando não há correspondência, decide-se primeiro se a característica deve ser procurada no pacote individual ou no fluxo reconstituído, em vez de alterar apenas o tamanho ou o padrão de conteúdo.

Para regras complexas, aplica-se a sintaxe de IPS personalizado suportada pelo SFOS 22 e descrita acima. Palavras-chave Snort não documentadas ou regras copiadas de outros motores não devem ser adotadas sem verificação.

Operandos: endereço, porta, URI e posição dos dados

Os fragmentos seguintes devem ser introduzidos em Custom rule, e não na shell. São uma referência para SFOS 22/23, não assinaturas de ataque prontas e testadas. Combinam-se apenas as condições adequadas ao caso a detetar; Protocol, a política piloto e Allow packet continuam a fazer parte do teste descrito acima. Os parênteses retos nos modelos de sintaxe identificam partes opcionais e não são introduzidos.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; compara os IP de origem e de destino com endereços individuais. Os endereços de documentação são substituídos pelos endereços de teste observados; daqui não se pode inferir suporte para sub-redes ou listas de endereços.

• srcport:40000; dstport:8080; compara as portas de origem e de destino com números. A porta de destino representa aqui o serviço de teste. Uma porta de origem do cliente que varie só deve ser fixada se fizer realmente parte do caso a detetar; caso contrário, as novas ligações não satisfarão esta condição.

• uricontent:"/ips-pilot"; procura o caminho substituível no URI normalizado do pedido. Também são possíveis padrões mistos de texto e dados binários. A comparação tem de corresponder ao valor do URI normalizado, e não apenas à forma apresentada na barra de endereços do navegador.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; exige adicionalmente dados na posição 50 relativamente ao fim desta correspondência de conteúdo. Sem relative, a posição no payload é absoluta. O número é escolhido de acordo com a estrutura real do protocolo; verifica a disponibilidade de dados, não o conteúdo desses dados.

• content:"ABC"; content:"DEF"; distance:1; within:10; utiliza dois padrões substituíveis com uma janela de pesquisa relativa. distance define a distância a partir do fim da primeira correspondência; within limita a pesquisa seguinte. Para janelas absolutas, offset e depth também recebem valores numéricos, por exemplo offset:4; depth:20; no content correspondente. Estes números são escolhidos com base na posição e no comprimento reais do padrão; não são valores predefinidos do protocolo.

Expressões regulares com pcre

As formas básicas são pcre:"/REGEX/"; e pcre:"m/REGEX/";. Um ! antes das aspas de abertura nega a expressão, por exemplo pcre:!"/AVANET-IPS-PILOT/i";. Trata-se de uma condição de ausência de correspondência e pode ter um alcance muito amplo sem restrições adicionais. REGEX ou o token do piloto é substituído pelo padrão necessário. As opções são colocadas depois da / de fecho, por exemplo pcre:"/AVANET-IPS-PILOT/i";.

• i ignora maiúsculas e minúsculas; s permite que . também corresponda a quebras de linha.
• m permite que ^ e $ também atuem no início e no fim das linhas no buffer. x ignora caracteres de espaço em branco não escapados no padrão, exceto nas classes de caracteres.
• A ancora a correspondência no início do buffer. E associa $ apenas ao fim real, e não à posição anterior a uma quebra de linha final.
• G inverte o comportamento guloso predefinido dos quantificadores; um ? subsequente volta a invertê-lo.
• R começa relativamente ao fim da última correspondência de padrão. U utiliza buffers de URI descodificados; B não utiliza buffers descodificados.

Por isso, antes do piloto, define-se em que buffer e a partir de que posição o padrão deve ser aplicado. Uma expressão regular correta para dados em bruto não tem necessariamente de corresponder a um URI descodificado.

Ler campos binários: byte_test e byte_jump

byte_test lê um campo e verifica o seu valor numérico. O esquema é byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT é o número de bytes lidos e OFFSET o ponto de início no payload; com relative, o início é relativo à última correspondência de padrão. VALUE é o valor de comparação. Estão documentados <, >, =, ! e &: menor, maior, igual, diferente e AND bit a bit, respetivamente. Um ! antes de um operador de comparação nega o respetivo resultado. big ou little define a ordem dos bytes. Com string, são lidos algarismos em texto em vez de um campo numérico binário; hex, dec e oct aplicam-se apenas a este modo de texto.

Exemplo de um campo binário: byte_test:2,=,16,0,big; lê dois bytes a partir da posição 0 do payload em big-endian e compara o valor com 16. O número de bytes, a posição, a ordem dos bytes e o valor de comparação têm de ser determinados pelo protocolo, e não por este exemplo. Um valor numérico fortuito não comprova um ataque.

byte_jump, por sua vez, lê um comprimento e desloca a posição para as verificações seguintes. O esquema é byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. Os dois primeiros operandos determinam a largura do campo e a posição de leitura; relative torna o deslocamento relativo à última correspondência de padrão. multiplier multiplica o valor lido para determinar a distância do salto. align arredonda essa distância por excesso para o limite de 32 bits seguinte. Com from_beginning, a distância do salto é aplicada a partir do início do payload, em vez da posição atual. string e as bases numéricas têm a mesma finalidade que em byte_test.

byte_jump:2,0,big; é, portanto, um fragmento para um campo de comprimento de dois bytes no início do payload, com a ordem dos bytes explicitamente escolhida. Não é uma comparação de tamanho; o operador de comparação e o valor de comparação não são operandos de byte_jump. Para ambas as palavras-chave de bytes, escolhe-se explicitamente big ou little nos campos binários de vários bytes: não se deve confiar numa ordem de bytes predefinida inferida da documentação. Primeiro, confirmar o campo e o destino do salto no payload real de teste; depois, verificar um caso positivo e um caso negativo para a condição seguinte. Um comprimento incorreto pode levar a posição de pesquisa para além do padrão pretendido.

Campos IP, opções e fragmentos

• ttl:64;, ttl:>64; e ttl:<64; comparam o Time to Live do IP por igualdade, por valor superior ou por valor inferior. tos:16; compara o campo TOS; id:1234; compara o campo IP-ID. Estes números de exemplo não são valores de deteção recomendados; são escolhidos com base na característica do cabeçalho efetivamente procurada.
• ipopts:rr; verifica a presença de uma opção IP. Os valores permitidos são rr (Record Route), eol (End of List), nop (No Operation), ts (Timestamp), sec (Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier) e any (qualquer opção IP). Portanto, any exige uma opção, e não simplesmente um pacote IP qualquer.
• fragoffset:0; compara o deslocamento do fragmento no cabeçalho IP com um número decimal. Este campo não é o deslocamento de pesquisa de conteúdo no payload.
• fragbits verifica M (More Fragments), D (Don’t Fragment) e R (Reserved). Um + anteposto permite outros bits além dos indicados; * exige pelo menos um dos bits indicados e ! exige que os bits indicados não estejam definidos. Assim, fragbits:+M; verifica se More Fragments está definido, sem excluir outros bits.
• dsize:300;, dsize:>300;, dsize:<300; e dsize:300<>400; descrevem o tamanho exato do payload, uma comparação superior/inferior ou um intervalo. Os números referem-se aos dados de payload do pacote, não à ligação inteira. Mantêm-se as limitações relativas aos fluxos reconstituídos explicadas acima.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; e ip_proto:<6; comparam o identificador numérico do protocolo no cabeçalho IP, e não a porta TCP/UDP. samip; não tem valor e exige que os IP de origem e de destino sejam iguais.

Campos TCP e seleção de fluxos

flags verifica as flags TCP: S para SYN, A para ACK, F para FIN, R para RST, U para URG e P para PSH. Sem modificador, por exemplo, flags:S; verifica a presença exclusiva de SYN. Um +, * ou ! anteposto tem o significado explicado acima para fragbits. Por isso, flags:+S; permite flags adicionais. A ajuda mostra um segundo grupo opcional de flags após uma vírgula, mas não explica a sua semântica de comparação. Assim, não tratar flags:S,A; como uma instrução confirmada para ignorar ACK; esclarecer este comportamento para a compilação instalada antes da utilização. Os casos especiais relativos a bits TCP reservados e a «nenhuma flag definida» não são aqui disponibilizados deliberadamente como sintaxe pronta a copiar; necessitam de uma regra confirmada para a versão específica e não devem ser inferidos de uma designação ambígua.

Para flow, estão disponíveis as direções já explicadas, bem como established, no_stream e only_stream. flow:established; exige uma ligação TCP estabelecida. flow:no_stream; exclui pacotes de fluxos reconstituídos; flow:only_stream; limita a deteção a esses pacotes. Estes fragmentos explicam cada seleção individual e não constituem uma indicação para utilizar as duas opções de fluxo em conjunto. bi_direction continua a ser o alargamento ao tráfego de ida e de retorno descrito acima.

seq:1234;, ack:1234; e window:4096; comparam, respetivamente, o número de sequência TCP, o número de confirmação e o tamanho da janela com um número. Os valores exatos de sequência ou de ACK mudam entre ligações e só fazem sentido se esse valor específico fizer parte do caso a detetar. A janela TCP não é uma janela de pesquisa no payload.

ICMP e RPC

itype:8; e icode:0; comparam o tipo e o código ICMP. Ambos também suportam <, > e intervalos como itype:3<>5;; o tipo e o código são campos distintos. icmp_id:1234; e icmp_seq:1; comparam por igualdade o identificador ICMP e o valor de sequência. Os valores são escolhidos com base no caso ICMP pretendido, não equiparados a números de sequência TCP.

rpc:100000,2,*; verifica, em pedidos SUNRPC-CALL, o número de aplicação 100000, a versão 2 e qualquer procedimento. O esquema é rpc:APPLICATION,VERSION,PROCEDURE;; * é permitido para a versão e para o procedimento, mas não para o número de aplicação. Os números são substituídos pela aplicação, versão e procedimento procurados. Um caráter universal não dispensa a análise do protocolo: deixa deliberadamente em aberto a parte correspondente, alargando assim a deteção.

Criar uma assinatura e atribuí-la a uma política

Em Intrusion prevention > Custom IPS signatures > Add, definem-se Name, Protocol, Custom rule, Severity e Recommended action. Um nome como PILOT-TCP-8080-AVANET-TOKEN torna visíveis a finalidade e os limites do teste. Severity descreve a avaliação de risco feita pelo administrador; não comprova que o padrão seja malicioso.

Na primeira execução, Recommended action mantém-se em Allow packet. Importante: a ação da regra da política IPS sobrepõe-se a esta recomendação. Por isso, a regra piloto também tem de utilizar Allow packet. As restantes ações têm consequências significativamente mais fortes:

• Drop packet descarta apenas o pacote correspondente.
• Drop session termina a sessão após a correspondência.
• Reset termina uma sessão TCP e envia um reset para a origem.
• Bypass session permite o tráfego e deixa de inspecionar o resto da sessão.

Nas ações baseadas em sessões, o SFOS só inspeciona até ao primeiro pacote correspondente. Antes de mudar de Allow packet para uma dessas ações, é necessário confirmar que esse primeiro resultado corresponde exatamente à sessão pretendida.

Ao guardar, o SFOS reconfigura o motor IPS. Se houver RAM livre suficiente, isto ocorre sem interrupção. Se houver pouca RAM livre, o motor pode reiniciar e causar uma breve interrupção. Por isso, mesmo alterações a uma assinatura aparentemente pequena devem ser efetuadas numa janela monitorizada. Depois de guardar, verificam-se o estado do IPS e ips.log quanto a reinícios ou erros, antes de prosseguir com o piloto.

Após esta verificação preliminar, guardar a assinatura com Save e voltar a abrir a respetiva entrada: Protocol, Custom rule, Severity e Recommended action têm de corresponder aos valores planeados. Manter Firewall Acceleration e PKI Acceleration inalteradas durante o piloto; cada ativação ou desativação reinicia o IPS e falseia a comparação. A verificação de zonas, Trusted MAC, os pares IP-MAC e as exceções DoS são mecanismos separados, descritos em Proteção contra DoS e spoofing, e não propriedades de uma assinatura personalizada.

Segue-se a segunda parte, frequentemente esquecida: em Intrusion prevention > IPS policies, abrir uma política destinada ao piloto que possa ser eliminada, adicionar uma regra, selecionar Custom signature, marcar a assinatura e posicionar a regra específica acima das regras mais abrangentes. O SFOS avalia as regras das políticas IPS de cima para baixo. Guardar a regra da política com Save e, depois, guardar também a política IPS que a contém com Save. Voltar a abrir a política e verificar a seleção da assinatura e a ação guardadas. Em seguida, associar esta política à regra piloto efetivamente aplicada em Rules and policies > Firewall rules > [regra piloto] > Detect and prevent exploits (IPS); guardar também a regra de firewall e verificar com uma nova sessão.

Gerir o mesmo objeto de assinatura através da XML API

Quem automatiza o piloto trabalha com o objeto XML IPSCustomSignature, e não com uma regra de política IPS. A referência SFOS 22/23 designa as operações como Add Custom Signature, Update custom signature e Delete Custom Signature. O acesso, a operação explícita de escrita, a cópia de segurança, a avaliação da resposta e a paragem perante um payload por esclarecer são explicados de forma centralizada em Utilizar a XML API em segurança. Antes de escrever, é necessário confirmar a definição do objeto e a operação em API help da compilação instalada; aqui não é fornecido nenhum pedido de escrita executável adicional.

No exemplo de objeto, Name, Protocol, CustomRule, Severity e RecommendedAction estão dentro de IPSCustomSignature. Name identifica a assinatura, não a política nem a regra de firewall. A tabela de parâmetros exige para este campo uma cadeia de caracteres escalar com, no máximo, 15 caracteres; Delete também exige esse nome exato. Por isso, para automatização via API, escolher um nome curto e inequívoco, como IPS-PILOT-8080. O nome mais longo do exemplo WebAdmin acima não é um modelo para copiar para a API. Antes de Update ou Delete, consultar a identidade efetivamente guardada e todas as utilizações em políticas, em vez de inferir o alvo a partir de um SID ou de uma entrada com um nome semelhante.

A tabela identifica os cinco dados de Add/Update como obrigatórios e escalares. Protocol permite TCP, UDP, ICMP ou ALL; Severity permite Critical, Major, Moderate, Minor ou Warning. CustomRule contém a definição da assinatura como cadeia de caracteres. A designação Custom Rule da tabela, com espaço, não é a grafia XML CustomRule. A indicação adicional de separar letras com um ponto não explica uma conversão geral de regras nem o escape XML. Por isso, não alterar mecanicamente a sintaxe descrita acima introduzindo pontos; verificar antes o conteúdo da regra e a codificação XML correta para a compilação. O exemplo do fabricante utiliza apenas SignatureDefinition como marcador de posição; isso não produz uma assinatura pronta a utilizar nem uma assinatura que comprovadamente detete tráfego malicioso.

Não confundir recomendação com ação: O exemplo XML utiliza RecommendedAction, enquanto a tabela de parâmetros designa o mesmo tema como Action. Como valores de texto, apresenta Allow Packet, Drop Packet, Drop Session, Reset e Bypass Session, bem como, adicionalmente, 3. Isto não constitui uma autorização confirmada para substituir RecommendedAction por uma etiqueta XML Action. Não é explicado qualquer significado de 3 nem qualquer correspondência com uma ação textual; não adivinhar esse valor nem utilizá-lo como abreviatura de uma ação específica. Consultar a recomendação efetivamente guardada e continuar a verificar separadamente a ação da regra da política IPS. Um objeto criado através da API não substitui a atribuição da política nem os testes positivos e negativos.

Confrontar as respostas da API com a operação e o estado guardado

As linhas seguintes estão documentadas nas referências dos objetos SFOS 22/23. Os nomes Message.* continuam a ser símbolos da documentação por resolver: não são mensagens de execução garantidas, textos de erro traduzidos nem causas definitivamente confirmadas. Os números também são códigos de estado XML, não códigos de estado HTTP. Guardar em conjunto a operação, o código e a resposta efetiva; não substituir as linhas específicas do objeto por uma interpretação geral dos códigos do artigo central sobre a API.

Para Add Custom Signature, a referência indica:

• 200 — Message.CustomSigAddSuccess
• 500 — Message.CustomSigAddFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigInvalidSignatureRule
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Para Update custom signature, indica:

• 200 — Message.CustomSigUpdateSuccess
• 500 — Message.CustomSigUpdateFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigCustomSignatureCheck1
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Em particular, 504 distingue Add de Update pelo símbolo; Message.CustomSigCustomSignatureCheck1 não é reinterpretado como uma mensagem de erro de sintaxe supostamente inequívoca. Antes de repetir Add/Update, voltar a abrir a entrada no WebAdmin ou verificá-la com uma consulta de leitura confirmada para a compilação: Name, Protocol, Custom rule, Severity e Recommended action correspondem ao estado pretendido? Perante 502, comparar a identidade existente com a pretendida, sem substituir automaticamente nem criar sob um segundo nome. Perante 504, confrontar também a regra exata com a documentação da compilação. Perante 505, verificar em conjunto o estado guardado, o estado do IPS e ips.log; o símbolo não permite concluir que houve uma reversão segura nem autoriza o reinício do motor. Perante 506, verificar o estado do IPS e da licença descrito na secção sobre o ciclo de vida, mas não alterar o estado do IPS por tentativa. Mesmo após 200, continua a ser necessário verificar os valores guardados, a associação à política e o percurso dos dados; 500 não comprova que não tenha ocorrido qualquer alteração parcial.

Para Delete Custom Signature, estão documentadas estas linhas específicas:

• 200 — Message.CustomSigDeleteSuccess
• 500 — Message.CustomSigDeleteFailed
• 503 — Message.CustomSignatureInUse
• 506 — Message.CustomSignatureIpsOff

Autorizar Delete apenas após a reversão descrita abaixo e uma verificação completa das utilizações. Perante 503, examinar as referências das políticas ao objeto efetivo, sem eliminar indiscriminadamente uma política de produção. Perante 506, esclarecer o estado do IPS e da licença, em vez de desativar globalmente o IPS para tentar eliminar o objeto. Após a resposta, confirmar a ausência do nome exato e o estado esperado das políticas dependentes; perante 500 ou uma resposta ambígua, não repetir a eliminação às cegas. Se o estado guardado, a resposta ou a responsabilidade continuarem por esclarecer, parar a automatização e esclarecer com o suporte da Sophos, fornecendo a resposta expurgada de dados sensíveis, a versão da regra, a compilação e os registos. Não se afirma aqui que qualquer comportamento em execução tenha sido testado numa firewall.

Realizar testes positivos e negativos

O teste positivo envia o padrão acordado pela porta prevista e na direção esperada. No Log Viewer, no canto superior direito do WebAdmin, seleciona-se o módulo IPS e filtra-se pela hora do teste, Source e Destination. A assinatura ou o SID, a ação e a hora têm de corresponder ao teste. ips.log fornece detalhes adicionais do motor. O Packet Capture em Diagnostics > Packet capture mostra também Firewall Rule ID e IPS Policy ID. A relação entre a regra, o Packet Capture e o módulo de segurança é explicada em Testar sistematicamente uma regra de firewall.

Após a fase piloto, também é possível avaliar o efeito em Reports > Network & threats > Intrusion attacks. O relatório é útil para comparações entre períodos, mas não substitui os testes positivos e negativos realizados atempadamente no Log Viewer. XGS 87/87w e XGS 88/88w não suportam relatórios locais no dispositivo; nestes modelos, efetuar as verificações imediatas descritas no Log Viewer.

Segue-se pelo menos um teste negativo: o mesmo serviço sem o token, uma porta diferente ou uma direção diferente. A assinatura não deve produzir correspondências. No caso de um padrão de conteúdo, também são importantes os pedidos normais da aplicação, pois cadeias curtas ou genéricas podem ocorrer em payloads perfeitamente legítimos.

Só quando ambos os testes forem estáveis se define a ação de bloqueio planeada e se volta a verificar. Uma assinatura de bloqueio só é considerada validada se bloquear precisamente o caso positivo, permitir que o caso negativo continue e nenhuma outra regra de firewall ou de IPS for responsável pelo efeito.

Verificar o número de assinaturas

O número pode ser determinado no WebAdmin sem recorrer à shell. Em Intrusion prevention > IPS policies, abre-se uma política que possa ser eliminada e cria-se uma nova regra de política. Com Select all, o SFOS mostra o número total acima de Action. A lista só é visível ao adicionar uma regra a uma política que possa ser eliminada; depois, a caixa de diálogo pode ser fechada sem guardar.

A Sophos documenta adicionalmente duas consultas 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; o segundo conta as assinaturas personalizadas. Estas consultas à base de dados não alteram nada, mas devem ser realizadas numa sessão documentada de suporte ou de diagnóstico. O número não comprova a qualidade nem o funcionamento e pode mudar com as atualizações de padrões.

Espera-se, para cada consulta, uma única linha de resultado sob count, seguida de (1 row). Os valores de exemplo da Sophos, 28623 e 1, provêm de um exemplo de SFOS 19.0.1 e não são valores de referência para SFOS 22/23. Perante erros de base de dados, de ligação ou de permissões, não alterar tabelas nem serviços: utilizar a verificação no WebAdmin e guardar a saída exata e a compilação para o suporte.

Quando a assinatura não funciona como esperado

Não há correspondências

Primeiro, verifica-se se o IPS está ativo, se o tráfego corresponde à regra de firewall esperada com a política IPS correta e se a assinatura personalizada está efetivamente numa regra de política que é avaliada. Depois, verificam-se o protocolo, a direção, a porta, a cifragem e o payload real. Uma cadeia apresentada no navegador não tem necessariamente de constar sem alterações no pacote de rede.

É útil uma captura de pacotes com filtros restritos que mostre a direção, a porta e o conteúdo visível nesse ponto de captura. No entanto, a ausência de um padrão em texto simples numa captura cifrada não comprova a sua ausência no buffer IPS decifrado. Por isso, verificar em conjunto o ponto de captura, a decifragem e a reconstituição do fluxo. Num teste controlado em texto simples, tem de ser possível confirmar o padrão efetivamente transmitido; depois, verificam-se offset, depth, distance, within, o estado do fluxo e a ordem das regras da política.

Demasiadas ligações produzem correspondências

A assinatura mantém-se em Allow packet até se restringirem Source, Destination, a porta, a direção ou a janela de pesquisa. 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, após guardar, a firewall apresentar um aumento do consumo de recursos ou um reinício do IPS, guardar a hora, o modelo, o firmware, os recursos livres e ips.log. Guardar repetidamente variantes diferentes não constitui, nessa situação, um teste rigoroso; primeiro, esclarecem-se a causa e a janela de manutenção.

Reverter em segurança

Perante correspondências inesperadas, remover primeiro a regra personalizada da política piloto ou repor a política IPS anterior na regra de firewall. Depois, verificar novas sessões com testes positivos e negativos. A assinatura personalizada só é eliminada quando não tiver qualquer outra utilização.

Antes da eliminação, deve estar documentado que política, regra de firewall e aplicação a utilizaram. Os registos, a versão da regra testada e o motivo da reversão devem constar do registo da alteração. Desativar globalmente o IPS ou remover toda a política de produção não é uma reversão adequada para uma única assinatura defeituosa.

FAQ