Vous n'êtes pas identifié(e).
Dernière modification par Henry33 (21-05-2018 09:07:17)
Hors ligne
Commentaires sur le second fichier avec chaînes utitisateur.
Tu pourrais alléger encore plus en factorisant les règles des 3 types ICMP d'erreur dans une chaîne utilisateur.
En faisant :
-A in_priv -j in
-A out_priv -j out
?
Hors ligne
concernant les requêtes echo-request: je comprends l'état NEW, mais est-ce qu'elles peuvent avoir l'état ESTABLISHED ?
Oui. Les paquets ICMP echo-request et echo-reply contiennent deux champs particuliers : un numéro d'identification et un numéro de séquence. La commande ping envoie une série de paquets avec le même numéro d'identification et des numéros de séquence qui s'incrémentent. Le suivi de connexion de netfilter considère que tous les paquets ICMP echo-request et echo-reply ayant les mêmes adresses source et destination (interverties pour les réponses) et le même numéro d'identification font partie de la même "connexion". Par conséquent, conformément au principe général des états de suivi de connexion de netfilter, les paquets echo-request ont l'état NEW tant qu'une réponse n'a pas été vue, le premier paquet echo-request a l'état ESTABLISHED et ensuite tous les paquets echo-request et echo-reply suivants ont aussi l'état ESTABLISHED.
(Factorisation des règles ICMP)
Non, pas comme ça.
En créant une chaîne pour les type d'erreur ICMP.
En y mettant les règles de traitement de ces types.
Et en remplaçant ces règles dans les autres chaînes par une règle d'appel à la chaîne.
Il vaut mieux montrer que raconter.
Hors ligne
Ca :
Devient ça :
C'est bon, non ?
EDIT : mais par contre, je ne dois pas le faire avec les réseaux publiques sinon ils se mettront à répondre au ping, alors que je ne veux pas. Toujours correct ?
Ca:
N'est pas remplaçable par ça:
Dernière modification par Henry33 (21-05-2018 14:53:52)
Hors ligne
Ainsi on exclut les requêtes dans l'état NEW provenant de l'extérieur.
Mais je me dis que cela pourrait nuire à la lisibilité.
Il vaut mieux montrer que raconter.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par Henry33 (22-05-2018 11:06:59)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (21-05-2018 20:14:44)
Il vaut mieux montrer que raconter.
Hors ligne
Est-ce qu'il y en a de trop ? Est-ce qu'il en faut plus ?
J'ai mis de coté le multicast, mais à ce que j'ai compris (d’après les adresses), c'est que c'est pour le local. Donc est-ce qu'il ne vaut mieux pas que je les ajoute ou est-ce que le routeur (par dnsmasq ou autre que je ne connais pas encore) peut gérer ça ? A savoir qu'il est possible que des machines extérieur (non paramétrée pour mon réseau) viennent se connecter occasionnellement (ordi/tablette d'un pote ou d'une copine).
Sources :
https://blog.stephane-huc.net/securite/ … all-icmpv6
https://www.iana.org/assignments/icmpv6 … ters.xhtml
Dernière modification par Henry33 (21-05-2018 21:13:02)
Hors ligne
J'ai mis de coté le multicast, mais à ce que j'ai compris (d’après les adresses), c'est que c'est pour le local. Donc est-ce qu'il ne vaut mieux pas que je les ajoute
Que tu ajoutes quoi ?
Pour naviguer sur le web, pas besoin de multicast autre que le NDP.
Il vaut mieux montrer que raconter.
Hors ligne
Que tu ajoutes quoi ?
Tout ça :
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Est-ce que tu sais si les Certification Path sont nécessaires ?
Déjà répondu en #88 :
A mon avis ce n'est pas demain la veille que tu auras besoin de SEND (Secure ND, signature cryptographique pour authentifier les paquets NDP).
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Je ne sais pas encore ce que ça veut dire mais ça vient de là. Concernant la vie privée, j'ai peut-être un début de réponse mais pas encore la solution.
https://linuxfr.org/news/proteger-sa-vi … vec-l-ipv6
Dernière modification par Henry33 (22-05-2018 08:01:43)
Hors ligne
Hors ligne