14.4. rc.DHCP.firewall.txt

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] Note

Ce script peut être un peu moins sûr que le rc.firewall.txt. Je vous préviens qu'il est d'avantage ouvert aux attaques depuis l'extérieur.

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.

  1. 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 »).

  2. 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 ?

  3. 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.