iptables módulo conntrack: estado SNAT (ou DNAT) no lugar de ESTABLISHED / RELATED?

Question

Por um tempo agora (introduzido na versão 1.3, acredito), o módulo iptables ' conntrack pode rastrear dois estados virtuais, SNAT e DNAT:

SNAT A virtual state, matching if the original source address differs from the reply destination. DNAT A virtual state, matching if the original destination differs from the reply source.

No meu host de roteador / firewall, tenho algumas regras para o SNAT assim:

# SNAT
iptables -t filter -A FORWARD -i $FROM_IFACE -o $TO_IFACE -s $FROM_IP -d $TO_IP -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -i $TO_IFACE -o $FROM_IFACE -s $TO_IP -d $FROM_IP -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o $TO_IFACE -s $FROM_IP -d $TO_IP -j SNAT --to-source $SNAT_IP

# DNAT
iptables -t nat -A PREROUTING -i $FROM_IFACE -d $FROM_IP -p $PROTO --dport $PORT -j DNAT --to-destination $TO_IP
iptables -t filter -A FORWARD -i $FROM_IFACE -o $TO_IFACE -d $TO_IP -p $PROTO --dport $PORT -j ACCEPT
iptables -t filter -A FORWARD -i $TO_IFACE -o $FROM_IFACE -s $TO_IP -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Depois de um pouco de googling, não consegui encontrar nenhum exemplo das regras iptables usando esses "novos" estados SNAT ou DNAT , mas tentei mesmo assim substituir ESTABLISHED,RELATED por SNAT ou DNAT , assim:

# SNAT
iptables -t filter -A FORWARD -i $FROM_IFACE -o $TO_IFACE -s $FROM_IP -d $TO_IP -m conntrack --ctstate NEW,SNAT -j ACCEPT
iptables -t filter -A FORWARD -i $TO_IFACE -o $FROM_IFACE -s $TO_IP -d $FROM_IP -m conntrack --ctstate SNAT -j ACCEPT
iptables -t nat -A POSTROUTING -o $TO_IFACE -s $FROM_IP -d $TO_IP -j SNAT --to-source $SNAT_IP

# DNAT
iptables -t nat -A PREROUTING -i $FROM_IFACE -d $FROM_IP -p $PROTO --dport $PORT -j DNAT --to-destination $TO_IP
iptables -t filter -A FORWARD -i $FROM_IFACE -o $TO_IFACE -d $TO_IP -p $PROTO --dport $PORT -j ACCEPT
iptables -t filter -A FORWARD -i $TO_IFACE -o $FROM_IFACE -s $TO_IP -m conntrack --ctstate DNAT -j ACCEPT

Parecia funcionar , e esse método tem pelo menos um benefício que eu notei: meu firewall costumava remover pacotes RST dos meus hosts internos para a Internet (já que eles estão em INVALID state), mas com este novo método, eles foram autorizados a passar .

Infelizmente, apesar de conveniente, não tenho certeza se esse método é realmente adequado, porque meu conhecimento teórico sobre redes não é suficiente para entender se é muito permissivo (ou seja, permitir que alguns pacotes indesejados de fora da minha LAN cheguem lá dentro).

Acho que minha pergunta poderia ser assim: um pacote pode ter o estado SNAT ou DNAT , embora não tenha também o estado ESTABLISHED ou RELATED (exceto, obviamente, o primeiro que tem o NEW state)?

Observação: tentei registrar tais pacotes, mas, que eu saiba, é impossível, pois iptables aceita apenas uma opção --ctstate e ! não pode ser usado dentro dela (em outras palavras, eu não posso dizer, ou pelo menos não consegui encontrar uma maneira de dizer, "logar pacotes que possuem% estadoSNAT mas não ESTABLISHED ou RELATED estado"). Se existe um método alternativo para registrá-los, eu não pensei, isso também seria muito bem-vinda.

EDIT 1: depois de algumas tentativas e erros, eu percebi que estava errado (daí o texto acariciado): alguns pacotes ainda estão no estado INVALID e assim finalmente caíram.

