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

No Linux, geralmente usamos a tabela "filter" para fazer a 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 primeiro viajam pela tabela "bruta":

Para que possamos 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 tratados mais cedo, sem a necessidade de passar pelo roteamento conntrack + mangle + nat +. Portanto, menos CPU / memória usada (e, por sua vez, ligeiramente compensada pelo fato de o módulo iptable_raw precisar ser carregado)
• apenas uma regra, caso a caixa também seja um roteador (obviamente não será válida para todas as regras), porque não há necessidade de adicionar a mesma regra para filtragem / encaminhamento

Eu fiz apenas testes rápidos, e isso funciona perfeitamente bem.
As documentações que encontrei sempre descrevem a tabela bruta a ser usada em casos estritos. Mas ninguém dá a menor justificativa.

Pergunta: existem razões para não usar a tabela bruta, além das dogmáticas?

Do man 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 :

Portanto, a tabela RAW é anterior ao conntrack e foi projetada com o objetivo de ser usada para definir a marca NOTRACK nos pacotes que você não deseja rastrear no netfilter.

Os destinos -j não estão restritos apenas ao NOTRACK; portanto, sim, você conecta os pacotes de filtro na tabela bruta com os benefícios de menos consumo de CPU / memória.

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

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

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

Casos de uso :

Um exemplo seria se você tiver um roteador com tráfego intenso no qual deseja proteger 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 energia de processamento.

Outro exemplo em que o NOTRACK pode ser usado é se você tiver um servidor da Web altamente trafegado, poderá configurar uma regra que revele o rastreamento da porta 80 em todos os endereços IP de propriedade local ou naqueles que realmente estão atendendo tráfego na Web. Você pode desfrutar de um rastreamento com estado em todos os outros serviços, exceto no tráfego da Web, que pode economizar um pouco de poder de processamento em um sistema já sobrecarregado.

Exemplo -> executando um roteador linux semi-stateless-for-private-network

Conclusão : Não há um motivo forte para não usar a tabela não processada, mas há alguns motivos para ter cuidado ao usar o destino NOTRACK na tabela não processada.