Logs & Integração SIEM

O Sentinel DNS gera logs estruturados e de alta performance de resolução DNS e eventos de segurança (bloqueios RPZ, tentativas de acesso a domínios maliciosos e ações do módulo AnaBlock). Estes logs são nativamente preparados para integração com plataformas de SIEM (Security Information and Event Management) e centros de operações de segurança (SOC/NOC).

1. Visão Geral do Sistema de Logging

Em um ambiente de operadora de telecomunicações (ISP) ou grande datacenter, o volume de logs de DNS pode chegar a milhares de EPS (Eventos Por Segundo). O Sentinel DNS otimiza isso em duas camadas:

  • Logs de Resolução (Trace): Apenas habilitados em modo de debug estrito devido ao alto volume.
  • Logs de Segurança (Action/Block): Registram especificamente ações do RPZ (NODATA, NXDOMAIN, passthrough), atualizações de feed de Threat Intelligence e bloqueios AnaBlock. Volume focado e ideal para consumo de SIEM.

2. Formatos de Exportação Suportados

Para garantir máxima compatibilidade com sistemas legados e modernos, o Sentinel DNS suporta nativamente:

  • Syslog Padrão (RFC 5424/3164): Enviado via UDP ou TCP, direto para o host de coleta local.
  • JSON Estruturado: Formato chave-valor ideal para parsing imediato (sem necessidade de Regex/Grok pesados).
  • Log em Disco Nativo: Utiliza o journalctl (systemd) ou arquivos físicos em /var/log/unbound.log para ingestão por agentes locais (ex: Filebeat, Fluentbit).

3. Integração com Soluções de SIEM

A ingestão recomendada em um ambiente de NOC/SOC é instalar um agente leve (shipper) na própria máquina do Sentinel DNS, que fará o forward para a ferramenta SIEM central. Exemplos comuns:

  • Elastic Stack (ELK): Utilizar o Filebeat lendo o arquivo /var/log/unbound.log. Módulo nativo disponível para parse de log unbound.
  • Splunk: Instalar o Splunk Universal Forwarder monitorando o diretório de log.
  • Graylog: Configurar um coletor Syslog UDP/TCP e apontar o Unbound para enviar os logs de segurança para a porta de ingestão.

4. Estrutura e Campos Disponíveis

Os logs estruturados do Sentinel DNS contém o contexto completo da transação bloqueada, permitindo fácil correlação:

{
  "timestamp": "2026-07-25T14:32:01.455Z",
  "client_ip": "192.168.45.12",
  "query": "malicious-c2-domain.com",
  "qtype": "A",
  "action": "BLOCKED",
  "reason": "RPZ_NXDOMAIN",
  "policy_source": "Threat_Intel_API",
  "category": "C2_Botnet"
}

Dicionário de Campos Principais:

  • client_ip: Endereço IP do cliente/CPE que fez a requisição.
  • action: ALLOWED, BLOCKED, ou REDIRECTED.
  • reason: A regra específica do RPZ que engatilhou (ex: NODATA, NXDOMAIN).
  • policy_source: De onde veio a regra (AnaBlock_Judicial, Manual, Threat_Intel_API).

5. Retenção e Rotação (Logrotate)

Para evitar preenchimento de disco, o Sentinel DNS implanta automaticamente regras restritas de logrotate na instalação.

  • Frequência: Rotação Diária.
  • Retenção Local: 7 dias (padrão editável em /etc/logrotate.d/unbound).
  • Compressão: Arquivos antigos são comprimidos com gzip automaticamente.

Nota Operacional: A retenção a longo prazo e o armazenamento para compliance legal devem ser realizados no SIEM ou Cold Storage externo, não no disco físico do Appliance DNS.

6. Exemplo de Dashboards e NOC

A estrutura de logs foi desenhada para correlacionar perfeitamente com os dashboards de Threat Hunting. Consultas típicas feitas no Elastic (KQL) ou Splunk:

Top IPs infectados na rede tentando contato com Botnets (KQL):

action: "BLOCKED" AND category: "C2_Botnet" | stats count by client_ip | sort -count

Pico de bloqueios Judiciais/AnaBlock (Splunk SPL):

sourcetype=sentinel_dns policy_source="AnaBlock_Judicial" | timechart span=1h count by query
Políticas RPZ