Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal
Salut,
J'ai 2 machines reliée par un routeur qui fonctionne sous Linux Fedora Core 4. Je passe mes règles de routage par le script qui suit
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.1.1 -j ACCEPT iptables -A FORWARD -d 192.168.1.1 -j ACCEPT
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT iptables -A FORWARD -d 10.0.0.2 -j DROP
Dans ce cas à partir de chaque machine je peux joindre l'autre en accès HTTP.
Avec le script suivant ça ne marche plus
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.1.1 -j ACCEPT iptables -A FORWARD -d 192.168.1.1 -j DROP
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT iptables -A FORWARD -d 10.0.0.2 -j ACCEPT
Pourquoi dans un sens et pas dans l'autre. Je vide les tables à chaque essai.
A cause de l'ordre des règles.
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Salut,
J'ai 2 machines reliée par un routeur qui fonctionne sous Linux Fedora Core
4.
Je passe mes règles de routage par le script qui suit
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.1.1 -j ACCEPT
iptables -A FORWARD -d 192.168.1.1 -j ACCEPT
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2 -j DROP
Dans ce cas à partir de chaque machine je peux joindre l'autre en accès
HTTP.
Avec le script suivant ça ne marche plus
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.1.1 -j ACCEPT
iptables -A FORWARD -d 192.168.1.1 -j DROP
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2 -j ACCEPT
Pourquoi dans un sens et pas dans l'autre. Je vide les tables à chaque
essai.
A cause de l'ordre des règles.
Dans le premier cas :
La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la
4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre
sens avant que la politique par défaut les bloque.
Dans le deuxième cas :
La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la
3ème puisse les accepter.
J'ai 2 machines reliée par un routeur qui fonctionne sous Linux Fedora Core 4. Je passe mes règles de routage par le script qui suit
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.1.1 -j ACCEPT iptables -A FORWARD -d 192.168.1.1 -j ACCEPT
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT iptables -A FORWARD -d 10.0.0.2 -j DROP
Dans ce cas à partir de chaque machine je peux joindre l'autre en accès HTTP.
Avec le script suivant ça ne marche plus
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.1.1 -j ACCEPT iptables -A FORWARD -d 192.168.1.1 -j DROP
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT iptables -A FORWARD -d 10.0.0.2 -j ACCEPT
Pourquoi dans un sens et pas dans l'autre. Je vide les tables à chaque essai.
A cause de l'ordre des règles.
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Thierry Michels
A cause de l'ordre des règles.
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel. Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à mettre en place non ? et dans ce cas quel est la parade ?
Merci pour l'info.
A cause de l'ordre des règles.
Dans le premier cas :
La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la
4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre
sens avant que la politique par défaut les bloque.
Dans le deuxième cas :
La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la
3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel.
Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à
mettre en place non ?
et dans ce cas quel est la parade ?
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel. Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à mettre en place non ? et dans ce cas quel est la parade ?
Merci pour l'info.
Pascal
A cause de l'ordre des règles.
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Correction : en fait la 2ème règle accepte les paquets dans l'autre sens, la troisième n'est pas nécessaire.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel. Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à mettre en place non ?
Quel genre de cas, par exemple ?
et dans ce cas quel est la parade ?
Ça dépend des cas. ;-)
A cause de l'ordre des règles.
Dans le premier cas :
La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la
4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre
sens avant que la politique par défaut les bloque.
Correction : en fait la 2ème règle accepte les paquets dans l'autre
sens, la troisième n'est pas nécessaire.
Dans le deuxième cas :
La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la
3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel.
Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à
mettre en place non ?
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Correction : en fait la 2ème règle accepte les paquets dans l'autre sens, la troisième n'est pas nécessaire.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel. Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à mettre en place non ?
Quel genre de cas, par exemple ?
et dans ce cas quel est la parade ?
Ça dépend des cas. ;-)
Thierry Michels
"" a écrit dans le message de news:43b6c628$0$7183$
A cause de l'ordre des règles.
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Correction : en fait la 2ème règle accepte les paquets dans l'autre sens, la troisième n'est pas nécessaire.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel. Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à
mettre en place non ?
Quel genre de cas, par exemple ? Je n'ai pas d'exemple en tête mais il y a certainement des méthodes pour
l'application de ces règles comme établir les règles pour les machines avant d'établir les règles pour les réseaux. Et une petite modification en début de liste peux ruiner tout le reste.
et dans ce cas quel est la parade ?
Ça dépend des cas. ;-)
"Pascal@plouf" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news:43b6c628$0$7183$636a15ce@news.free.fr...
A cause de l'ordre des règles.
Dans le premier cas :
La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la
4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre
sens avant que la politique par défaut les bloque.
Correction : en fait la 2ème règle accepte les paquets dans l'autre
sens, la troisième n'est pas nécessaire.
Dans le deuxième cas :
La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la
3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel.
Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles
à
mettre en place non ?
Quel genre de cas, par exemple ?
Je n'ai pas d'exemple en tête mais il y a certainement des méthodes pour
l'application de ces règles comme établir les règles pour les machines avant
d'établir les règles pour les réseaux.
Et une petite modification en début de liste peux ruiner tout le reste.
"" a écrit dans le message de news:43b6c628$0$7183$
A cause de l'ordre des règles.
Dans le premier cas : La 1ère règle accepte les paquets 192.168.1.1 -> 10.0.0.2 avant que la 4ème puisse les bloquer. La 3ème règle accepte les paquets dans l'autre sens avant que la politique par défaut les bloque.
Correction : en fait la 2ème règle accepte les paquets dans l'autre sens, la troisième n'est pas nécessaire.
Dans le deuxième cas : La 2ème règle bloque les paquet 10.0.0.2 -> 192.168.1.1 avant que la 3ème puisse les accepter.
Cest vrai, je ne pensais plus à ce traitement séquentiel. Compte tenu de cet ordre à respecter il doit y avoir des cas impossibles à
mettre en place non ?
Quel genre de cas, par exemple ? Je n'ai pas d'exemple en tête mais il y a certainement des méthodes pour
l'application de ces règles comme établir les règles pour les machines avant d'établir les règles pour les réseaux. Et une petite modification en début de liste peux ruiner tout le reste.
et dans ce cas quel est la parade ?
Ça dépend des cas. ;-)
Pascal Hambourg
Je n'ai pas d'exemple en tête mais il y a certainement des méthodes pour l'application de ces règles comme établir les règles pour les machines avant d'établir les règles pour les réseaux.
Quand il y a des exceptions à des règles générales, il faut traiter les cas particuliers avant le cas général. Après, c'est trop tard !
Par exemple, on veut accepter les paquets venant de 192.168.0.0/24 mais bloquer les paquets "spoofés", c'est-à-dire avec l'adresse source 192.168.0.1 de la machine elle-même :
iptables -A INPUT -i eth0 -s 192.168.0.1 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT
On peut aussi utiliser une chaîne utilisateur pour intercepter un cas général et y traiter les cas particuliers, avant d'appliquer le traitement général :
iptables -N user_chain iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j user_chain iptables -A user_chain -s 192.168.0.1 -j DROP iptables -A user_chain -j ACCEPT
Et une petite modification en début de liste peux ruiner tout le reste.
Effectivement, un jeu de règles est un ensemble cohérent et on ne peut pas s'amuser à insérer des règles n'importe où.
Je n'ai pas d'exemple en tête mais il y a certainement des méthodes pour
l'application de ces règles comme établir les règles pour les machines avant
d'établir les règles pour les réseaux.
Quand il y a des exceptions à des règles générales, il faut traiter les
cas particuliers avant le cas général. Après, c'est trop tard !
Par exemple, on veut accepter les paquets venant de 192.168.0.0/24 mais
bloquer les paquets "spoofés", c'est-à-dire avec l'adresse source
192.168.0.1 de la machine elle-même :
iptables -A INPUT -i eth0 -s 192.168.0.1 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT
On peut aussi utiliser une chaîne utilisateur pour intercepter un cas
général et y traiter les cas particuliers, avant d'appliquer le
traitement général :
iptables -N user_chain
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j user_chain
iptables -A user_chain -s 192.168.0.1 -j DROP
iptables -A user_chain -j ACCEPT
Et une petite modification en début de liste peux ruiner tout le reste.
Effectivement, un jeu de règles est un ensemble cohérent et on ne peut
pas s'amuser à insérer des règles n'importe où.
Je n'ai pas d'exemple en tête mais il y a certainement des méthodes pour l'application de ces règles comme établir les règles pour les machines avant d'établir les règles pour les réseaux.
Quand il y a des exceptions à des règles générales, il faut traiter les cas particuliers avant le cas général. Après, c'est trop tard !
Par exemple, on veut accepter les paquets venant de 192.168.0.0/24 mais bloquer les paquets "spoofés", c'est-à-dire avec l'adresse source 192.168.0.1 de la machine elle-même :
iptables -A INPUT -i eth0 -s 192.168.0.1 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT
On peut aussi utiliser une chaîne utilisateur pour intercepter un cas général et y traiter les cas particuliers, avant d'appliquer le traitement général :
iptables -N user_chain iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j user_chain iptables -A user_chain -s 192.168.0.1 -j DROP iptables -A user_chain -j ACCEPT
Et une petite modification en début de liste peux ruiner tout le reste.
Effectivement, un jeu de règles est un ensemble cohérent et on ne peut pas s'amuser à insérer des règles n'importe où.
