Bloqueio aplicado não é bloqueio verificado

Quase toda ferramenta de bloqueio funciona do mesmo jeito: detecta um ataque, roda um comando no firewall e marca o IP como bloqueado. O problema está na última parte. “Rodei o comando” e “a regra está lá agora” são afirmações diferentes, e a distância entre as duas é maior do que parece.

O que apaga uma regra sem avisar

Num servidor de verdade, várias coisas mexem no firewall além da sua ferramenta de bloqueio:

• Reloads de outras ferramentas. ufw, firewalld e CSF reconstroem as próprias cadeias quando recarregam. Dependendo de como fazem isso, um salto que outra ferramenta inseriu na INPUT some junto.
• Disputa de posição. Ferramentas que querem ficar no topo da INPUT podem trocar de lugar em ciclos. Aconteceu com o próprio atalince e o mailcow, que trocavam de posição a cada vinte segundos, até a versão 1.0.2 do agente corrigir.
• Reinício do servidor. Regras de iptables não sobrevivem a um boot sozinhas.
• Famílias diferentes. Um bloqueio que existe em IPv4 não protege nada se o ataque vem por IPv6 e o firewall dessa família não está disponível.

Em todos esses casos, o painel da ferramenta continua mostrando “bloqueado”. Ninguém mentiu de propósito; só ninguém voltou para conferir.

Quatro estados, não um

O atalince mostra cada bloqueio como uma trilha com quatro etapas:

1. Detectado: o detector leu o log e identificou o ataque.
2. Bloqueio solicitado: o painel pediu ao agente daquele servidor.
3. Aplicação informada pelo agente: o agente aplicou e mandou um recibo.
4. Leitura do firewall verificada: uma leitura do kernel confirmou que a regra está lá.

As etapas 3 e 4 parecem iguais, mas não são. O recibo diz que o comando rodou sem erro. A leitura diz que, no momento em que o agente olhou, o bloqueio estava de pé.

O que a leitura confere

De hora em hora, o painel pede a leitura dos bloqueios ativos. O agente aplica o que estiver pendente, repara os saltos e então lê o kernel, conferindo três coisas para cada bloqueio:

• a INPUT salta para a cadeia ATALINCE-BANS;
• a cadeia tem a regra de descarte do conjunto (-m set --match-set atalince-bans src -j DROP);
• o IP está dentro do conjunto atalince-bans.

Se uma delas falha, o painel diz qual. “A entrada (INPUT) não passa pela cadeia de bloqueio” é um recado bem diferente de “o IP não está no conjunto”, e cada um pede uma ação diferente. No caso do salto apagado por um reload, o agente percebe e refaz sozinho.

Desconhecido não é sucesso

A regra mais importante da trilha é sobre o que acontece quando falta informação. Se o recibo não chegou, ou se a leitura não pôde ser feita, o estado fica desconhecido. O painel escreve isso com todas as letras: “Sem evidência; não equivale a sucesso.”

Parece um detalhe de interface, mas é uma decisão de produto. Um painel que arredonda o desconhecido para cima é um painel em que você não pode confiar no dia em que mais precisa dele.

Na prática

Na página de bloqueios, cada linha mostra o estado atual, e o detalhe abre a trilha com o horário de cada etapa. Se você quiser saber quantos bloqueios estão de fato confirmados agora, esse é o número que importa, e não o total de pedidos.

Leia mais sobre como isso funciona em Proteção.