Dans ce chapitre nous verrons en détail la théorie du filtrage IP, ce que c'est, comment ça fonctionne et certaines choses basiques comme, à quel endroit placer les pare-feux, les règles de filtrage, etc.
Les questions de ce chapitre pourront être, où placer un pare-feu ? Dans la plupart des cas, c'est une question simple, mais dans des réseaux étendus cela peut devenir ardu. Quelles en seraient les règles ? Qui y aurait accès et où ? Qu'est-ce qu'un filtre IP ? Nous y répondrons ici.
Il est important de bien comprendre ce qu'est un filtre IP. Iptables est un filtre IP, et si vous ne comprenez pas complètement cela, vous irez au devant de sérieux problèmes dans la conception de vos pare-feux.
Un filtre IP opère principalement au niveau de la couche 2 de la pile de référence TCP/IP. Iptables cependant peut également travailler au niveau de la couche 3. Mais par définition un filtre IP travaille sur la seconde couche.
Si l'implémentation du filtre IP suit strictement la définition, il devrait être capable, en d'autres termes, de filtrer les paquets basés sur leurs en-têtes IP (adresses source et destination, TOS/DSCP/ECN, TTL, protocole, etc.). Toutes choses actuellement dans l'en-tête IP. Cependant, l'implémentation d'Iptables n'est pas strictement en accord avec la définition, il est aussi capable de filtrer les paquets basés sur d'autres en-têtes se trouvant dans le paquet (TCP, UDP, etc.), et l'adresse MAC.
Il y a une chose cependant sur laquelle Iptables est plutôt strict aujourd'hui. Il ne "suit" pas les flux ou les morceaux de données ensemble. Ce serait une grosse perte de temps. Il garde la trace des paquets et regarde s'ils font partie du même flux de données (via numéros d'interclassement, numéros de port, etc.) à peu près comme la vraie pile TCP/IP. Ceci est appelé traçage de connexion, et grâce à ça nous pouvons effectuer de la translation (masquage/traduction) d'adresse source et destination (généralement appelé SNAT et DNAT), aussi bien que de la vérification d'état de paquets.
Comme nous l'avons vu ci-dessus, Iptables ne peut pas connecter des données provenant de différents paquets entre eux, et donc vous ne pourrez jamais être tout à fait certains que vous verrez la totalité des données à tout moment. Je mentione ça car il y a constamment des questions sur les différentes listes de discussion concernant netfilter et iptables à ce sujet. Par exemple, chaque fois qu'il survient un nouveau virus basé sur Windows, diverses personnes me demandent comment supprimer tous les flux contenant une chaîne spécifique. Par exemple, si nous regardons quelque chose comme ça :
cmd.exe
Que se passe-t-il si l'auteur du virus/exploit est suffisamment malin pour rendre la taille du paquet si petite que cmd tienne dans un seul paquet et .exe dans le paquet suivant ? Les fonctions de vérification de chaîne sont incapables de passer à travers les frontières de paquet, le paquet continuera sa route.
Certains pourront se poser la question, pourquoi ne pas faire simplement des vérifications de chaîne ? C'est actuellement très simple. Ce serait trop coûteux en temps processeur. Le traçage de connexion prend déjà beaucoup de temps processeur. Ajouter une autre couche complexe au traçage de connexion, surchargerait la plupart des pare-feux. Sans parler de la quantité de mémoire supplémentaire qui serait nécessaire pour effectuer cette tâche pour chaque machine.
Il existe une seconde raison pour que cette fonctionnalité ne soit pas développée. Il existe une technique appelée proxy (mandataire). Les proxies ont été développés pour le trafic dans les couches les plus hautes, et donc répondent au mieux à ces besoins. Les proxies ont été créés à l'origine pour gérer les téléchargements et les pages les plus souvent utilisées et accélérer les transferts avec des connexions Internet lentes. Par exemple, Squid est un proxy pour le web. Une personne qui désire charger une page envoie la requête, le proxy soit extrait la requête soit reçoit la requête et ouvre la connexion au navigateur, et ensuite le connecte au serveur web et charge le fichier, et une fois chargé le fichier ou la page, l'envoie au client. Maintenant, si un second navigateur désire lire la même page, le fichier ou la page sont déja chargés par le proxy, et peuvent être envoyés directement, vous économisant du temps (et de la bande passante).
Comme vous pouvez le comprendre, les proxies ont un ensemble de fonctionnalités leur permettant de voir le contenu des fichiers qu'ils chargent. À cause de ça, ils sont bien meilleurs pour visualiser l'ensemble des flux, fichiers, pages, etc.
Après vous avoir prévenu au sujet des problèmes inhérents au filtrage niveau 7 dans Iptables et Netfilter, il existe actuellement un ensemble de patches qui se sont attaqués à ces problèmes. Voir http://l7-filter.sourceforge.net/. Il peuvent être utilisés pour sélectionner un ensemble de protocoles niveau 7 mais sont principalement utilisés avec QoS et le contrôle de trafic, même s'il peuvent être utilisés pour du filtrage pur. Le 17-filter est encore expérimental et développé en dehors des équipes travaillant sur le noyau et Netfilter.