detalhes das entradas do conntrack

Question

Eu estou lendo a documentação do Iptables sobre o rastreamento de conexão aqui e tenho problemas para entender a parte seguinte , destacado por mim:

tcp   6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
 dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
 dport=32775 [ASSURED] use=2

This example contains all the information that the conntrack module maintains to know which state a specific connection is in. First of all, we have a protocol, which in this case is tcp. Next, the same value in normal decimal coding. [...] Lastly, we see what we expect of return packets. The information details the source IP address and destination IP address (which are both inverted, since the packet is to be directed back to us). The same thing goes for the source port and destination port of the connection

Não consigo entender por que deve ser útil manter o controle dos IPs e portas esperados se eles estiverem invertidos. Quando um pacote chega, a pesquisa pode ser feita usando apenas um par de IPs e Portas, e se não for encontrado, pode ser feito com os mesmos campos, mas revertidos. É manter essa informação algum tipo de otimização ou estou faltando algum caso de uso em que esta é a única maneira de conseguir algo?

Obrigado

    

Answer 1

É útil rastrear estados atuais e esperados. É mais útil quando os IPs esperados e a porta não são apenas invertidos no sentido inverso. Isso acontece, por exemplo, quando o NAT está em uso ou apenas quando o inverso não é exatamente o mesmo. Também, quando relevante, verificar que as transições de estado são respeitadas (por exemplo: para TCP) Alguns exemplos:

Aqui, após um simples ping de 192.0.2.2, espera-se que a resposta tenha um tipo ICMP 0 (resposta de eco) em vez do tipo inicial 8 (solicitação de eco):

icmp     1 12 src=192.0.2.2 dst=8.8.8.8 type=8 code=0 id=26387 src=8.8.8.8 dst=192.0.2.2 type=0 code=0 id=26387 mark=0 use=1

Uma sessão FTP ativa (em vez de passiva) (rastreada com conntrack -E ) de um host 10.1.2.3 atrás de um roteador NAT com IP público 198.51.100.32 para um servidor FTP 203.0.113.47. Observe que na resposta, o ip do roteador é esperado em vez do ip do cliente ftp NATed (e não roteável pela Internet). A criação da expectativa foi alterada por uma regra SNAT (ou MASQUERADE):

    [NEW] tcp      6 120 SYN_SENT src=10.1.2.3 dst=203.0.113.47 sport=47800 dport=21 [UNREPLIED] src=203.0.113.47 dst=198.51.100.32 sport=21 dport=47800 helper=ftp
 [UPDATE] tcp      6 60 SYN_RECV src=10.1.2.3 dst=203.0.113.47 sport=47800 dport=21 src=203.0.113.47 dst=198.51.100.32 sport=21 dport=47800 helper=ftp
 [UPDATE] tcp      6 432000 ESTABLISHED src=10.1.2.3 dst=203.0.113.47 sport=47800 dport=21 src=203.0.113.47 dst=198.51.100.32 sport=21 dport=47800 [ASSURED] helper=ftp

Após ls , uma entrada de expectativa com o destino calculada a partir do comando ftp PORT do cliente, bem como a entrada conntrack anterior (com nat) foi incluída pelo auxiliar de ftp na tabela de expectativa, para permitir que o fluxo fosse aprovado (< em> por exemplo com uma regra RELATED no firewall) antes do processamento auxiliar adicional. Isso pode ser lido lá (mas irá desaparecer assim que uma conexão correspondente, o que significa que a conexão é vista, então não pode ser visto a menos que um firewall atrase):

# cat /proc/net/nf_conntrack_expect
295 l3proto = 2 proto=6 src=203.0.113.47 dst=198.51.100.32 sport=0 dport=41603 ftp

e ser alterado pelo ajudante (aqui DNATed, ainda usando a entrada conntrack anterior para obter ajuda) para finalmente obter essa nova conexão rastreada:

    [NEW] tcp      6 120 SYN_SENT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 [UNREPLIED] src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20
 [UPDATE] tcp      6 60 SYN_RECV src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20
 [UPDATE] tcp      6 432000 ESTABLISHED src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
 [UPDATE] tcp      6 120 FIN_WAIT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
 [UPDATE] tcp      6 60 CLOSE_WAIT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
 [UPDATE] tcp      6 30 LAST_ACK src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
 [UPDATE] tcp      6 120 TIME_WAIT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
[DESTROY] tcp      6 src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]

Essas entradas de expectativa são usadas para rastrear fluxos (conntrack), permitindo, por exemplo, ter facilmente um firewall com estado, eliminando o que não é rastreado (não deixe passar uma resposta de eco icmp se não houver o icmp inicial echo ping feito antes com o mesmo id) e lembre-se como traduzir IPs / port (se nat estiver em uso).