Vous n'êtes pas identifié(e).
iptables-save
Merci pour votre aide !
Dernière modification par Henry33 (22-05-2018 10:21:03)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
J'ai voulu le configurer avec les noms d'interfaces mais il refuse pour les règles OUTPUT
D'ailleurs, là ce sont des règles de filtrage, est-ce qu'il ne vaudrait mieux pas que je fasse des règles NAT ? De ce que j'ai lu et de ce que j'en comprends, ça correspond plus à ce que je veux faire mais j'ai un peu de mal à bien bien comprendre la configuration des PREROUTING, INPUT, OUUTPU et POSTROUTING.
Est-ce que des règles NAT ne permettent pas un meilleur filtrage/protection que des filtres classiques ?
Hors ligne
Et ça, c'est pas bon ?
Quand la machine communique avec l'extérieur via eth1 ou wlan1, ce n'est pas avec des adresses de tes réseaux privés.
Can't use -i with OUTPUT
Normal. Dans OUTPUT on ne peut spécifier que l'interface de sortie (-o) et dans INPUT l'interface d'entrée (-i).
est-ce qu'il ne vaudrait mieux pas que je fasse des règles NAT ?
Les seules règles de NAT nécessaires sont déjà présentes.
On ne fait pas de la sécurité avec du NAT.
Dernière modification par raleur (13-05-2018 11:08:34)
Il vaut mieux montrer que raconter.
Hors ligne
j'ai un peu de mal à bien bien comprendre la configuration des PREROUTING, INPUT, OUUTPU et POSTROUTING.
Voir le diagramme "packet flow" dans https://fr.wikipedia.org/wiki/Netfilter (seulement la couche verte "network layer").
Il y a trois types de paquets IP :
- ceux qui entrent et sont destinés à la machine
- ceux qui entrent mais ne sont pas destinés à la machine et vont ressortir (si la machine est un routeur)
- ceux qui sont émis par la machine elle-même.
Les chaînes PREROUTING voit passer tous les paquets qui entrent avant qu'on regarde s'ils sont destinés à la machine ou pas.
Les chaînes INPUT voient passer les paquets entrants passés par PREROUTING destinés à la machine.
Les chaînes FORWARD voient passer les paquets entrants passés par PREROUTING destinés à une autre machine.
Les chaînes OUTPUT voient passer les paquets émis par la machine.
Les chaînes POSTROUTING voient passer tous les paquets passés par FORWARD ou OUTPUT avant de sortir.
La table filter n'a que des chaînes INPUT, FORWARD et OUTPUT, chacune traitant un des trois types de paquets ci-dessus.
Dernière modification par raleur (13-05-2018 11:22:00)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (13-05-2018 11:24:19)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
J'ai remarqué le doublon de fail2ban, j'en ai parlé dans le premier post, je l'ai installé trop tôt, ai voulu le désinstallé mais l'ai du coup réinstallé... Donc il y a un script quelque part qui rajoute la ligne au démarrage à la configuration enregistrée dans iptables.
J'ai un PC portable, juste à coté du Raspberry, qui se connecte à la même box par le wifi. J'ai également un clé usb d’acquisition vidéo qui me permet d'avoir l'affichage AV du Raspi. Je dois rester sous Windows 7 car la clé d'acquisition n'est pas compatible avec Debian (autre OS du portable).
Pour les tests, je peux me déconnecter du wifi de la box et me connecter au wifi "testtest" du Raspi, ou me brancher sur l'ethernet de son switch. Je peux tester la navigation sur Internet et pour SSH, j'utilise Putty sur le même PC.
Grâce à la clé vidéo, je ne perds jamais la mains sur le Raspberry.
Hors ligne
j'aimerai ne faire apparaitre qu'une adresse IP pour l'extérieur, quoi qu'il arrive.
C'est déjà précisément ce que font les règles avec la cible MASQUERADE.
Du coup, PREROUTING et POSTROUTING me permettent de changer l'adresse IP des paquets FORWARD(és) alors que le simple filtrage non. J'ai bon ?
Pas seulement des paquets FORWARDés mais de tous les paquets qui passent par ces chaînes.
Il est superflu de MASQUERADEr les paquets émis par le routeur lui-même, mais cela simplifie les règles.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Voici les règles actuelles
Tu as modifié les règles pour trafic sur les interfaces privées, mais il n'y a toujours pas de règle pour autoriser le trafic sur les interfaces publiques.
Les règles avec les préfixes privés sont maintenant superflues et présentent un risque si un attaquant situé dans un réseau public usurpe une adresse d'un de ces préfixes.
Règles fail2ban : il suffit de les supprimer du fichier de règles après l'avoir généré avec iptables-save.
Je peux tester la navigation sur Internet et pour SSH, j'utilise Putty sur le même PC
La navigation est probablement l'une des pires façons de tester un accès internet car il est difficile de savoir ce que fait le navigateur et où ça coince.
Il vaut mieux tester avec des outils simples comme ping ou traceroute vers des adresses IP, dig/host/nslookup pour la résolution DNS...
Putty vers quoi ? Le routeur ? Une machine extérieure ?
Dernière modification par raleur (13-05-2018 11:55:24)
Il vaut mieux montrer que raconter.
Hors ligne
Donc pour cacher les machines de mes réseaux privés, ne vaut-il pas mieux que je fasse des règles NAT avec PRE et POST-ROUTING ?
Qu'est-ce qui n'est pas clair dans "C'est déjà précisément ce que font les règles avec la cible MASQUERADE" ?
De toute façon l'accès internet ne marcherait pas sans elles car les équipements des réseaux publics ne savent pas router tes préfixes privés.
Il vaut mieux montrer que raconter.
Hors ligne
Les règles avec les préfixes privés sont maintenant superflues
Comment ça "maintenant superflues" ?
Quand j'ai un doute sur la connexion, je fais un ping vers www.google.fr, comme ça je vois si ça passe ou pas.
J'utilise Putty, pour me connecter au serveur.
Hors ligne
Qu'est-ce qui n'est pas clair dans "C'est déjà précisément ce que font les règles avec la cible MASQUERADE" ?
Réponse -> Moi...
Je croyais que MASQUERADE ne faisait que le routage à l'intérieur du routeur mais que les paquets portait toujours (pas directement bien sûr, mais d'une certaine manière), l'adresse IP de la machine qui les envoie. Comme si les paquets étaient routés mais pas modifiés. Il est logique que l'adresse IP de sortie soit celle du serveur, c'est normal, mais je pensais qu'avec MASQUERADE, le serveur qui reçoit les paquets peut encore faire la différence entre les machines que j'ai sur mon réseau, alors qu'avec PREROUTING et surtout POSTROUTING, toutes les machines apparaissent comme étant une seule machine.
Hors ligne
Hors ligne
Je veux refuser les accès par les interfaces publiques
Les accès à quoi ? Depuis où ?
En matière de filtrage il est capital de toujours spécifier explicitement la source, la destination et le cheminement des flux qu'on veut autoriser ou interdire. Cela conditionne le placement des règles dans telle ou telle chaîne, et le contenu de ces règles.
Pour moi, les règles d'accès Internet sont déjà définis par les règles FORWARD
Seulement pour les flux qui traversent le routeur, pas ceux dont il est la source ou la destination, comme les flux DNS.
Je n'ai pas trop besoin de bloquer eth0
"Bloquer une interface" n'a pas de sens. Si on ne veut pas de trafic sur une interface, on la désactive, on la débranche...
D'un point de vue fonctionnel, on accepte ou bloque des flux. Et du point de vue d'iptables, on accepte ou bloque les paquets qui appartiennent à ces flux.
Wlan1 et eth1 ne doivent pas avoir accès au serveur.
Cette phrase ne veut rien dire. wlan1 et eth1 ne sont que des interfaces du routeur.
Comment ça "maintenant superflues" ?
Tu as ajouté des règles acceptant les paquets destinés au routeur entrant par eth0 et wlan0. Pas besoin d'accepter en plus les paquets destinés au routeur ayant une adresse source dans les préfixes des réseaux privés et entrant par n'importe quelle interface.
Quand j'ai un doute sur la connexion, je fais un ping vers www.google.fr, comme ça je vois si ça passe ou pas.
Ce test est insuffisamment précis. Si c'est la résolution DNS qui échoue, tu ne testes pas l'accès internet puisque les paquets de ping ne sont même pas envoyés. Il faut donc tester la connectivité et la résolution DNS séparément, depuis différents point du réseau (une machine d'un réseau privé et depuis le routeur).
Il vaut mieux montrer que raconter.
Hors ligne
Est-ce qu'il y a lieu de peaufiner les règles iptables pour l'instant ?
Pour me prononcer, il faudrait que je les voie dans l'état actuel.
Il vaut mieux montrer que raconter.
Hors ligne
Je sais qu'il faut que je supprime les règles INPUT -s car les INPUT -i sont mieux ainsi que le doublon fail2ban.
Au fait, merci pour ton aide et pour ta patience, j'ai beaucoup appris grâce à toi.
EDIT : Je viens de voir ta réponse du dessus.
Dernière modification par Henry33 (13-05-2018 13:32:25)
Hors ligne
Dernière modification par raleur (13-05-2018 14:11:51)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Je veux dire "je ne veux pas que des connexions en SSH et ICMP puisse se faire au serveur depuis wlan 1 et eth1"
"Depuis le réseau public par wlan1 et eth1."
je veux dire "je n'ai pas trop besoin de filtrer eth0"
Bof. "Filtrer le trafic sur eth0."
Quels outils permettent de tester la connectivité et la résolution DNS séparément ?
Je les ai mentionnés dans mon message #12.
est-il possible/nécessaire de cacher les adresses MAC des machines qui sont sur mes réseaux privés ?
Les cacher de qui/quoi ?
Les adresses MAC sont contenues dans l'en-tête des trames ethernet ou wifi, pas dans les paquets IP. Contrairement à un pont, un switch ethernet ou un point d'accès wifi, un routeur IP ne transmet pas les trames ethernet ou wifi qu'il reçoit mais seulement les paquets IP qu'elles contiennent, en les encapsulant dans de nouvelles trames ethernet ou wifi avec l'adresse MAC de son interface de sortie.
Il vaut mieux montrer que raconter.
Hors ligne
Avec ces règles, l'accès internet depuis le routeur lui-même ne devrait pas fonctionner, ni la résolution DNS via dnsmasq depuis les postes des réseaux privés. La seule chose qui devrait marcher, c'est l'accès internet depuis un poste d'un réseau privé utilisant un DNS extérieur.
Edit : la résolution DNS via dnsmasq peut continuer à fonctionner pour les noms demandés et mis en cache lorsque les politiques d'iptables étaient à ACCEPT, tant que le cache n'a pas expiré. Teste avec des noms de domaines que tu n'avais pas déjà utilisés.
Je ne sais pas si ça compte mais je peux faire des apt-get update/upgrade/install depuis le serveur.
Je n'ai pas (encore) configurer de serveur DNS extérieur dans dnsmasq, la navigation passe toujours pas les serveur DNS des fournisseurs (Orange/Free).
La navigation à l'air de se faire normalement : j'accède sans problème à n'importe quel favoris enregistré (et non consultés depuis un moment), n'importe quelle page d'un résultat d'un moteur de recherche. Même rentrer un nom inconnus du système, ou au hasard fonctionne (zebulon.fr, henry.fr, même chose pour francais.fr).
Tu as répondu à ma question sur les adresses MAC, j'ai pas besoin de m'en préoccuper.
Dernière modification par Henry33 (13-05-2018 14:41:35)
Hors ligne
Je ne sais pas si ça compte mais je peux faire des apt-get update/upgrade/install depuis le serveur.
Qu'appelles-tu le serveur ? Si c'est le routeur aux 4 interfaces, cela ne devrait pas être possible avec ces règles car ni les politiques par défaut ni les règles des chaînes INPUT et OUPUT n'acceptent quoi que ce soit sur eth1 ou wlan1. Vérifie ta configuration parce que quelque chose ne colle pas.
Sur le routeur :
Même chose sur un poste client. Si c'est un Windows :
Je n'ai pas (encore) configurer de serveur DNS extérieur dans dnsmasq, la navigation passe toujours pas les serveur DNS des fournisseurs (Orange/Free).
Peu importe. Je parlais de tous les serveurs DNS extérieurs au routeur utilisés directement (pas via dnsmasq), donc cela inclut les DNS des FAI.
Il vaut mieux montrer que raconter.
Hors ligne
ip route
cat /etc/resolv.conf
traceroute -m 3 8.8.8.8
Voici les résultats sur PC Windows 7 :
ipconfig /all
route print
tracert 8.8.8.8
Hors ligne