netfilter / iptables: por que não usar a tabela bruta?

Question

No Linux, geralmente usamos a tabela "filter" para fazer uma filtragem comum:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

De acordo com o fluxograma do netfilter abaixo, os pacotes viajam primeiro pela tabela "bruta":

Então podemos escrever:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

• os pacotes são manipulados antes, sem a necessidade de passar pelo conntrack + mangle + nat + routing. Então, levemente menos CPU / memória usada (e, por sua vez, levemente compensada pelo fato do módulo iptable_raw precisar ser carregado)
• apenas uma regra, caso a caixa também seja um roteador (não será aceitável para todas as regras, obviamente), pois não há necessidade de adicionar a mesma regra para filtrar / encaminhar

Eu fiz apenas testes rápidos, e isso funciona perfeitamente bem. As documentações encontradas sempre descrevem a tabela bruta a ser usada em casos restritos. Mas nenhum dá sequer a menor justificativa.

Pergunta: há alguma razão para não usar a mesa bruta, além das dogmáticas?

    

Answer 1

De homem iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

Análise :

Assim, a tabela RAW está antes do conntrack e foi projetada com o objetivo de ser usada para definir a marca NOTRACK em pacotes que você não deseja rastrear no netfilter.

Os alvos -j não são restritos apenas a NOTRACK, então sim, você pode filtrar os pacotes na tabela bruta com os benefícios de menos consumo de CPU / memória.

Na maioria das vezes, os servidores não precisam controlar todas as conexões. Você só precisa rastrear se precisar filtrar os pacotes no iptables com base nas conexões estabelecidas anteriormente. Em servidores que servem apenas a um propósito simples, como com apenas a porta 80 (e talvez 21) aberta, não exija isso. Nesses casos, você pode desativar o rastreamento de conexão.

No entanto, se você está tentando executar um roteador NAT, as coisas ficam um pouco complicadas. Para NAT alguma coisa, você precisa acompanhar essas conexões para entregar pacotes da rede externa para a rede interna.

Se uma conexão inteira for definida com NOTRACK, você não poderá rastrear conexões relacionadas, os ajudantes conntrack e nat simplesmente não funcionarão para conexões não rastreadas, nem os erros ICMP relacionados. Você terá que abrir para estes manualmente em outras palavras. Quando se trata de protocolos complexos, como FTP e SCTP e outros, isso pode ser muito difícil de gerenciar.

Casos de uso :

Um exemplo seria se você tem um roteador com tráfego intenso no qual deseja ativar o tráfego de entrada e saída, mas não o tráfego roteado. Em seguida, você pode definir a marca NOTRACK para ignorar o tráfego encaminhado para economizar o poder de processamento.

Outro exemplo de quando o NOTRACK pode ser usado é que, se você tiver um servidor da web com alto tráfego, poderá configurar uma regra que gira de rastreamento para a porta 80 em todos os endereços IP de propriedade local ou que estejam realmente atendendo tráfego da web. Você pode, então, aproveitar o rastreamento com informações de estado em todos os outros serviços, com exceção do tráfego da Web, que pode economizar algum poder de processamento em um sistema já sobrecarregado.

Exemplo - > executando-a-semi-stateless-linux-roteador-para-privado -rede

Conclusão : Não há um motivo strong para não usar a tabela bruta, mas há algumas razões para tomar cuidado ao usar o destino NOTRACK na tabela bruta.