# Digression Installation parefeu (iptables & ip6tables) "pour les nuls" **URL:** \ **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:** 25
**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 15, 2016, 7:55 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/482 "2016-03-15T07:55:33Z")
> [@PengouinPdt](#): > > Tels que 53 (dns:tcp/udp), 67 & 68 (dhcp:udp), 123 (ntp:udp), 5353 (multicast:udp) - qui ne sont vraiment qu’un minimum … non ?! Non, excepté DNS dans la plupart des cas. > [@ricardo](#): > > Sur une machine non serveur (sauf SSH), est-ce que le port 443 doit être obligatoirement ouvert ? Non, pas obligatoirement. Et arrêtez de parler de port « ouvert », c’est ambigu. Ce sont les sockets qui ouvrent des ports, pas le pare-feu. Celui-ci ne fait qu’autoriser ou bloquer des paquets ou des connexions. D’autre part il faut préciser si c’est en entrée ou en sortie. Un poste client qui fait des connexions HTTPS sortantes n’a pas besoin d’autoriser les paquets entrants à destination du port 443. ---
**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 15, 2016, 8:39 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/483 "2016-03-15T08:39:27Z")
@PascalHambourg : merci, j’intègre tout ça dans la journée ! * * * > [@PengouinPdt](#): > > Dans la partie Vérification, peut-être informer/rajouter l’option ‹ –line-numbers › qui est bien pratique, non ?! Je ne connaissais pas, je vais l’ajouter en facultatif. > [@PengouinPdt](#): > > Dans la partie Configuration, peut-être mettre un laïus plus explicite, sur les ports à ouvrir absolument sur une machine pour qu’elle puisse discuter sur un réseau, et bien-sûr lié à Internet a-fortiori. Tels que 53 (dns:tcp/udp), 67 & 68 (dhcp:udp), 123 (ntp:udp), 5353 (multicast:udp) - qui ne sont vraiment qu’un minimum … non ?!Et, pourquoi pas faire un petit rappel, sur ceux liés à la gestion de mails, hkp, cups, samba, bref, les plus courants … ?! > [@ricardo](#): > > Sur une machine non serveur (sauf SSH), est-ce que le port 443 doit être obligatoirement ouvert ?Si oui : tcp, udp, les deux ?Merci Comme déjà répondu par PascalHambourg, il ne faut pas confondre l’entrée (INPUT) et la sortie (OUTPUT). Pour une machine de bureau, je propose une stratégie (POLICY) OUTPUT sur ACCEPT. Donc tout est autorisé à sortir de la machine. En revanche, à moins que cette machine ne soit un serveur HTTP(S), DNS, DHCP, NTP ou autre, elle n’a aucune raison d’accepter des requêtes en INPUT sur ces ports-là. ---
**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 15, 2016, 10:38 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/484 "2016-03-15T10:38:59Z")
Personnellement, je connais très bien la différence entre les deux … et, il est vrai que j’ai oublié de le préciser dans mon post précédent. Désolé, _quand on a l’habitude de certains sujets, et de certaines évidences - où l’on n’oublie que nos évidences ne sont pas celles des autres_ 😛 @Pascal, toujours dans la précision ultime, tu es 😃 En effet, tu as raison de préciser - cela s’appelle de notre part un abus de language. @seb-ksl: Par contre, là où je ne suis pas d’accord - et je viens de relire plus précisément ton tuto - en effet, tu as autorisé par défaut toutes tes sorties sur les stations. Personnellement, je ne le ferais pas - c’est pourquoi dans mon post précédent, j’ai écrit d’ouvrir certains ports par défaut, et là je le précise, en sortie … @Pascal, je suis d’accord avec toi de ne pas préciser les ports en sortie, **seulement et si seulement** , toutes les sorties sont autorisées - ce qui est le cas dans le tuto de seb-ksl - que j’avais seulement survolé. Concernant la partie serveur, autorisée en sortie le port 443 est rarement utile, dans la pratique, cela te servira pour surfer sur Internet … les serveurs de package ne sont accessibles que sur le port 80, voire FTP, mais pas HTTPS ; donc, surfer sur Internet depuis le serveur, sans besoin réel, personnellement je n’en vois pas l’utilité - mais là, encore, je peux me tromper 😛 En tout cas, je tiens à le dire à nouveau, c’est du bon boulot de présentation, voire d’explications. Merci ! ---
**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 15, 2016, 11:13 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/485 "2016-03-15T11:13:29Z")
> [@PascalHambourg](#): > > … > Et arrêtez de parler de port « ouvert », c’est ambigu. Ce sont les sockets qui ouvrent des ports, pas le pare-feu. Celui-ci ne fait qu’autoriser ou bloquer des paquets ou des connexions. D’autre part il faut préciser si c’est en entrée ou en sortie. Un poste client qui fait des connexions HTTPS sortantes n’a pas besoin d’autoriser les paquets entrants à destination du port 443. Quel terme suffisamment court employer : autoriser ? autre ? ---
**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 15, 2016, 11:50 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/486 "2016-03-15T11:50:27Z")
> [@PengouinPdt](#): > > Concernant la partie serveur, autorisée en sortie le port 443 est rarement utile, dans la pratique, cela te servira pour surfer sur Internet … les serveurs de package ne sont accessibles que sur le port 80, voire FTP, mais pas HTTPS ; donc, surfer sur Internet depuis le serveur, sans besoin réel, personnellement je n’en vois pas l’utilité - mais là, encore, je peux me tromper 😛 Sur mon serveur j’ai besoin des 80/443 sortants parce que j’ai une page (un agrégateur de flux RSS) qui envoie des requêtes HTTP et HTTPS à travers `wget` pour récupérer le contenu des flux. > [@PengouinPdt](#): > > Personnellement, je ne le ferais pas - c’est pourquoi dans mon post précédent, j’ai écrit d’ouvrir certains ports par défaut, et là je le précise, en sortie … Libre à toi de régler la POLICY d’OUTPUT à DROP et d’autoriser les sorties port par port, je l’avais fait au début 🙂. Mais ça fait un moment que je suis repassé en ACCEPT, pour une simple raison : trop prise de tête sur une machine de bureau classique. À chaque installation d’un nouveau programme tu dois faire attention à ce qu’il soit bien autorisé à communiquer sur un/des port(s) particulier(s), ce qui n’est pas toujours bien documenté par l’auteur du programme d’ailleurs. Mon dernier exemple en date : qarte. Dans son cas, il fallait « simplement » le lancer depuis un terminal en mode debug pour suivre ses requêtes, et notamment le port. Pour d’autres programmes je me suis retrouvé à enchaîner des netstat pour voir ce qu’ils essayaient de faire qui était bloqué de mon côté. C’est vite pénible, d’autant que je ne suis pas persuadé de l’utilité de la chose. Si quelqu’un a une bonne raison à avancer… ? En revanche je me suis contraint à l’exercice sur mon pare-feu serveur : si tu as bien regardé, toutes ses POLICY sont à DROP. Je l’ai fait parce que je pense que c’est une bonne chose de « tout » contrôler sur un serveur, en tout cas ça force à savoir quel service fait quoi à travers quel port. Je peux me tromper, mais je pense aussi que ça évite d’être transformé trop facilement en bot, puisque la machine ne peut pas envoyer ce qu’on veut à travers tous les ports (bien que le 80 ouvert en sortie doive pouvoir être suffisant pour ça). Voilà, évidemment ce sont des choix personnels qui peuvent tout à fait se discuter 🙂. ---
**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 15, 2016, 12:26 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/487 "2016-03-15T12:26:39Z")
> [@PascalHambourg](#): > > - En IPv4, je ne vois pas l’utilité d’accepter tous les paquets ICMP. Sans la règle `iptables -A INPUT -p icmp -j ACCEPT`, la machine répondra toujours au ping ? Ou peut-être que tu veux suggérer d’être plus fin dans le filtrage des paquets ICMP ? J’avoue mon incompétence à ce sujet. > [@PascalHambourg](#): > > - En IPv6, je ne vois pas l’utilité d’accepter tous les paquets ICMPv6. > - Pourquoi accepter tous les paquets ICMPv6 echo-reply en sortie mais pas en entrée et pas en IPv4 ? Note : ce n’est utile que si l’adresse source de la réponse est différente de l’adresse destination de la requête, ce qui n’est à ma connaissance possible que si cette dernière est une adresse anycast ou multicast. Dans le cas contraire, la réponse est dans l’état ESTABLISHED et donc déjà acceptée par une autre règle. Idem, j’ai peur de ne pas comprendre. Je me suis basé sur ce qui a été dit dans le post sur IPv6 [ici](https://www.debian-fr.org/t/apprendre-a-passer-en-ipv6/68242/26), visiblement maladroitement. Je vais essayer de me rencarder un peu sur l’ICMPv6, en attendant n’hésite pas à proposer des corrections. ---
**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 15, 2016, 2:13 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/488 "2016-03-15T14:13:48Z")
> [@seb-ksl](#): > > Sans la règle iptables -A INPUT -p icmp -j ACCEPT, la machine répondra toujours au ping ? Ou peut-être que tu veux suggérer d’être plus fin dans le filtrage des paquets ICMP ? J’avoue mon incompétence à ce sujet. Pour être + fin relativement à ICMP, et donc ne pas autoriser tout le flux correspondant, ta règle se transforme ainsi, pour ta station : ```auto iptables -A INPUT -p icmp --icmp-type echo-reply -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT ``` Bien sûr, si tu veux autoriser qu’une machine quelconque te ping, il faut rajouter l’état ‹ NEW › à la deuxième règle … Sauf que si tu places ces règles d’entrées liées à ICMP, après l’écriture définissant l’acceptation des règles relatives aux états ‹ RELATIFS ›, ‹ ETABLIES ›, elles n’ont plus lieu d’être … d’ailleurs personnellement, j’aurais mis en premier cette règle, juste après celles relatives à localhost. De même, dans le contexte de station la règle de sortie n’a pas lieu, puisque tu as écrit que tout devait sortir … Juste pour info, voici les règles before écrite dans le projet ufw lors de l’installation : ` # règles INPUT -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT ` Il n’y a pas de règles en sortie, car par défaut les ‹ policies › sont allouées. Voili, voilou … si ça peut aider 😃 * * * Et, oui, comme le dit PascalHambourg, je suis surpris aussi que tu les ai écrites pour icmpv6, et pas icmp … ? Mais tu l’expliques toi-même 😉 ---
**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 15, 2016, 8:00 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/489 "2016-03-15T20:00:05Z")
Réponses en vrac. > [@PengouinPdt](#): > > @Pascal, je suis d’accord avec toi de ne pas préciser les ports en sortie, seulement et si seulement, toutes les sorties sont autorisées Je ne me rappelle pas avoir écrit cela. Si tu fais référence à ma réponse « Non, excepté DNS dans la plupart des cas », cela n’avait rien à voir, je contestais seulement que DHCP, NTP, mDNS fassent partie du minimum obligatoire. > [@PengouinPdt](#): > > les serveurs de package ne sont accessibles que sur le port 80, voire FTP, mais pas HTTPS Au risque de te contredire encore, il existe un transport HTTPS optionnel pour APT : cf. paquet apt-transport-https. > [@ricardo](#): > > Quel terme suffisamment court employer : autoriser ? Oui, ou accepter, laisser passer. Et surtout, préciser de quoi on parle. Comme si le filtrage n’était déjà pas assez compliqué en soi, les règles iptables traitent des paquets individuels alors que les humains ont tendance à raisonner avec des connexions (qui mettent en oeuvre des paquets émis et reçus). > [@seb-ksl](#): > > Sans la règle iptables -A INPUT -p icmp -j ACCEPT, la machine répondra toujours au ping ? Ou peut-être que tu veux suggérer d’être plus fin dans le filtrage des paquets ICMP ? Oui, je suggère d’être plus fin. Sinon, à quoi bon toutes les autres règles pour des types ICMP et ICMPv6 spécifiques ? > [@PengouinPdt](#): > > Bien sûr, si tu veux autoriser qu’une machine quelconque te ping, il faut rajouter l’état ‹ NEW › à la deuxième règle A propos de cette règle, à quoi sert-elle au juste sans l’état NEW ? D’autant plus qu’il y a déjà une règle générale qui accepte tous les paquets dans l’état ESTABLISHED. (Au passage, les paquets ICMP echo-request dans l’état ESTABLISHED sont plutôt rares). > [@PengouinPdt](#): > > Juste pour info, voici les règles before écrite dans le projet ufw lors de l’installation Juste pour info, le type source-quench a été déclaré dangereux, obsolète et déconseillé. ---
**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 15, 2016, 10:54 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/490 "2016-03-15T22:54:24Z")
Question bête, dont la réponse à due être déjà donnée mais … Quels sont les dangers qu’il y a à être “pingué”, pour vouloir l’empêcher ? ---
**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 15, 2016, 11:09 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/491 "2016-03-15T23:09:37Z")
> [@PascalHambourg](#): > > Au risque de te contredire encore, il existe un transport HTTPS optionnel pour APT : cf. paquet apt-transport-https. Oui, optionnel … confidentiel … etc, etc, etc … Qui est réellement informé ?! Tu n’as pas le sentiment de pinailler, un peu là 😉 > [@PascalHambourg](#): > > Si tu fais référence à ma réponse « Non, excepté DNS dans la plupart des cas », cela n’avait rien à voir, je contestais seulement que DHCP, NTP, mDNS fassent partie du minimum obligatoire. Oui, je parlais de cette réponse … Et, tu peux contester ; mon expérience sait qu’il faut un minima pour une station, en output … 53, 67, 68 … Et, certains utiles, tels que 80, 443, mDNS, certains ICMP, etc … etc … > [@PascalHambourg](#): > > Juste pour info, le type source-quench a été déclaré dangereux, obsolète et déconseillé. Merci de la précision. Comme quoi, même dans les projets libres officiels, on peut faire certaines bêtises, n’est-ce pas ?! Et, en effet, le draft IETF 2014 rappelle ceci : > [@https://tools.ietf.org/html/draft-ietf-opsec-icmp-filtering-04#section-2.1.2.2](#): > > 2.1.2.2. Message Specification > > The Source Quench (…) is being formally deprecated by [RFC6633]. > > 2.1.2.3. Threats > > Can be exploited for performing throughput-reduction attacks > [RFC5927]. * * * > [@ricardo](#): > > Quels sont les dangers qu’il y a à être « pingué », pour vouloir l’empêcher ? De ce que j’ai compris, simplement le fait de renseigner que ta machine est bel et bien fonctionnelle ! Et, ainsi de « cartographier » ton réseau … _C’est encore et toujours l’histoire du renseignement, ni plus ni moins, et de ce qui peut en être fait, ensuite …_ Mais c’est toute la différence, entre un autodidacte - _très certainement mal averti_ -, et un GRAND 😛 professionnel comme Pascal, qui encore une fois, corrigera le propos 😉 @Pascal: Je sais pertinemment que je ne fais pas le poids - au moins, je participe avec plaisir ; et tes remontrances nous permettront à tous de nous améliorer réellement. Merci @ricardo: Je te réponds avec la documentation sus-mentionné ci-dessus : > [@https://tools.ietf.org/html/draft-ietf-opsec-icmp-filtering-04#section-2.2.1.1.3](#): > > 2.2.1.1.3. Threats > > Can be used for network mapping [icmp-scanning]. This vector could > be partially mitigated by applying rate-limit to this traffic. > > Has been exploited to perform Smurf attacks [smurf]. A router could > mitigate this by dropping ICMP echor request messages directed to any > of its directly-connected subnets. > > 2.2.1.1.4. Operational and Interoperability Impact if Blocked > > Filtering this error message will break the ping tool. The best > current practice is to rate-limit this ICMP message. > > (…) > > 2.2.1.2.3. Threats > > Can be used for network mapping [icmp-scanning]. Has been exploited > to perform Smurf attacks [smurf]. > > 2.2.1.2.4. Operational and Interoperability Impact if Blocked > > Filtering this error message will break the ping tool. The best > current practice is to rate-limit this ICMP message. Comme quoi, c’est mieux de laisser répondre les docs intéressantes … PS : Si jamais besoin de traduction, c’est avec plaisir que je m’y essayerais, tant bien que mal ! 😉 ---
**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, 12:42 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/492 "2016-03-16T00:42:15Z")
À peu près compris mais la semaine de défense de la langue française, tu pourrais faire l’effort de placer des liens en français.😀 ---
**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, 12:58 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/493 "2016-03-16T00:58:49Z")
Faudrait-il qu’ils existent encore 😛 Quoiqu’il en soit le document en question, dit que plutôt de bloquer le flux correspondant au ping, mieux vaut limiter son flux… là, c’est l’usage de l’option ‘-m -limit --limit 1/second’, par exemple. Sinon, la revue Hackin9 avait sorti en 02/2006 un article intéressant sur l’utilisation et les abus ICMP possibles. Très explicite. Si tu le veux, mail-me, tu sais où me trouver 😉 ---
**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 16, 2016, 9:09 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/494 "2016-03-16T09:09:02Z")
OK, je commence à saisir le débat sur ICMP, ouf 🙂. Avant d’écrire une bêtise sur le T&A, je vous soumets une version revue des règles relatives à ICMP et ICMPv6, j’attends vos avis pour corriger le T&A. Ancienne version : ``` ## IPv4 ## iptables -A INPUT -p icmp -j ACCEPT ## IPv6 ## ip6tables -t filter -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT ``` Nouvelle version : ``` ## IPv4 ## iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT # Uniquement pour le script serveur, puisque sur la machine de bureau je laisse tout sortir iptables -A OUTPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -j ACCEPT ## IPv6 ## ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT # Uniquement pour le script serveur, puisque sur la machine de bureau je laisse tout sortir ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-request -m conntrack --ctstate NEW -j ACCEPT ``` J’ai un petit doute quand même : en OUTPUT, c’est bien les echo-request qu’il faut laisser passer, pas les echo-reply ? Si j’ai bien compris, pas besoin de toucher aux règles NDP broadcast ? En cherchant des sources, je suis tombé sur ce jeu de règles proposé pour limiter le DoS : [https://petermolnar.eu/hardening-iptables-config-with-limit-rates/](https://petermolnar.eu/hardening-iptables-config-with-limit-rates/). Vous pensez que ça vaut le coup, dans le script config\_firewall pour serveur que je propose, d’ajouter ces limites un peu partout (je pense surtout à 80 et 443) ? ---
**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, 9:45 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/495 "2016-03-16T09:45:51Z")
> [@seb-ksl](#): > > J’ai un petit doute quand même : en OUTPUT, c’est bien les echo-request qu’il faut laisser passer, pas les echo-reply ? Oui, en effet … De toute façon, vu les règles que tu as écrites, si un machine interroge ton serveur, elle lui répondra car : ```auto iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT (...) ip6tables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT ``` Mon avis est que ces règles-ci, tu devrais les mettre bien plus haut, après celles gérant le localhost … > [@seb-ksl](#): > > En cherchant des sources, je suis tombé sur ce jeu de règles proposé pour limiter le DoS : [Hardening iptables with limit rates - petermolnar.net](https://petermolnar.eu/hardening-iptables-config-with-limit-rates/). Vous pensez que ça vaut le coup, dans le script config\_firewall pour serveur que je propose, d’ajouter ces limites un peu partout (je pense surtout à 80 et 443) ? En effet, cela peut être intéressant - sauf si les personnes ne comprennent pas l’intérêt faut d’abord les instruire 😛 - Un autre manière est de filtrer ainsi, par exemple : ```auto $IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m recent --name HTTP --set $IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m recent --name HTTP --update --seconds 60 --hitcount 10 -j LOG --log-prefix "IPv4 BAD HTTP: " $IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m recent --name HTTP --update --seconds 60 --hitcount 10 -j DROP $IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m limit --limit 900/s -j ACCEPT -m comment --comment "HTTP,HTTPS" ``` Explications à donner : =\> 1ère règle : toute nouvelle connexion est enregistré dans une variable HTTP =\> 2ème : si dans la minute qui vient, j’ai 10 tentatives de connexion, je log - parce qu’en soit, ce n’est pas normal d’avoir un nombre important de connexions d’une même adresse ip =\> 3ème : le nombre atteint, je DROP - cela peut-être un REJECT avec connexion TCP fermé: _'-j REJECT --reject-with tcp-reset_’ =\> 4ème : le nombre de connexion limit acceptée … C’est un exemple qui vaut ce que ça vaut … et, là, je m’attends à ce que Pascal le corrige 😉 Mon avis est que tu peux informer d’un laïus sur l’intérêt de l’option ‹ limit ›, sans pour autant l’écrire - n’oublions pas que c’est un tuto à destination de débutant. Si la personne veut aller plus loin, elle a été informé que cela existe, soit elle viendra en demander plus, et/ou, soit elle ira chercher plus d’informations sur le web. * * * C’est moi ou le site [inetdoc.net](http://inetdoc.net) est bel et bien tombé, voire fermé définitivement … - _c’est bizarre, le ndd a été acheté jusqu’en septembre 2021_ - Autrement, on aurait pu linker justement vers l’information relative à l’option ‹ limit › ---
**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, 10:51 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/496 "2016-03-16T10:51:25Z")
Je pense que tout ça va tourner à la “cacophonie écrite”. Ne pensez-vous pas qu’il serait souhaitable de reprendre toutes ces règles **générales** , UNE par UNE et en deux temps : 1/ Machine Bureau, puis, une fois que l’accord a été trouvé, on passe à - 2/ Serveur. Quelle serait la liste de ces règles que j’appelle ‘générales’ (mais si vous préférez un autre adjectif : communes, incontournables, etc.) et dans quel ordre devrait-elle être établie ? -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT J’en oublie ? Je ne parle pas là des règles d’autorisation ou de rejet de port ou autres, qui seraient traitées **dans un second temps** , sous forme : - _Si vous utilisez SSH_ - _libellé de la règle_ - _Si vous installez un serveur HTTP_ - _libellé de la règle_ - _etc._ Questions subsidiaires : - Est-il souhaitable d’axer cette discussion sur la concaténation IPv4/IPv6, ou faut-il proposer aussi des réponse “IPv4 uniquement” ? - Si vous êtes de mon avis, doit-on continuer sur le présent fil, avec en tête, une référence à la page de début de cette discussion, ou est-il préférable d’ouvrir un autre fil ? À votre sagacité ! ---
**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, 11:27 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/497 "2016-03-16T11:27:57Z")
Pour moi, c’est du pareil au même, discuter ici ou sur un autre fil, soit … Mais si je ne me trompe pas, ce fil a été ouvert justement pour discuter du tuto, en question, n’est-ce pas ?! 😉 Quoiqu’il en soit, je suis pour la clarification des idées - que @seb-ksl fasse le point, comme il l’a fait ce matin, c’est très bien, et vraiment utile. La concaténation du sujet me va très bien - mais je comprendrais parfaitement que cela soit plus complexe pour d’autres. Bref, je suis la tendance - et j’espère vraiment ne pas importuner par mes interventions “lettrées”, dont le but est vraiment de partager et de discuter de ce que, même moi, je dois modifier dans ma compréhension des choses 😛 @la vôtre! _(de sagacité)_ ---
**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 16, 2016, 11:57 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/498 "2016-03-16T11:57:24Z")
En ce qui me concerne, ça me va comme ça ! J’estime qu’on est précisément en train de débattre d’une version correcte d’un pare-feu basique pour débuter. Si tu veux qu’on crée un fil ceci dit, ça ne me dérange pas outre mesure 🙂. Merci PengouinPdt pour tes interventions, je vais prendre un petit moment ASAP pour relire le script de config entier. Là je m’acharne sur des petits bouts et je perds la vision d’ensemble, ce qui me fait effectivement écrire des règles redondantes et en oublier d’autres. Je reviens rapidement quand j’ai mis tout ça à plat ! ---
**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, 1:20 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/499 "2016-03-16T13:20:33Z")
> [@seb-ksl](#): > > Merci PengouinPdt pour tes interventions, je vais prendre un petit moment ASAP pour relire le script de config entier. De rien, c’est vraiment avec plaisir. Je n’ai pas la prétention de maîtriser le sujet, mais je dois avouer qu’il m’intéresse 😉 Il y a quelques semaines, j’ai ouvert cet autre [fil](https://www.debian-fr.org/t/ip6tables-et-icmp-recommandations/56046/5), que j’ai complété hier soir de mes dernières recherches concernant imcpv6. J’y ai intégré les commentaires relatifs aux recommandations de filtrage, selon les deux documents cités. En espérant que cela fasse avancer le débat - sachant qu’on n’est plus dans un contexte débutant 😉 Je ne cache pas que j’attends avec une certaine impatience ce que pourrait en dire @PascalHambourg, _sur le fil en question, bien-sûr._ * * * Juste pour info, si j’ai bien compris il y a deux manières d’écrire à-propos d’ICMP IPV6, je cite : > [@http://linux.die.net/man/8/ip6tables](#): > > icmpv6 > > This extension is loaded if ‹ –protocol ipv6-icmp › or ‹ –protocol icmpv6 › is specified. Donc, on peut utiliser invariablement ‹ icmpv6 › ou ‹ ipv6-icmp ›. De fait, ne pas être surpris de trouver l’une ou l’autre de ces écritures, selon l’auteur d’un tutoriel. Personnellement, je préfère la deuxième écriture, plus courte … _mais c’est mon choix_. 😉 * * * Concernant source-quench, dans ufw, je viens de lever un bogue de sécurité : [Bug #1558068 “remove extraneous source quench rule” : Bugs : ufw](https://bugs.launchpad.net/ufw/+bug/1558068) (mode privé, car nommé ‹ security bug ›) ---
**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, 1:50 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/500 "2016-03-16T13:50:54Z")
> [@PengouinPdt](#): > > Qui est réellement informé ?! Au moins les lecteurs de cette discussion. > [@PengouinPdt](#): > > Tu n’as pas le sentiment de pinailler, un peu là J’assume entièrement de bonne grâce. > [@PengouinPdt](#): > > mon expérience sait qu’il faut un minima pour une station, en output … 53, 67, 68 … 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. > [@PengouinPdt](#): > > Et, certains utiles, tels que 80, 443, mDNS, certains ICMP, Utiles dans certains cas, oui. Indispensables, non. Je n’ai jamais eu besoin de mDNS et je suis loin d’être le seul. Quant aux messages ICMP, les seuls indispensables sont les types d’erreur qui sont dans l’état RELATED, donc qui n’ont pas besoin de règle spécifique. > [@ricardo](#): > > Quels sont les dangers qu’il y a à être « pingué », pour vouloir l’empêcher ? En plus de la cartographie, il y a deux types de risques. L’un est lié à l’existence d’éventuelles failles de sécurité qui peuvent être exploitées par tout paquet reçu non sollicité, l’un des exemples les plus connus bien qu’ancien étant le fameux « ping of death » de Windows. L’autre est lié au fait que cette requête déclenche l’émission d’une réponse de même taille, pouvant servir à divers abus du réseau, dénis de service… L’exemple bête avec une victime qui a une connexion ADSL typique 16 Mbit/s descendant 1 Mbit/s montant : il suffit de lui envoyer un flux de ping à 1 Mbit/s pour qu’elle sature elle-même sa voie montante avec les réponses. Il y a d’autres attaques basées sur l’usurpation d’adresse, le broadcast (bien que les OS modernes sont configurés par défaut pour ne pas répondre au ping broadcast). J’approuve la recommandation de limiter le ping entrant. Par contre 1 par seconde, c’est un peu juste puisque c’est la fréquence par défaut des programmes ping. On peut aussi limiter la taille des requêtes à une valeur pas trop basse (2000 octets suffit généralement pour analyser les problèmes de MTU et de fragmentation). > [@seb-ksl](#): > > Si j’ai bien compris, pas besoin de toucher aux règles NDP broadcast ? IPv6 n’utilise pas de broadcast mais du multicast. > [@PengouinPdt](#): > > si dans la minute qui vient, j’ai 10 tentatives de connexion, je log - parce qu’en soit, ce n’est pas normal d’avoir un nombre important de connexions d’une même adresse ip Je n’ai pas étudié les versions récentes du protocole HTTP, mais une page web pouvant contenir un nombre d’éléments externes (images, feuilles de style, frames…) important, si le navigateur fait une connexion séparée pour télécharger chaque élément ça peut faire beaucoup en pas longtemps. Certes un navigateur peut réutiliser la même connexion pour télécharger plusieurs éléments si le serveur le permet, mais est-ce une obligation ? D’autre part, comme je l’ai déjà écrit dans d’autres discussions à plusieurs reprises, les limitations basées sur iptables sont sensibles à l’usurpation d’adresse et peuvent être exploitées pour causer des dénis de service. De plus, la correspondance `recent` a une faiblesse qui permet à un attaquant utilisant l’usurpation d’adresse de se « faire oublier » sans attendre le délai. PS : Je ne suis pas un « professionnel » du filtrage réseau. ---
**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, 2:01 UTC](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771/501 "2016-03-16T14:01:50Z")
> [@PascalHambourg](#): > > Une station configurée en statique et non en DHCP n’a pas besoin d’autoriser les ports 67 et 68. Statique est le mot … Dans beaucoup de cas, c’est plus le contraire. Il est vrai que mes propos sous-entendaient ce fait -_ahhh l’implicite m’a encore piégé_ 😛 > [@PascalHambourg](#): > > 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. Ahhh ??? Là, tu m’apprends quelque chose. Donc, les règles iptables en question ne servent pas alors ? > [@PascalHambourg](#): > > Par contre 1 par seconde, c’est un peu juste puisque c’est la fréquence par défaut des programmes ping. On peut aussi limiter la taille des requêtes à une valeur pas trop basse (2000 octets suffit généralement pour analyser les problèmes de MTU et de fragmentation). Tu conseillerais quoi comme fréquence de limitation ? Et, tu limites comment la taille des requêtes ? _- désolé, de poser la question, suis sous codéine, là, en ce moment … donc, j’ai un peu plus de mal à réfléchir, je vais quand même essayé de voir ce que je peux trouver -_ [Page précédente](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771.md?page=24) [Page suivante](https://www.debian-fr.org/t/digression-installation-parefeu-iptables-ip6tables-pour-les-nuls/771.md?page=26)