iptables (Français) - ArchWiki

Jump to content

# iptables (Français)

From ArchWiki

É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-firewallAUR

- 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/ || fireholAUR

- 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 || firetableAUR

- 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/ || shorewallAUR

- 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/ || pglAUR

- 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/ || vuurmuurAUR

#### 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/ || pglAUR

- 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-binAUR[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 :

1. `raw` est utilisée uniquement pour configurer les paquets afin qu'ils soient exempts de suivi de connexion.
2. `filter` est la table par défaut, et c'est là que toutes les actions typiquement associées à un pare-feu ont lieu.
3. `nat` est utilisée pour network address translation (par exemple, la redirection de port).
4. `mangle` est utilisé pour les altérations spécialisées de paquets.
5. `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

Category:

- Firewalls (Français)

Hidden categories:

- Pages with broken package links
- Pages with dead links

iptables (Français)
Add topic