EDIT 2: se usar SNAT / DNAT no lugar de ESTABLISH,RELATED não for seguro, forneça alguns exemplos concretos de casos em que os pacotes poderiam estar naqueles estados anteriores sem estarem nestes últimos.

    

Answer 1

Graças ao conselho da @ AB sobre o registro, eu pude fazer mais alguns testes e aqui estão os resultados, assim como as respostas às minhas próprias perguntas, na esperança de que isso ajude outras pessoas que, como eu, não encontre algo na web sobre os estados SNAT e DNAT e / ou sua capacidade de substituir ESTABLISHED,RELATED para correspondência.

Assim, em uma rede doméstica moderadamente movimentada (alguns hosts que acessam a Internet via SNAT, bem como algumas máquinas virtuais que hospedam servidores (HTTP / HTTPS, SMTP, IMAP, etc.) acessíveis publicamente pela DNAT), em cinco dias, eu não vi uma única linha de log sobre um pacote que estaria em SNAT ou DNAT state, e não também ESTABLISHED ou RELATED .

Assim, a resposta à pergunta "pode um pacote ter o estado SNAT ou DNAT , embora não tenha também o estado ESTABLISHED ou RELATED " é não .

Como minha verdadeira preocupação era que a correspondência com SNAT ou DNAT em vez de ESTABLISHED,RELATED permitir que os pacotes entrassem em minha LAN poderia ser muito permissiva, isso pareceria tranquilizador no começo, mas descobri que não é uma boa ideia.

Na verdade, parece que isso é, ao contrário, menos permissivo: durante meus testes com essas regras, eu vi um pequeno mas não desprezível número de pacotes no estado RELATED que foram descartados, principalmente ICMP tipo 3, códigos 1 e 3 (respectivamente host de destino inacessível e porta de destino inacessível ), vindos da Internet e destinados aos hosts dentro da minha LAN. Em outras palavras (e se eu entendi as redes corretamente), meus hosts tentaram fazer algumas conexões com a Internet, os roteadores remotos responderam que a conexão não poderia ser feita, e meu próprio host de firewall / roteador bloqueava essas respostas. Isso não pode ser bom.

Assim, a resposta para a pergunta subjacente "É uma boa ideia substituir ESTABLISHED,RELATED por SNAT ou DNAT " é, novamente, não .

    

Answer 2

Eu não usaria seu método para segurança. Imagine que você refaz sua rede e não precisa mais usar o SNAT. O que aconteceria? Essa é a parte óbvia. Pode haver problemas ocultos à espreita em algum lugar.

Tanto quanto possível, as regras NAT e as regras de filtragem devem permanecer independentes, a menos que haja uma boa razão para não o fazer. Não tenho certeza se você tem um bom motivo. Uma boa razão seria tratar de forma diferente o tráfego NAT do tráfego não NAT (por exemplo: o servidor DNATs um serviço para outro servidor, mas não permite ser usado como roteador para acesso direto ao servidor / serviço por trás .

Agora, sobre sua anotação: basta dividir o problema em várias etapas.

Esta regra incorreta:

iptables -A FORWARD -m conntrack --ctstate SNAT ! --ctstate ESTABLISHED,RELATED -j LOG

pode ser substituído por:

iptables -N subtest
iptables -A FORWARD -m conntrack --ctstate SNAT -j subtest
iptables -A subtest -m conntrack ! --ctstate ESTABLISHED,RELATED -j LOG

ou, em vez disso, com RETURN e lógica invertida:

iptables -N speciallog
iptables -A FORWARD -j speciallog
iptables -A speciallog -m conntrack ! --ctstate SNAT -j RETURN
iptables -A speciallog -m conntrack ! --ctstate ESTABLISHED,RELATED -j LOG

ou, usando marcas (não se marcas são usadas em outro lugar (e não querendo se preocupar com máscaras)) também pode alcançar o mesmo:

iptables -A FORWARD -m conntrack --ctstate SNAT -j MARK 1
iptables -A FORWARD -m mark --mark 1 -m conntrack ! --ctstate ESTABLISHED,RELATED -j LOG

Para cada método, pode-se imaginar encadear mais testes facilmente (incrementando a marca para o método mark).