netfilter / iptables: pourquoi ne pas utiliser la table brute?

Sous Linux, nous utilisons généralement la table "filter" pour effectuer un filtrage commun:

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

Selon l'organigramme netfilter ci-dessous, les paquets voyagent d'abord à travers la table "brute":

On peut donc écrire:

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

• les paquets sont traités plus tôt, sans avoir à passer par conntrack + mangle + nat + routage. Donc, un peu moins de CPU / mémoire utilisé (et à son tour légèrement compensé par le fait que le module iptable_raw doit être chargé)
• une seule règle au cas où la box est également un routeur (ne sera pas ok pour toutes les règles, évidemment) car il n'est pas nécessaire d'ajouter la même règle pour le filtrage / transfert

Je n'ai fait que des tests rapides, et cela fonctionne parfaitement bien.
Les documentations que j'ai trouvées décrivent toujours la table brute à utiliser dans des cas stricts. Mais aucun ne donne la moindre justification.

Question: y a-t-il des raisons de ne pas utiliser la table brute, à part celles dogmatiques?

De l' homme 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)

Analyse :

Ainsi, la table RAW est avant conntrack et elle a été conçue avec l'objectif d'être utilisée pour définir la marque NOTRACK sur les paquets que vous ne souhaitez pas suivre dans netfilter.

Les cibles -j ne sont pas limitées uniquement à NOTRACK, donc oui, vous con filtrez les paquets dans la table brute avec les avantages de moins de consommation CPU / mémoire.

Le plus souvent, les serveurs n'ont pas besoin de garder une trace de toutes les connexions. Vous n'avez besoin d'un suivi que si vous devez filtrer les paquets dans iptables en fonction des connexions établies précédemment. Sur les serveurs qui ne servent qu'à des fins simples comme avec uniquement le port 80 (et peut-être 21) ouvert, cela n'est pas nécessaire. Dans ces cas, vous pouvez désactiver le suivi des connexions.

Cependant, si vous essayez d'exécuter un routeur NAT, les choses se compliquent légèrement. Afin de NAT quelque chose, vous devez garder une trace de ces connexions afin que vous puissiez livrer des paquets du réseau extérieur au réseau interne.

Si une connexion entière est définie avec NOTRACK, vous ne pourrez pas non plus suivre les connexions associées, les assistants conntrack et nat ne fonctionneront tout simplement pas pour les connexions non suivies, pas plus que les erreurs ICMP associées. Vous devrez les ouvrir manuellement en d'autres termes. Lorsqu'il s'agit de protocoles complexes tels que FTP et SCTP et autres, cela peut être très difficile à gérer.

Cas d'utilisation :

Un exemple serait si vous avez un routeur très fréquenté sur lequel vous souhaitez pare-feu le trafic entrant et sortant, mais pas le trafic routé. Ensuite, vous pouvez définir la marque NOTRACK pour ignorer le trafic transféré afin d'économiser la puissance de traitement.

Un autre exemple lorsque NOTRACK peut être utilisé est que si vous avez un serveur Web à fort trafic, vous pouvez ensuite configurer une règle qui transforme le suivi pour le port 80 sur toutes les adresses IP détenues localement, ou celles qui servent réellement le trafic Web. Vous pouvez alors bénéficier d'un suivi avec état sur tous les autres services, à l'exception du trafic Web qui peut économiser de la puissance de traitement sur un système déjà surchargé.

Exemple -> exécuter un routeur linux semi-sans état pour un réseau privé

Conclusion : Il n'y a pas de bonne raison de ne pas utiliser la table brute, mais il y a quelques raisons de faire attention lors de l'utilisation de la cible NOTRACK dans la table brute.