Introdução
Sistemas de Detecção de Intrusão (IDS), como o Snort, dependem fortemente de regras para identificar tráfego de rede malicioso. Uma regra bem elaborada atua como uma assinatura, permitindo que o sistema dispare um alerta quando padrões específicos são observados nos pacotes de dados.
A detecção baseada em assinatura funciona reconhecendo padrões conhecidos, e não compreendendo diretamente a intenção do atacante. Isso a torna rápida e útil, mas também imperfeita. Se o padrão for muito amplo, ele gera falsos positivos. Se for muito restrito, os atacantes podem evitá-lo com pequenas alterações. Portanto, escrever boas regras é um exercício de equilíbrio entre precisão e cobertura.
Neste laboratório, você assumirá o papel de um analista de segurança. Você escreverá regras Snort de correspondência de conteúdo capazes de detectar ataques na camada de aplicação. Especificamente, você analisará um payload de ataque de SQL Injection simulado capturado em um arquivo PCAP (Packet Capture) e criará regras Snort precisas usando tanto a correspondência de conteúdo básica quanto Expressões Regulares avançadas (PCRE) para inspecionar o tráfego HTTP e emitir um alerta sempre que essa string maliciosa for detectada.
Analisar o Payload do Ataque (PCAP)
Nesta etapa, você analisará um arquivo de captura de pacotes de rede para entender como é um payload malicioso. Antes de escrever uma regra de detecção, um analista de segurança deve saber exatamente o que está tentando detectar.
Essa ordem é importante. Um erro comum de iniciantes é começar a escrever assinaturas antes de inspecionar o tráfego real. Na prática, os defensores geralmente começam com evidências: um PCAP, uma amostra de log ou uma prova de conceito de exploit. Somente após entender o padrão observável é que eles o traduzem em uma regra.
Seu ambiente foi pré-configurado com um arquivo chamado sqli_attack.pcap no seu diretório ~/project. Este arquivo contém um pacote de rede simulado onde um atacante está tentando realizar um ataque de SQL Injection contra um servidor web.
Para inspecionar o conteúdo deste arquivo PCAP, você pode usar uma ferramenta chamada tcpdump. O comando tcpdump é um poderoso analisador de pacotes de linha de comando. Ao usar a flag -A, você pode imprimir o conteúdo do pacote em ASCII (texto simples), o que é perfeito para ler requisições HTTP. A flag -r diz ao tcpdump para ler de um arquivo em vez de uma interface de rede ativa.
Execute o seguinte comando no seu terminal para analisar o payload:
tcpdump -A -r sqli_attack.pcap
Você deverá ver uma saída semelhante à seguinte:
reading from file sqli_attack.pcap, link-type EN10MB (Ethernet), snapshot length 262144
10:23:45.123456 IP 192.168.1.100.12345 > 192.168.1.10.http: Flags [P.], seq 1:78, ack 1, win 8192, length 77: HTTP: GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
E..u..@.@............9.P..P.P.......+......GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
Host: example.com
Observe atentamente a parte em texto simples da saída. Você pode ver uma requisição HTTP GET sendo feita para /login.php. Observe o parâmetro user: admin'%20UNION%20SELECT%201,2,3--.
O %20 é a representação codificada em URL de um caractere de espaço. A frase UNION SELECT é uma assinatura clássica de um ataque de SQL Injection, onde um atacante tenta combinar os resultados de sua própria consulta maliciosa ao banco de dados com a consulta original. Esta é a assinatura exata que queremos detectar.
Escrever Regras de Correspondência de Conteúdo
Nesta etapa, você escreverá sua primeira regra Snort personalizada para detectar a assinatura de SQL Injection que você descobriu na etapa anterior.
A palavra-chave content é a forma mais simples de inspeção de payload. Ela é rápida e fácil de entender porque busca por uma string literal. A correspondência literal é frequentemente o primeiro rascunho ideal para uma assinatura, pois torna a lógica de detecção transparente.
As regras do Snort são escritas em uma sintaxe específica. Uma regra básica consiste em um cabeçalho de regra e opções de regra.
- O cabeçalho define a ação, o protocolo, os endereços IP de origem/destino e as portas.
- As opções definem o conteúdo específico a ser procurado e a mensagem a ser exibida quando um alerta é disparado.
Criaremos uma regra que procura pela string exata UNION%20SELECT em qualquer tráfego TCP destinado à porta 80 (a porta HTTP padrão).
Abra o arquivo de regras personalizadas usando o editor de texto nano:
nano ~/project/rules/local.rules
Adicione a seguinte linha ao arquivo:
alert tcp any any -> any 80 (msg:"Basic SQL Injection Detected"; content:"UNION%20SELECT"; sid:1000001; rev:1;)
Vamos detalhar o que essa regra significa:
alert: A ação a ser tomada quando a regra corresponder (gerar um alerta).tcp: O protocolo a ser inspecionado.any any -> any 80: IP e porta de origem (qualquer) indo para o IP de destino (qualquer) na porta 80.msg:"...": A mensagem de alerta a ser exibida ao analista.content:"UNION%20SELECT": A string exata que o Snort buscará no payload do pacote.sid:1000001: O ID do Snort. Regras personalizadas devem ter um ID de 1.000.000 ou superior.rev:1: O número de revisão da regra.
Após adicionar a linha, salve o arquivo e saia do nano pressionando Ctrl+O, Enter e, em seguida, Ctrl+X.
Você pode verificar o conteúdo do seu arquivo de regras usando o comando cat:
cat ~/project/rules/local.rules
Configurar PCRE (Expressões Regulares)
Nesta etapa, você aprimorará suas capacidades de detecção usando PCRE (Perl Compatible Regular Expressions).
As expressões regulares aumentam a flexibilidade porque descrevem famílias de padrões em vez de uma sequência exata de bytes. Isso é poderoso, mas também aumenta o risco de correspondência excessiva. Os defensores usam PCRE quando é provável que os atacantes variem a formatação enquanto mantêm o comportamento subjacente reconhecível.
Embora a palavra-chave content seja rápida e eficaz, ela é muito rígida. Os atacantes frequentemente tentam evitar a detecção alterando ligeiramente seus payloads. Por exemplo, em vez de %20 (espaço codificado em URL), um atacante pode usar um espaço normal (``), múltiplos espaços ou um sinal de mais (+). Uma correspondência simples de content perderia essas variações.
O PCRE permite que você escreva padrões flexíveis. Escreveremos uma segunda regra que usa uma expressão regular para capturar variações do ataque UNION SELECT.
Abra seu arquivo de regras novamente:
nano ~/project/rules/local.rules
Adicione a seguinte nova regra em uma nova linha abaixo da sua primeira regra:
alert tcp any any -> any 80 (msg:"Advanced SQL Injection Detected"; pcre:"/UNION(%20|\s|\+)SELECT/i"; sid:1000002; rev:1;)
Vamos detalhar a opção pcre:
pcre:"/ ... /i": As barras denotam o início e o fim da expressão regular. Oino final torna a busca insensível a maiúsculas/minúsculas (corresponderá aunion,UNION,UnIoN, etc.).UNION: Corresponde à palavra UNION.(%20|\s|\+): Este é um grupo de captura com lógica OU (|). Ele corresponde a%20, OU a um caractere de espaço em branco (\s), OU a um sinal de mais (\+).SELECT: Corresponde à palavra SELECT.
Salve o arquivo e saia do nano (Ctrl+O, Enter, Ctrl+X).
Seu arquivo local.rules agora deve conter duas regras distintas projetadas para capturar tentativas de SQL Injection.
Validar a Detecção da Regra
Nesta etapa final, você colocará suas regras personalizadas à prova. Você executará o Snort no modo offline, instruindo-o a ler o arquivo sqli_attack.pcap e aplicar as regras que você acabou de escrever em local.rules.
Testar contra uma amostra conhecida é essencial, pois uma regra que parece correta no papel pode falhar operacionalmente. A validação confirma que a regra realmente dispara no tráfego que você pretendia, o que é o requisito mínimo antes de confiar nela em um ambiente real.
O Snort pode ser executado com várias flags. Aqui está o que usaremos:
-q: Modo silencioso (Quiet). Isso suprime o banner grande e o texto de inicialização, tornando a saída mais fácil de ler.-c: Especifica o arquivo de configuração ou de regras a ser usado.-r: Especifica o arquivo PCAP a ser lido.-A console: Diz ao Snort para imprimir alertas diretamente no console do terminal.
Execute o seguinte comando para testar suas regras contra o payload malicioso:
sudo snort -q -c rules/local.rules -r sqli_attack.pcap -A console
Se suas regras foram escritas corretamente, você deverá ver uma saída semelhante a esta:
10/23-10:23:45.123456 [**] [1:1000001:1] Basic SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80
10/23-10:23:45.123456 [**] [1:1000002:1] Advanced SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80
Parabéns! Ambas as suas regras foram disparadas com sucesso. A primeira regra correspondeu à string exata, e a segunda regra correspondeu ao padrão usando expressões regulares. Você atuou com sucesso como um analista de segurança, identificando uma ameaça e implantando uma assinatura para detectá-la.
Resumo
Neste laboratório, você obteve experiência prática com detecção de intrusão em rede escrevendo regras Snort personalizadas. Você começou analisando uma captura de pacotes bruta para identificar a assinatura específica de um ataque de SQL Injection. Em seguida, aprendeu como traduzir essa assinatura em uma regra Snort básica de correspondência de conteúdo. Finalmente, você aprimorou suas capacidades de detecção implementando Expressões Regulares Compatíveis com Perl (PCRE) para capturar variações do ataque e validou com sucesso suas regras executando o Snort contra o tráfego malicioso. Essas habilidades são fundamentais para qualquer profissional de cibersegurança encarregado de defender a infraestrutura de rede.
