Cette section contient toutes les informations et les questions fréquemment posées que je ne pouvais faire entrer dans la structure ci-dessus.
Cette question nécessite un peu de réflexion. Vous pouvez tenter de les organiser pour optimiser la vitesse (minimiser le nombre de vérifications de règles pour la plupart des paquets) ou pour augmenter la maniabilité.
Si vous avez une connexion intermittente, disons une connexion PPP, vous
pouvez configurer la première règle de la chaîne d'entrée pour être `-i ppp0
-j DENY' au lancement, puis avoir quelque chose comme ceci dans votre script
ip-up :
# Re-crée la chaîne "ppp-in"
ipchains-restore -f < ppp-in.firewall
# Remplace la règle DENY par un saut vers la chaîne se chargeant du ppp
ipchains -R input 1 -i ppp0 -j ppp-in
Votre script ip-down pourrait ressembler à ça :
ipchains -R input 1 -i ppp0 -j DENY
Il y a un certain nombre de choses auxquelles vous devez faire attention avant de commencer à filtrer quelque chose que vous n'auriez pas voulu filtrer.
Les paquets ICMP sont utilisés (entre autres choses) pour indiquer des problèmes aux autres protocoles (comme TCP et UDP). Les paquets "destination-unreachable" (destination non accessible) en particulier. Le bloquage de ces paquets signifie que vous n'obtiendrez jamais les erreurs "Host unreachable" ou "No route to host" ; toute connexion attendra une réponse qui ne viendra jamais. C'est irritant, mais rarement fatal.
Un problème plus inquiétant est le rôle des paquets ICMP dans la découverte MTU. Toutes les bonnes implémentations de TCP (y compris celle de Linux) utilisent la recherche MTU pour tenter de trouver quel est le plus grand paquet qui peut atteindre une destination sans être fragmenté (la fragmentation diminue les performances, principalement lorsque des fragments occasionnels sont perdus). La recherche MTU fonctionne en envoyant des paquets avec le bit "Don't Fragment" mis, et en envoyant ensuite des paquets plus petits s'il reçoit un paquet ICMP indiquant "Fragmentation needed but DF set" (`fragmentation-needed'). C'est un paquet de type "destination-unreachable", et s'il n'est jamais reçu, l'hôte local ne réduira pas le MTU, et les performances seront abyssales ou inexistantes.
Notez qu'il est commun de bloquer tous les messages ICMP de redirection (type 5) ; ils peuvent être utilisés pour manipuler le routage (bien que les piles IP bien conçues disposent de gardes-fou), et sont donc souvent considérés comme quelques peu risqués.
Si vous tentez de bloquer toutes les connexions TCP sortantes, rappellez vous que le DNS n'utilise pas toujours UDP ; si la réponse du serveur dépasse les 512 octets, le client utilise une connexion TCP (allant toujours sur le port numéro 53) pour obtenir les données.
Ceci peut être un piège car le DNS fonctionnera "en gros" si vous interdisez de tels transferts TCP ; vous pouvez expérimenter des délais longs et étranges, et d'autres problèmes liés au DNS si vous le faites.
Si les demandes de votre DNS sont toujours dirigées vers les mêmes sources
externes (soit directement en utilisant la ligne nameserver dans
/etc/resolv.conf ou en utilisant un serveur de noms cache en mode de
redirection), alors vous n'aurez besoin d'autoriser que les connexions du
port domain sur ce serveur de nom à partir du port local domain
(si vous utilisez un serveur de nom cache) ou d'un port élevé (> 1023) si
vous utilisez /etc/resolv.conf.
L'autre problème classique du filtrage de paquets est celui posé par le FTP. Le FTP a deux modes ; le mode traditionnel est appelé mode actif et le plus récent est appelé mode passif. Les navigateurs web utilisent souvent le mode passif par défaut, mais les programmes de ftp en ligne de commmande utilisent en général par défaut le mode actif.
En mode actif, lorsque l'hôte distant désire envoyer un fichier (ou même les
résultats d'une commande ls ou dir), il essaye d'ouvrir une
connexion TCP sur la machine locale. Celà signifie que vous ne pouvez filtrez
ces connexions TCP sans supprimer le FTP actif.
Si vous avez comme option l'utilisation du mode passif, alors tout va bien ; le mode passif fait passer les connexions de données du client au serveur, même pour les données arrivantes. Autrement, il est recommendé de n'autoriser que les connexions TCP vers les ports supérieurs à 1024 et de les interdire entre 6000 et 6010 (6000 est utilisé par X-Windows).
Les machines Linux sont maintenant immunisées du fameux Ping of Death, qui implique l'envoi de paquets ICMP illégalement grands qui font déborder les buffers de la pile TCP du récepteur et causent de gros dégâts.
Si vous voulez protéger des machines qui peuvent être vulnérables, vos pouvez simplement bloquer les fragments ICMP. Les paquets ICMP normaux ne sont pas assez gros pour nécessiter la fragmentation, et vous ne casserez rien à part les gros pings. J'ai entendu parler (non confirmé) de rapports comme quoi quelques systèmes ont seulement besoin du dernier fragment d'un paquet ICMP déformé pour les corrompre, donc bloquer seulement le premier fragment n'est pas recommandé.
Même si tous les programmes exploitant cette erreur que j'ai vu utilisent l'ICMP, il n'y a pas de raisons qu'un fragment TCP ou UDP (ou d'un protocole inconnu) ne puisse être utilisé pour cette attaque, donc le bloquage des fragments ICMP est seulement une solution temporaire.
Teardrop et Bonk sont deux attaques (principalement contre les machines sous Microsoft Windows NT) qui reposent sur des fragments superposés. Avoir votre routeur Linux défragmenter, ou interdisant tous les fragments vers vos machines vulnérables sont d'autres options.
Quelques piles TCP moins fiables sont connues pour avoir des problèmes à gérer de larges ensembles de fragments de paquets lorsqu'elles ne reçoivent pas tous les fragments. Linux n'a pas ce problème. Vous pouvez filtrer les fragments (ce qui peut casser les utilisations légitimes) ou compiler votre noyau avec l'option "IP: always defragment" mise sur "Y" (seulement si votre machine Linux est la seule route possible pour ces paquets).
Il y a quelques problèmes de temps qui sont impliqués dans la modification des règles pare-feu. Si vous n'y faites pas attention, vous pouvez laisser entrer des paquets lorsque vous avez fait la moitié de vos changements. Une approche simpliste serait de faire la suite :
# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY
... Mise en place des changements ...
# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#
Ceci supprime tous les paquets pour la durée des changements.
Si vos changements sont restreints à une chaîne simple, vous pouvez créer une nouvelle chaîne avec les nouvelles règles, et ensuite remplacer ("-R") la règle qui pointait sur la vieille chaîne par une qui pointe sur la nouvelle chaîne ; ensuite, vous pouvez supprimer la vieille chaîne. Le remplacement se fera à vitesse atomique.
L'IP spoofing est une technique dans laquelle un hôte envoie des paquets qui prétendent venir d'un autre hôte. Puisque le filtrage des paquets prend ses décisions sur la base de cette adresse source, l'IP spoofing est utilisé pour abuser les filtres de paquets. Elle est également utilisée pour cacher l'identité d'un attaquant utilisant les techniques SYN, Teardrop, Ping of Death et autres dérivés (ne vous inquiétez si vous ne savez pas ce que c'est).
Le meilleur moyen de se protéger de l'IP spoofing est la vérification de
l'adresse source, et il est réalisé par le code de routage, et non par le
pare-feu et autres.
Cherchez un fichier nommé /proc/sys/net/ipv4/conf/all/rp_filter.
S'il existe, alors l'activation de la
vérification de l'adresse source à chaque lancement est la bonne solution pour
vous. Pour se faire, insérez les lignes suivantes quelque part dans vos
scripts d'initialisation, avant l'initialisation des interfaces réseau :
# This is the best method: turn on Source Address Verification and get
# spoof protection on all current and future interfaces.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "Setting up IP spoofing protection..."
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1> $f
done
echo "done."
else
echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED.
echo "CONTROL-D will exit from this shell and continue system startup."
echo
# Start a single user shell on the console
/sbin/sulogin $CONSOLE
fi
Si vous ne pouvez faire ceci, vous pouvez insérer manuellement les règles pour
protéger chaque interface. Ceci nécessite la connaissance de chaque interface.
La série des noyaux 2.1 et supérieurs rejette automatiquement les paquets qui
prétendent venir des adresses 127.* (réservées pour l'interface de loopback,
lo).
Par exemple, disons que vous avez trois interfaces, eth0, eth1 et
ppp0. Nous pouvons utiliser ifconfig pour nous donner les adresses
et les masques de réseau de chaque interface. Disons que eth0 est
rattachée à un réseau 192.168.1.0 avec le masque de sous-réseau 255.255.255.0,
eth1 est raccordée à un réseau 10.0.0.0 avec le masque de sous-réseau
255.0.0.0, et ppp0 connectée à l'Internet (où toutes les adresses sauf
les adresses IP privées réservées sont autorisées), nous insérerions les
règles suivantes :
# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#
Cette approche n'est pas aussi bonne que l'approche par vérification de l'adresse source, parce que si votre réseau change, vous devrez changer vos règles pare-feu pour être à jour.
Si vous utilisez un noyau de série 2.0, vous pouvez également vouloir protéger l'interface loopback, en utilisant une règle telle que :
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
Il y a une bibliothèque dans l'espace utilisateur que j'ai écrit et qui est inclue avec la distribution source, nommée "libfw". Elle utilise la capacité de IP Chains 1.3 et suivants pour copier un paquet vers l'espace utilisateur (via l'option du noyau IP_FIREWALL_NETLINK).
La valeur "mark" peut être utilisée pour spécifier les paramètres de Qualité de Service pour les paquets, ou pour spécifier comment les paquets doivent être renvoyés. Je ne l'ai cependant jamais utilisée, mais si vous voulez écrire sur ce sujet, contactez moi.
Des choses comme le stateful inspection (je préfère le terme "pare-feu dynamique") peuvent être implémentées dans l'espace utilisateur en utilisant cette bibliothèque. D'autres idées géniales peuvent être le contrôle des paquets sur une base "par utilisateur" en faisant une demande sur un démon résidant dans l'espace utilisateur. Ceci devrait être relativement simple.
ftp://ftp.interlinx.bc.ca/pub/spf est le site du projet SPF de Brian Murrell, qui permet le suivi de connexion dans l'espace utilisateur. Ceci ajoute une dose significative de sécurité pour les sites à faible bande passante.
Il y a peu de documentation pour le moment, mais voici un message que Brian a envoyé à la liste de diffusion en répondant à quelques questions :
> Je présume qu'il fait exactement ce que je veux~: installer une règle de> "retour" temporaire pour laisser entrer des paquets en réponse à une> requête extérieure.
Yup, c'est exactement ce à quoi il sert. Plus il comprendra de protocoles,
plus il obtiendra de règles de retour exactes. Pour l'instant il supporte
(de mémoire, excusez les erreurs ou les omissions) le FTP (à la fois actif et
passif, intérieur et extérieur), un peu de RealAudio, de traceroute, d'ICMP et
d'un ICQ basique (transmission des serveurs ICQ, connexions TCP directes, mais
hélas la seconde connexion directe TCP pour des trucs comme le transfert de
fichiers, etc., ne sont pas encore présentes)> S'agit-il d'un remplaçant pour ipchains ou d'un ajout~?
C'est un ajout. Pensez à ipchains comme étant le moteur pour autoriser et
empêcher les paquets de traverser une machine Linux. SPF est le pilote, gérant
et surveillant constamment le traffic et disant à ipchains comment changer ses
polices pour refléter les changements dans les schémas du traffic.
Michael Hasenstein de SuSE a codé un correctif pour le noyau qui ajoute le suivi des connexions ftp à ipchains. Celui-ci peut être trouvé sur http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz
Les codes de pare-feu et de NAT sont en cours de remise à jour pour le 2.3. Les plans et les discussions sont disponibles sur l'archive de netdev, et sur la liste ipchains-dev. Ces extensions doivent nettoyer de nombreux problèmes d'utilisation (réellement, la mise en place du pare-feu et le camouflage ne devrait pas être aussi dur, et devrait autoriser une croissance pour un pare-feu beaucoup plus flexible).
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:35