Turorial iptables

Tutorial : filtrage avec iptables Mai 2015 Tutorial : Filtrage du réseau sur Linux avec netfilter (iptables) Par Benoit Darties mail : [email protected] Avant-­‐propos: Le filtrage de paquets est le concept qui consiste à accepter ou refuser l’envoi, la réception, ou le suivi d’un paquet réseau en fonction d’éléments qui lui sont propres tels que l’adresse IP de l’émetteur ou du destinataire, le protocole de communication, le port utilisé dans la communication etc … Ce tutoriel explique pas à pas le concept de filtre, ainsi que la mise en place d’un filtrage de paquets sous Linux au moyen de l’outil iptables. Pour comprendre efficacement la mise en place d’un filtrage de paquets Notion de paquets entrants, sortants, et à transférer Dans un réseau, au niveau d’un périphérique donné (routeur, serveur, ordinateur, smartphone, etc), les paquets sont généralement dissociés en 3 familles (indépendamment des notions de filtrage): 1. Les paquets entrants: ce sont les paquets dont la destination est le périphérique, c’est à dire que l’adresse IP de destination du paquet est celle du périphérique 2. Les paquets sortants : ce sont les paquets qui sont émis par le périphérique, c’est à dire que l’adresse IP source est celle du périphérique. 3. Les paquets à transférer : ce sont les paquets qui ne sont pas émis par le périphérique, et qui n’ont pas pour destination ce dernier. Ces paquets n’ont de sens que si le périphérique est un routeur. Autrement ils sont généralement ignorés. Naturellement, cette classification ne dépend pas uniquement du paquet en lui-­‐même, mais bien du paquet par rapport au périphérique sur lequel on l’observe. Supposons un paquet P émis par l’ordinateur A, à destination du serveur D, et qui passe par les routeurs. B et C (voir Figure 1). Alors ce même paquet sera vu comme un paquet sortant pour A, un paquet entrant pour D, et un paquet transféré pour B et C. Paquet P Figure 1 : exemple d’un paquet émis depuis A vers D, et transitant par B et C Remarque : Généralement, les périphériques terminaux (ordinateurs , smartphone, serveurs, ne devraient traiter que des paquets entrants ou sortants, tandis que les routeurs traitent principalement des paquets à transférer, mais également des paquets entrants et sortants. Cette dernière affirmation est particulièrement vraie si le périphérique fait à la fois routeur et serveur. Ainsi dans des conditions normales de fonctionnement et sans aucun filtrage : Réutilisation de ce tutorial soumise à approbation de son auteur Tutorial : filtrage avec iptables -­‐
-­‐
-­‐
Mai 2015 les paquets dits entrants sont toujours acceptés par le périphérique : ils sont lus, et leur contenu est remonté aux différentes couches du modèle OSI jusqu’à l’application de destination. les paquets dits sortants sont toujours autorisés à être envoyés sur le réseau. Ils sont envoyés sur la carte réseau qui va les coder sur le support réseau. Les paquets à transférer sont acceptés si le périphérique est un routeur, qui va se charger de lire l’adresse IP du destinataire, de déterminer le prochain périphérique vers qui envoyer le paquet, et de le lui faire suivre. Le concept de filtrage Règles et politiques Globalement, le filtrage consiste à modifier le comportement par défaut en cas d’envoi, de réception, ou de transfert de paquet, et d’adapter ce comportement en fonction d’éléments propres au paquets eux-­‐mêmes (adresses IP source et destination, port, protocole, etc). Ceci s’opère par l’utilisation conjointe de deux concepts que sont les règles d’une part, et les politiques d’autre part . Grossièrement : -­‐ les règles définissent des éléments (et conditions) que l’on va surveiller sur des paquets, par exemple si l’adresse IP source est 192.168.0.1 et que le port de destination est 80. -­‐ les politiques sont les actions que l’on va appliquer aux paquets lorsque ces derniers répondent aux règles que l’on a définies. Les deux principales politiques que l’on applique sont généralement les suivantes (mais il en existe d’autres, utilisées pour ces manipulations avancées) : o accepter le paquet : le paquet est validé et suit un processus similaire à celui sans filtrage (énoncé plus haut) o jeter le paquet : le paquet est invalidé. S’il s’agissait d’un paquet entrant, il n’est pas lu, s’il s’agissait d’un paquet sortant ou à transférer, il ne sera pas envoyé sur le réseau. Processus de filtrage Le fonctionnement d’un filtrage sous Linux (et pour de nombreux autres systèmes) suit l’organisation suivante : -­‐ Pour chaque famille de paquets (entrant / sortant / à transférer) on définit zéro, une, ou plusieurs règles. -­‐ Pour chaque règle, on définit la politique à appliquer. -­‐ On définit également une politique par défaut pour chaque famille de paquet. Il est bien important de noter qu’une règle est définie pour une seule famille de paquets seulement. Le processus de filtrage d’un paquet suit alors le cheminement suivant : Si le paquet est un paquet sortant, on va regarder une à une les règles définies pour les paquets sortants : dès qu’une règle correspond au paquet étudié, alors on applique immédiatement la politique associée à cette règle (généralement : acceptation ou refus du paquet), et l’analyse se termine : on ne regarde pas les autres règles. Ceci signifie que l’ordre des règles au sein d’une famille de paquets a son importante ! En revanche si une règle ne correspond pas, on regarde la suivante, et ainsi de suite, jusqu’à parcourir l’ensemble des règles. Lorsqu’aucune règle n’a été trouvée, on applique alors la politique par défaut. Quelques remarques avant de poursuivre : Les remarques suivantes sont préliminaires à la partie application, permettent de comprendre les configurations initiales et les erreurs courantes : -­‐ Lorsque qu’aucun filtrage n’est configuré sur le périphérique, ce dernier est en fait dans une configuration dans laquelle pour chaque famille de paquets (entrant, sortant, ou à transférer), aucune règle n’est définie, et la politique par défaut pour chaque famille est d’accepter les paquet -­‐ On peut opter pour deux approches diamétralement opposées dans l’établissement de règles de filtrages : Réutilisation de ce tutorial soumise à approbation de son auteur Tutorial : filtrage avec iptables Mai 2015 a.
-­‐
-­‐
une approche ouverte dans laquelle la politique par défaut consiste à autoriser le trafic, et on rajoute progressivement des règles pour interdire du trafic particulier. Cette approche est moins sécurisée mais plus adaptée à un poste de travail ou un serveur qui propose une ressource sur Internet b. une approche fermée dans laquelle la politique par défaut consiste à rejeter tout le trafic, et on rajoute les règles pour autoriser du trafic spécifique. Cette approche est plus sécurisée et convient surtout à des serveurs d’entreprise ou privés qui contiennent des données sensibles ou qui ne peuvent pas être accédées de n’importe où. Cependant, elle nécessite un peu plus d’attention car il faut considérer tout le trafic et services que le périphérique est autorisé à utiliser. Une communication est bidirectionnelle! Si l’on autorise une communication de l’hôte A vers l’hôte B, il ne faut pas oublier que l’hôte B doit également pouvoir répondre à l’hôte A. Cet élément est souvent oublié principalement lorsque l’on utilise des approches fermées. De nombreux services utilisent une communication réseau sous-­‐jacente, et doivent être pris en compte dans l’établissement de règles de filtrage. Ceci est là encore particulièrement vrai dans les approches fermées. Par exemple, autoriser un ping vers le site www.yahoo.fr ne nécessite pas simplement d’autoriser le trafic de type ICMP, mais ne pas oublier qu’il faut pouvoir transformer l’adresse www.yahoo.fr en adresse IP, et donc autoriser le trafic DNS (UDP, port 53). Application : Linux, netfilter et iptables Sous Linux, le module noyau netfilter s’occupe de filtrer les paquets. La commande iptables est la commande qui permet à l’administrateur de configurer netfilter (les deux noms sont souvent abusivement confondus). Les éléments présentés précédemment se retrouvent ici sous des formes analogues. Les règles que l’on définit sur les familles de paquets vont être définies dans une table1 contenant trois listes indépendantes, que l’on appelle des chaines. Les trois chaînes par défaut correspondant aux familles de paquets entrants sortants et à transférer sont respectivement INPUT, OUTPUT et FORWARD (en majuscule). Prise en main d’iptables et premières commandes Afficher la configuration actuelle La commande iptables requiert les droits administrateurs et doit être lancé avec les droits adéquats (exemple sudo iptables sous de nombreuses architectures UNIX, que nous réutiliserons sur ce tutorial). Pour afficher l’ensemble des trois chaînes, on utilisera la commande : sudo iptables –L Pour chaque chaîne, la politique par défaut (policy) est affichée. Si la chaîne comporte des règles, ces dernières sont affichées successivement en dessous de chaque chaîne, et dans l’ordre utilisé pour leur application. Notons que pour chaque chaîne, la politique par défaut est ACCEPT, qui signifie que tout le trafic est autorisé. Ajouter une politique par défaut Pour changer la politique par défaut sur une chaîne, on utilisera la commande iptables en utilisant l’option –P. Il faudra préciser quelle chaîne on souhaite modifier et quelle politique par défaut mettre sur cette chaîne. 1 (la table netfilter, mais il en existe d’autres, notamment pour la mise en place d’un NAT) Réutilisation de ce tutorial soumise à approbation de son auteur Tutorial : filtrage avec iptables Mai 2015 sudo iptables –P chain policy L’option chain peut prendre une valeur parmi INPUT, OUTPUT, FORWARD. Nous avons dit précédemment que deux politiques sont principalement utilisées : accepter un paquet , et le jeter. Ces deux politiques sont identifiées par les valeurs ACCEPT ou DROP, qui pourront être utilisées dans la ligne de commande. Par exemple si on tape : sudo iptables –P INPUT DROP sudo iptables –P OUTPUT DROP Alors la politique par défaut des chaines INPUT (paquets entrants) et OUPUT (paquets sortants) sera de refuser les paquets. Il est possible de vérifier le changement de politique en réutilisant la commande sudo iptables –L Il est important de comprendre que les règles iptables sont à manier avec précaution, surtout si vous configurez un périphérique à distance (par exemple via ssh) ! si vous modifiez la politique par défaut à DROP sans vous assurer que les communications ssh entre votre machine et le périphérique ne vont pas être jetées, vous pouvez perdre l’accès à la machine. Une erreur ? On efface tout et on recommence Les erreurs de configuration peuvent très vite entraîner des disfonctionnements, surtout lors des premières manipulations. Pour effacer toute la configuration entrée par iptables et revenir à une configuration initiale, on tapera : sudo iptables –F sudo iptables –X L’option –F signifie généralement « flush » (traduction anglaise de « tirer la chasse ») Ajout de quelques entrées de filtrage Les éléments d’une règle Pour ajouter une entrée de filtrage, il faut avant tout se demander sur quoi on veut agir (famille de paquets + règle), et comment on veut agir (politique à appliquer). Pour ajouter une règle à une chaîne donnée, on utilisera l’option –A (pour ajout) suivi de la chaîne à laquelle on souhaite ajouter la règle, puis la liste des éléments propres à la règle (détail ci dessous), et on terminera par la politique à appliquer que l’on précisera avec l’option –j. D’une manière générale, on peut ajouter une règle avec la commande suivante : sudo iptables –A chain [elements de la regle] –j policy On peut examiner dans une règle zéro ou plusieurs éléments, parmi lesquels (liste non exhaustive) : -­‐ Les adresse IP source du paquet, spécifié avec l’option –s : peut prendre comme valeur une adresse IP simple, ou une plage d’adresse avec la notation IP/nombre de bits de masque -­‐ Les adresse IP de destination du paquet, spécifié avec l’option –d : peut prendre comme valeur une adresse IP simple, ou une plage d’adresse avec la notation IP/nombre de bits de masque -­‐ Le protocole, spécifié avec l’option –p : peut prendre les valeurs tcp, udp, icmp -­‐ Le port source, spécifié avec l’option –sport (contraction de source port): peut prendre une valeur entre 1 et 65535, ou le nom courant du service associé à ce port (exemple ssh pour le port 22) -­‐ Le port destination, spécifié avec –dport (contraction de destination port): peut prendre une valeur entre 1 et 65535, ou le nom courant du service associé à ce port -­‐ L’interface sur laquelle le paquet est reçu, spécifié avec –i suivi du nom de l’interface -­‐ L’état d’une connexion (ouverte ou pas) avec l’option –m et –cstate Quelques exemples : • Pour interdire toutes les connexions entrantes sur un serveur, sauf celles sur le serveur web (port 80), on utilisera les commandes suivantes : Réutilisation de ce tutorial soumise à approbation de son auteur Tutorial : filtrage avec iptables Mai 2015 sudo iptables –P INPUT DROP sudo iptables –A INPUT –p tcp –dport 80 -­‐–j accept •
Pour être encore plus restreint et interdire toute communication autre que le web vers et depuis ce serveur, on utilisera les commandes suivantes : sudo iptables –P INPUT DROP sudo iptables –A INPUT –p tcp –dport 80 -­‐–j accept sudo iptables –P OUTPUT DROP sudo iptables –A OUTPUT –p tcp –sport 80 -­‐–j accept •
Sur le routeur du réseau 192.168.0.0/24, pour interdire tout le trafic sauf le trafic web, on utilisera les commandes suivantes : sudo iptables –P FORWARD DROP sudo iptables –A FORWARD –p tcp –sport 80 –d 192.168.0.0/24 -­‐–j accept sudo iptables –A FORWARD –p tcp –s 192.168.0.0/24 –dport 80 -­‐–j accept •
Pour autoriser les clients de ce réseau à pouvoir résoudre les noms de domaine en adresse ip avec le protocole DNS, on ajoutera les règles suivantes : sudo iptables –A FORWARD –p udp –sport 53 –d 192.168.0.0/24 -­‐–j accept sudo iptables –A FORWARD –p udp –s 192.168.0.0/24 –dport 53 -­‐–j accept •
Réutilisation de ce tutorial soumise à approbation de son auteur