Por um tempo agora (introduzido na versão 1.3, acredito), iptables
' o módulo conntrack pode rastrear dois estados virtuais, SNAT e DNAT:
SNAT Um estado virtual, correspondendo se o endereço de origem original for diferente do destino de resposta. DNAT Um estado virtual, correspondendo se o destino original for diferente da fonte de resposta.
No meu roteador/host de firewall, tenho algumas regras para SNAT como esta:
# 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 pesquisar bastante no Google, não consegui encontrar nenhum exemplo de iptables
regras usando esses "novos" SNAT
ou DNAT
estados, mas tentei de qualquer maneira 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
Pareceu funcionar , e esse método tem pelo menos um benefício que pude notar: meu firewall costumava descartar pacotes RST indo de meus hosts internos para a Internet (já que estão no .INVALID
estado), mas com esse novo método, eles foram autorizados a passar
Infelizmente, embora 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 ao interior).
Acho que minha pergunta poderia ser formulada assim: um pacote pode ter o estado SNAT
or DNAT
sem ter o estado ESTABLISHED
or RELATED
(exceto, obviamente, o primeiro que tem o NEW
estado)?
Nota: Eu tentei logar tais pacotes, mas pelo que sei é impossível, pois iptables
aceita apenas uma --ctstate
opção e !
não pode ser usado dentro dela (ou seja, não posso dizer, ou pelo menos não consegui encontrar uma maneira de dizer, "registrar pacotes que têm SNAT
estado, mas não ESTABLISHED
ou RELATED
estado"). Se houver um método alternativo para registrá-los em que não pensei, isso também seria muito bem-vindo.
EDIT 1: depois de algumas tentativas e erros, percebi que estava errado (daí o texto riscado): alguns pacotes ainda estão no estado INVALID
e, portanto, finalmente descartados.
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 podem estar nesses estados anteriores sem estar nos últimos.
Graças ao conselho de @AB sobre o logging, pude fazer mais alguns testes e aqui estão os resultados, bem como as respostas para minhas próprias perguntas, na esperança de ajudar outras pessoas que, como eu, não encontraram nada na web sobre os estados
SNAT
eDNAT
, e/ou sua capacidade de substituirESTABLISHED,RELATED
para correspondência.Portanto, em uma rede doméstica moderadamente ocupada (alguns hosts acessando a Internet por SNAT, bem como algumas máquinas virtuais hospedando servidores (HTTP/HTTPS, SMTP, IMAP, etc etc) publicamente acessíveis por DNAT), em cinco dias, eu não vi uma única linha de log sobre um pacote que estaria em
SNAT
ouDNAT
estado, e não tambémESTABLISHED
ouRELATED
.Portanto, a resposta para a pergunta "um pacote pode ter o estado
SNAT
orDNAT
sem ter o estadoESTABLISHED
orRELATED
" é não .Como minha verdadeira preocupação era que a correspondência contra
SNAT
ouDNAT
em vez deESTABLISHED,RELATED
permitir que os pacotes entrassem na minha LAN pudesse ser muito permissiva, isso pareceria reconfortante no início, mas descobri que não é uma boa ideia.Na verdade, parece que isso é, ao contrário, menos permissivo: durante meus testes com essas regras, vi um número pequeno, mas não desprezível, de pacotes em 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 ), provenientes da Internet e destinados aos hosts dentro da minha LAN. Em outras palavras (e se eu entendo as redes corretamente), meus hosts tentaram fazer algumas conexões com a Internet, os roteadores remotos responderam que a conexão não pôde ser feita e meu próprio host de firewall/roteador bloqueou essas respostas. Isso não pode ser bom.Portanto, a resposta para a pergunta subjacente "É uma boa ideia substituir
ESTABLISHED,RELATED
porSNAT
ouDNAT
" é, novamente, não .Eu não usaria seu método por segurança. Imagine que você retrabalha sua rede e não precisa mais usar SNAT. O que aconteceria? Essa é a parte óbvia. Pode haver problemas ocultos à espreita em algum lugar.
Tanto quanto possível, as regras de NAT e as regras de filtro devem permanecer independentes, a menos que haja um bom motivo para não fazê-lo. Não tenho certeza se você tem um bom motivo. Uma boa razão seria tratar tráfego NATed de forma diferente do tráfego não NATed (por exemplo: o servidor DNATs um serviço para outro servidor atrás, mas não permite ser usado como roteador para acesso direto ao servidor/serviço atrás ).
Agora sobre sua nota: apenas divida o problema em várias etapas.
Esta regra incorreta:
pode ser substituído por:
ou então com RETURN e lógica reversa:
ou, usando marcas (não se as marcas forem usadas em outro lugar (e não querendo se preocupar com máscaras)) também pode conseguir o mesmo:
Para cada método, pode-se imaginar encadear mais testes facilmente (incrementando a marca para o método de marca).