# Digression Installation parefeu (iptables & ip6tables) "pour les nuls"

**URL:** <https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771>\
**Category:** Support Debian\
**Created:** [Février 19, 2016, 12:17 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771 "2016-02-19T00:17:08Z")\
**Posts on this page:** 20\
**Page:** 26

<div class="post-metadata">

**Author:** ![ricardo](https://www.debian-fr.org/user_avatar/www.debian-fr.org/ricardo/32/3864_2.png) [@ricardo](https://www.debian-fr.org/u/ricardo)\
**Post date:** [Mars 16, 2016, 3:03 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/502 "2016-03-16T15:03:29Z")

</div>

> [@PascalHambourg](#):
>
> Mon expérience me dit le contraire (à l’exception du port 53, je l’ai déjà indiqué).Une station configurée en statique et non en DHCP n’a pas besoin d’autoriser **les ports 67 et 68**  
> . D’autre part, les clients DHCP envoient et reçoivent les paquets directement sur l’interface réseau, sans passer par la couche IP et donc sans devoir traverser les règles iptables.

Je ne connaissais pas et je n’ai jamais porté ces deux ports sur mon parefeu.  
Je viens de voir qu’ils géraient (certainement pas le bon terme) BOOTP server et BOOTP client.  
Qu’est-ce exactement ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Mars 16, 2016, 4:20 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/503 "2016-03-16T16:20:26Z")

</div>

BOOTP est l’ancêtre de DHCP qui utilise les mêmes ports.

> [@PengouinPdt](#):
>
> Tu conseillerais quoi comme fréquence de limitation ?

Réponse de Normand : une qui ne gêne pas l’usage normal que tu comptes faire tout en préservant les ressources. Non, je ne me mouille pas, mais il n’y a pas de réponse universelle.

> [@PengouinPdt](#):
>
> Et, tu limites comment la taille des requêtes ?

Avec la correspondance `length`. Mais cela risque de ne pas être efficace en IPv6 si la limite de taille est supérieure à la taille maximum des paquets (MTU) car les paquets de taille supérieure sont fragmentés et chaque fragment a une taille inférieure ou égale à la MTU. (En IPv4 le problème est masqué par conntrack qui réassemble les fragments).

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 16, 2016, 4:58 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/504 "2016-03-16T16:58:07Z")

</div>

A priori (mais ça m’étonne que tu sois passé à coté), il y a le module nf\_conntrack\_ipv6 qui peut/doit (?) procèder lui aussi à une defragmentation de l’ipv6.  
Mais c’est juste ce que j’ai trouvé sur wikipedia par curiosité: je n’ai rien trouvé détaillant comment ça marche, et l’info peut dater de l’ipv6 expérimental et trainer là.

> **[Netfilter | Packet defragmentation](https://en.wikipedia.org/wiki/Netfilter#Packet_defragmentation)**
>
> The nf\_defrag\_ipv4 module will defragment IPv4 packets before they reach Netfilter's connection tracking (nf\_conntrack\_ipv4 module). This is necessary for the in-kernel connection tracking and NAT helper modules (which are a form of "mini-ALGs") that only work reliably on entire packets, not necessarily on fragments. The IPv6 defragmenter is not a module in its own right, but is integrated into the nf\_conntrack\_ipv6 module.

---

<div class="post-metadata">

**Author:** ![PengouinPdt](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pengouinpdt/32/3978_2.png) [@PengouinPdt](https://www.debian-fr.org/u/PengouinPdt)\
**Post date:** [Mars 16, 2016, 5:13 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/505 "2016-03-16T17:13:14Z")

</div>

> [@PascalHambourg](#):
>
> Réponse de Normand : une qui ne gêne pas l’usage normal que tu comptes faire tout en préservant les ressources. Non, je ne me mouille pas, mais il n’y a pas de réponse universelle.

[mode delirium:engage]  
Bon, Monsieur le Normand, beh oui, Pascal Le Normand 😛 - _alors, là, PTDR 😃 ; suis peut-être «&nbsp;sous influence&nbsp;», mais ça ne m’empêche pas d’avoir de l’humour … hihihihihi_-  
mais non, pas Le Normand, puisqu’on te dit Hambourg … Quoi, de Hambourg ? mais non … tsss, laisse tomber, c’est pas grave 😃 -  
y comprend rien lui, alors … ouais, c’est normal, fais pas attention. 😛  
[/mode delirium:ended]

Je me doute qu’il n’y a pas de réponse universelle, le propos est de comprendre justement comment «&nbsp;faire la recette&nbsp;», quels éléments prendre en compte …  
Exemple : choisir 3/s, soit, mais pourquoi, et pourquoi pas 10/s … etc, etc …

Or, ça, personne ne veut livrer ce genre d’informations.

> [@PascalHambourg](#):
>
> Avec la correspondance length. Mais cela risque de ne pas être efficace en IPv6 si la limite de taille est supérieure à la taille maximum des paquets (MTU) car les paquets de taille supérieure sont fragmentés et chaque fragment a une taille inférieure ou égale à la MTU. (En IPv4 le problème est masqué par conntrack qui réassemble les fragments)

Ok, creusons … un début de piste 😛  
Merci

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Mars 16, 2016, 6:00 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/506 "2016-03-16T18:00:46Z")

</div>

> [@mattotop](#):
>
> A priori (mais ça m’étonne que tu sois passé à coté), il y a le module nf\_conntrack\_ipv6 qui peut/doit (?) procèder lui aussi à une defragmentation de l’ipv6.

C’est un point que je n’ai pas encore réussi à éclaircir. Du fait qu’un routeur IPv6 ne doit pas fragmenter, le conntrack IPv6 ne faisait qu’un réassemblage «&nbsp;virtuel&nbsp;», et ensuite les fragments originels poursuivaient leur chemin. Ça a un peu changé depuis le noyau 3.7 et l’introduction du NAT IPv6, cf. la description suivante extraite du changelog :

> commit 4cdd34084d539c758d00c5dc7bf95db2e4f2bc70  
> Author: Patrick McHardy [kaber@trash.net](mailto:kaber@trash.net)  
> Date: Sun Aug 26 19:13:58 2012 +0200

> ```
> netfilter: nf_conntrack_ipv6: improve fragmentation handling
> 
> The IPv6 conntrack fragmentation currently has a couple of shortcomings.
> Fragmentes are collected in PREROUTING/OUTPUT, are defragmented, the
> defragmented packet is then passed to conntrack, the resulting conntrack
> information is attached to each original fragment and the fragments then
> continue their way through the stack.
> 
> Helper invocation occurs in the POSTROUTING hook, at which point only
> the original fragments are available. The result of this is that
> fragmented packets are never passed to helpers.
> 
> This patch improves the situation in the following way:
> 
> - If a reassembled packet belongs to a connection that has a helper
> assigned, the reassembled packet is passed through the stack instead
> of the original fragments.
> 
> - During defragmentation, the largest received fragment size is stored.
> On output, the packet is refragmented if required. If the largest
> received fragment size exceeds the outgoing MTU, a "packet too big"
> message is generated, thus behaving as if the original fragments
> were passed through the stack from an outside point of view.
> 
> - The ipv6_helper() hook function can't receive fragments anymore for
> connections using a helper, so it is switched to use ipv6_skip_exthdr()
> instead of the netfilter specific nf_ct_ipv6_skip_exthdr() and the
> reassembled packets are passed to connection tracking helpers.
> 
> The result of this is that we can properly track fragmented packets, but
> still generate ICMPv6 Packet too big messages if we would have before.
> 
> This patch is also required as a precondition for IPv6 NAT, where NAT
> helpers might enlarge packets up to a point that they require
> fragmentation. In that case we can't generate Packet too big messages
> since the proper MTU can't be calculated in all cases (f.i. when
> changing textual representation of a variable amount of addresses),
> so the packet is transparently fragmented iff the original packet or
> fragments would have fit the outgoing MTU.
> 
> ```

Le plus sûr, c’est encore de faire des tests pour vérifier.

> [@PengouinPdt](#):
>
> Exemple : choisir 3/s, soit, mais pourquoi

Parce que c’est suffisant pour ton besoin que tu es le seul à pouvoir définir.

---

<div class="post-metadata">

**Author:** ![ricardo](https://www.debian-fr.org/user_avatar/www.debian-fr.org/ricardo/32/3864_2.png) [@ricardo](https://www.debian-fr.org/u/ricardo)\
**Post date:** [Mars 16, 2016, 6:19 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/507 "2016-03-16T18:19:54Z")

</div>

> [@Pare-feu IPv4/IPv6, versions bureau et serveur](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665):
>
> Bonjour à tous, Sur suggestion de Ricardo, j’ouvre un nouveau fil pour proposer une mise à jour de pare-feu basique présenté [ici](https://www.debian-fr.org/t/installation-parefeu-iptables-ip6tables-pour-les-nuls/). Le principe reste le même, l’idée était simplement d’unifier un peu toutes les nouveautés liées à l’IPv6 et de proposer une version bureau et serveur. Ce fil est destiné aux débutants, et j’accepterai bien volontiers toutes les modifications proposées par des personnes plus compétentes que moi (elles sont nombreuses slight_smile). #Le principe ##iptables Sur De…

Si on doit débattre sur le présent fil, il serait souhaitable que tu ajoute une réponse dans ce sens avec le lien vers ici.  
Sinon, les demandes vont fuser dans T&A.

Ton œuvre me semble parfaite mais j’attends la vérification et le feu vert du Chef pour l’appliquer à mon futur serveur.

---

<div class="post-metadata">

**Author:** ![seb-ksl](https://www.debian-fr.org/user_avatar/www.debian-fr.org/seb-ksl/32/2946_2.png) [@seb-ksl](https://www.debian-fr.org/u/seb-ksl)\
**Post date:** [Mars 17, 2016, 8:42 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/508 "2016-03-17T08:42:53Z")

</div>

> [@ricardo](#):
>
> il serait souhaitable que tu ajoute une réponse dans ce sens avec le lien vers ici.

C’est fait !

> [@ricardo](#):
>
> Ton œuvre me semble parfaite

Loin s’en faut, je suis justement en train de me relire et corriger pour essayer de prendre en compte tout ce qui a été dit par PascalHambourg et PengouinPdt au-dessus.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Mars 17, 2016, 10:26 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/509 "2016-03-17T10:26:09Z")

</div>

Je n’ai pas encore tout lu mais une petite info mineure en passant à prendre en compte pour la partie réinitialisation du script (clean), assez ancienne mais peut-être méconnue. Depuis le noyau 2.6.36, la table `nat` a aussi une chaîne `INPUT`.

---

<div class="post-metadata">

**Author:** ![seb-ksl](https://www.debian-fr.org/user_avatar/www.debian-fr.org/seb-ksl/32/2946_2.png) [@seb-ksl](https://www.debian-fr.org/u/seb-ksl)\
**Post date:** [Mars 17, 2016, 3:22 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/510 "2016-03-17T15:22:23Z")

</div>

OK, merci à @PascalHambourg et @PengouinPdt pour les conseils 🙂.

J’ai tenté de tout intégrer dans le T&A, et je pense qu’on est bons ! La seule chose que je ne comprends toujours pas (et qui n’est donc qu’un bête copier/coller d’un post de Pascal) sont les règles NDP en icmpv6. Il y a donc peut-être des choses à y corriger.

Si vous pouviez faire une petite relecture, ça me rassurerait ! À vot’ bon cœur !

Édit : rappel de l’URL du T&A : [https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur).

---

<div class="post-metadata">

**Author:** ![PengouinPdt](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pengouinpdt/32/3978_2.png) [@PengouinPdt](https://www.debian-fr.org/u/PengouinPdt)\
**Post date:** [Mars 17, 2016, 3:26 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/511 "2016-03-17T15:26:28Z")

</div>

> [@PascalHambourg](#):
>
> Depuis le noyau 2.6.36, la table nat a aussi une chaîne INPUT.

Tu as lu cela où ?  
Le manpage 1.4.21 n’en parle pas !

---

<div class="post-metadata">

**Author:** ![PengouinPdt](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pengouinpdt/32/3978_2.png) [@PengouinPdt](https://www.debian-fr.org/u/PengouinPdt)\
**Post date:** [Mars 17, 2016, 3:34 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/512 "2016-03-17T15:34:41Z")

</div>

@seb-ksl: ça me semble correct …  
Juste un léger détail, dans les règles ND-IPv6 pour serveur, ajoute une ligne vide entre les écritures INPUT et celles concernant OUTPUT … il m’a fallu quelques secondes pour comprendre la différence ténue … histoire d’aérer 😉

---

<div class="post-metadata">

**Author:** ![seb-ksl](https://www.debian-fr.org/user_avatar/www.debian-fr.org/seb-ksl/32/2946_2.png) [@seb-ksl](https://www.debian-fr.org/u/seb-ksl)\
**Post date:** [Mars 17, 2016, 3:40 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/513 "2016-03-17T15:40:16Z")

</div>

C’est fait 😉

---

<div class="post-metadata">

**Author:** ![ricardo](https://www.debian-fr.org/user_avatar/www.debian-fr.org/ricardo/32/3864_2.png) [@ricardo](https://www.debian-fr.org/u/ricardo)\
**Post date:** [Mars 17, 2016, 4:48 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/514 "2016-03-17T16:48:06Z")

</div>

Pour un SERVEUR de courrier, que l’on n’utilise en direct seulement pour recevoir, l’expédition se faisant via le serveur du FAI (Free), je ne pense pas être obligé d’autoriser et de rediriger le port 25 ?

Pour la réception, j’autorise et je redirige le port 993 (imaps), suis obligé d’y ajouter le port 143 (imap2) ?

Merci pour ces précisions

---

<div class="post-metadata">

**Author:** ![PengouinPdt](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pengouinpdt/32/3978_2.png) [@PengouinPdt](https://www.debian-fr.org/u/PengouinPdt)\
**Post date:** [Mars 17, 2016, 6:44 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/515 "2016-03-17T18:44:12Z")

</div>

@ricardo: Alors, à moins que je ne me trompe sérieusement …

Deux choses à gérer :

1/Il te faut envoyer, cela passe par SMTP(S?), donc à moins d’un changement érigé et dicté par le serveur du FAI, c’est le port 25 TCP, voire 465 TCP - pour sa version S - en sortie …  
Il te faut bien-sûr autoriser les paquest relatifs ou établis en entrée correspondants.

2/ Autoriser l’entrée, protocole TCP, port 993, si tu ne souhaites ABSOLUMENT la connexion sur ce port - tu n’es en rien obligé d’avoir le port 143, et 993 sur lesquels les sockets s’ouvrent.  
Il te faut bien-sûr autoriser là, aussi, les paquets relatifs et/ou établis, en entrée, comme en sortie.

Voili, voilou …  
PS : Ne pas hésiter à corriger, si je me suis tromper

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Mars 19, 2016, 8:13 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/516 "2016-03-19T20:13:38Z")

</div>

Les protocoles POP et IMAP ne servent que pour relever le courrier d’une boîte aux lettres. Donc à moins que ton serveur ne traite que des mails locaux ou les récupère sur d’autres serveurs de courrier par `fetchmail` ou équivalent, il va bien falloir un moyen de lui envoyer des mails depuis l’extérieur. C’est le rôle du protocole SMTP, qui utilise le port TCP 25 (en clair ou chiffrement explicite) ou 465 (chiffrement implicite).

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Mars 19, 2016, 8:29 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/517 "2016-03-19T20:29:58Z")

</div>

> [@PengouinPdt](#):
>
> Tu as lu cela où ?

Dans le changelog du noyau 2.6.36 :

> commit c68cd6cc21eb329c47ff020ff7412bf58176984e  
> Author: Patrick McHardy [kaber@trash.net](mailto:kaber@trash.net)  
> Date: Thu Jun 17 06:12:26 2010 +0200`

> ```
> netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN`
> 
> ```

Je reconnais que l’intitulé du patch n’est pas très parlant, et ce changement ne semble pas avoir été jugé assez important pour être mentionné par kernelnewbies.  
[http://kernelnewbies.org/Linux\_2\_6\_36](http://kernelnewbies.org/Linux_2_6_36)

Une phrase plus explicative est cachée au milieu de la description longue :

> ```
> This patch adds a new INPUT chain to the NAT table and changes the
> targets performing SNAT to be usable in that chain.
> 
> ```

---

<div class="post-metadata">

**Author:** ![ricardo](https://www.debian-fr.org/user_avatar/www.debian-fr.org/ricardo/32/3864_2.png) [@ricardo](https://www.debian-fr.org/u/ricardo)\
**Post date:** [Mars 20, 2016, 12:04 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/518 "2016-03-20T00:04:27Z")

</div>

Merci à vous deux.  
Donc autorisation 25 et 993.

---

<div class="post-metadata">

**Author:** ![chris38](https://www.debian-fr.org/user_avatar/www.debian-fr.org/chris38/32/12918_2.png) [@chris38](https://www.debian-fr.org/u/chris38)\
**Post date:** [Mars 26, 2016, 7:09 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/519 "2016-03-26T19:09:02Z")

</div>

Salut tous,

J’ai un pc equipé avec du filaire et une carte wifi, selon si je me trouve au domicile j’utilise le filaire et en dehors le wifi, comment adapté ce script ?

Merci

---

<div class="post-metadata">

**Author:** ![PengouinPdt](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pengouinpdt/32/3978_2.png) [@PengouinPdt](https://www.debian-fr.org/u/PengouinPdt)\
**Post date:** [Mars 26, 2016, 10:08 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/520 "2016-03-26T22:08:35Z")

</div>

Regarde donc ce post : [Pare-feu IPv4/IPv6, versions bureau et serveur](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665)

Tu as exactement ce qu’il te faut pour une machine !  
C’est bien sûr un script de base, à modifier selon tes besoins, mais dans le cas que tu décris, il ne devrait pas y avoir de modifications.

---

<div class="post-metadata">

**Author:** ![chris38](https://www.debian-fr.org/user_avatar/www.debian-fr.org/chris38/32/12918_2.png) [@chris38](https://www.debian-fr.org/u/chris38)\
**Post date:** [Mars 27, 2016, 8:56 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/521 "2016-03-27T08:56:07Z")

</div>

Ok, merci .

[Page précédente](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771.md?page=25)

[Page suivante](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771.md?page=27)
