Introdução
Uma equipe normalmente envia documentos a docs.approved.test. Uma pequena captura gravada também contém uploads para outro destino. Você tem autorização para criar um detector offline desses intercâmbios sintéticos.
Uma captura de pacotes (PCAP) armazena pacotes de rede. O Suricata reconstrói suas requisições HTTP e testa regras. Aqui ele lê arquivos sem contatar esses hosts. Todos os nomes e documentos são fictícios. HTTP sem criptografia torna o corpo visível; este exercício não demonstra a leitura de HTTPS criptografado.
Use a aba Analyst para comandos. Selecione a aba Traffic Reference para ver as mesmas requisições preparadas de traffic/requests.txt; a página de referência abre diretamente. São exemplos gravados, não uma topologia ao vivo. Basta saber digitar no terminal e alternar abas; não é necessária experiência com IDS.
Reconhecer requisições de upload
Nesta etapa, crie a primeira regra para encontrar POSTs, inclusive uploads normais. Um alerta significa correspondência com uma regra; não prova comprometimento nem bloqueia tráfego.
Selecione a aba Analyst na interface do laboratório para começar esta etapa.
HTTP é um protocolo de requisições e respostas. O método indica a ação: POST envia conteúdo e GET solicita um recurso. O cabeçalho Host identifica o site de destino, a URI sua rota e o corpo os campos do documento enviado. Mude para a aba Traffic Reference para ver os intercâmbios HTTP preparados no navegador. A página é uma referência, não um monitor de pacotes ao vivo. Depois volte à aba Analyst para ler os mesmos intercâmbios e executar todos os comandos abaixo. cat imprime um arquivo; caminhos indicam sua localização.
Mude para a aba Analyst antes de executar o comando a seguir.
cat traffic/requests.txt
Compare o POST legítimo para docs.approved.test, o GET do coletor e o POST com classification=internal. A organização permite documentos internos no serviço aprovado. A rota do coletor aceita demonstrações públicas, mas não documentos internos. Destino e conteúdo importam juntos; um hostname desconhecido sozinho não é prova.
Uma regra Suricata tem cabeçalho e opções entre parênteses. alert http seleciona alertas sobre HTTP analisado. Os dois pares any any aceitam quaisquer endereços e portas de origem/destino; -> indica o sentido. flow:established,to_server limita a inspeção às requisições de um cliente conectado. Ponto e vírgula termina cada opção. msg descreve a correspondência, sid é o identificador numérico da assinatura e rev a revisão. Cada regra usa um sid exclusivo.
Um buffer persistente seleciona o campo HTTP inspecionado pelo próximo content. http.method seleciona o método. content:"POST" procura o texto; startswith e endswith exigem o campo inteiro em vez de uma substring. Use a regra abaixo.
cat > method.rules grava o arquivo e substitui o conteúdo anterior. <<'RULE' inicia entrada literal em várias linhas; o RULE final deve ocupar sua própria linha. É uma edição simples: se errar, execute novamente o bloco inteiro.
cat > method.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; sid:1000001; rev:1;)
RULE
Reproduza a captura. mkdir -p cria o diretório de saída e aceita um existente. --runmode single usa uma thread de processamento; -c seleciona a configuração, -S carrega apenas seu arquivo de regras, -r lê o PCAP e -l escolhe a saída. --init-errors-fatal interrompe se uma regra não carregar. A configuração inspeciona até 64 KB de cada corpo; todos os exemplos cabem. Os limites de uma implantação real precisam de avaliação separada.
mkdir -p method-output
suricata --runmode single -c suricata.yaml -S method.rules -r traffic/core.pcap -l method-output --init-errors-fatal
python3 /opt/c09/read-alerts.py method-output/eve.json
A mensagem de parada ao chegar ao fim do arquivo offline é normal. eve.json contém um objeto JSON por evento. JSON usa campos nomeados: event_type: alert identifica a correspondência, signature_id a regra e os campos HTTP a requisição. O leitor Python fornecido imprime porta de origem, método, host, URI e ID de assinatura de cada alerta. A porta relaciona o intercâmbio à referência; não é condição da política.
Espere Alerts: 10. Aparecem POSTs normais de documentos e POSTs do coletor. GET e PUT ficam silenciosos. Esse primeiro detector intencionalmente amplo ensina a correspondência de método.
O verificador executa sua regra inalterada em dois pequenos conjuntos independentes, usando diretórios temporários. Ele ignora logs salvos e preserva regra e capturas. Verifique o detector de método:
python3 /opt/c09/check.py method.rules method
As duas linhas devem indicar 10 intercâmbios esperados. Se houver erro de sintaxe, confira aspas, pontos e vírgulas e parêntese final; reescreva e tente novamente. Reutilizar a saída acrescenta eventos; use outro diretório para comparar quantidades. O verificador sempre começa limpo.
Selecionar o destino do coletor
Nesta etapa, combine método e host para excluir uploads normais ao serviço de documentos. Todos os buffers da regra devem corresponder à mesma transação HTTP.
Selecione a aba Analyst na interface do laboratório para começar esta etapa.
O nome do site de destino pertence a http.host, não à busca no corpo: um documento pode mencionar o coletor sem ser enviado a ele. O Suricata normaliza esse buffer para minúsculas. A referência contém collector.example.test.other.test, outro host. A correspondência do campo inteiro o mantém separado.
Crie um novo arquivo, preservando o primeiro detector para comparação. Cabeçalho e método continuam; o novo buffer acrescenta a condição de destino.
Mude para a aba Analyst antes de executar o comando a seguir.
cat > destination.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p destination-output
suricata --runmode single -c suricata.yaml -S destination.rules -r traffic/core.pcap -l destination-output --init-errors-fatal
python3 /opt/c09/read-alerts.py destination-output/eve.json
Espere Alerts: 6. O serviço aprovado e o host de nome semelhante desaparecem. POSTs a /status e /collect-backup ainda correspondem, pois a regra não distingue rotas. São falsos positivos conhecidos úteis: correspondências fora do comportamento que você quer investigar.
python3 /opt/c09/check.py destination.rules destination
Os dois conjuntos devem corresponder a seis intercâmbios de método e host. Se um host permitido ainda alertar, confira startswith; endswith; depois do conteúdo do host. Alterar JSON salvo não corrige o detector; altere a regra e reproduza.
Limitar a detecção à rota de upload
Nesta etapa, crie um detector de rota funcional reconhecendo sua limitação de conteúdo. A URI é a rota da requisição, como /collect, diferente do host.
Selecione a aba Analyst na interface do laboratório para começar esta etapa.
Use http.uri e o campo inteiro para selecionar exatamente /collect. /collect-backup é outra rota. Preserve método e destino para manter silenciosas verificações de saúde e destinos legítimos.
Mude para a aba Analyst antes de executar o comando a seguir.
cat > upload.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; http.uri; content:"/collect"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p route-output
suricata --runmode single -c suricata.yaml -S upload.rules -r traffic/core.pcap -l route-output --init-errors-fatal
python3 /opt/c09/read-alerts.py route-output/eve.json
Espere Alerts: 4 para 41002, 41003, 41007 e 41011. Compare os corpos na referência: dois documentos internos e duas demonstrações públicas. Todos são POSTs ao host e rota escolhidos. O monitoramento da rota funciona, mas superestima uploads sensíveis.
python3 /opt/c09/check.py upload.rules route
Ambos os conjuntos devem corresponder a quatro intercâmbios da rota. O verificador também muda nomes de documentos e portas de origem: valores incidentais não devem decidir a detecção. Explique o propósito da regra ao compartilhar alertas. O próximo laboratório acrescenta contexto documental e testa a redução de ruído em um ambiente novo.
Resumo
Você criou detectores de método, destino e rota com a reprodução real do Suricata. Relacionou alertas às requisições gravadas e identificou falsos positivos de documentos públicos antes de afirmar que detectava uploads sensíveis.
