Troubleshooting

causa

O nome da interface configurado em af-packet não existe de verdade na máquina — normalmente porque foi copiado de outro contexto (eth0, comum em guias genéricos ou hardware físico, enquanto VMs costumam usar enp0s3 ou similar). O Suricata não erra ao iniciar com uma interface errada, ele só nunca captura nada.

correção

Rode ip a na própria máquina, confirme o nome real, e atualize o campo interface em af-packet no suricata.yaml. Confira também se o HOME_NET aponta pro IP real da máquina, não um endereço de exemplo.

causa

Esse é o gateway interno da rede Docker — aparece quando o teste é feito de dentro da própria máquina host da VM (ssh -p 2222 root@localhost), não de outro ponto da rede.

correção

Não é um erro de configuração. Pra validar a captura de tráfego "de verdade", teste sempre de outra máquina da rede, nunca de dentro da própria VM.

causa

O serviço sshd pode ter voltado a escutar na porta padrão (22) em vez da porta de gestão configurada — um upgrade do pacote openssh-server pode restaurar o sshd_config original se o gerenciador de pacotes interpretar o arquivo como não modificado, dependendo de como um prompt de conflito foi respondido.

correção

Confirme com sudo ss -tlnp | grep ssh em qual porta ele está de fato escutando. Se as linhas de hardening no sshd_config estiverem comentadas (com # na frente), descomente e reinicie o serviço. Prevenção: sudo apt-mark hold openssh-server depois de tudo estabilizado.

causa mais comum

Rodar o comando SSH com sudo na frente muda qual usuário (e, portanto, qual chave privada) é usado — sudo ssh ... procura a chave em /root/.ssh/, não na pasta do seu usuário normal.

segunda causa possível

A chave pública nunca foi de fato copiada pro authorized_keys do usuário certo — especialmente fácil de acontecer se o clipboard entre host e VM estiver desabilitado (recomendado por segurança) e a chave tiver sido colada manualmente, com algum caractere perdido no processo.

correção

Nunca use sudo na frente de um comando ssh comum. Pra copiar a chave sem depender de colar manualmente, use ssh-copy-id -p PORTA usuario@IP — evita o problema por completo.

causa

O docker-compose.yaml referencia uma rede marcada como external: true — ou seja, espera que ela já exista — mas ela nunca foi criada.

correção

docker network create nome-da-rede antes do docker compose up.

causa

A imagem oficial do Cowrie é minimalista de propósito (menos binários = menor superfície de ataque se alguém escapar do sandbox) — não inclui tail nem outros utilitários de coreutils.

correção

Use docker logs cowrie --tail 20 (lê via o driver de log do Docker, não depende de nada dentro do container) ou leia o arquivo direto do volume, pelo host.

causa

Grafana e Loki rodando em containers Docker separados não compartilham 127.0.0.1 — cada container tem seu próprio loopback isolado. Usar http://127.0.0.1:3100 como URL do Data Source aponta o Grafana pra ele mesmo, não pro Loki.

correção

Coloque os dois containers na mesma rede Docker dedicada e use o nome do container como hostname (http://loki:3100) — resolvido via DNS interno do Docker, disponível só entre containers da mesma rede.

causa

O Alloy roda como usuário de sistema não-root. A pasta /var/lib/docker costuma ter permissão drwx--x---, que bloqueia usuários fora do grupo root de sequer atravessar essa pasta — mesmo o arquivo de log final estando com leitura liberada, a cadeia quebra no meio do caminho.

como diagnosticar

sudo namei -l /caminho/completo/do/arquivo.json lista a permissão de cada pasta do caminho, uma por linha — mostra exatamente onde a cadeia quebra.

correção

sudo setfacl -m u:alloy:x /var/lib/docker — dá permissão de atravessar só pro usuário do Alloy, sem abrir a pasta pra mais ninguém.

causas possíveis

Regra de encaminhamento de porta ainda não configurada no roteador, ou o provedor de internet usa CGNAT (NAT compartilhado da operadora) — nesse segundo caso, o pacote nem chega no seu roteador.

correção

Confirme o IP público real com curl -4 ifconfig.me e teste com canyouseeme.org antes de insistir em ajustar a configuração do roteador. Se confirmar CGNAT, port-forward tradicional não é uma opção — considere pedir IP público ao provedor ou usar um túnel reverso.

causa

Uma regra criada sem restringir a origem (ufw allow PORTA/tcp, sem o from) libera a porta pra qualquer IPv4 e qualquer IPv6 — IPv6 não passa por NAT do roteador do jeito que IPv4 passa, então isso pode expor a porta à internet mesmo sem nenhum port-forward configurado.

correção

sudo ufw delete allow PORTA/tcp
sudo ufw allow from SUA_SUB_REDE/24 to any port PORTA proto tcp

Confirme no ufw status verbose que aparece sua sub-rede, não Anywhere, e que não sobrou nenhuma linha (v6).

causa

O Promtail foi oficialmente descontinuado e removido do repositório de releases do Loki — não é uma questão de versão errada, o binário não existe mais.

correção

Use o Grafana Alloy no lugar — mesmo papel (agente de coleta de logs), configuração diferente (linguagem River em vez de YAML). Detalhes no capítulo 4.

o que está acontecendo

É esperado — o processo interno de estabilização do "ring" do Loki pode levar de 15 segundos a 1-2 minutos, dependendo da máquina. Não é travamento nem erro de configuração.

quando se preocupar

Se passar de uns 2-3 minutos sem nunca ficar ready, aí sim vale investigar — checar o relógio do sistema (VMs às vezes têm desincronização) e os logs do container com docker logs loki.