Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Il vaut mieux montrer que raconter.
Hors ligne
voici mon nouvel iptables , le filtrage ce fait sur eth0 (si je commente les lignes web et steam j ai plus rien qui fonctionne).
par contre je comprend pas le principe , j ai le ping sur tous les réseau d 'un client de B mais la passerelle n est pas autorisée (donc je pense a eth0 qui est drop alors que eth1 est accept ).
ça me derrange pas de filtrer sur eth0 , par contre mon parefeu est terminé , si mon logiciel fah sort sur le port 8080 et 80 , si steam aussi en 27000 et le dns aussi , tout le reste va etre sur le reseau B
a la rigueur un parefeu sur chaque client (le filter va etre comme ici , sur eth0 du client (une seule carte reseau) ).
regarde si tout est correct , le related sur steam j ai un doute , pour le web je pense oui , les regles en input et output aussi puisque la regle par defaut est drop pour eth0 .
reste le forward je vai regarder sur le web ,
Pour icmp sur le reseau " B => clients" pour l instant tout est ouvert ,de B ver A les pings passent , du reseau A vers B c est nécessaire ?
pour mangle et nat je pense que c est correct , le proxy fonctionne bien , je vai faire un post a ce sujet , a propos du wiki proxy et de mes soucis 
Dernière modification par anonyme (18-11-2014 04:24:35)
Il vaut mieux montrer que raconter.
Hors ligne
(avec parefeu + proxy + dhcp + bind )Dernière modification par anonyme (20-11-2014 18:50:47)
Il y a des serveurs FTP, STEAM, DNS, HTTP, HTTPS et écoutant sur le port 8000 dans le réseau B, avec lesquels le routeur a besoin de communiquer ?
oui tous ses services sont sur le réseau B
Sur des machines du réseau B ou sur la passerelle ?
Je doute qu'il y ait un serveur STEAM sur le réseau B.
Ces règles permettent à la passerelle de se connecter à ces services sur des machines via eth1. Si tu veux faire l'inverse, permettre aux machines du réseau B de se connecter à ces services sur la passerelle, les règles sont différentes. Grosso modo, il faut permuter les entrées et les sorties pour les paquets aller et retour :
Permettre à la machine de se connecter au port TCP X d'autres machines accessibles par eth1 (connexion sortante) :
Permettre à d'autres machines de se connecter au port TCP X de la machine par eth1 (connexion entrante) :
Néanmoins, en autorisant tout le trafic entrant et sortant sur eth1, tu n'as pas besoin de règles individiduelles. Aussi, que ce soit dans un sens ou dans l'autre ces règles ne servent pas pour les paquets des connexions qui traversent la passerelle entre le réseau B et le réseau A ou internet. Ces paquets ne passent pas dans les chaînes INPUT ni OUTPUT mais dans la chaîne FORWARD.
pour ftp serveur pas encore fait mon choix , mais sera sur un client port par defaut (pas d acces de l exterieur ni de A )
Je ne comprends pas cette phrase. Serveur, client, port par défaut ?
j ai un programme (fah) sur chaque client qui utilise le port 8080
fah = Folding@home ? Folding@home se connecte à des serveurs qui sont sur internet. S'il est installé sur des machines du réseau B, les paquets des connexions traversantes du réseau B vers internet doivent être acceptés dans la chaîne FORWARD :
(Ces règles ne sont pas nécessaires s'il y a déjà des règles plus permissives autorisant les connexions du réseau B vers internet sur tous les ports.)
S'il est installé sur la passerelle, les paquets des connexions sortantes vers internet doivent être acceptés dans les chaînes INPUT et OUTPUT :
definition de "RELATED" le serveur 2 reçoit le paquet SYN (suite a un NEW du serveur 1) et renvoie un accusé de réception SYN-ACK (synchronize ackowledgement ) .
si je prend l exemple du dns , un client fait une demande , c est ma passerelle adsl qui traite la requette et pas la passerelle de B , donc la poignée de main est entre la box machin et le client du réseau B .
Mon ip du dns du réseau est l ip de la boxmachin 192.168.1.1 donc pour eth1 de la passerelle ESTABLISHED suffit .
Mon raisonnement est correct ?
Non. En fait j'ai beau le lire dans tous les sens, je n'arrive pas à le comprendre. Je vais essayer d'expliquer le plus clairement possible sans trop entrer dans les détails.
Le protocole IP fournit une connectivité de bout en bout : le client communique directement avec le serveur, et les routeurs intermédiaires sont quasi-transparents, ils se contentent de faire suivre les paquets de l'un vers l'autre.
Le suivi de connexion ("conntrack", contraction de "connection tracking"), examine chaque paquet qui va être traité par iptables pour lui donner un état que pourra utiliser iptables pour décider du sort du paquet. Si c'est un paquet reçu, conntrack intervient avant les chaines PREROUTING. Si c'est un paquet émis, conntrack intervient avant les chaînes OUTPUT. Une chose importante est qu'il ne faut pas confondre un paquet et une connexion, ni l'état d'un paquet avec l'état d'une connexion. Une connexion implique généralement plusieurs paquets dans les deux directions aller et retour, ayant des états différents. A noter que pour conntrack, contrairement aux règles iptables, la direction n'est pas définie par l'entrée ou la sortie mais par la source et la destination du paquet. La direction aller ou retour d'un paquet est définie par rapport à la direction du premier paquet de la connexion : dans le même sens = aller, dans le sens inverse = retour.
Le premier paquet aller d'une connexion, celui qui "crée" la connexion (au sens de conntrack), a l'état NEW. Si ce paquet est bloqué par les règles iptables, la connexion n'est pas créée. Si ce paquet est répété en l'absence de réponse, il a encore l'état NEW.
Le premier paquet retour appartenant à une connexion a l'état ESTABLISHED. Tous les paquets aller et retour suivants ont aussi l'état ESTABLISHED.
Les paquets liés à une connexion existante mais ne lui appartenant pas ont l'état RELATED. Les messages d'erreurs ICMP émis en réponse à un autre paquet sont dans ce cas. Le premier paquet d'une connexion de données liée à une connexion de commande en clair (non chiffrée) qu'on rencontre dans certains protocoles complexes comme FTP, TFTP, SIP, PPTP... a l'état RELATED au lieu de NEW si le module de conntrack pour ce protocole est actif.
Enfin, les paquets qui ne créent pas une nouvelle connexion et ne peuvent pas être rattachés à une connexion existante ont l'état INVALID. Cela concerne principalement les protocoles TCP (qui a intrinsèquement une notion d'état assez stricte) et ICMP. Je ne connais pas de cas où un paquet UDP aurait l'état INVALID. Une particularité notable des paquets dans l'état INVALID est qu'ils sont ignorés par les règles de NAT (DNAT, REDIRECT, MASQUERADE...). Dans la plupart de cas, ces paquets devraient être bloqués.
Quelques exemples pour illustrer :
a) Etablissement d'une connexion TCP HTTP :
- le client envoie au serveur un paquet SYN vers le port 80 qui a l'état NEW
- le serveur envoie au client un paquet SYN/ACK depuis le port 80 qui a l'état ESTABLISHED
- le client envoie au serveur un paquet ACK vers le port 80 qui a l'état ESTABLISHED
b) Résolution DNS :
- le client envoie au serveur un paquet UDP vers le port 53 qui a l'état NEW
- le serveur envoie au client un paquet UDP depuis le port 53 qui a l'état ESTABLISHED
Dans certains cas, les requêtes suivantes peuvent avoir l'état ESTABLISHED au lieu de NEW.
c) Ping (ICMP echo)
- le client envoie au serveur un paquet ICMP de type echo-request qui a l'état NEW
- le serveur envoie au client un paquet ICMP de type echo-reply qui a l'état ESTABLISHED
Dans certains cas, les requêtes suivantes peuvent avoir l'état ESTABLISHED au lieu de NEW.
d) Traceroute
- le client envoie au serveur un paquet UDP avec le TTL=1 qui a l'état NEW
- le premier routeur envoie au client un paquet ICMP de type time-exceeded qui a l'état RELATED
- le client envoie au serveur un paquet UDP avec le TTL=2 qui a l'état NEW
- le second routeur envoie au client un paquet ICMP de type time-exceeded qui a l'état RELATED
- etc.
-A OUTPUT -o eth1 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
ces regles ont été commenté pour l instant, a supprimer ( ps : aprés le reboot de la passerelle plus de web..... a cause du proxy pas vu )
Normal. Les connexions HTTP sont redirigés vers le port 3129 du proxy local par une règle de NAT, mais s'il n'y a pas de règles globales (celles ci-dessus que tu as commentées) ou spécifiques (voir exemple plus haut) acceptant les connexions entrantes sur eth1 vers de ce port, le proxy ne reçoit rien.
-A OUTPUT -o eth1 -p udp -m udp --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
Ces règles acceptent les requêtes DNS émises par le routeur vers le réseau B et les réponses reçues.
Il y a vraiment un serveur DNS sur le réseau B ?
non pas de dns sur le réseau B , je les gardes pour re-tester bind9 (le dns sera sur la carte eth1 de la passerelle et fera les requets externe sur la passerelle adsl.)
Alors ces règles ne servent à rien. Elles permettent à la passerelle d'interroger un serveur DNS situé sur le réseau B (connexion sortante sur eth1), ce dont tu n'as pas besoin. Tu as besoin de règles permettant à la passerelle d'interroger un serveur sur le réseau A ou internet (connexion sortante sur eth0), et de règles permettant aux machines du réseau B d'interroger le serveur DNS sur la passerelle (connexion entrante sur eth1.
ces regles devraient suffire pour le web ?
-A OUTPUT -o eth1 -p tcp -m multiport --dports 80,443,8080 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443,8080 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m multiport --sports 80,443,8080 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p tcp -m multiport --sports 80,443,8080 -j ACCEPT
Les règles pour eth1 sont inutiles. Elles permettent à la passerelle d'interroger un serveur HTTP, HTTPS ou FAH situé sur le réseau B (connexion sortante sur eth1), ce dont tu n'as pas besoin.
Dans les règles pour eth0, le proxy transparent a seulement besoin du port 80. Un proxy ne peut fonctionner avec le port 443 que s'il fonctionne en mode non transparent. Par contre d'autrs processus locaux de la passerelle peuvent avoir besoin de se connecter à un serveur HTTPS pour certains usages, par exemple pour des mises à jour. Quant au port 8080, la passerelle n'en a besoin que si elle fait tourner le logiciel FAH.
Commentaires sur ton dernier jeu de règles
A quoi servent ces deux règles ? Pourquoi bloquer précocément les paquets entrants sur ces deux ports ?
Le proxy local écoute sur le port 3129, mais pourquoi bloquer les connexions vers ce port qui n'ont pas été redirigées à partir du port 80 ?
A quoi correspond le port 3128 ?
Pourquoi rediriger vers le port du proxy les connexions HTTP qui entrent par eth0, côté réseau A et internet (et qui seront bloquées puisqu'il n'y a pas de règles les autorisant ensuite) ?
Côté réseau B, pourquoi rediriger les connexions HTTP vers l'adresse IP 192.168.1.10, qui est je suppose l'adresse IP d'eth0 ? Cela me laisse penser que le proxy écoute sur cette adresse, alors qu'il me semble qu'il serait plus logique qu'il écoute soit sur toutes les adresses locales, soit sur l'adresse d'eth1.
Je répète que ces règles ne sont utiles (sans RELATED) que si un client STEAM tourne sur la passerelle. Je doute que ce soit le cas.
Il manque la gestion des paquets ICMP sur eth0 en entrée (INPUT) et en sortie (OUTPUT). Au minimum il faut accepter les types destination-unreachable, time-exceeded et parameter-problem dans l'état RELATED.
Il vaut mieux montrer que raconter.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
et j ai l impression que eth1 ne profite pas des regles de eth0 donc grand ouvert sur le réseau A (je n ai pas de soucis avec apt du reseau B) .
pour les tests je n ai DROP que INPUT (FORWARD est toujours DROP , pas de soucis sur le reseau B uniquement sur la passerelle ) .
@++
en mode dépressif l iptables
ici il manque le RELATED sur le FORWARD , connection sur le site avec un client de B possible , mais au momment d enregistrer un post réinitialisation de la connextion et hop ejecté .
Dernière modification par anonyme (22-11-2014 09:40:56)
Il vaut mieux montrer que raconter.
Hors ligne
j ai l impression que eth1 ne profite pas des regles de eth0
En effet, les règles sur eth0 n'ont pas d'effet direct sur les paquets sur eth1.
il manque le RELATED sur le FORWARD , connection sur le site avec un client de B possible , mais au momment d enregistrer un post réinitialisation de la connextion et hop ejecté
Quel site ? Ce forum ? Je ne vois pas de rapport entre l'état RELATED et le protocole HTTP. Tu es sûr que ce n'est pas juste l'expiration de la session ?
Il vaut mieux montrer que raconter.
Hors ligne
Normal pour l'imprimante réseau, tu n'as pas ajouté de règles permettant la passerelle de s'y connecter (généralement port TCP 9100).
Pour le reste, peux-tu préciser comment ça ne fonctionne pas ?
Quels sont les serveurs DNS définis dans /etc/resolv.conf sur la passerelle et les postes du réseau B ?
Si c'est ton propre BIND sur la passerelle, est-ce que ça marche mieux avec le DNS de la box ?
Tu peux aussi faire des tests simples :
- résolution DNS avec host, dig ou nslookup vers le DNS par défaut ou un DNS spécifique (box, FAI)
- tcptraceroute vers une adresse IP extérieure sur un port TCP censé être autorisé
- requête NTP manuelle avec ntpdate...
Si tu souçonnes les règles de filtrage, c'est simple : tu autorises tout en INPUT et tu regardes si ça règle le problème.
Tu peux aussi ajouter des règles avec la cible LOG à la fin des chaînes dont la politique par défaut est DROP afin d'enregistrer les paquets bloqués dans les logs du noyau (/var/log/kern.log).
imprimante je suis d accord pour la regle elle n existe pas
pour le resolv tu a pas lut mon post bind il est complet , mais oui j ai name server 192.168.10.1 , name server 80.10.246.130 et search exemple.com
les postes du reseau B sont en auto-config et c est ok (dhcp de la passerelle)
pas de soucis de dns et de dhcp
ntp fonctionne bien et celui de la passerelle distribue au client
je suis en mode depressif tout est autorisé et cela fonctionne bien
@++
Dernière modification par anonyme (22-11-2014 10:01:47)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par anonyme (22-11-2014 10:39:49)
Il vaut mieux montrer que raconter.
Hors ligne