Thomas Clavier a écrit :
imaginons le cas suivant : eth0 => internet eth1 => lan vlan0 => vlan d'administration
[...]
si le pilote d'eth0 ne se charge pas bien, eth1 devient eth0 ...avec un script générique on se retrouve avec les règles internet sur le lan
Effectivement, bien vu. L'inverse pourrait aussi se produire, à savoir appliquer les règles du LAN à l'interface internet.
Pour les interfaces ethernet, il y a moyen de contourner le problème. On peut les renommer en fonction de leur adresse MAC avec nameif ou ifrename. Ainsi elles ont toujours le même nom quel que soit l'ordre de détection et on peut en profiter pour choisir des noms plus parlants : lan, wan, dmz...
[...]
effectivement avec du DROP par défaut ça doit tout bloquer ... mon raisonement ne tient pas la route :-(
J'ai une théorie : un jeu de règles de filtrage ne devrait pas être considéré comme "robuste" s'il devient moins permissif quand on lui enlève une ou plusieurs règles quelles qu'elles soient. Cela implique notamment que les politiques de filtrage par défaut doivent être à DROP. Cela implique également qu'il ne doit pas y avoir de séquence du genre "je bloque ce qui entre par telle interface, puis j'accepte tout le reste". Si on retire la règle qui bloque - ce qui revient à peu près au même que de spécifier dans cette règle un nom d'interface qui n'existe pas - ça peut conduire à accepter du trafic qui n'aurait pas dû l'être.
Pourtant j'avais eu un exemple entre les mains ... dès que je le retrouve, c'est promis, je vous le donne.
Je veux bien, merci.