Vous n'êtes pas identifié(e).
Dernière modification par Henry33 (13-05-2018 16:09:35)
Hors ligne
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Ça devrait échouer, les règles iptables interdisant à un processus local d'interroger dnsmasq.
Ajouter les deux règles suivantes pour autoriser l'accès des processus locaux à dnsmasq (et d'autre choses peut-être passées inaperçues) :
Refaire des requêtes DNS depuis le routeur avec des noms jamais utilisés (pas dans le cache de dnsmasq).
Si ça répond, alors dnsmasq se joue des règles iptables.
Si ça part en time-out ou SERVFAIL, alors les règles iptables bloquent les flux sortants de dnsmasq mais alors le fait que la résolution DNS marche depuis Windows reste inexplicable.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Hors ligne
il peut arriver que dnsmasq ne bloque pas les requêtes de DNS
Je n'ai jamais prétendu que dnsmasq pouvait bloquer des requêtes DNS, mais que les règles iptables en place devraient bloquer les requêtes DNS relayées vers l'extérieur par dnsmasq.
voici mes règles iptables actuelles
- Avec les politiques par défaut d'INPUT et OUTPUT à ACCEPT, les règles ACCEPT dans ces chaînes sont inutiles.
- Quel est l'objectif des règles DROP dans ces chaînes ?
Il vaut mieux montrer que raconter.
Hors ligne
Je n'ai jamais prétendu que dnsmasq pouvait bloquer des requêtes DNS, mais que les règles iptables en place devraient bloquer les requêtes DNS relayées vers l'extérieur par dnsmasq.
Ha mais oui, mais je mélange les fonctions des deux... Je pensais (en dehors du sujet) que dnsmasq pouvait bloquer les requêtes si il n'était pas configuré comme il faut... Donc c'est normal qu'il les laisse passer (ça commence à rentrer, sisi...). Pour le non filtrage d'iptables, j'en ai aucune idée...
- Avec les politiques par défaut d'INPUT et OUTPUT à ACCEPT, les règles ACCEPT dans ces chaînes sont inutiles.
Oui, c'est sûr, ce sont les règles temporaire d'un apprenti qui apprend...
Je suis en train d'apprendre et de faire les règles de filtrage d'iptables en même temps, donc je bascule ces règles de ACCEPT à DROP et de DROP à ACCEPT, sinon j'ai plus de navigation Web... Je configure les règles de filtrage en ACCEPT car les règles par défaut seront DROP. En clair, je veux tout filtrer en DROP et n'ouvrir que ce dont j'ai besoin depuis le routeur.
J'ai (un peu) fait évoluer les règles depuis. Maintenant, je peux pinguer les adresses extérieures (IP et DNS) depuis le routeur et il ne répond pas au ping venant de l'extérieur. Mais j'étais en train de chercher la liste des protocoles contenu dans le Raspberry/Linux. Dans une doc, j'ai vu passer cette liste, c'est celle qui permet de faire le lien entre "-p icmp" et les ports correspondants. Je voudrai configurer iptables avec les noms des protocoles pour pouvoir changer les numéros de ports indépendamment sans avoir à modifier les règles avec les numéros correspondant... Mais je ne l'ai pas encore retrouvé...
- Quel est l'objectif des règles DROP dans ces chaînes ?
Rejeter sans message pour l'expéditeur les requêtes icmp et SSH. C'était pour tester (et comprendre) le fonctionnement des règles, mais je vais faire l'inverse, tout DROPer et n'ACCEPTer que ce dont j'ai besoin.
Je n'ai beaucoup avancé sur les règles car j'ai passé la matinée pour (en autres) trouver comment attribuer les noms des interface réseau par adresse MAC (et donc mettre à jour le brouillon de mon tutoriel) et à régler un problème avec un fournisseur. En plus j'ai encore une chose cette après midi dans le monde réel, donc je ne vais pas pouvoir me remettre dessus tout de suite...
Vu qu'en plus il me faut à chaque fois un moment pour me rappeler ce que je veux faire, comment le faire et, du coup, quoi faire, j'avance pas vite...
Hors ligne
Mais j'étais en train de chercher la liste des protocoles contenu dans le Raspberry/Linux
Qu'entends-tu par "contenu dans le Raspberry/Linux" ?
Dans une doc, j'ai vu passer cette liste, c'est celle qui permet de faire le lien entre "-p icmp" et les ports correspondants.
Quelle doc ? Quel lien ? Les ports n'existent pas dans le protocole ICMP.
Je voudrai configurer iptables avec les noms des protocoles pour pouvoir changer les numéros de ports indépendamment sans avoir à modifier les règles avec les numéros correspondant
Je n'ai rien compris. Un exemple concret peut-être ?
Rejeter sans message pour l'expéditeur les requêtes icmp et SSH
Pour info, cela bloque les demandes de connexion SSH sortantes émises par le routeur. Pas les demandes de connexion entrantes reçues par le routeur.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Le fichier qui contient les correspondances entre le nom des protocoles et les numéros de ports.
Tu veux parler du fichier /etc/services ?
Les ports n'existent pas dans le protocole ICMP.
Ha... ça passe par où alors, pour savoir ?
Désolé, je ne comprends pas la question. Les messages ICMP sont des paquets IP et sont routés comme les paquets des autres protocoles basés sur IP (TCP, UDP...). Les ports n'interviennent pas dans le routage des paquets IP.
Je voudrai faire règle du style
-A OUTPUT -d wlan1 -p http -j ACCEPT
plutôt que de faire-A OUTPUT -d wlan1 -p tcp -m tcp --dport xx -j ACCEPT
(<- cette règle n'est certainement pas exacte, c'est pour la forme c'est tout)
En effet elle ne l'est pas car le protocole HTTP n'est pas transporté directement sur IP (comme TCP, UDP, ICMP...) mais sur un protocole de transport (TCP) lui-même transporté sur IP. On ne peut donc pas le spécifier dans l'option -p. Ce qu'on peut faire en revanche, c'est remplacer le numéro du port par le nom du service correspondant dans le fichier /etc/services :
Si tu envisages de modifier des numéros de ports dans ce fichier, je te le déconseille car ce fichier est utilisé par d'autres programmes que iptables pour faire la correspondance entre les noms de services/protocoles et les numéros de ports. Par contre tu peux y ajouter tes propres ports et services.
Et ça ? C'est sensé les bloquer ?
Seulement les sortantes, pas les entrantes.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
suivit entre autres de :
Alors que ce qui fonctionne chez moi (eth1=eth0, eth0=wlan1)
A force d'essai, j'ai fini par enlever les NEW, RELATED etc. car j'ai eu du mal à faire fonctionner les filtres indiqués dans ce tutoriel. Ca vient de moi ?
PS: Je m'y recolle, a plus tard.
Hors ligne
J'ai passé la journée d'hier a suivre ce tuto
Quel tutoriel ?
Si on commence par tout accepter en entrée et en sortie sur une interface, ce n'est pas la peine d'ajouter des règles ensuite pour cette même interface.
A force d'essai, j'ai fini par enlever les NEW, RELATED etc. car j'ai eu du mal à faire fonctionner les filtres indiqués dans ce tutoriel. Ca vient de moi ?
Oui. S'il faut enlever quelque chose, c'est plutôt le --sport. Il n'a pas vraiment d'utilité quand on utilise les états de suivi de connexion, et quand on ne les utilise pas il peut constituer une brèche. Ce n'est pas pour rien qu'on a développé le suivi de connexion.
Si je prends en exemple tes deux règles suivantes :
Pour toi, elles autorisent les connexions sortantes vers un serveur HTTP ou HTTPS. La règle OUTPUT accepte les paquets sortants vers le serveur, et la règle INPUT accepte les paquets entrants provenant du serveur.
Mais pour un attaquant, elles permettent de se connecter à n'importe quel port TCP de ta machine du moment qu'on utilise un de ces ports sources. La raison est que tes règles ne vérifient pas l'état des paquets ; or elles devraient n'accepter un paquet entrant que s'il appartient à une connexion établie. Et si c'est une connexion établie, c'est que le paquet initial avec son port de destination a été accepté, donc il est inutile de contrôler le port source. C'est pourquoi il est courant de n'avoir qu'une seule règle commune pour accepter tous les paquets des connexions établies.
Note : pour éviter de multiplier les règles pour chaque interface, tu peux définir des chaînes utilisateur, par exemple :
Il vaut mieux montrer que raconter.
Hors ligne
Merci du coup de main.
EDIT :
-N output_pub
-A OUTPUT -i eth0 -j output_pub
-A OUTPUT -i wlan1 -j output_pub
-A output_pub -p tcp -m multiport --dports 80,443,8000 -j ACCEPT
-A output_pub -p udp --dport 53 -j ACCEPT
C'est bien OUTPUT -i ? pas -o ?
Dernière modification par Henry33 (19-05-2018 08:16:48)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Avec OUTPUT c'est -o évidemment.
Pas de soucis, ça montre que j'ai au moins compris quelque chose...
Copier / coller corrigé
Je ne vais pas suivre ton conseil avec "-N output_pub" pour l'instant. J'ai déjà du mal à suivre et à comprendre, je vais en rester à la méthode basique, même si elle est répétitive. Je reviendrai dessus quand j'aurai résolu ce [hum-hum de] problème de COMMIT et que j'aurai établi des règles qui fonctionnent.
Hors ligne
Tu as oublié de changer tcp en udp.
Note : l'option -m tcp/udp n'est pas nécessaire, elle est implicite avec -p tcp/udp.
EDIT : explication : la vérification de la cohérence entre -p et -m est faite par le noyau et non par iptables-save, donc l'erreur ne se manifeste que lors du COMMIT quand iptables-save essaie de charger l'ensemble des règles dans le noyau.
Dernière modification par raleur (19-05-2018 09:54:30)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il manque la notion de "source" dans ma phrase
"depuis son port ssh", ce n'est pas une source ?
Il vaut mieux montrer que raconter.
Hors ligne
L'erreur ne vient pas de la ligne COMMIT mais de deux des règles précédentes :
Tu as oublié de changer tcp en udp.
Note : l'option -m tcp/udp n'est pas nécessaire, elle est implicite avec -p tcp/udp.
EDIT : explication : la vérification de la cohérence entre -p et -m est faite par le noyau et non par iptables-save, donc l'erreur ne se manifeste que lors du COMMIT quand iptables-save essaie de charger l'ensemble des règles dans le noyau.
Wahou, je ne l'avais pas trouvé celle-là ! Trois heures que je suis bloqué à cause de ça... Je cherchais du coté des états de paquets. Ca va m'apprendre !
Merci pour les explications, c'est donc normal que iptables ne me donne pas la source de mon erreur. Si ça avait été une erreur d'états de paquets, il ne m'aurait rien dit, c'est ça ?
Au fait, tu as été voir le tutoriel https://debian-facile.org/doc:reseau:ip … passerelle. Il est juste ??
Hors ligne