O tcpdump ignora o iptables?

Por engano, configurei o servidor DNS do resolvedor aberto, que logo foi usado para vários ataques DDoS originários de algum lugar da / para a Rússia. Por esse motivo, bloqueei completamente a porta 53 nos dois servidores DNS para todos, exceto para IPs confiáveis. Funciona, não consigo mais me conectar a eles, mas o que me parece estranho é que, quando executo o tcpdump no eth1 (que é a interface no servidor com a Internet pública), vejo muitos pacotes de entrada do invasor até a porta 53.

É normal que o tcpdump exiba esses pacotes mesmo que o iptables os descarte? Ou eu configurei o iptables errado?

Por outro lado, não vejo pacotes de saída do meu servidor, o que vi antes, então suponho que o firewall esteja funcionando. Apenas me surpreende que o kernel não descarte pacotes completamente? Ou está tcpdumpligado ao kernel de uma maneira que vê os pacotes antes mesmo de chegarem ao iptables?

Esta é uma boa pergunta.

Por uma questão de fato, o tcpdump é o primeiro software encontrado após a ligação (e a NIC, se você desejar) no caminho IN , e o último no caminho OUT .

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Assim, ele vê todos os pacotes atingindo sua interface e todos os pacotes deixando sua interface. Como os pacotes da porta 53 não recebem uma resposta, como visto pelo tcpdump, você verificou com êxito que suas regras do iptables foram configuradas corretamente.

EDITAR

Talvez eu deva adicionar alguns detalhes. O tcpdump é baseado na libpcap , uma biblioteca que cria um soquete de pacote . Quando um pacote normal é recebido na pilha de rede, o kernel primeiro verifica se há um soquete de pacote interessado no pacote recém-chegado e, se houver, encaminha o pacote para esse soquete. Se a opção ETH_P_ALL for escolhida, todos os protocolos passarão pelo soquete do pacote.

A libpcap implementa um desses soquetes de pacotes com a opção ativada, mantém uma cópia para seu próprio uso e duplica o pacote de volta na pilha de rede, onde é processado pelo kernel da maneira usual, incluindo passá-lo primeiro para o netfilter , o kernel contraparte espacial do iptables . A mesma coisa, na ordem inversa ( ou seja , primeiro netfilter e depois a passagem pelo soquete do pacote), na saída.

Isso é propenso a hackers? Mas é claro. Certamente, existem rootkits de prova de conceito usando o libpcap para interceptar as comunicações destinadas ao rootkit antes que o firewall possa colocar sua mão neles. Mas mesmo isso empalidece em comparação com o fato de uma simples consulta do Google descobrir código de trabalho que oculta o tráfego até da libpcap . Ainda assim, a maioria dos profissionais pensa que as vantagens superam amplamente as desvantagens na depuração de filtros de pacotes de rede.