iptables (Français)

État de la traduction:
Cet article est la version francophone de
iptables
. Date de la dernière traduction: 2023-03-17. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
nftables
Fail2ban
sshguard
Simple stateful firewall
Sysctl#TCP/IP stack hardening
Uncomplicated Firewall
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.
Note
iptables
est une ancienne infrastructure,
nftables
vise à fournir un remplacement moderne incluant une couche de compatibilité.
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.
https://rocky.eld.leidenuniv.nl/
||
arno-iptables-firewall
AUR
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.
http://ferm.foo-projects.org/
||
ferm
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.
https://firehol.sourceforge.net/
||
firehol
AUR
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.
https://gitlab.com/hsleisink/firetable
||
firetable
AUR
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.
https://firewalld.org/
||
firewalld
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.
http://www.shorewall.net/
||
shorewall
AUR
Uncomplicated Firewall
— Interface simple pour iptables.
https://launchpad.net/ufw
||
ufw
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).
https://sourceforge.net/projects/peerguardian/
||
pgl
AUR
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.
https://www.vuurmuur.org/
||
vuurmuur
AUR
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.
https://fwbuilder.sourceforge.net/
||
fwbuilder
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.
https://firewalld.org/
||
firewalld
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.
https://gufw.org/
||
gufw
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).
https://sourceforge.net/projects/peerguardian/
||
pgl
AUR
Portmaster
— Portmaster est un pare-feu applicatif gratuit et open-source avec des paramètres par défaut pour améliorer votre vie privée.
https://safing.io/
||
portmaster-stub-bin
AUR
[
broken link
: package not found]
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 :
raw
est utilisée uniquement pour configurer les paquets afin qu'ils soient exempts de suivi de connexion.
filter
est la table par défaut, et c'est là que toutes les actions typiquement associées à un pare-feu ont lieu.
nat
est utilisée pour
network address translation
(par exemple, la redirection de port).
mangle
est utilisé pour les altérations spécialisées de paquets.
security
est 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
[
dead link
2025-01-19—HTTP 404]
.  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 contrôle du trafic des tables dans l'ordre indiqué dans l'organigramme
[1]
[
dead link
2025-01-19—HTTP 404]
. La première décision de routage consiste à déterminer si la destination finale du paquet est la machine locale (auquel cas le paquet traverse les chaînes
INPUT
) ou une autre machine (auquel cas le paquet traverse les chaînes
FORWARD
). Les décisions de routage ultérieures consistent à décider de l'interface à attribuer à 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 trois 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 toutes les règles d'une chaîne que vous avez sautée ne parviennent pas à fournir une correspondance complète, le paquet est renvoyé dans la chaîne d'appel ; voir l'illustration suivante
[2]
. 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 atteint un saut vers la cible ACCEPT, il ne traversera pas d'autres règles de la chaîne et des chaînes suivantes de la table. Son traitement passera à la première chaîne de la table suivante dans l'ordre. Voir aussi
Traversing tables and chains
et
Accept Target
du tutoriel frozentux.
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
Attention
Le reste de cette section a pour but d'enseigner la syntaxe et les concepts des règles iptables. Il ne s'agit pas d'un moyen de sécuriser les serveurs. Pour améliorer la sécurité de votre système, consultez
Simple stateful firewall
pour une configuration iptables minimalement sécurisée et
Security
pour renforcer Arch Linux en général.
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
Note
Nous utilisons ici
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
Permettre le trafic multidiffusion
Les protocoles qui utilisent l'identification multicast (par exemple
SANE
qui recherche des scanners de réseau) enverront du trafic à l'IP de diffusion du réseau et les réponses reviendront de l'IP d'un client spécifique. Puisque ces adresses IP sont différentes, iptables ne reconnaîtra pas la réponse comme
RELATED
ou
ESTABLISHED
, et il bloquera la réponse. Voir
[3]
pour savoir comment accepter le trafic multicast sans créer un pare-feu trop permissif.
Tout d'abord, créez un conteneur de hachage
ipset
. Le délai d'attente est la fenêtre de temps pour accepter les réponses du client.
# ipset create upnp hash:ip,port timeout 3
Ensuite, créez une règle pour ajouter le trafic multicast sortant au hash ipset.
# iptables -A OUTPUT -d 239.255.255.250/32 -p udp -m udp -j SET --add-set upnp src,src --exist
Troisièmement, créez une règle pour autoriser le trafic entrant qui correspond au hachage de l'ipset.
# iptables -A INPUT -p udp -m set --match-set upnp dst,dst -j ACCEPT
Enfin, n'oubliez pas de sauvegarder les nouvelles règles (voir
#Configuration et utilisation
et
ipset#Making ipset persistent
), et assurez-vous que
iptables.service
et
ipset.service
sont
activés
pour que les règles se chargent au démarrage du système.
Guides
Simple stateful firewall
Router
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.
Voir aussi
Article Wikipedia
Port knocking
Site web officiel d'iptables
iptables Tutorial 1.2.2
par Oskar Andreasson
Debian Wiki - iptables
Utilisation sécurisée des aides au suivi des connexions