Le script rc.DHCP.firewall.txt est à peu près identique au Section 14.2, « rc.firewall.txt ». Cependant, il n'utilise pas la variable STATIC_IP, ce qui est la principale différence avec le script rc.firewall.txt. La raison en est qu'il ne fonctionne pas avec une connexion IP dynamique. Les modifications à effectuer sur le script d'origine sont minimes, cependant, certaines personnes m'ont demandé si ce script est une bonne solution. Il permet d'utiliser des connexions DHCP, PPP et SLIP pour l'Internet.
Le script rc.DHCP.firewall.txt
nécessite que les options suivantes soient compilées statiquement
dans le noyau, ou comme modules, pour fonctionner correctement.
-
CONFIG_NETFILTER
-
CONFIG_IP_NF_CONNTRACK
-
CONFIG_IP_NF_IPTABLES
-
CONFIG_IP_NF_MATCH_LIMIT
-
CONFIG_IP_NF_MATCH_STATE
-
CONFIG_IP_NF_FILTER
-
CONFIG_IP_NF_NAT
-
CONFIG_IP_NF_TARGET_MASQUERADE
-
CONFIG_IP_NF_TARGET_LOG
Le principal changement dans ce script consiste en la
suppression de la variable STATIC_IP
et à supprimer toute référence à cette variable. Le script filtrera
maintenant sur la variable INET_IFACE
.
En d'autres termes -d
$STATIC_IP a été changé en -i$INET_IFACE. C'est la seule
modification qu'il est réellement nécessaire de faire.
Il y a plusieurs choses à penser. Nous ne pouvons pas faire de
filtrage sur ce qui dépend de la chaîne INPUT, par exemple,
--in-interface $LAN_IFACE --dst
$INET_IP. Ceci nous force à faire du filtrage
uniquement sur les interfaces dans le cas où les machines internes
doivent accéder à une IP Internet adressable. Un bon exemple est,
si nous faisons tourner un serveur HTTP sur notre pare-feu. Si nous
allons sur la page principale (i.e., http://192.168.0.1/), qui
contient des liens statiques vers le même hôte (i.e.,
http://foobar.dyndns.net/fuubar.html), qui pourrait être une
solution dyndns, nous rencontrons un problème. La machine NATée
cherchera le DNS pour l'IP du serveur HTTP, et ensuite tentera
d'accéder à cette IP. Dans le cas où nous filtrons sur l'interface
et l'IP, la machine NATée sera incapable d'accéder au HTTP car la
chaîne INPUT DROP les
paquets. Ceci s'applique aussi dans le cas où nous avons une IP
statique, mais dans ces cas nous pouvons contourner le problème en
ajoutant des règles qui sélectionnent les paquets de l'interface
LAN pour notre INET_IP
, et les plaçons
à ACCEPT.
Comme vous l'avez vu plus haut, ce peut être une bonne idée de
faire un script qui traite les IP dynamiques d'une meilleure façon.
Nous pouvons par exemple faire un script qui récupère l'IP depuis
ifconfig et l'ajoute
à une variable, dans l'initialisation de la connexion Internet. Un
bon moyen pour faire ça, serait d'utiliser, par exemple, les
scripts ip-up
fournis par
pppd ou tout autre
programme. Voir sur le site linuxguruz.org qui possède une quantité
de scripts disponibles en téléchargement. Le lien est dans l'annexe
Annexe E,
Autres ressources et liens.
Note | |
---|---|
Ce script peut être un peu moins sûr que le |
Il est également possible d'ajouter certaines choses comme cela dans votre script :
INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \
cut -d ' ' -f 1`
La commande ci-dessus récupère automatiquement l'adresse IP de la variable $INET_IFACE, affiche la ligne qui contient l'adresse IP et la transforme en une adresse IP gérable. Pour une façon plus élaborée de faire ceci, vous pouvez appliquer des bouts de code disponibles dans le script retreiveip.txt, qui récupère automatiquement votre adresse IP Internet quand vous lancez le script. Notez que cette façon de faire peut conduire à un comportement un peu aléatoire, comme le blocage des connexions depuis votre pare-feu en interne. Les comportements étranges les plus courants sont décrits dans la liste suivante.
-
Si le script est lancé depuis un script exécuté par exemple, par le démon PPP, il suspendra toutes les connexions actives à cause des règles NEW non-SYN (voir la section Section B.2, « Paquets NEW non-SYN »).
-
Si vous avez des règles statiques, il est plus difficile d'ajouter et d'enlever ces règles tout le temps, sans modifier celles déjà existantes. Par exemple, si vous voulez bloquer l'accès des hôtes de votre LAN au pare-feu, mais en même temps exécuter un script depuis le démon PPP, comment ferez vous sans effacer vos règles actives qui bloquent le LAN ?
-
Ce n'est pas nécessairement compliqué, mais peut conduire à des compromis sur la sécurité. Si le script est très simple, il est facile de corriger les problèmes.