Sous Linux, la table « raw » du pare-feu (netfilter) est traversée en premier (étape prerouting). Il semble alors évident d’y placer le plus de règles DROP ou ACCEPT possibles afin d’alléger la charge de traitement. Cependant la totalité de la documentation, des explications et tutoriels se contentent de parler de la table filter. Même les logiciels d’aide à la création de règles de pare-feu n’en que peu d’usage.
Par exemple :
iptables –table raw –append PREROUTING –source 1.2.3.4 –jump DROP
iptables –table raw –append PREROUTING –in-interface lo –jump ACCEPT
Cela a également l’avantage de n’avoir besoin que d’une seule règle dans le cas où les paquets peuvent être transférés ailleurs (forwarding). Si on utilise la table filter il faut parfois écrire une règle pour input et une autre pour forward.
Il est également recommandé d’utiliser la table raw pour y placer ipset, surtout s’ils y a beaucoup de données.
A part ce cas typique et à moins d’avoir un débit réseau énorme, n’importe quelle machine traite sans problème de nombreuses règles. Le prétexte d’optimisation mémoire/processeur ne tient donc pas.
Le principal frein à l’utilisation de la table raw est que le suivi des connexion (CONNTRACK) n’est pas disponible car les paquets sont suivis à partir de l’étape suivante. Cela limite l’utilisation de nombreuses de règles.
Restent beaucoup de cas où la table raw est parfaitement adaptée, bien que souvent négligée.