Ceci permet de ne pas s’embarrasser à gérer les paquets en relation avec ceux que l'on a déjà acceptés. Mais si je comprends bien, utiliser ainsi l'état RELATED peut s'avérer dangereux car le module ne permet pas toujours de filtrer correctement ?
Oui, cette utilisation de RELATED ouvre grand les vannes car les modules de suivi de connexions peuvent permettre des connexions arbitraires. L'audit que j'ai réalisé semble indiquer qu'ils se comportent bien mais le degré de liberté est parfois très important. Il est donc très recommandé de limiter l'utilisation de RELATED en ciblant son usage sur des connexions que l'on connait (comme vers le serveur FTP dans la DMZ).
Une autre question concerne la mise en place du pare-feu. J'ai lu qu'il était plus efficace d'écrire un fichier iptables.rules lu ensuite par iptables-restore que de faire des appels répétés à iptables dans un script. Je pense que cela est vrai mais quelle est une (la ?) bonne façon de mettre en place son pare-feu ?
L'utilisation de iptables-restore permet de gagner énormément de temps. De plus, le changement de jeu de filtrage est atomique ce qui permet de ne pas avoir à gérer les états de transition.
[^] # Re: Quelques questions
Posté par Eric Leblond . En réponse au journal Nouveau document sur la sécurisation des pare-feu Netfilter. Évalué à 2.
Oui, cette utilisation de RELATED ouvre grand les vannes car les modules de suivi de connexions peuvent permettre des connexions arbitraires. L'audit que j'ai réalisé semble indiquer qu'ils se comportent bien mais le degré de liberté est parfois très important. Il est donc très recommandé de limiter l'utilisation de RELATED en ciblant son usage sur des connexions que l'on connait (comme vers le serveur FTP dans la DMZ).
L'utilisation de iptables-restore permet de gagner énormément de temps. De plus, le changement de jeu de filtrage est atomique ce qui permet de ne pas avoir à gérer les états de transition.