Quando o módulo conntrack do iptable rastreia os estados dos pacotes?
Primeiro, ele precisa armazenar estados. Com algum firewall BSD antigo que usei, acho que se chamava IPFW, eu costumava colocar uma regra que sacava "rastreie o estado do pacote de saída", e isso era colocado na direção de saída das interfaces. Em seguida, outra regra na direção de entrada que os verificou em relação aos estados que foram criados pela regra na direção de saída. Portanto, costumava haver 2 regras: (1) para preencher a tabela de estados, isso era na direção de saída, e (2) para consultar a tabela de estados, isso era na direção de entrada.
Mas com connntrack, vejo que é aplicado na cadeia INPUT, como esta regra:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Isso me faz pensar, o que essa declaração está realmente fazendo?
- Está dizendo que começará a rastrear os pacotes que correspondem a essa regra, colocando suas informações na tabela de estados?
- Ou está dizendo que já possui as informações de estados e que atuará contra as mensagens de entrada com base nelas? (por exemplo, aceitar se eles pertencessem a uma conexão previamente aceita?). Mas, neste caso, onde a tabela de estados foi preenchida? Qual regra funciona? Ou é sem regras e implícito?
Respostas
Apresentação introdutória do Netfilter e conntrack
Primeiro, o esquema obrigatório sobre o fluxo de pacotes no Netfilter e Rede Geral:
Netfilter é a estrutura de filtragem de pacotes que se insere no resto da pilha da rede (representada por "decisão de roteamento" e outras partes da caixa com bordas redondas brancas). O Netfilter fornece ganchos e APIs para outros subsistemas e "clientes". Entre essas partes estão conntrack (o rastreador de conexão) e iptables (ou nftables ). A separação entre Netfilter e conntrack é bastante confusa. Você pode apenas considerar o conntrack como uma parte integrada do Netfilter.
No esquema que descreve as várias etapas que um pacote atravessa, você pode ver que em algum ponto (entre raw / PREROUTING e mangle / PREROUTING, ou entre raw / OUTPUT e mangle / OUTPUT) o pacote atravessa conntrack .
Neste ponto, conntrack irá pesquisar em suas próprias tabelas de pesquisa (um banco de dados de mini pesquisa mantido na memória do kernel):
- se as características deste pacote não forem encontradas (e se não for declarado UNTRACKED na tabela bruta), uma nova entrada de tupla bidirecional conntrack (protocolo, família específica e informações de protocolo: fonte inicial e porta, destino inicial e porta, fonte de resposta e porta, destino de resposta e porta (os dois últimos são geralmente o inverso, a menos que NAT ou alguns protocolos estranhos estejam envolvidos, como resposta de eco correspondente a solicitação de eco para ICMP)) descrevendo o fluxo é criado com o estado NOVO.
- se corresponder (em qualquer direção) a uma entrada anterior e for compatível com o estado deste fluxo, o estado do fluxo pode ser alterado (por exemplo: mudar de NOVO para ESTABELECIDO se não era o caso antes).
- se por algum motivo específico o pacote não corresponder a um fluxo existente, apesar de ter suas características (por exemplo: um pacote TCP atrasado recebido após uma retransmissão já iniciada com sucesso, portanto, estando fora da janela em relação à sequência e aos valores SACK), o o pacote será marcado como INVÁLIDO.
- existem alguns outros casos como RELATED: trata-se de pacotes que não fazem parte do fluxo em si, mas relacionados a um novo fluxo que pode ser associado a um outro fluxo existente (ou seja: no banco de dados). Dois exemplos são um erro ICMP criado ao receber um pacote (por exemplo: porta UDP inalcançável) ou quando um auxiliar de protocolo especial como o módulo do kernel
nf_conntrack_ftp, que é um plug-in para o subsistema conntrack , detecta que um pacote faz parte do fluxo de dados separado associado com os comandos FTP PASV / EPSV ou PORT / EPRT feitos no fluxo de comando (na porta 21).
Resolvendo a questão
Com tudo isso dito, aqui estão as respostas para seus dois marcadores:
no namespace da rede principal, conntrack começa a rastrear conexões assim que seus módulos (incluindo possíveis submódulos específicos de protocolo relevantes) são carregados. Para namespaces de rede não iniciais (contêineres ...), isso também requer que algum outro subsistema faça referência a ele (como o módulo conntrack do iptables do OP ou usando uma vez o comando
conntrackdescrito posteriormente). Este é o padrão e um pacote deve ser especificamente marcado como UNTRACKED antes que o subsistema conntrack o veja para que este pacote não seja rastreado. No Linux, existem apenas alguns casos em que o não rastreamento seria necessário, mas é claro que o firewall com estado e o NAT dinâmico / com estado não estarão mais disponíveis (o NAT estável que pode até exigir o uso de UNTRACKED em primeiro lugar, ainda pode ser feito, mas não com iptables . tc ou nftables podem). Para evitar o manuseio de conntrack de alguns pacotes, este tipo de regra iptables pode ser usada (por exemplo: porta 80 / tcp):iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrackQuando o pacote atravessa o filtro / INPUT e atinge esta regra:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTO módulo de kernel específico do iptables
xt_conntrackconsulta o subsistema conntrack (gerenciado pelos vários módulos de kernel relevantesnf_conntrack*) e pergunta sobre o estado desse pacote em seu banco de dados de pesquisa. Se a resposta forRELATEDouESTABLISHEDo pacote corresponder, prossiga para o veredicto ACEITAR. Na verdade, o resultado já está armazenado em cache no pacote na primeira vez que a pesquisa foi feita (geralmente por conntrack ), então esta é uma "pesquisa" barata. Esta é, portanto, uma regra genérica para lidar com fluxos já aceitos anteriormente. Esses fluxos podem ser inicialmente aceitos em regras que mencionam explicitamente-m conntrack --ctstate NEWou simplesmente regras que não os mencionam, mas colocadas após essa regra genérica (mas tenha em mente o estado INVALID, que normalmente deve ser DROPed antes de fazê-lo).adicionando um marcador: o tratamento de pacotes de entrada e de saída é bastante simétrico entre PREROUTING e OUTPUT (mesmo que não pareçam simétricos): interfaces conntrack em PREROUTING e também em OUTPUT (e em alguns outros lugares, considerando que NAT é trabalhando com conntrack , exceto para seu primeiro pacote no estado NEW passando pela tabela nat do iptables ). Isso pode ser um pouco diferente da descrição que você escreveu sobre o IPFW. Se um servidor que executa aplicativos também está restringindo os fluxos de saída, provavelmente precisará dessa mesma regra genérica de iptables em filter / OUTPUT e em filter / INPUT, para permitir a passagem de pacotes de resposta de saída de tráfego de entrada já aceito.
Informações adicionais
Existem ferramentas dedicadas para interagir com as tabelas de pesquisa do subsistema conntrack em conntrack-tools .
conntrack: para consultar, excluir ou atualizar o conteúdo das tabelas de pesquisa gerenciadas por conntrack .
Alguns exemplos.
Você pode listar todas as entradas rastreadas (que podem ser grandes sem filtro adicional) com:
conntrack -LSe o seu sistema está fazendo NAT (por exemplo, um roteador na frente de uma LAN privada, ou máquinas virtuais em execução e recipientes) que você pode usar
--any-nat,--src-natou--dst-natapenas resp display. todos os NAT, todos os NAT de origem (mascaramento) ou todos os NAT de destino (normalmente para portas encaminhadas):Monitoramento em tempo real de eventos conntrack :
conntrack -Econntrackd: um daemon cujas duas finalidades principais são (conntrack) contabilidade e estatísticas de fluxo ou sincronização de estado de cluster de firewall stateful de alta disponibilidade .
O rastreamento de conexão é uma função separada do Netfilter e não é configurado com IPTables.
Na figura, há duas conntracketapas no caminho de INPUT e uma no caminho de SAÍDA. Essas etapas associam pacotes individuais a conexões existentes rastreadas na tabela de rastreamento de conexão ou criam novas entradas de rastreamento de conexão na tabela.
A funcionalidade Conntrack é um módulo do kernel do Linux e geralmente está incluído no kernel na configuração padrão.
A operação Conntrack pode ser ajustada ajustando os net.netfilter.nf_conntrackvalores sysctl.
Sua segunda alternativa é o que acontece. As informações de estado são registradas pela função Conntrack e a regra IPTables simplesmente consulta a tabela Conntrack para obter informações.