# Pare-feu IPv4/IPv6, versions bureau serveur **URL:** \ **Category:** Support Debian\ **Created:** [Juin 18, 2018, 3:01 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003 "2018-06-18T15:01:40Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juin 18, 2018, 3:01 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/1 "2018-06-18T15:01:40Z")
Bonjour, J’aurais besoin d’un petit renseignement au sujet du post sur Pare-feu IPv4/IPv6, versions bureau serveur [https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665). J’espère ne pas me méprendre en disant que lorsque l’on utilise le paquet iptables-persistant, on ne doit pas créer le fichier init-firewall dans le dossier /etc/init.d mais seulement recopier , dans un terminal, les règles de ledit fichier avant d’inscrire les règles de configuration, c’est bien ça? Exemple: ``` iptables -t filter -F iptables -t nat -F iptables -t mangle -F iptables -t raw -F iptables -t filter -P INPUT ACCEPT iptables -t filter -P OUTPUT ACCEPT iptables -t filter -P FORWARD ACCEPT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P INPUT ACCEPT iptables -t nat -P OUTPUT ACCEPT iptables -t mangle -P PREROUTING ACCEPT iptables -t mangle -P OUTPUT ACCEPT iptables -t mangle -P POSTROUTING ACCEPT iptables -t mangle -P FORWARD ACCEPT iptables -t mangle -P INPUT ACCEPT iptables -t raw -P OUTPUT ACCEPT iptables -t raw -P PREROUTING ACCEPT ip6tables -t filter -F ip6tables -t nat -F ip6tables -t mangle -F ip6tables -t raw -F ip6tables -t filter -P INPUT ACCEPT ip6tables -t filter -P OUTPUT ACCEPT ip6tables -t filter -P FORWARD ACCEPT ip6tables -t nat -P PREROUTING ACCEPT ip6tables -t nat -P POSTROUTING ACCEPT ip6tables -t nat -P INPUT ACCEPT ip6tables -t nat -P OUTPUT ACCEPT ip6tables -t mangle -P PREROUTING ACCEPT ip6tables -t mangle -P OUTPUT ACCEPT ip6tables -t mangle -P POSTROUTING ACCEPT ip6tables -t mangle -P FORWARD ACCEPT ip6tables -t mangle -P INPUT ACCEPT ip6tables -t raw -P OUTPUT ACCEPT ip6tables -t raw -P PREROUTING ACCEPT iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT iptables -A INPUT -p tcp --dport xxxx -j ACCEPT iptables -A INPUT -p udp --dport xxxx -j ACCEPT ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT ip6tables -A INPUT -p tcp --dport xxxx -j ACCEPT ip6tables -A INPUT -p udp --dport xxxx -j ACCEPT sudo -s iptables-save -c ``` Merci de m’éclairer ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Juin 18, 2018, 3:36 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/2 "2018-06-18T15:36:53Z")
Non, ça crée plutôt deux fichiers : `/etc/iptables/rules.v4` et `/etc/iptables/rules.v6` qui est formaté autrement (mais c’est sensiblement compréhensible si tu comprends ton fichier). ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juin 20, 2018, 1:55 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/3 "2018-06-20T13:55:39Z")
Oui, j’étais au courant que iptables-persistant créait deux fichiers mais je pensais supprimer certaines règles dans ces derniers par la suite: supprimer les règles ipv6 du fichier ipv4 et vice versa. ---
**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:** [Juin 20, 2018, 2:59 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/4 "2018-06-20T14:59:50Z")
Il n’y a pas de règles IPv6 dans le fichier IPv4 et vice versa. Les jeux de règles IPv4 et IPv6 sont distincts. ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juin 20, 2018, 5:05 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/5 "2018-06-20T17:05:42Z")
J’ai du mal à comprendre! Mon script est-il correct ou pas? Que dois-je modifier? ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Juin 20, 2018, 7:34 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/6 "2018-06-20T19:34:18Z")
En fait, je ne sais pas, j’ai plutôt l’habitude des fichiers de configuration de `iptables-persistant` ou du retour de `iptables-save`… ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juin 21, 2018, 4:37 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/7 "2018-06-21T16:37:07Z")
Moi aussi j’utilise iptables-persistant. C’est pour cela que je me demande ce que je dois modifier dans mon script pour qu’il fonctionne avec iptables-persistant. ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Juin 21, 2018, 8:34 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/8 "2018-06-21T20:34:11Z")
En fait, il faut que tu lances ton script pour appliquer tes règles iptables, puis tu lances la configuration de `iptables-persistant`. C’est comme ça que je fais à chaque fois. ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juin 22, 2018, 4:03 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/9 "2018-06-22T16:03:59Z")
oui d’accord mais les règles de mon script ([https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003) )sont-elles correctes? Peut-on les utiliser avec iptables-persistant? ---
**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:** [Juin 23, 2018, 2:35 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/10 "2018-06-23T14:35:50Z")
iptables-persistent se fiche de ton script et des règles qu’il met en place. Il se contente de les rendre persistantes. Quant à savoir si elles sont “correctes”, ça dépend de ce que tu veux qu’elles fassent. ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juin 24, 2018, 3:44 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/11 "2018-06-24T15:44:35Z")
La configuration est destinée à une machine bureau. C’est pour cela que j’ai simplement recopié le script “Pour une machine de bureau” du tuto “Pare-feu IPV4/IPv6, versions bureau et serveur” ([https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665) )car je n’ai pas besoin de plus. La seule question que je me pose est pour la première partie du script, celle dédiée au “nettoyage” du firewall: est-il indispensable de rajouter ces règles? D’habitude, je me contentai seulement de “ipatbles -F” et “iptables -X”. ---
**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:** [Juin 27, 2018, 9:47 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/12 "2018-06-27T21:47:10Z")
Il est évident que des séquences comme ``` iptables -t filter -P INPUT ACCEPT iptables -P INPUT DROP ``` où la seconde commande fait l’inverse de la première, sont absurdes. D’autre part, si le but est d’effacer toute trace du jeu de règles antérieur, il manque les commandes -X pour effacer les éventuelles chaînes utilisateur. En revanche la réinitialisation de toutes les tables, même celles que tu n’utilises pas, a du sens : en effet un jeu de règles enregistré par iptables-save (utilisé par iptables-persistent) ne réinitialise que les tables présentes lors de la sauvegarde. ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juin 28, 2018, 4:13 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/13 "2018-06-28T16:13:03Z")
Donc, je dois commencer le script par: sudo iptables -L sudo iptables -X Et ensuite, je réinitialise toutes les tables, c’est bien ça? > [@PascalHambourg](#): > > Il est évident que des séquences comme > > iptables -t filter -P INPUT ACCEPT > iptables -P INPUT DROP > > où la seconde commande fait l’inverse de la première, sont absurdes. Je comprends que les 2 commandes soient absurdes mais pourquoi sont-elles présentes dans le fil [https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur/68665) ? ---
**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:** [Juin 29, 2018, 2:33 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/14 "2018-06-29T14:33:53Z")
> [@Richard2](#): > > sudo iptables -L > sudo iptables -X 1. On n’utilise pas sudo dans un script. 2. Il faut faire la même chose pour toutes les autres tables (la table par défaut est « filter »). > [@Richard2](#): > > Et ensuite, je réinitialise toutes les tables, c’est bien ça? « Ensuite » ? Les commandes ci-dessus font déjà partie des opérations ayant pour but de réinitialiser une table. > [@Richard2](#): > > Je comprends que les 2 commandes soient absurdes mais pourquoi sont-elles présentes dans le fil Je ne suis pas responsable de ce que les autres écrivent. ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juillet 2, 2018, 3:11 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/15 "2018-07-02T15:11:23Z")
Petite erreur de frappe dans mon poste précédent. Ce n’était `iptables -L` mais `iptables -F` . Voici le script rectifié: ``` #table filter iptables -t filter -F iptables -t filter -X iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT ACCEPT #table NAT iptables -t nat -F iptables -t nat -X iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P OUTPUT ACCEPT #table mangle iptables -t mangle -F itpables -t mangle -X ptables -t mangle -P PREROUTING ACCEPT iptables -t mangle -P OUTPUT ACCEPT iptables -t mangle -P POSTROUTING ACCEPT iptables -t mangle -P FORWARD ACCEPT iptables -t mangle -P INPUT ACCEPT #table raw iptables -t raw -F itpables -t raw -X iptables -t raw -P OUTPUT ACCEPT iptables -t raw -P PREROUTING ACCEPT #autorise lo iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #maintenir les connexions établies iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT #accepte ping iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT # On log les paquets en entrée. iptables -A INPUT -j LOG # On log les paquets forward. iptables -A FORWARD -j LOG ``` ---
**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:** [Juillet 2, 2018, 6:18 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/16 "2018-07-02T18:18:43Z")
Je n’avais même pas remarqué la coquille -L/-F. - Table nat (et non NAT, le nom des tables est en minuscule) : il manque la définition de la politique par défaut de la chaîne INPUT, pourtant présente dans ton script initial. Tu a peut-être été influencé par la lecture de scripts écrits avant que la chaîne INPUT soit ajoutée à la table nat (c’est relativement récent comparativement à l’âge d’iptables). - Table mangle : faute de frappe à une commande. - Règles de filtrage : `iptables -A OUTPUT -o lo -j ACCEPT` Cette règle est redondante puisque la politique par défaut de la chaîne OUTPUT est déjà ACCEPT. `iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT` Quel est la limitation précise que cette règle est supposée imposer ? Il faut avoir à l’esprit que tous les paquets ICMP echo-request et echo-reply d’une même séquence sont considérés comme appartenant à la même “connexion” (au sens de netfilter), un séquence étant par exemple l’ensemble des paquets émis et reçus lors de l’exécution continue d’une commande `ping`. Par conséquent si le destinataire répond au ping, seul le premier paquet ICMP echo-request d’une séquence a l’état NEW, les suivants ont l’état ESTABLISHED. La conséquence sur ton jeu de règles, qui accepte tous les paquets entrants dans l’état ESTABLISHED, est que le nombre de requêtes appartenant à une même séquence par seconde n’est pas limité ; seul le nombre de séquences différentes par seconde l’est. Est-ce bien ce que tu souhaites ? ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juillet 4, 2018, 3:17 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/17 "2018-07-04T15:17:21Z")
Merci d’avoir rectifié le script. > [@PascalHambourg](#): > > Tu a peut-être été influencé par la lecture de scripts écrits avant que la chaîne INPUT soit ajoutée à la table nat (c’est relativement récent comparativement à l’âge d’iptables). Oui c’est vrai, j’ai lu plusieurs tutos qui datent d’années différentes. > [@PascalHambourg](#): > > La conséquence sur ton jeu de règles, qui accepte tous les paquets entrants dans l’état ESTABLISHED, est que le nombre de requêtes appartenant à une même séquence par seconde n’est pas limité ; seul le nombre de séquences différentes par seconde l’est. Est-ce bien ce que tu souhaites ? Mon idée de départ était de bloquer les requêtes ICMP car je pense que cela n’a aucune utilité pour moi. Je n’ai jamais utilisé la commande ping et je ne le ferais sans doute jamais. Les règles que je mettais étaient celles-ci : ``` iptables -A INPUT -p icmp --icmp-type echo-request -j DROP iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP ``` Grâce à ces deux commandes, mon PC ne répond plus aux requêtes « ping ». Mais me permettent-elles quand même d’effectuer des pings ? Peut-être qu’un jour j’aurais besoin de vérifier si un serveur est joignable ! ---
**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:** [Juillet 4, 2018, 6:24 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/18 "2018-07-04T18:24:36Z")
La seconde règle est inutile car si les requêtes echo-request sont bloquées, aucune réponse echo-reply n’est émise. Note qu’il y a un autre moyen plus simple d’empêcher ta machine de répondre au ping : ``` net.ipv4.icmp_echo_ignore_all=1 ``` dans /etc/sysctl.conf ou dans un fichier /etc/sysctl.d/\*.conf pour désactiver la réponse au ping. Ces deux règles n’empêchent pas le ping sortant qui fait intervenir des paquets ICMP echo-request ayant l’état NEW ou ESTABLISHED dans la chaîne OUTPUT et des paquets ICMP echo-reply ayant l’état ESTABLISHED (dans le cas d’un ping unicast) ou INVALID (dans le cas d’un ping broadcast ou multicast, le suivi de connexion de netfilter ne gérant pas ces modes de communication) dans la chaîne INPUT. ---
**Author:** ![Richard2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/eb8c5e/32.png) [@Richard2](https://www.debian-fr.org/u/Richard2)\ **Post date:** [Juillet 5, 2018, 5:07 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/19 "2018-07-05T17:07:35Z")
Je vais alors plutôt modifier le fichier systctl.conf. J’ai donc réécrit le script : ``` #table filter iptables -t filter -F iptables -t filter -X iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT ACCEPT #table nat iptables -t nat -F iptables -t nat -X iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P INPUT ACCEPT iptables -t nat -P OUTPUT ACCEPT #table mangle iptables -t mangle -F itpables -t mangle -X iptables -t mangle -P PREROUTING ACCEPT iptables -t mangle -P OUTPUT ACCEPT iptables -t mangle -P POSTROUTING ACCEPT iptables -t mangle -P FORWARD ACCEPT iptables -t mangle -P INPUT ACCEPT #table raw iptables -t raw -F itpables -t raw -X iptables -t raw -P OUTPUT ACCEPT iptables -t raw -P PREROUTING ACCEPT #autorise lo iptables -A INPUT -i lo -j ACCEPT #maintenir les connexions établies iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # On log les paquets en entrée. iptables -A INPUT -j LOG # On log les paquets forward. iptables -A FORWARD -j LOG ``` Quelques dernières questions : Du point de vue de la sécurité, ne serait-il pas plus prudent de droper aussi l’OUTPUT de la table filter et ensuite de maintenir les connexions établies et d’accepter en sortie lo… ``` iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -i lo -j ACCEPT (enfin, peut-être que cette règle est superflue vu que je maintiens les connexions établies en OUTPUT) ``` J’ai aussi lu qu’il fallait autoriser tout le trafic loopback et droper tout le trafic vers 127/8 qui n’utilise pas lo. iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -i lo -d 127.0.0.0/8 -j DROP Pour ce qui est de se protéger des scans XMAS et NULL: ``` iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP ``` ---
**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:** [Juillet 5, 2018, 6:38 UTC](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003/20 "2018-07-05T18:38:02Z")
> [@Richard2](#): > > Je vais alors plutôt modifier le fichier systctl.conf. J’ai mentionné le fichier sysctl.conf car c’est l’emplacement historique où on plaçait ce genre de réglage. Cependant il est géré en « conffile » (fichier de configuration) du paquet procps par `dpkg`, donc si une mise à jour du paquet fournit une nouvelle version du fichier, le système détectera que le fichier d’origine a été modifié localement et il faudra choisir entre conserver le fichier ou le remplacer par la nouvelle version. La tendance actuelle est plutôt de créer un fichier \*.conf dans /etc/sysctl.d/. Avantages : on peut créer des fichiers distincts pour différentes catégories de réglages (réseau, gestion de la mémoire, du noyau…), ce qui facilite la maintenance, et ces fichiers ne sont pas affectés par les mises à jour de procps. La même tendance existe pour les fichiers de configuration de modprobe et [X.org](http://X.org). > [@Richard2](#): > > Du point de vue de la sécurité, ne serait-il pas plus prudent de droper aussi l’OUTPUT de la table filter et ensuite de maintenir les connexions établies et d’accepter en sortie lo Bof. Ça ne fera que bloquer les paquets ayant l’état INVALID émis par la machine. Et je ne vois pas le rapport avec l’interface de loopback. Il n’y a pas plus de paquets INVALID émis sur l’interface de loopback que sur les autres interfaces. Au passage la première règle est superflue puisque la seconde accepte la même chose et plus encore. La troisième règle est en doublon avec un règle déjà présente dans le script. Contre quel type de menace veux-tu protéger ta machine en filtrant dans OUTPUT ? Si tu veux vraiment filtrer dans OUTPUT, il faut n’accepter que les flux dont tu as besoin, comme en INPUT. La difficulté étant de lister exhaustivement ces flux. > [@Richard2](#): > > J’ai aussi lu qu’il fallait autoriser tout le trafic loopback Ton script le fait déjà, pas besoin d’en rajouter. > [@Richard2](#): > > et droper tout le trafic vers 127/8 qui n’utilise pas lo. Oui. Il me semble que la pile IP de Linux le fait déjà nativement, mais il y a longtemps que j’ai étudié ce genre de choses. Ça ne coûte pas cher d’ajouter une règle pour être tranquille. > [@Richard2](#): > > Pour ce qui est de se protéger des scans XMAS et NULL: Pourquoi pas, mais ces combinaisons de drapeaux TCP sont invalides et les paquets devraient être classés dans l’état INVALID par le suivi de connexion. [Page suivante](https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-serveur/77003.md?page=2)