iptables (Français)
iptables est un utilitaire de ligne de commande pour configurer le pare-feu du noyau Linux implémenté dans le projet Netfilter. Le terme iptables est aussi couramment utilisé pour désigner ce pare-feu au niveau du noyau. Il peut être configuré directement avec iptables, ou en utilisant l'une des nombreuses interfaces en console ou graphique. iptables est utilisé pour IPv4 et ip6tables est utilisé pour IPv6. iptables et ip6tables ont la même syntaxe, mais certaines options sont spécifiques à IPv4 ou IPv6.
Installation
Le noyau Arch Linux de base est compilé pour fournir iptables. Vous n'aurez besoin que d'installer les utilitaires de l'utilisateur, qui sont fournis par le paquet iptables. Le paquet iptables est une dépendance indirecte du méta-paquet base, il devrait donc être installé sur votre système par défaut.
Interfaces utilisateur
Console
- Arno's firewall — Pare-feu sécurisé pour les machines à hébergement unique ou multiple. Très facile à configurer, pratique à gérer et hautement personnalisable. Prend en charge : NAT et SNAT, transfert de port, modems ethernet ADSL avec IPs statiques et dynamiques, filtrage d'adresse MAC, détection de scan de port furtif, transfert de DMZ et DMZ-2-LAN, protection contre les inondations SYN/ICMP, journalisation étendue définissable par l'utilisateur avec limitation du taux pour éviter l'inondation des journaux, tous les protocoles IP et VPNs tels que IPsec, support des plugins pour ajouter des fonctionnalités supplémentaires.
- ferm — Outil pour maintenir des pare-feu complexes, sans avoir la peine de réécrire les règles complexes encore et encore. Il permet de stocker l'ensemble des règles du pare-feu dans un fichier séparé et de les charger avec une seule commande. La configuration du pare-feu ressemble à un langage structuré de type programmation, qui peut contenir des niveaux et des listes.
- FireHOL — Langage permettant d'exprimer des règles de pare-feu, et pas seulement un script qui produit une sorte de pare-feu. Il permet de construire facilement des pare-feu, même sophistiqués, comme vous le souhaitez.
- Firetable — Outil pour maintenir un pare-feu IPtables. Chaque interface peut être configurée séparément via son propre fichier de configuration, qui contient une syntaxe facile et lisible par l'homme.
- firewalld (firewall-cmd) — Daemon et interface console pour la configuration du réseau et des zones de pare-feu ainsi que pour la mise en place et la configuration des règles de pare-feu.
- Shorewall — Outil de haut niveau pour la configuration de Netfilter. Vous décrivez les exigences de votre pare-feu/ passerelle à l'aide d'entrées dans un ensemble de fichiers de configuration.
- Uncomplicated Firewall — Interface simple pour iptables.
- PeerGuardian (pglcmd) — Application de pare-feu orientée vers la protection de la vie privée. Elle bloque les connexions vers et depuis les hôtes spécifiés dans d'énormes listes de blocage (des milliers ou des millions de plages IP).
- Vuurmuur — Puissant gestionnaire de pare-feu. Il a une configuration simple et facile à apprendre qui permet des configurations simples et complexes. La configuration peut être entièrement configurée via une ncurses GUI, qui permet une administration à distance sécurisée par SSH ou sur la console. Vuurmuur prend en charge la mise en forme du trafic et dispose de puissantes fonctions de surveillance, qui permettent à l'administrateur de consulter les journaux, les connexions et l'utilisation de la bande passante en temps réel.
- Servicewall — Interface simple d'iptables adaptative qui vous permet de définir les services autorisés lorsque vous êtes connecté à un domaine spécifique, et de changer automatiquement de profil si nécessaire. Il utilise les définitions de services fournies par jhansonxi et utilisées par ufw. Il s'appuie sur ulogd pour alimenter journald avec les journaux de paquets abandonnés, et fournit un cadre d'inspection des journaux en mettant l'accent sur la restriction d'accès aux journaux.
Graphique
- Firewall Builder — Outil graphique de configuration et de gestion de pare-feu qui prend en charge iptables (netfilter), ipfilter, pf, ipfw, Cisco PIX (FWSM, ASA) et les listes d'accès étendues des routeurs Cisco. Le programme fonctionne sous Linux, FreeBSD, OpenBSD, Windows et macOS et peut gérer les pare-feu locaux et distants.
- firewalld (firewall-config) — Daemon et interface graphique pour la configuration du réseau et des zones de pare-feu ainsi que pour la mise en place et la configuration des règles de pare-feu.
- Gufw — Une interface basé sur GTK pour ufw qui se trouve être une interface CLI pour iptables (gufw->ufw->iptables), est super facile et super simple à utiliser.
- PeerGuardian — Application pare-feu orientée vers la protection de la vie privée. Elle bloque les connexions vers et depuis les hôtes spécifiés dans d'énormes listes de blocage (des milliers ou des millions de plages IP).
Concepts de base
iptables est utilisé pour inspecter, modifier, transférer, rediriger et/ou supprimer des paquets IP. Le code pour filtrer les paquets IP est déjà intégré au noyau et est organisé en une collection de tables, chacune ayant un but spécifique. Les tables sont constituées d'un ensemble de "chaînes" prédéfinies, et les chaînes contiennent des règles qui sont parcourues dans l'ordre. Chaque règle consiste en un prédicat de correspondances potentielles et une action correspondante (appelée cible) qui est exécutée si le prédicat est vrai, c'est-à-dire si les conditions sont remplies. Si le paquet IP atteint la fin d'une chaîne intégrée, y compris une chaîne vide, alors la cible politique de la chaîne détermine la destination finale du paquet IP. iptables est l'utilitaire utilisateur qui vous permet de travailler avec ces chaînes/règles. La plupart des nouveaux utilisateurs trouvent les complexités du routage IP sous Linux assez décourageantes, mais, en pratique, les cas d'utilisation les plus courants (NAT et/ou pare-feu Internet de base) sont considérablement moins complexes.
La clé pour comprendre comment iptables fonctionne est ce tableau. Le mot minuscule en haut est le tableau et le mot majuscule en bas est la chaîne. Chaque paquet IP qui arrive sur n'importe quelle interface réseau passe par cet organigramme de haut en bas. Une idée fausse courante est que les paquets entrant depuis, par exemple, une interface interne sont traités différemment des paquets provenant d'une interface tournée vers Internet. Toutes les interfaces sont traitées de la même manière ; c'est à vous de définir des règles qui les traitent différemment. Bien entendu, certains paquets sont destinés à des processus locaux, ils entrent donc par le haut de l'organigramme et s'arrêtent à <Processus local>, tandis que d'autres paquets sont générés par des processus locaux ; ils commencent donc à <Processus local> et descendent dans l'organigramme. Une explication détaillée du fonctionnement de cet organigramme peut être trouvée ici.
Dans la grande majorité des cas d'utilisation, vous n'aurez pas du tout besoin d'utiliser les tables raw, mangle, ou security. Par conséquent, le tableau suivant représente un flux de paquets réseau simplifié à travers iptables :
XXXXXXXXXXXXXXXXXX
XXX Network XXX
XXXXXXXXXXXXXXXXXX
+
|
v
+-------------+ +------------------+
|table: filter| <---+ | table: nat |
|chain: INPUT | | | chain: PREROUTING|
+-----+-------+ | +--------+---------+
| | |
v | v
[local process] | **************** +--------------+
| +---------+ Routing decision +------> |table: filter |
v **************** |chain: FORWARD|
**************** +------+-------+
Routing decision |
**************** |
| |
v **************** |
+-------------+ +------> Routing decision <---------------+
|table: nat | | ****************
|chain: OUTPUT| | +
+-----+-------+ | |
| | v
v | +-------------------+
+--------------+ | | table: nat |
|table: filter | +----+ | chain: POSTROUTING|
|chain: OUTPUT | +--------+----------+
+--------------+ |
v
XXXXXXXXXXXXXXXXXX
XXX Network XXX
XXXXXXXXXXXXXXXXXX
Tables
iptables contient cinq tables :
-
rawest utilisée uniquement pour configurer les paquets afin qu'ils soient exempts de suivi de connexion. -
filterest la table par défaut, et c'est là que toutes les actions typiquement associées à un pare-feu ont lieu. -
natest utilisée pour network address translation (par exemple, la redirection de port). -
mangleest utilisé pour les altérations spécialisées de paquets. -
securityest utilisé pour les règles de contrôle d'accès obligatoire du réseau (par exemple SELinux -- consulter cet article pour plus de détails).
Dans la plupart des cas, vous n'en utiliserez que deux : filter et nat. Les autres tables sont destinées à des configurations complexes impliquant plusieurs routeurs et décisions de routage et sont de toute façon au-delà de la portée de ces remarques introductives.
Chaînes
Les tables sont composées de chaînes, qui sont des listes de règles qui sont suivies dans l'ordre. La table par défaut, filter, contient trois chaînes intégrées : INPUT, OUTPUT et FORWARD qui sont activées à différents moments du processus de filtrage des paquets, comme l'illustre le graphique. La table nat comprend les chaînes PREROUTING, POSTROUTING et OUTPUT.
Consultez iptables(8) pour une description des chaînes intégrées dans d'autres tables.
Par défaut, aucune des chaînes ne contient de règles. C'est à vous d'ajouter des règles aux chaînes que vous souhaitez utiliser. Les chaînes ont une politique par défaut, qui est généralement définie sur ACCEPT, mais qui peut être réinitialisée sur DROP, si vous voulez être sûr que rien ne passe à travers votre jeu de règles. La politique par défaut s'applique toujours à la fin d'une chaîne uniquement. Par conséquent, le paquet doit passer par toutes les règles existantes dans la chaîne avant que la politique par défaut ne soit appliquée.
Des chaînes définies par l'utilisateur peuvent être ajoutées pour rendre les jeux de règles plus efficaces ou plus facilement modifiables. Consultez Simple stateful firewall pour un exemple d'utilisation des chaînes définies par l'utilisateur.
Règles
Le filtrage de paquets est basé sur des règles, qui sont spécifiées par plusieurs correspondances (conditions que le paquet doit satisfaire pour que la règle puisse être appliquée), et une cible (action prise lorsque le paquet correspond à toutes les conditions). Les éléments typiques sur lesquels une règle peut correspondre sont l'interface par laquelle le paquet est arrivé (par exemple eth0 ou eth1), le type de paquet (ICMP, TCP ou UDP) ou le port de destination du paquet.
Les cibles sont spécifiées à l'aide de l'option -j ou --jump. Les cibles peuvent être des chaînes définies par l'utilisateur (c'est-à-dire que si ces conditions sont remplies, il faut sauter à la chaîne suivante définie par l'utilisateur et y poursuivre le traitement), une des cibles spéciales intégrées ou une extension de cible. Les cibles intégrées sont ACCEPT, DROP, QUEUE et RETURN, les extensions de cible sont, par exemple, REJECT et LOG. Si la cible est une cible intégrée, le sort du paquet est décidé immédiatement et le traitement du paquet dans la table courante est arrêté. Si la cible est une chaîne définie par l'utilisateur et que le sort du paquet n'est pas décidé par cette seconde chaîne, il sera filtré par les règles restantes de la chaîne originale. Les extensions de cible peuvent être soit terminantes (comme les cibles intégrées) ou non-terminantes (comme les chaînes définies par l'utilisateur), consultez iptables-extensions(8) pour plus de détails.
Traverser les chaînes
Un paquet réseau reçu sur n'importe quelle interface traverse les chaînes de tables de contrôle du trafic dans l'ordre indiqué dans le flow chart. La première décision de routage consiste à décider si la destination finale du paquet est la machine locale (auquel cas le paquet traverse les chaînes INPUT) ou une autre (auquel cas le paquet traverse les chaînes FORWARD). Les décisions de routage ultérieures consistent à décider de l'interface à affecter à un paquet sortant. À chaque chaîne du chemin, chaque règle de cette chaîne est évaluée dans l'ordre et chaque fois qu'une règle correspond, l'action cible/saut correspondante est exécutée. Les 3 cibles les plus couramment utilisées sont ACCEPT, DROP, et le saut vers une chaîne définie par l'utilisateur. Alors que les chaînes intégrées peuvent avoir des politiques par défaut, les chaînes définies par l'utilisateur ne le peuvent pas. Si chaque règle d'une chaîne que vous avez sautée ne parvient pas à fournir une correspondance complète, le paquet est rejeté dans la chaîne appelante, comme illustré ici. Si, à tout moment, une correspondance complète est obtenue pour une règle avec une cible DROP, le paquet est abandonné et aucun autre traitement n'est effectué. Si un paquet est ACCEPTedans une chaîne, il sera ACCEPTedans toutes les chaînes de supersets également et il ne traversera plus aucune des chaînes de supersets. Cependant, il faut savoir que le paquet continuera à traverser toutes les autres chaînes des autres tables de façon normale.
Modules
Il existe de nombreux modules qui peuvent être utilisés pour étendre iptables tels que connlimit, conntrack, limit et recent. Ces modules ajoutent des fonctionnalités supplémentaires pour permettre des règles de filtrage complexes.
Configuration et utilisation
iptables est un service systemd et est démarré en conséquence. Le paquet Arch iptables installe un ensemble vide de règles dans /etc/iptables/iptables.rules qui sera chargé lorsque vous démarrez l'unité iptables.service pour la première fois. Comme pour les autres services, si vous voulez qu'iptables soit chargé automatiquement au démarrage, vous devez l'activer.
Les règles iptables pour IPv6 sont, par défaut, stockées dans /etc/iptables/ip6tables.rules, qui est lu par ip6tables.service. Vous pouvez le démarrer de la même manière que ci-dessus.
Après avoir ajouté des règles via la ligne de commande comme indiqué dans les sections suivantes, le fichier de configuration n'est pas modifié automatiquement ; vous devez le sauvegarder manuellement :
# iptables-save -f /etc/iptables/iptables.rules
Si vous modifiez le fichier de configuration manuellement, rechargez iptables.
Ou vous pouvez le charger directement à travers iptables :
# iptables-restore /etc/iptables/iptables.rules
En ligne de commande
Afficher les règles actuelles
La commande de base pour lister les règles actuelles est --list-rules (-S), dont le format de sortie est similaire à celui de l'utilitaire iptables-save. La principale différence entre les deux est que ce dernier affiche les règles de toutes les tables par défaut, alors que toutes les commandes iptables n'affichent par défaut que la table filter.
Lorsque vous travaillez avec iptables sur la ligne de commande, la commande --list (-L) accepte plus de modificateurs et affiche plus d'informations. Par exemple, vous pouvez vérifier le jeu de règles actuel et le nombre d'occurrences par règle en utilisant la commande :
# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Si la sortie ressemble à ce qui précède, alors il n'y a pas de règles (c'est-à-dire que rien n'est bloqué) dans la table filter par défaut. D'autres tables peuvent être spécifiées avec l'option -t.
Pour afficher les numéros de ligne lors de l'énumération des règles, ajoutez --line-numbers à cette entrée. Les numéros de ligne sont un raccourci utile pour la #Modification des règles sur la ligne de commande.
Réinitialisation des règles
Vous pouvez purger et réinitialiser iptables par défaut en utilisant ces commandes :
# iptables -F # iptables -X # iptables -t nat -F # iptables -t nat -X # iptables -t mangle -F # iptables -t mangle -X # iptables -t raw -F # iptables -t raw -X # iptables -t security -F # iptables -t security -X # iptables -P INPUT ACCEPT # iptables -P FORWARD ACCEPT # iptables -P OUTPUT ACCEPT
La commande -F sans argument vide toutes les chaînes de sa table courante. De même, -X supprime toutes les chaînes vides autres que celles par défaut dans une table.
Les chaînes individuelles peuvent être vidées ou supprimées en suivant -F et -X avec un argument [chain].
Modification des règles
Les règles peuvent être éditées en ajoutant -A une règle à une chaîne, en l'insérant -I à une position spécifique de la chaîne, en remplaçant -R une règle existante, ou en la supprimant -D. Les trois premières commandes sont illustrées dans ce qui suit.
Tout d'abord, notre ordinateur n'est pas un routeur (à moins, bien sûr, qu'il soit un routeur). Nous voulons changer la politique par défaut sur la chaîne FORWARD de ACCEPT à DROP.
# iptables -P FORWARD DROP
La fonction de synchronisation sur réseau local de Dropbox diffuse des paquets toutes les 30 secondes à tous les ordinateurs qu'elle peut consulter. Si nous nous trouvons sur un réseau local avec des clients Dropbox et que nous n'utilisons pas cette fonction, nous pouvons souhaiter rejeter ces paquets.
# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
REJECT plutôt que DROP, car la RFC 1122 exige que les hôtes renvoient les erreurs ICMP chaque fois que possible, au lieu de laisser tomber les paquets. Cette page explique pourquoi il est presque toujours préférable de REJETER plutôt que de DROP les paquets.Supposons maintenant que nous changeons d'avis sur Dropbox et que nous décidions de l'installer sur notre ordinateur. Nous voulons également effectuer une synchronisation en réseau local, mais uniquement avec une adresse IP particulière sur notre réseau. Nous devons donc utiliser -R pour remplacer notre ancienne règle. Où 10.0.0.85 est notre autre IP :
# iptables -R INPUT 1 -p tcp --dport 17500 ! -s 10.0.0.85 -j REJECT --reject-with icmp-port-unreachable
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Nous avons maintenant remplacé notre règle originale par une règle qui autorise 10.0.0.85 à accéder au port 17500 de notre ordinateur. Mais nous réalisons maintenant que cette règle n'est pas évolutive. Si notre sympathique utilisateur de Dropbox tente d'accéder au port 17500 sur notre appareil, nous devons l'autoriser immédiatement, et non pas le tester en fonction des règles de pare-feu qui pourraient venir par la suite !
Nous écrivons donc une nouvelle règle pour autoriser immédiatement notre utilisateur de confiance. En utilisant -I pour insérer la nouvelle règle avant l'ancienne :
# iptables -I INPUT -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */ 2 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Et remplacez notre deuxième règle par une règle qui rejette tout sur le port 17500 :
# iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable
Notre liste de règles finale ressemble maintenant à ceci :
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */ 2 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Guides
Journalisation
La cible LOG peut être utilisée pour consigner les paquets qui ont rencontré une règle. Contrairement à d'autres cibles telles que ACCEPT ou DROP, le paquet continuera à avancer dans la chaîne après avoir atteint une cible LOG. Cela signifie que pour activer la journalisation de tous les paquets abandonnés, vous devez ajouter une règle LOG en double avant chaque règle DROP. Comme cela réduit l'efficacité et rend les choses moins simples, une chaîne logdrop peut être créée à la place.
Créez la chaîne avec :
# iptables -N logdrop
Et ajoutez les règles suivantes à la chaîne nouvellement créée :
# iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG # iptables -A logdrop -j DROP
L'explication des options limit et limit-burst est donnée ci-dessous.
Maintenant, chaque fois que nous voulons laisser tomber un paquet et enregistrer cet événement, nous sautons simplement à la chaîne logdrop, par exemple :
# iptables -A INPUT -m conntrack --ctstate INVALID -j logdrop
Limiter le débit de logs
La chaîne logdrop ci-dessus utilise le module limit pour empêcher le journal iptables de devenir trop volumineux ou de provoquer des écritures inutiles sur le disque dur. Sans limitation, un service configuré de manière erronée qui essaie de se connecter, ou un attaquant, pourrait remplir le disque (ou au moins la partition /var) en provoquant des écritures dans le journal iptables.
Le module limit est appelé avec -m limit. Vous pouvez ensuite utiliser --limit pour définir un taux moyen et --limit-burst pour définir un taux de rafale initial. Dans l'exemple logdrop ci-dessus :
iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
ajoute une règle qui enregistrera tous les paquets qui la traversent. Les 10 premiers paquets consécutifs seront enregistrés, et à partir de là, seulement 5 paquets par minute seront enregistrés. Le compte de "limit burst" est remis à zéro chaque fois que le "limite rate" n'est pas dépassé, c'est-à-dire que l'activité de journalisation revient automatiquement à la normale.
Visualisation des paquets journalisés
Les paquets journalisés sont visibles sous forme de messages du noyau dans le journal de systemd.
Pour voir tous les paquets qui ont été journalisés depuis le dernier démarrage de la machine :
# journalctl -k --grep="IN=.*OUT=.*"
syslog-ng
En supposant que vous utilisez syslog-ng, vous pouvez contrôler l'emplacement de la sortie du journal d'iptables dans syslog-ng.conf. Remplacez :
filter f_everything { level(debug..emerg) and not facility(auth, authpriv) ; } ;
en
filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_iptables) ; } ;
Ceci arrêtera la journalisation de la sortie d'iptables dans /var/log/everything.log.
Si vous voulez aussi qu'iptables enregistre dans un fichier différent de /var/log/iptables.log, vous pouvez simplement changer la valeur du fichier de destination d_iptables ici (toujours dans syslog-ng.conf) :
destination d_iptables { file("/var/log/iptables.log") ; } ;
ulogd
ulogd est un daemon spécialisé de journalisation de paquets en espace utilisateur pour netfilter qui peut remplacer la cible LOG par défaut. Le paquet ulogd est disponible dans le dépôt [community].