Não entendo alguns conceitos básicos do módulo conntrack.
Em primeiro lugar, tenho certeza de que está ativado no meu sistema (Ubuntu 18.04), modinfo
mostra informações sobre nf_conntrack e /proc/modules
o arquivo informa que nf_conntrack está "ao vivo".
Segundo, tenho a seguinte configuração de teste:
Máquina A (192.168.1.2) <-----> Máquina Roteadora (192.168.1.1 e 192.168.2.1) <----> Máquina B (192.168.2.2)
Na máquina do roteador eu tenho a seguinte regra do iptables:
iptables -t filter -A FORWARD -m set --match-set BlackListPort dst -j DROP
BlackListPort é uma tabela ipset.
Agora estabeleço uma conexão SSH da Máquina A (1.2) para a Máquina B (2.2). Depois de confirmar que funciona, adiciono a porta 22 (padrão SSH) à tabela BlackListPort.
A conexão SSH congela/trava até que eu remova a porta 22 dessa tabela ipset.
Agora a pergunta : Como o conntrack está presente no meu sistema, por que o bloco SSH é bem-sucedido? A conexão SSH foi estabelecida antes que a porta 22 fosse adicionada ao ipset, então o conntrack deve pular todos os pacotes, permitindo que o SSH funcione.
Isso não está correto.
Todos os pacotes serão processados através das regras de filtro, sejam eles pertencentes a conexões rastreadas ou não.
É uma otimização muito comum das regras do iptables colocar algo assim perto do início da cadeia de regras relevante (
FORWARD
no seu exemplo):Em distribuições mais antigas, você pode ver esta versão:
(Entendo que a
conntrack
partida agora é preferida àstate
partida. Acho que algumas versões do kernel até incomodam você por causa disso.)Isso permitirá que os pacotes pertencentes a conexões existentes passem, se houver informações de rastreamento de conexão para eles. Mas o ponto é que você pode controlar onde exatamente você coloca essa regra ou se você a usa. Assim, você pode fazer com que suas regras de firewall se preocupem com os estados de conexão tanto - ou tão pouco - quanto você quiser.