Vous n'êtes pas identifié(e).
"depuis son port ssh", ce n'est pas une source ?
Si, mais d'un point de vue mnémotechnique, c'est pas génial... (d)epuis ne ressemble pas à (s)ource mais plutôt à (d)estination. Je me demandais donc si il n'y avait une meilleure définition.
Hors ligne
c'est donc normal que iptables ne me donne pas la source de mon erreur.
Oui. Il aurait fallu penser à regarder dans les logs du noyau avec dmesg pour y trouver des messages de ce genre :
(Le protocole 17 est UDP, cf. /etc/protocols)
Si ça avait été une erreur d'états de paquets, il ne m'aurait rien dit, c'est ça ?
Comment ça, une erreur d'état ?
Au fait, tu as été voir le tutoriel
Oui, j'y ai jeté un coup d'oeil. Mais en règle générale je n'aime pas les tutoriels, alors mon avis est biaisé. Je crains qu'il soit un peu compliqué pour les débutants. Je ne me suis pas penché sur les détails pour voir s'il contient d'autres incohérences que celle que tu as relevée.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Je n'imaginais pas qu'écrire des règles de filtrage soit aussi complexe...
PS: j'ai doublé et inversé les règles ssh pensant que c'était la méthode pour que la connexion soit commencée à la fois depuis un client et depuis le routeur mais je ne peux pas encore tester la connexion en ssh à mon PC depuis le routeur car le pare-feu semble bloquer l'arrivée de connexion ssh (en clair, ça marche pas alors que je crois que ça devrait). Le PC est protégé avec ufw et il va me falloir quelques heures pour me mettre à jour...
Globalement, qu'est-ce que tu en penses de cette table de filtrage ?
Dernière modification par Henry33 (19-05-2018 12:32:31)
Hors ligne
(d)epuis ne ressemble pas à (s)ource mais plutôt à (d)estination.
Et d'un point de vue sémantique, ce n'est pas suffisamment proche ?
Sinon, tu peux dire explicitement "depuis le port source" et "vers le port destination".
Une erreur d'état = une mauvaise formulation des états par rapport sens des paquets et à ce que je veux faire.
Ce ne serait une erreur qu'au sens de ce que tu veux faire, et pas au sens d'iptables. Iptables ne peut pas deviner ce que tu veux faire.
Concernant le tutoriel, ça serait bien que quelqu'un aille y jeter un oeil
Passer en revue et nettoyer un tutoriel aussi long et écrit par quelqu'un d'autre, c'est un peu s'attaquer aux écuries d'Augias...
Il vaut mieux montrer que raconter.
Hors ligne
Passer en revue et nettoyer un tutoriel aussi long et écrit par quelqu'un d'autre, c'est un peu s'attaquer aux écuries d'Augias...
Y en a un qui a réussi...
A part ça, que penses-tu de ma table de filtrage ? Je peux me baser dessus pour terminer mon projet ?
Hors ligne
Y en a un qui a réussi...
Mon pseudo n'est pas Hercule. Et c'est bien connu, les râleurs ça n'a que de la gueule, pour critiquer il y a du monde mais quand il faut agir il n'y a plus personne.
A part ça, que penses-tu de ma table de filtrage ?
Il y a des règles qui me semblent louches. Et notamment celles-ci :
Avec ces règles, je ne vois pas comment une machine du LAN peut accéder au web car les paquets sortants d'une connexion HTTP(S) ont le port destination 80 ou 443 et les paquets entrants ont le port source 80 ou 443, soit l'inverse de tes règles.
Tant qu'on y est,
Peux-tu me dire à quoi sont censées servir ces règles ? Moi, je ne vois pas.
J'en profite pour rappeler que l'état NEW doit être associé à --dport et non à --sport, car c'est le port destination du paquet initial qui permet d'identifier un service. Le port source du paquet initial n'est généralement pas significatif. Accepter un paquet TCP ou UDP dans l'état NEW sans --dport, c'est autoriser une demande de connexion à n'importe quel service.
Je l'ai déjà écrit, -s et -d sont inutile quand il suffit de se baser sur -i ou -o. D'ailleurs tu n'utilises -s ou -d nulle part ailleurs.
Je profite de ces règles pour mentionner le traitement des paquets ICMP. Tu n'autorises pas les paquets ICMP dans l'état RELATED. Or certains de ces types de paquets sont très importants car il signalent des erreurs qui doivent être prises en compte pour un bon fonctionnement des communications. Ces types sont : destination-unreachable, time-exceeded, parameter-problem.
Il y a en revanche d'autres types de paquets ICMP dans l'état RELATED qui peuvent être exploités à des fins malveillantes et qu'il est recommandé de ne plus utiliser : source-quench et redirect. Si pour cette raison on ne veut pas prendre le risque d'accepter tous les types de paquets ICMP dans l'état RELATED, il est recommandé d'accepter au moins les trois types précédents.
Parlons un peu des paquets DHCP :
D'une part, il y a des chances que ces règles soient inutiles car les logiciels clients et serveur DHCP ont tendance à communiquer directement avec l'interface réseau, sans passer par la couche IP du noyau qui fait appel à iptables. En effet, bien qu'étant formellement des paquets IP, les paquets DHCP peuvent avoir des particularités qui les rendent impropres à la prise en charge normale par la pile IP du noyau.
D'autre part, le suivi de connexion est inopérant sur ces paquets, donc il ne faut pas chercher à les filtrer sur l'état.
Pour finir, tes règles autorisent indifféremment les deux ports 67 et 68 et uniquement en source ou en destination, alors qu'ils ont des rôles bien définis : 67 est le port côté serveur et 68 est le port côté client.
client vers serveur : sport=68 et dport=67
serveur vers client : sport=67 et dport=68
Par contre, accepter des paquets DHCP dans FORWARD, tu peux oublier. La seule façon de transmettre des paquets DHCP entre deux réseaux est avec un relais DHCP, pas un routeur.
Passons au DNS dans FORWARD.
Si le but est d'autoriser les requêtes directes du LAN vers l'extérieur, il n'y aurait pas une inversion entre sport et dport ?
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Henry33 (20-05-2018 08:52:53)
Hors ligne
Ca commence à ressembler à quelque chose de juste ?
Dernière modification par Henry33 (20-05-2018 10:02:30)
Hors ligne
Hors ligne
Je viens de voir mon erreur dans FORWARD, je corrige
Corrige dans ton message précédent pour économiser de la place, ne fais pas un nouveau message.
Je rédige quelques commentaires en attendant.
Il vaut mieux montrer que raconter.
Hors ligne
Je n'ai pas ajouté les requêtes ICMP echo-reply en INPUT pour l'interface extérieur wlan1 car je ne veut pas que mon routeur réponde au ping depuis le réseau publique, j'ai bon ?
C'est comme tu veux. Ton réseau, tes règles.
- Une question concernant dnsmasq, vu qu'il est installé sur le routeur, est-ce que la règle FORWARD des paquets DNS ne le contourne pas ?
Oui. Cela peut être utile pour interroger directement un serveur DNS particulier. Par exemple cela m'arrive souvent quand je fais des tests sur une zone DNS, j'interroge directement les serveurs DNS faisant autorité pour celle-ci. Y a-t-il un intérêt à forcer les clients du LAN de passer par dnsmasq ?
- Concernant ssh, j'ai doublé les règles en INPUT -i eth0 et OUTPUT -i eth0 pour que je puisse établir la connexion depuis et vers le routeur. Est-ce qu'il n'y a un moyen de simplifier ces règles ?
Non, puisque ce sont des connexions en sens inverse qui nécessitent des règles différentes.
- Concernant ICMP, j'ai établit des règles pour 6 types mais il y en a plein d'autres (j'ai vu des règles pour 3/2, 3/3, 3/4, et 12). Sont-elles utiles et quels états leurs appliquer ?
J'ai écrit que les types source-quench et redirect étaient à proscrire.
Le type 12 correspond à parameter-problem qu'il est recommendé d'accepter.
Inutile de différencier les codes d'un même type.
Les types ICMP peuvent être classés en différentes catégories :
- les requêtes, ex : echo-request
- les réponses, ex : echo-reply
- les messages d'erreur, ex : destination-unreachable, time-exceeded, parameter-problem
Les requêtes ont l'état NEW ou ESTABLISHED et les réponses valides ont l'état ESTABLISHED, comme en TCP et UDP.
Les erreurs valides ont l'état RELATED.
J'ai une question : as-tu vraiment besoin d'accéder à des serveurs web qui écoutent sur le port 8000 ? Ce n'est pas un port standard.
Je voulais aussi ajouter quelques observations sur la rédaction du fichier de règles. Il n'est pas obligatoire de respecter le groupement par chaîne du format généré par iptables-save. Pour ma part, je regroupe les règles INPUT, OUTPUT et FORWARD qui traitent une même connexion, je trouve que c'est plus lisible. Voici un exemple de disposition que j'utiliserais, basé sur une ancienne version de ton fichier :
J'ai aussi supprimé les commentaires de date et les compteurs de paquets ajoutés par iptables-save qui ne sont pas pertinents et peuvent être omis.
Tu as dit ne pas encore vouloir utiliser de chaînes utilisateur, mais je voulais aussi te montrer un exemple de leur puissance dans l'exemple suivant ou j'ai intégré eth1 et wlan1. Sans les chaînes utilisateur, il aurait fallu doubler les règles INPUT/OUTPUT et quadrupler les règles FORWARD pour prendre en compte toutes les combinaisons. J'ai même pu regrouper certaines règles INPUT/OUTPUT et FORWARD dans une chaîne commune.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Les types ICMP peuvent être classés en différentes catégories :
- les requêtes, ex : echo-request
- les réponses, ex : echo-reply
- les messages d'erreur, ex : destination-unreachable, time-exceeded, parameter-problem
Les requêtes ont l'état NEW ou ESTABLISHED et les réponses valides ont l'état ESTABLISHED, comme en TCP et UDP.
Les erreurs valides ont l'état RELATED.
Donc echo-request et echo-reply ne doivent pas avoir l'état RELATED.
Et destination-unreachable, time-exceeded, parameter-problem ne peuvent pas avoir les états NEW ou ESTABLISHED.
C'est bien ça ?
Mais du coup, les OUTPUT de destination-unreachable, time-exceeded sont-ils nécessaires ? Si le routeur/destinataire a un problème, qui envoie les réponses RELATED...(?)
C'est le cas aussi pour parameter-problem ?
En gros, ça donne:
Hors ligne
Donc echo-request et echo-reply ne doivent pas avoir l'état RELATED.
Et destination-unreachable, time-exceeded, parameter-problem ne peuvent pas avoir les états NEW ou ESTABLISHED.
C'est ça. En fait j'aurais dû écrire "ne peuvent pas" plutôt que "ne doivent pas".
Un paquet ICMP de type echo-reply ne sera jamais dans l'état NEW ou RELATED. S'il correspond à un paquet ICMP de type echo-request vu récemment il sera considéré comme une réponse à cette requête et aura l'état ESTABLISHED, sinon il aura l'état INVALID.
Même chose pour un type d'erreur : s'il correspond à une connexion existante il aura l'état RELATED, sinon il aura l'état INVALID.
Donc ce n'est pas très grave si on accepte un état que le type paquet ne peut pas avoir, du moment que ce n'est pas l'état INVALID.
Mais du coup, les OUTPUT de destination-unreachable, time-exceeded sont-ils nécessaires ? Si le routeur/destinataire a un problème, qui envoie les réponses RELATED...(?)
Les messages d'erreur ICMP servent à informer l'expéditeur d'un paquet (processus local ou autre machine) que le paquet n'a pas pu être délivré à son destinataire. Ils sont donc importants pour que l'expéditeur puisse réagir en conséquence. Par exemple, si un paquet n'a pas pu être délivré parce qu'il est trop gros, l'expéditeur informé pourra renvoyer le paquet en le fragmentant pour ne pas dépasser la taille maximum indiquée dans le message.
Comme expliqué plus haut, un paquet ICMP echo-reply ne peut pas avoir l'état NEW mais ce n'est pas grave de le mentionner, la condition ne sera simplement jamais vraie. Aucun paquet qui n'aurait pas dû être accepté ne sera accepté.
- Autant mettre "parameter-problem" que 12, c'est un peu plus parlant.
- Pourquoi avoir commenté la règle dans OUTPUT (même remarque pour les types destination-unreachable et time-exceeded) ? Le routeur peut émettre ces types de message. Un exemple est lors d'un traceroute ; ce sont les messages ICMP de type time-exceeded qui permettent de lister les noeuds intermédiaires du chemin.
Dernière modification par raleur (20-05-2018 13:57:51)
Il vaut mieux montrer que raconter.
Hors ligne
Pour finir, tes règles autorisent indifféremment les deux ports 67 et 68 et uniquement en source ou en destination, alors qu'ils ont des rôles bien définis : 67 est le port côté serveur et 68 est le port côté client.
client vers serveur : sport=68 et dport=67
serveur vers client : sport=67 et dport=68
Ca donne donc :
C'est bien ça ?
iptables.encours.chaines
EDIT1 : Bon... La tablette (Android) a du mal a obtenir une adresse du routeur. Le seul paramètre qui semble fonctionner c'est 67:68 en sport et dport... Ca correspond pas à ce que j'avais compris...
EDIT2: J'ai vu que la tablette avait une adresse ipv6 donc j'ai activé le filtrage ipv6 et j'ai adapté la table de filtrage, comme ce sera fait. Je vais aller faire pareil à dnsmasq.
EDIT3 : J'ai ajouter les règles concernant packet-too-big, je me suis dit que ça doit être important. Il y a aussi router-advertisement, il est utile celui là ?
Dernière modification par Henry33 (20-05-2018 17:39:24)
Hors ligne
J'ai vu que la tablette avait une adresse ipv6 donc j'ai activé le filtrage ipv6 et j'ai adapté la table de filtrage
C'est-à-dire ?
Si l'adresse commence par fe80, c'est juste une adresse locale sans intérêt.
J'ai ajouter les règles concernant packet-too-big, je me suis dit que ça doit être important. Il y a aussi router-advertisement, il est utile celui là ?
Packet-too-big est l'équivalent en ICMPv6 de fragmentation-needed en ICMPv4 mais c'est un nouveau type à part entière qu'il faut effectivement prendre en compte et non plus un des codes du type destination-unreachable. Son rôle est encore plus important en IPv6 qu'en IPv4 car les paquets IPv6 ne peuvent être fragmentés qu'à la source contrairement aux paquets IPv4 qui ont le drapeau DF=0 (Don't Fragment) qui peuvent aussi être fragmentés en chemin par un routeur.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
La même table avec en plus wlan0, réseau privé, et eth1, réseau publique, et chaînes utilisateur
Tables mises à jour le 21/05/2018
Deuxième table mise à jour et corrigée le 22/05/2018
Dernière modification par Henry33 (23-05-2018 05:25:12)
Hors ligne
Le ipv6 m'est totalement inconnu et comme il n'y a (apparemment) pas grand chose à faire pour le paramétrer en plus de l'ipv4, je l'ai fait.
Sur un hôte en configuration automatique, peut-être. En revanche il y a un peu plus que "pas grand-chose" à configurer pour prendre en charge l'IPv6 en tant que routeur : les préfixes de chaque réseau, les interfaces, radvd, optionnellement le protocole DHCPv6 (jamais utilisé)...
j'ai recopié la table de filtrage de l'ivp4 en ajoutant les v6 aux icmp et ajouter le icmpv6-type fragmentation-needed.
Ce n'est pas si simple. L'IPv6 sur un LAN a des besoins spécifiques qui n'ont pas d'équivalent en IPv4 : j'ai nommé NDP (Neighbour Discovery Protocol) qui comprend les 4 types ICMPv6 de sollicitation et annonce de voisin et de routeur.
Dernière modification par raleur (20-05-2018 21:23:17)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Même s'il n'y a pas de serveur DNS installé sur le routeur, il faut bien que les processus locaux du routeur puissent envoyer des requêtes DNS vers les serveurs DNS extérieurs, donc il ne faut jamais commenter ces règles.
Suggestion de présentation :
Une "connexion" (au sens large, pas seulement au sens étroit de TCP) fait intervenir des paquets dans les deux sens : du client vers le serveur ("requête") et du serveur vers le client ("réponse").
Je recommande de systématiquement placer côte à côte les deux règles iptables qui traitent ces deux sens pour une même connexion, et de mettre en premier la règle qui traite le sens client vers serveur (avec l'état NEW puisque le premier paquet est transmis dans ce sens), car cela me semble le plus logique et lisible.
Sur wlan1 le routeur est client DHCP donc il faut intervertir les port 67 (serveur) et 68 (client) dans ces règles.
En suivant ma recommandation, tu aurais peut-être détecté plus facilement que la règle censée accepter les requêtes n'a pas l'état NEW, donc qu'il est impossible d'initier une connexion et que l'état ESTABLISHED ne sera jamais atteint.
Si tu ne veux pas autoriser le ping depuis l'extérieur vers le LAN, il suffit de supprimer ces deux règles plutôt que leur donner des états impossibles à atteindre.
J'observe au passage que tu n'as pas mis de règles autorisant le ping du routeur vers l'extérieur par wlan1. Oubli ou absence de besoin ? Ça peut être utile pour faire des tests.
Pour le reste du fichier, ça me semble bon.
Il vaut mieux montrer que raconter.
Hors ligne
Mais moi je veux pas mettre mon réseau en ipv6, je veux juste le rendre compatible au cas où, un jour, je sois connecté à un réseau ipv6.
Tu peux préparer les règles ip6tables à l'avance, mais il faudra quand même te taper la configuration IPv6 elle-même le jour où tu auras une connectivité IPv6.
Note : pas de NAT en IPv6. Ça existe, ip6tables peut le faire mais c'est mal, et IPv6 a précisément été développé et déployé pour ne pas en avoir besoin, avec suffisamment d'adresses IPv6 globales (publiques) pour toutes les machines connectées à l'internet.
Dernière modification par raleur (20-05-2018 22:06:49)
Il vaut mieux montrer que raconter.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Henry33 (21-05-2018 07:53:47)
Hors ligne