Vous n'êtes pas identifié(e).
Hors ligne
la personne indique un ip6tables -A INPUT -p icmpv6 -j DROP avant la suite de ses règles, et tout fonctionne (la personne semble avoir un doute sur si la policy par défaut d'imcpv6 est drop, je comprend pas...)
Le DROP ne concerne que les paquets ICMPv6, et les règles suivantes de la chaîne INPUT concernent d'autres protocoles (TCP, UDP) donc pas d'interférence.
La règle DROP avec la politique DROP, c'est juste ceinture et bretelles. Ça évite aussi de parcourir le reste des règles de la chaîne pour rien sachant qu'aucune ne peut accepter de paquet ICMPv6. Mais quand ce n'est pas un paquet ICMPv6, ça fait une règle de plus à examiner pour rien. Donc bof.
Aussi : icmpv6 --icmpv6-type redirect -j REJECT : quel intérêt si policy drop ?
La cible REJECT ne fait pas que bloquer le paquet, elle renvoie aussi un paquet en réponse ( par défaut, un message d'erreur ICMPv6 port-unreachable).
Je ne vois pas du tout l'intérêt de cette règle qui s'applique aux paquets ICMPv6 de type redirect sortants. D'une part c'est le noyau qui émet ce type de paquet, et il n'a rien à faire de recevoir un message d'erreur de lui-même en réponse, contrairement à un processus en espace utilisateur. D'autre part le noyau n'émet ce type de message ICMPv6 redirect que s'il est configuré en routeur IPv6, et normalement on veut qu'un routeur puisse émettre ce type de message. Même chose pour le type router-advertisement.
Pourquoi ip6tables -A OUTPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT si après : ip6tables -A OUTPUT -p icmpv6 -j ACCEPT ?!
Encore ceinture et bretelles, je suppose. Les types indispensables sont explicitement acceptés au cas où on changerait d'avis et on ne voudrait plus accepter tous les types ICMPv6.
J'ajoute les remarques suivantes.
Si l'adresse de loopback ::1 ne peut être utilisée que sur l'interface de loopback lo, la réciproque n'est pas vraie : toutes les adresses locales configurées sur d'autres interfaces peuvent être utilisées sur l'interface de loopback. Cette règle est donc trop restrictive, et trop laxiste puisqu'elle ne vérifie pas l'interface d'entrée.
Je suppose que le but est de refuser poliment la demande de connexion lorsqu'elle provient du réseau local au lieu de la bloquer silencieusement. REJECT permet d'informer l'émetteur immédiatement au lieu de le laisser attendre jusqu'au time-out. Mais ça ne marche pas car les paquets émis sur le réseau local n'ont pas forcément un hop limit à 255 (valeur maxi). Les paquets de neighbour discovery sont une exception. Le hop limit initial est plutôt à 64.
https://serverfault.com/questions/61431 … -requests#
Où là il nous met un icmpv6 drop après ses règles, partant du principe j'accepte ce qui m'intérresse avant de dropper le reste.
Ça marche quelle que soit la politique par défaut de la chaîne INPUT qui n'est pas spécifiée dans l'extrait.
Il vaut mieux montrer que raconter.
Hors ligne
Il y a probablement des choses redondantes, mais d'un strict point de vue sécurité, je ne pense pas pouvoir faire mieux, je me trompe ?
Hors ligne
Le protocole IPv6 n'utilise pas les paquets de type broadcast donc cette règle est inutile.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (01-05-2019 16:01:49)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (03-05-2019 16:34:24)
Hors ligne
On vient de me faire remarquer que mon script n'était pas bon, que je devrais utiliser iptables -save et -restore plutôt, afin qu'il n'y ait pas de période de latence entre la connexion au réseau et l'application des règles.
Avec le tact habituel qui me caractérise, je vais répondre que c'est une grosse connerie. Ensuite, je vais nuancer. Faut quand même rester constructif, hein.
Certes, l'ajout de règles individuelles avec iptables -A prend plus de temps que l'importation d'un jeu de règles complet avec iptables-restore. Pourquoi ? Parce que pour ajouter une règle dans une table, iptables doit récupérer le contenu de la table complète du noyau (donc l'équivalent d'un iptables-save -t <table>), y ajouter la règle et réinjecter le tout dans la table du noyau (donc l'équivalent d'un iptables-restore -t <table>). Mais pour un jeu de quelques dizaines de règles, ça ne fait pas une grosse différence.
Cependant, le temps de mise en place du jeu de règles importe peu ; ce qui importe, c'est qu'il soit en place avant d'activer le réseau. Si on ne peut pas garantir ce séquencement, alors quel que soit le temps d'exécution du script il risque d'y avoir un intervalle de temps pendant lequel le réseau est actif mais pas les règles iptables. La question importante est donc : comment ton script est-il exécuté ?
Les règles de log me semblent un poil absurdes, n'importe qui pourrait mettre la machine à genoux en visant des ports non-autorisés
La remarque est justifiée. Compte tenu de la bande passante du réseau, la vitesse du processeur et du disque et l'espace de stockage disponible, si le nombre de paquets par seconde à traiter est susceptible de saturer les ressources de la machine, il est souhaitable de limiter les logs.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
J'utilise un /etc/network/if-pre-up.d/iptables. Cette méthode est toujours valable et permet bien la mise en place des règles avant la connexion au réseau ?
Attention : les scripts placés dans /etc/network/if-pre-up.d sont exécutés plusieurs fois : une fois quand ifup est exécuté avec l'option --all, et une fois pour chaque interface activée (donc trois fois avec les interfaces de loopback et ethernet). Cf. man interfaces pour les détails. D'autre part ils sont exécutés avant l'activation des interfaces configurées par ifupdown, mais pas forcément avant l'activation des interfaces gérées par d'autres systèmes (Wicd, NetworkManager...).
Dernière modification par raleur (03-05-2019 19:39:56)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (03-05-2019 19:46:53)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Comment est-ce que je fais pour que le script soit appelé au plus tôt, avant la connexion ?
Si la connexion est gérée par le service X, tu peux, au choix :
- Exécuter le script par le service X avant d'activer les connexions, s'il supporte cette fonctionnalité. NetworkManager permet l'exécution de scripts sur certains événéments d'une interface réseau, mais apparemment pas avant qu'elle soit "connectée" (signification à préciser).
- Exécuter le script par un autre service Y qui démarre avant le service X et qui supporte cette fonctionalité.
- Créer un service Z qui démarre avant le service X et exécute le script.
L'ordonnancement des services dépend du gestionnaire d'init (sysvinit, systemd...).
Le iptables-save "converti" donc mes règles en format lisibles par -restore ?
Voilà. Même si iptables-save est souvent détourné (par moi notamment) pour simplement afficher le jeu de règles iptables actif, sa fonction première est de le sauvegarder dans un format compatible avec iptables-restore, d'où son nom "iptables-save" et pas "iptables-list".
Il vaut mieux montrer que raconter.
Hors ligne
Voilà. Même si iptables-save est souvent détourné (par moi notamment) pour simplement afficher le jeu de règles iptables actif, sa fonction première est de le sauvegarder dans un format compatible avec iptables-restore, d'où son nom "iptables-save" et pas "iptables-list".
Logique, en effet. Merci bien !
L'ordonnancement des services dépend du gestionnaire d'init (sysvinit, systemd...).
Mmmh. On touche vraiment aux limites de mes compétences. Tout ce que je sais, c'est que systemd est utilisé, d'après mes souvenirs des logs et surtout parce que j'utilise souvent du systemd-analyze.
Mais de là à y placer l'application de mes règles avant network-manager... Pfiou.
Je vais lire plein de documentation cette après-midi, si tu avais quelques pistes pour orienter mes recherches (ou une réponse directe, ahah, ça marche aussi).
Merci d'avance !
Hors ligne