Vous n'êtes pas identifié(e).
# pour autoriser la plateforme de jeux STEAM
# pour autoriser la plateforme de jeux STEAM
Dernière modification par anonyme (18-11-2014 02:47:00)
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
En ligne
Il vaut mieux montrer que raconter.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
1) je laisse 2 ligne forward pour l udp et 2 pour le tcp ou je compile 2 lignes sans preciser udp ou tcp
Comme tu veux pour que ça marche ; mais il veut toujours mieux préciser les choses.
2) pour steam je configure pour eth0 et eth1 (comme fait actuel ) ou eth1 suffit (fonctionne avec les 2 methodes , je garde la meilleure). et mes lignes sont correcte (hors tuto)
Je ferais comme ça :
Il me semble bien qu'il est inutile d'ajouter des règles pour DNS sur FORWARD, à condition de l'avoir autorisé sur INPUT et OUTPUT, et d'ouvrir le passage sur forward avec suivi de connexion.
Surtout après ces deux lignes :
Pourquoi suivre la connexion pour ce qui vient qui vient de ton réseau interne et non sur ce qui vient de l'interface web ?
Il me semble que serait mieux (as-tu essayé ?) :
En tout cas ça marche parfaitement dans mes tests comme proposé là.
Hors ligne
voila ce que j ai actuellement comme config et qui fonctionne
j ai dl des jeux a 512ko/s (pas essayer plus) , lancer steam puis half-life , puis half-life2 , je navigue sur le web
Pour les ip j ai repris celle du tuto (moi c est 192.168.10.0/24 )
bonne soirée et bon week
Dernière modification par anonyme (15-11-2014 20:35:15)
1) je laisse 2 ligne forward pour l udp et 2 pour le tcp ou je compile 2 lignes sans preciser udp ou tcp ?
2) pour steam je configure pour eth0 et eth1 (comme fait actuel ) ou eth1 suffit (fonctionne avec les 2 methodes , je garde la meilleure). et mes lignes sont correcte (hors tuto)
1) Cela ne fait pas la même chose. Dans le premier cas cela n'accepte que les protocoles TCP et UDP, dans le second cela accepte tous les protocoles (TCP, UDP, ICMP, SCTP, GRE...). A toi de décider ce que tu veux.
2) Qui est-ce qui fait du STEAM ? Le routeur ou la machine B ? Si c'est seulement la machine B, alors tes règles dans INPUT et OUTPUT ne servent à rien ; il faut des règles dans FORWARD, comme pour le DNS.
Et ce ne sont pas les seules règles qui me semblent douteuses. Il y a en plus un tas de RELATED qui ne servent à rien d'autre qu'alourdir les règles. Ce serait bien que tu expliques le besoin de ce jeu de règles.
Il vaut mieux montrer que raconter.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
RELATED - The connection is new, but is related to another connection already permitted.
qui n'arriverait pas en FTP, par exemple ?
RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.
Est-ce une aberration ?
Hors ligne
Dernière modification par anonyme (16-11-2014 14:09:39)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par anonyme (16-11-2014 16:30:09)
Dernière modification par raleur (16-11-2014 16:10:07)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par anonyme (16-11-2014 16:26:50)
Il n'y a pas de distinction de la source des paquets, donc cela limite aussi les communications entre processus locaux sur l'interface de loopback.
La limite de 1 connexion par seconde est beaucoup trop basse.
Je suppose que cette règle a pour objet d'accepter les paquets entrants d'une connexion de données FTP passive existante.
Mais il n'y a pas de règle correspondante dans OUTPUT acceptant les paquets émis de cette connexion, ni de règle dans INPUT ou OUTPUT acceptant les paquets NEW créant cette connexion, donc il n'y aura jamais de paquets ESTABLISHED et la connexion va échouer.
Cette règle a pour objet d'accepter les paquets entrants d'une connexion de données FTP active provenant d'un serveur FTP auquel le routeur s'est connecté comme client.
Mais il n'y a pas de règle correspondante dans OUTPUT acceptant les paquets émis en réponse, donc la connexion va échouer.
Cette règle a pour objet d'accepter les paquets entrants d'une connexion de commande FTP avec un serveur FTP auquel le routeur s'est connecté comme client. Ce type de paquet ne peut pas avoir l'état RELATED.
Mais il n'y a pas de règle correspondante dans OUTPUT acceptant les paquets NEW émis, donc il n'y aura jamais de paquets ESTABLISHED reçus en réponse.
Apparemment c'est pour se connecter en SSH au routeur par eth0. Mais la première règle est absurde : elle n'accepte que les paquets reçus par eth0 avec une adresse source du réseau B connecté à eth1.
Ces règles acceptent les requêtes DNS émises par le routeur vers le réseau A et internet et les réponses reçues. Ces paquets ne peuvent avoir l'état RELATED.
Ces paquets ne peuvent avoir l'état RELATED. Le routeur a besoin de se connecter à des serveurs HTTP, HTTPS, sur le port 8000 (quel service ?) et STEAM sur le réseau A ou internet ?
Cela accepte tout le trafic entre processus locaux, mais après la limitation contre le SYN flood.
Ces règles acceptent tous les paquets émis ou reçus entre le routeur et le réseau B. Toutes les règles suivantes (et les règles ACCEPT précédentes) relatives à eth1 dans INPUT et OUTPUT donc sont redondantes.
Ces règles acceptent les requêtes DNS émises par le routeur vers le réseau B et les réponses reçues. Ces paquets ne peuvent avoir l'état RELATED.
Il y a vraiment un serveur DNS sur le réseau B ?
Il y a des serveurs SSH dans le réseau B, avec lesquels le routeur a besoin de communiquer ?
Il est illogique de limiter l'adresse source dans les paquets de réponse entrants et de ne pas limiter l'adresse destination dans les paquets originels sortants. Cela signifie qu'on peut envoyer des requêtes mais refuser la réponse. Tu vas me rétorquer qu'il n'y a que des adresses en 192.168.10.0/24 sur eth1, mais alors pourquoi la vérifier dans un sens et pas dans l'autre ?
Ces paquets ne peuvent avoir l'état RELATED, sauf ceux avec le port source 20 pour les connexion de données FTP actives. 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 ?
Les paquets ICMP valides de ce type (echo reply) sont dans l'état ESTABLISHED, donc déjà acceptés par la règle précédente.
Les paquets ICMP valides de ce type (destination unreachable) ont l'état RELATED de même que tous autres les types d'erreur, donc sont déjà acceptés par la règle précédente.
Ce type (source quench) est obsolète et considéré comme dangereux, et a l'état RELATED donc est déjà accepté par la règle d'état précitée.
Les paquets ICMP valides de ce type (time exceeded) ont l'état RELATED.
Les paquets ICMP valides de ce type (parameter problem) ont l'état RELATED.
Avec une limite à 3 paquets par heure, ça ne va pas logger grand-chose...
Je ne refais pas le discours pour les ICMP émis (OUTPUT) et retransmis (FORWARD).
Tu devrais spécifier les états NEW,ESTABLISHED,RELATED et l'interface d'entrée dans la règle vers internet. Sans cela, les paquets arrivant par eth0 à destination d'internet sont acceptés, ce qui n'est pas forcément une bonne chose. Les paquets dans l'état INVALID sont aussi acceptés mais ne subiront pas le MASQUERADE qui ne fonctionne que sur les paquets appartenant à des connexions valides.
Pourquoi n'accepter que les connexions en TCP sur n'importe quel port depuis les machines du réseau B vers les machines du réseau A, et pas les autres protocoles comme UDP ?
Dernière modification par raleur (16-11-2014 22:38:53)
Il vaut mieux montrer que raconter.
Hors ligne
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
réponse :
ceci n existe plus dans iptables mit provisoirement pour retrouver le net (enlevé apres avoir autoriser tcp et udp entre les 2 cartes réseau)
cité : raleur
-A FORWARD -s 192.168.10.0/24 -i eth1 -o eth0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.10.0/24 -i eth0 -o eth1 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
Pourquoi n'accepter que les connexions en TCP sur n'importe quel port depuis les machines du réseau B vers les machines du réseau A, et pas les autres protocoles comme UDP ?
réponse
voila la solution que j ai appliqué dans mon iptables (retié le -p tcp )
-A FORWARD -s 192.168.10.0/24 -i eth1 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.10.0/24 -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
je modifie le post du haut au fur et a mesure de mes réponses (la ou je décrit mon réseau ).
j ai installé un proxy transparent , dhcp et ssh serveur sur eth1 (réseau B) , le réseau A ne connait pas le B (pas de routage)
le réseau A ne me sert qu a joindre la passerelle adls (et dns) , une imprimante réseau et le net bien sur.
le ping de A ver B ne passe pas , aucun services de B ne devrait etre vu de A (ssh , proxy , dhcp et peut etre dns si je l installe sur B ) .
voila pour une premiere explication
ensuite pour tes remarques , icmp est t il vraiment nécessaire ? si oui il faut donc l ameliorer
Dernière modification par anonyme (17-11-2014 20:28:30)
cité: raleur
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
Ce type (source quench) est obsolète et considéré comme dangereux, et a l'état RELATED donc est déjà accepté par la règle d'état précitée.
je commence a mettre à jour mon iptables , je vai etre déco
re
citer : raleur
-A INPUT -i eth1 -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --sport 21 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --sport 20 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth1 -p udp -m udp --dport 27000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --sport 27000 -m state --state RELATED,ESTABLISHED -j ACCEPT
-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
-A OUTPUT -o eth1 -p tcp -m multiport --dports 80,443,8000 -j ACCEPT
-A INPUT -i eth1 -p tcp -m multiport --sports 80,443,8000 -j ACCEPT
Ces paquets ne peuvent avoir l'état RELATED, sauf ceux avec le port source 20 pour les connexion de données FTP actives. 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 ?
Réponses :
oui tous ses services sont sur le réseau B
pour l instant , seulement ssh , dhcp et proy sont installés (sur la passerelle ) , 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 )
pour le DNS je sais pas si utile pour quelques machines actuellement , si ce n est pour tester
non aucun logiciel a l ecoute sur le port 8000
pour le port 8000 je sais pas , j ai copié betement , par contre j ai un programme (fah) sur chaque client qui utilise le port 8080 (en priorité envoie et reception de fichiers ) (fonctionne actuellement si tu peut m expliquer comment )
j ai modifié 8000 par 8080 pour mon logiciel fah
donc je retire les "RELATED" sur ce que tu a listé , sauf la regle du port 20
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 ?
idem pour dns eth0
citer raleur
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -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 A et internet et les réponses reçues. Ces paquets ne peuvent avoir l'état RELATED.
c est modifié
pour le ftp vu que je n en ai pas , regles supprimées , je ferai quelque chose de propre .
citer : raleur
-A INPUT -i eth0 -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ftp_in_accept
-A ftp_in_accept -p tcp -j ACCEPT
Je suppose que cette règle a pour objet d'accepter les paquets entrants d'une connexion de données FTP passive existante.
Mais il n'y a pas de règle correspondante dans OUTPUT acceptant les paquets émis de cette connexion, ni de règle dans INPUT ou OUTPUT acceptant les paquets NEW créant cette connexion, donc il n'y aura jamais de paquets ESTABLISHED et la connexion va échouer.
-A INPUT -i eth0 -p tcp -m tcp --sport 20 -m state --state RELATED,ESTABLISHED -j ftp_in_accept
Cette règle a pour objet d'accepter les paquets entrants d'une connexion de données FTP active provenant d'un serveur FTP auquel le routeur s'est connecté comme client.
Mais il n'y a pas de règle correspondante dans OUTPUT acceptant les paquets émis en réponse, donc la connexion va échouer.
-A INPUT -i eth0 -p tcp -m tcp --sport 21 -m state --state RELATED,ESTABLISHED -j ftp_in_accept
Cette règle a pour objet d'accepter les paquets entrants d'une connexion de commande FTP avec un serveur FTP auquel le routeur s'est connecté comme client. Ce type de paquet ne peut pas avoir l'état RELATED.
Mais il n'y a pas de règle correspondante dans OUTPUT acceptant les paquets NEW émis, donc il n'y aura jamais de paquets ESTABLISHED reçus en réponse.
regles retirées (quand meme tenir compte de la remarque de raleur pour le tuto du wiki du site afin d'avoir quelque chose de correct).
citer : raleur
-A OUTPUT -o eth1 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
Ces règles acceptent tous les paquets émis ou reçus entre le routeur et le réseau B. Toutes les règles suivantes (et les règles ACCEPT précédentes) relatives à eth1 dans INPUT et OUTPUT donc sont redondantes.
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 )
donc regle en attente de suppression la j ai un gros soucis.
citer : raleur
-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. Ces paquets ne peuvent avoir l'état RELATED.
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.)
je commente ces 2 lignes et je supprime RELATED
ça va de plus en plus mal , j ai commenté toutes les regles icmp pour l instant .
apres avoir commente icmp , ssh , dns inutile et avoir ajoute les regles mangle et nat pour le proxy , j aimerai comprendre pourquoi lorsque je supprime -A OUTPUT -o eth1 -j ACCEPT et -A INPUT -i eth1 -j ACCEPT je n ai plus de web ?
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
a moins que ce soit la redirection du DNAT pour le proxy du port 80
et je n ai pas modifié la table de routage serveur et client , mais le DNAT ce fait en interne de la passerelle entre le port 80 et 3129 , pour le client ça reste transparent port 80
je cherche et refaire un essaie sans les 2 lignes redondantes sur eth1
Dernière modification par anonyme (18-11-2014 01:44:01)
Il vaut mieux montrer que raconter.
Hors ligne
Objet : installer un pare-feu pour une passerelle
Niveau requis :
avisé
Commentaires : Fignoler le routage, installer un pare-feu sur une passerelle debian.
Débutant, à savoir : Utiliser GNU/Linux en ligne de commande, tout commence là !. :-)
Suivi :
à-tester, à-placer
Création par Hypathie 14/10/2014
Testé par <…> le <…>
#accepter le sous-réseau
/sbin/iptables -A INPUT -i eth1 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth1 -j ACCEPT
donc toutes les regles sur eth1 ne serve a rien ?
ps: je fais une pause et je reviens "cotcot" mon post
voila re j ai cot cot partout.....
il faut que tu regarde regle mangle et nat j ai ajoute des choses suite au proxy sur le post du départ ou je décrit mon reseau et mon iptables et je precise encore pas de routage dans table route (serveur ou client) donc le sous réseau B inconnu , juste nat qui permet d aiguiller les paquets (toutes les machines ont le dns 192.168.1.1 par défaut)
avec "accepter le sous réseau" tout est fonctionnel , je trouve le proxy un peu lent mais il doit y avoir des choses a ameliorer aussi sur sa config.
@++
Dernière modification par anonyme (18-11-2014 01:58:01)