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.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
