Page suivante Page précédente Table des matières

11. Quelques Conseils sur la Conception d'un Filtre à Paquets

Dans l'univers de la sécurité informatique, la sagesse élémentaire suggère de tout fermer puis de créer des ouvertures quand c'est nécessaire. On l'exprime habituellement ainsi : `tout ce qui n'est pas explicitement autorisé est interdit'. Je vous recommande cette approche si la sécurité est votre souci majeur.

Ne faites pas tourner de services dont vous n'avez pas besoin, même si vous pensez avoir bloqué l'accès vers ceux-ci.

Si vous créez un pare-feu dédié, commencez par ne rien faire tourner et bloquer tous les paquets. Ensuite, ajoutez les services et laissez passer les paquets quand c'est nécessaire.

Je suis partisan de la sécurité en profondeur : associez les enveloppeurs de paquets ou `tcp-wrappers' (pour les connexions au filtre à paquets lui-même), les mandataires ou `proxies' (pour les connexions traversant le filtre à paquets), la vérification de route et le filtrage de paquets. La vérification de route intervient quand un paquet issu d'une interface inattendue est détruit : par exemple, si votre réseau interne contient des adresses du genre 10.1.1.0/24, et qu'un paquet avec cette adresse source vient sur votre interface externe, il sera détruit. On peut activer ce mode pour une interface (comme ppp0) avec :

# echo 1 > /proc/sys/net/ipv4/conf/ppp0/rp_filter
#

Ou pour toutes les interfaces présentes et futures avec :

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
#     echo 1 > $f
# done
#

La distribution Debian fait cela par défaut quand c'est possible. Si vous utilisez un routage asymétrique (c'est-à-dire que vous attendez des paquets venant de directions étranges), vous souhaiterez sûrement désactiver ce filtrage sur ces interfaces.

La journalisation est utile quand vous réalisez un pare-feu, surtout si quelque-chose ne marche pas. Mais sur un pare-feu de production, associez-le toujours avec la correspondance de type `limit', pour empêcher que quelqu'un ne sature vos journaux.

Je recommande fortement le traçage de connexions sur les systèmes sécurisés : il introduit un peu plus de charge, comme toutes les connexions sont suivies, mais il est très utile pour contrôler l'accès à vos réseaux. Vous devrez charger le module `ip_conntrack.o' si votre noyau ne charge pas automatiquement les modules et s'il n'est pas déjà compilé dans le noyau. Si vous voulez tracer précisément des protocoles complexes, vous devrez charger le module d'assistance approprié (par exemple `ip_conntrack_ftp.o').

# iptables -N no-conns-from-ppp0
# iptables -A no-conns-from-ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A no-conns-from-ppp0 -m state --state NEW -i ! ppp0 -j ACCEPT
# iptables -A no-conns-from-ppp0 -i ppp0 -m limit -j LOG --log-prefix "Bad packet from ppp0:"
# iptables -A no-conns-from-ppp0 -i ! ppp0 -m limit -j LOG --log-prefix "Bad packet not from ppp0:"
# iptables -A no-conns-from-ppp0 -j DROP

# iptables -A INPUT -j no-conns-from-ppp0
# iptables -A FORWARD -j no-conns-from-ppp0

Construire un bon pare-feu est au-delà du sujet de ce Guide Pratique, mais suivez mon conseil, soyez toujours minimaliste. Consultez le Guide Pratique de la Sécurité pour avoir plus d'informations sur la manière de tester et sonder votre machine.


Page suivante Page précédente Table des matières