iptables/nftables: como excluir todo o tráfego encaminhado do rastreamento de conexão em um roteador?

Question

Uma caixa Linux possui várias interfaces de rede. O encaminhamento de IP está habilitado para IPv4 e IPv6.

Gostaria de proteger os serviços executados no próprio roteador por meio de um firewall com estado. Para isso, o rastreamento de conexão precisa estar habilitado. Ao mesmo tempo, gostaria de excluir todo o tráfego encaminhado de uma interface para outra do rastreamento de conexão.

Para o firewall com estado, normalmente eu usaria as cadeias INPUT e OUTPUT da tabela de filtros. O tráfego encaminhado iria para a cadeia FORWARD. Mas AFAIK não há como marcar o tráfego como não rastreado na cadeia FORWARD. Essa lógica deve ir para a cadeia PREROUTING na tabela bruta. Mas acredito que na cadeia PREROUTING ainda não foi decidido se o tráfego será encaminhado ou não.

O rastreamento de conexão tem muitas desvantagens, como quedas de pacotes quando a lista de conexões rastreadas atinge seu tamanho máximo.

Qual é a maneira mais fácil de excluir o tráfego encaminhado (e somente esse tráfego encaminhado) do rastreamento de conexão?

Answer 1

Para um conjunto de regras genérico, pode-se perguntarnftáveispara fazer uma pesquisa de rota antecipadamente usando ofibexpressão em vez de esperar que a pilha de roteamento faça isso. Isto permite envolver o (futuro)saídainterface apesar de ainda não existir (a decisão de roteamento não aconteceu), ao custo de uma pesquisa extra. Então, se os resultados indicarem que o pacote será roteado, evite que o rastreamento aconteça usando umnotrackdeclaração.

EXPRESSÕES FIB

fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}

Amentiraexpressão consulta omentira(base de informações de encaminhamento) para obter informações como o índice da interface de saída que um determinado endereço usaria. A entrada é uma tupla de elementos que é usada como entrada para omentirafunções de pesquisa.

DECLARAÇÃO NOTRACK

A instrução notrack permite desabilitar o rastreamento de conexão para determinados pacotes.

notrack

Observe que para que esta declaração seja eficaz, ela deve ser aplicada aos pacotes antes de umconexãoa pesquisa acontece. Portanto, ele precisa estar em uma cadeia compré-roteamentoousaídagancho e uma prioridade de gancho de -300 ou menos.

Portanto, deve-se fazer uma verificação de rota "simples" a partir depré-roteamento, usando apenas o endereço de destino como seletor e verificando a existência de uma interface de saída (pacotes não roteáveis ​​ou pacotes destinados ao host não resolverão nenhum). Há uma exceção para oeis(loopback) para mantê-lo rastreado: embora represente o tráfego local, um pacote enviado (através dosaídacaminho) do host para si mesmo volta atravéspré-roteamentocaminho e tem uma interface de saída deeistambém. Como o pacote de saída já criou umconexãoentrada, é melhor manter isso consistente.

nft add table ip stateless
nft add chain ip stateless prerouting '{ type filter hook prerouting priority -310; policy accept; }'
nft add rule ip stateless prerouting iif != lo fib daddr oif exists notrack

Substituir a ipfamília pela inetfamília combo deve estender o mesmo comportamento genérico para IPv4+IPv6.

Para ser mais específico, pode-se especificar a interface de saída futura, fib daddr oif eth1por exemplo, que é mais ou menos equivalente a oif eth1, mas também está disponível empré-roteamento.

É claro que se a topologia for conhecida antecipadamente, é possível evitar uma pesquisa FIB usando uma ou algumas regras baseadas em testes de endereço, uma vez que as rotas são conhecidas antecipadamente pelo administrador. Pode ser necessário comparar os resultados para saber se isso é mais interessante do que manter um método genérico.

Por exemplo, com as informações fornecidas pelos OP, substituindo a regra anterior por:

nft add rule ip stateless prerouting 'ip daddr != { 192.168.1.1, 192.168.2.1, 127.0.0.0/8 } notrack'

deveria ter um efeito quase equivalente. 127.0.0.0/8 está presente pelas mesmas razões acima com oeisinterface.

Tratamento de transmissão (como 192.168.1.255 recebido emeth0) e multicast (como link-local 224.0.0.1 recebido em uma interface) podem não funcionar da mesma forma em ambos os métodos nem conforme o esperado e possivelmente exigiriam regras adicionais para necessidades específicas, especialmente com o segundo método. Como rastrear broadcast e multicast raramente é útil, porque uma fonte de resposta não será (e não pode) ser o destino original do endereço broadcast ou multicast, então a entrada conntrack nunca "verá" o tráfego bidirecional, geralmente não importa muito para regras estaduais.

---

Notas

• Isso geralmente não será compatível com NAT com estado.

  Meu entendimento é que o DNAT direcionado a um host remoto fará com que seu tráfego de resposta não seja desnatado e falhe, e que o SNAT encaminhado não será acionado, pois não houveconexãoentrada criada. SNAT raramente usado no caminho de entrada deve servir, e uma combinação de DNAT + SNAT (usando uma fonte de endereço local) também pode funcionar desde então, tanto na direção original quanto na de resposta, há um destino local envolvido, então umconexãoa entrada deve então ser sempre criada ou pesquisada corretamente.

• conjunto de regras padrão

  Regras reais usandotabelas de ipounftáveis(em sua própria tabela diferente) pode então ser feito normalmente, incluindo regras com estado para o próprio host. Como o tráfego roteado não criaráconexãoentradas, regras, se houver, envolvendo esse tráfego, devem ser apenas sem estado e não usar nenhuma ctexpressão porque nunca corresponderiam.

• verificando comportamento

  Pode-se verificar o comportamento geral mesmo sem regras de firewall adequadas:

  • usando uma ctregra fictícia para ter certeza de queconexãoinstalação é registrada no namespace de rede atual.

    nft add table ip mytable
    nft add chain ip mytable mychain '{ type filter hook prerouting priority -150; policy accept; }'
    nft add rule ip mytable mychain ct state new
    

  • use oconntrackferramenta para acompanhar eventos:

    conntrack -E
    

  • gerar tráfego remoto

    NOVOconexãoserão então criadas entradas para o tráfego a ser recebido pelo roteador, mas não para o tráfego roteado.