IPTables
Généralités : les pare-feux Linux
https://cybersecuritynews.com/linux-firewall-iptables/ https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture
Un pare-feu Linux est un appareil ou un composant quelconque qui inspecte le traffic réseau et décide le laisser passer ou non. Iptables est un outil permettant de gérer les règles de pare-feu sous Linux. La sécurité réseau a évolué avec les différents types de pare-feux qui ont existé à travers les âges : traditionnellement, les fw gèrent les couches 3 et 4, soit les couches routage et transport. Mais des pare-feux plus récents peuvent agir sur les couches plus hautes, par exemple pour analyser le trafic au niveau applicatif.
Iptables, c'est quoi
IPTables est une interface en ligne de commandes qui permet de configurer des règles spécifiques, lesquelles iront forcer le kernel avec sa couche netfilter à faire des actions comme inspecter, modifier ou dropper des paquets. Le fait d'utiliser IPtables permet d'accéder à des fonctions de pare-feu, mais aussi des fonctionnalités de routeur.
Différents modules de kernel et programmes sont utilisés pour différents protocoles : iptables est valide pour ipv4, ip6tables pour ipv6, arptables pour arp, ebtables pour les trames ethernet; etc. Le projet nftables, lui, a été développé pour la performance et la scalabilité et son fonctionnement est différent.
Comment marche le filtrage de paquets
Une policy iptables est construite avec un set ordonné de règles, lesquelles disent au kernel les actions qu'il devrait faire sur certains types de paquets.
Hooks netfilter
Il y a 5 hooks netfilter que les programmes peuvent utiliser. Alors qu'un paquet passe dans la stack, il va déclencher les modules de kernel associés à ces hooks (l'image étant que le paquet passant dans la stack s'accroche à certains crochets, un peu comme un steak sur un tapis roulant je suppose :thinking:). Les hooks déclenchés dépendent de la direction du paquet (in ou out), sa destination, et si il a déjà été droppé ou rejeté dans le passé.
Les hooks suivants représentent des points bien définis de la stack:
- NF_IP_PRE_ROUTING : Sera activé par n'importe quel traffic entrant peu après son arrivée dans la stack. Ce hook est pris en compte avant toute décision de routage.
- NF_IP_LOCAL_IN : Sera activé par un paquet entrant qui a été routé, si celui-ci est destiné au système local.
- NF_IP_FORWARD : Activé après qu'un paquet entrant ait été routé vers un autre host que le système local.
- NF_IP_LOCAL_OUT : Activé par n'importe quel traffic à destination de l'extérieur, qui a été créé sur le système local, dès son entrée dans la stack.
- NF_IP_POST_ROUTING : Activé par n'importe quel traffic forwardé ou sortant après le routage et avant l'envoi sur le câble.
Les modules de kernel qui veulent s'enregistrer auprès de ces hooks (pour pouvoir faire des choses lors du déclenchement des hooks) doivent fournir un numéro de priorité pous savoir dans quels ordre ils seront appellés. Ainsi, on peut connecter plusieurs modules à chacun des hooks, le tout dans un ordre déterminé. Chaque module sera appellé à son tour et rendra une décision au framework netfilter pour indiquer ce qu'il doit advenir du paquet.
Tables et chaînes
Iptables utilise des tables pour stocket ses règles : il s'agit de tables au même sens que dans une BDD. Ces tables sont chacune fonction d'un type de décision, et vont stocker des règles en rapport : par exemple, la table nat stocke tout ce qui a trait au nat. La table filter gère le filtrage des paquets en fonction de leur destination, par exemple.
Pour chaque table, les règles sont organisées dans des chaînes. Tandis que les tables sont définies de façon généraliste, les chaînes représentent quels "hooks" seront associés. En somme, les chaînes déterminent à quelle condition les règles seront évaluées. Les chaînes reprennent les noms des hooks netfilter:
- PREROUTING représente NF_IP_PRE_ROUTING
- INPUT représente NF_IP_LOCAL_IN
- FORWARD représente NF_IP_FORWARD
- OUTPUP représente NF_IP_LOCAL_OUT
- POSTROUTING représente NF_IP_POST_ROUTING.
Chaque table ayant plusieurs chaînes, elle peut intervenir à plusieurs endroits de la stack. Cela dit, toutes les tables n'ont pas toutes les chaînes, cela dépend de ce qui est logique avec leur nature. Il n'y a que 5 hooks, ce qui fait que les chaînes de plusieurs tables sont présentes à chaque hook : par exemple, il existe 3 tables ayant des chaînes PREROUTING. Elles sont donc hiérarchisées entre elles au niveau du hook.
Il existe plusieurs tables:
- filter : la plus utilisée. Prend des décisions pour laisser un paquet continuer vers sa destination ou non. C'est la table de filtrage qui fait le gros de ce qu'on attend d'un fw.
- nat : Sert à implémenter la traduction d'adresses. Les règles de cette table vont déterminer les modifications du paquet en lien avec la source / la dest afin d'avoir du nat.
- mangle : Utilisée pour altérer les en-têtes IP du paquet de plusieurs façons. Elle peut par exemple ajuster le ttl, modifiant ainsi le nombre de sauts valides pour le paquet. Elle peut aussi mettre une marque sur le paquet à destination du kernel, qui ne touche pas au contenu mais permettra divers traitements.
- raw : iptables est statefull, donc les paquets sont gérés en fonction de leur relation à ce qui s'est passé avant. Ainsi, netfilter permet de voir les paquets comme faisant partie d'une connection et pas simplement comme des colis. Cette logique de connection s'applique très tôt après que le paquet soit arrivé sur l'interface réseau. La table raw ne sert qu'à une chose : permettre de marquer les paquets pour s'échapper de cette logique de connection.
- security : Utilisée pour gérer les marques en lien avec le contexte de sécurité interne de SELinux.
Lien entre tables et chaînes
Le tableau qui suit indique quelles chaînes sont dispo pour chaque table, de gauche à droite en fonction de l'ordre des hooks. Lu de haut en bas, il indique l'ordre dans lequel les tables accèdent aux hooks. Il faut noter que la table NAT a été subdivisée : DNAT est pour Destination NAT et SNAT pour Source NAT. On indique aussi des points du routage sont prises et ou la gestion des connections est activées afin de donner une vue généraliste du processus :
Ordre de traversée des chaînes
En supposant qu'on sait comment router le paquet et qu'il a le droit d'être là en fonction des règles de fw, le flux suivant représente le chemin traversé selon la situation:
- Paquets entrant pour le système local : PREROUTING -> INPUT
- Paquets entrants à forwarder : PREROUTING -> FORWARD -> POSTROUTING
- Paquets générés localement : OUTPUT -> POSTROUTING
A CONTINUER A PARTIR DE LA SECTION IPTABLE RULES https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture