Mon reseau 192.168.2.0/24 est-il inclu dans le 192.168.0.0/16 ?
22 réponses
User Sarge
Bonjour les IPistes :)
Voilà je suis en train de vérifier un script sur un firewall qui
contient la ligne suivante :
iptables -A -s 192.168.0.0/16 -i ppp0 -j DROP # class C reserved
Ce qui se traduis par :
Rajouter la règle qui dit que : tous les paquets du reseau 192.168 en
provenance de l'interface ppp0 ( ce qui est grave louche puisque c'est
internet ), sont "droppés".
Mon 1er LAN est en 192.168.1.0/24 le deuxième en 192.168.2.0/24 ils ne
semblent pas concernés par cette règle, puisqu'ils représentent des
réseaux IP différents.
L'usage de rp_filter peut être intéressant à cet égard mais il ne permet la journalisation à l'inverse d'un ensemble de règles iptables équivalentes.
A ce propos j'avais demandé il y a quelques temps dans fcs si l'usage de rp_filter était aussi fiable que des règles iptables, la question était restée sans réponse.
Il suffit d'activer la journalisation des p'tits bonshommes gris :
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ? Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de connaître leur origine.
Interdire également l'icmp redirect tant qu'à faire.
Quel est le risque réel de les accepter avec une connexion internet de type PPP ? L'adresse de routeur de remplacement ne sera normalement acceptée que si elle appartient à une destination joignable directement qui ne peut être que son pair PPP (déjà par défaut) ou une adresse du LAN.
Et puis tant qu'à fait, refuser aussi d'en envoyer :
Sur l'interface LAN, ça peut être utile de les laisser, non ?
Salut,
Cedric Blancher wrote:
L'usage de rp_filter peut être intéressant à cet égard mais il ne permet la
journalisation à l'inverse d'un ensemble de règles iptables équivalentes.
A ce propos j'avais demandé il y a quelques temps dans fcs si l'usage de
rp_filter était aussi fiable que des règles iptables, la question était
restée sans réponse.
Il suffit d'activer la journalisation des p'tits bonshommes gris :
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ?
Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de
connaître leur origine.
Interdire également l'icmp redirect tant qu'à faire.
Quel est le risque réel de les accepter avec une connexion internet de
type PPP ? L'adresse de routeur de remplacement ne sera normalement
acceptée que si elle appartient à une destination joignable directement
qui ne peut être que son pair PPP (déjà par défaut) ou une adresse du LAN.
Et puis tant qu'à fait, refuser aussi d'en envoyer :
L'usage de rp_filter peut être intéressant à cet égard mais il ne permet la journalisation à l'inverse d'un ensemble de règles iptables équivalentes.
A ce propos j'avais demandé il y a quelques temps dans fcs si l'usage de rp_filter était aussi fiable que des règles iptables, la question était restée sans réponse.
Il suffit d'activer la journalisation des p'tits bonshommes gris :
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ? Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de connaître leur origine.
Interdire également l'icmp redirect tant qu'à faire.
Quel est le risque réel de les accepter avec une connexion internet de type PPP ? L'adresse de routeur de remplacement ne sera normalement acceptée que si elle appartient à une destination joignable directement qui ne peut être que son pair PPP (déjà par défaut) ou une adresse du LAN.
Et puis tant qu'à fait, refuser aussi d'en envoyer :
Sur l'interface LAN, ça peut être utile de les laisser, non ?
Cedric Blancher
Le Thu, 02 Dec 2004 13:23:34 +0100, a écrit :
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ?
Quel est l'intérêt de loguer des à part savoir que ça remonte des informations ?
Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de connaître leur origine.
Comme pour tout paquet venant d'un autre réseau que le réseau attaché, puisqu'alors l'adresse MAC de la trame sera celle de la dernière passerelle...
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects Sur l'interface LAN, ça peut être utile de les laisser, non ?
Tes tables de routage internes sont à ce point mal faites que tu as besoin de les corriger à coups de redirect ?
--
Si t'est en manque de copine, c'est pas comme ça que tu vas le résoudre :) Na, ça va aller. Je suis marié avec plusieurs ordinateurs déjà. Pas le temps
pour des trucs organiques avec lesquels faut argumenter la moindre décision :-) -+- AL in GFA : "Mauvaise transplantation d'organes" -+-
Le Thu, 02 Dec 2004 13:23:34 +0100, Pascal@plouf a écrit :
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ?
Quel est l'intérêt de loguer des à part savoir que ça remonte des
informations ?
Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de
connaître leur origine.
Comme pour tout paquet venant d'un autre réseau que le réseau attaché,
puisqu'alors l'adresse MAC de la trame sera celle de la dernière
passerelle...
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
Sur l'interface LAN, ça peut être utile de les laisser, non ?
Tes tables de routage internes sont à ce point mal faites que tu as
besoin de les corriger à coups de redirect ?
--
Si t'est en manque de copine, c'est pas comme ça que tu vas le résoudre :)
Na, ça va aller. Je suis marié avec plusieurs ordinateurs déjà. Pas le temps
pour des trucs organiques avec lesquels faut argumenter la moindre décision :-)
-+- AL in GFA : "Mauvaise transplantation d'organes" -+-
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ?
Quel est l'intérêt de loguer des à part savoir que ça remonte des informations ?
Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de connaître leur origine.
Comme pour tout paquet venant d'un autre réseau que le réseau attaché, puisqu'alors l'adresse MAC de la trame sera celle de la dernière passerelle...
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects Sur l'interface LAN, ça peut être utile de les laisser, non ?
Tes tables de routage internes sont à ce point mal faites que tu as besoin de les corriger à coups de redirect ?
--
Si t'est en manque de copine, c'est pas comme ça que tu vas le résoudre :) Na, ça va aller. Je suis marié avec plusieurs ordinateurs déjà. Pas le temps
pour des trucs organiques avec lesquels faut argumenter la moindre décision :-) -+- AL in GFA : "Mauvaise transplantation d'organes" -+-
Pascal
Cedric Blancher wrote:
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ?
Quel est l'intérêt de loguer des
Des quoi ?
à part savoir que ça remonte des informations ?
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets martiens, mais on le savait déjà sans log. Quelle information supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de connaître leur origine.
Comme pour tout paquet venant d'un autre réseau que le réseau attaché, puisqu'alors l'adresse MAC de la trame sera celle de la dernière passerelle...
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine qui fait la maligne.
Sur l'interface LAN, ça peut être utile de les laisser, non ?
Tes tables de routage internes sont à ce point mal faites que tu as besoin de les corriger à coups de redirect ?
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Cedric Blancher wrote:
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ?
Quel est l'intérêt de loguer des
Des quoi ?
à part savoir que ça remonte des informations ?
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets
martiens, mais on le savait déjà sans log. Quelle information
supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de
connaître leur origine.
Comme pour tout paquet venant d'un autre réseau que le réseau attaché,
puisqu'alors l'adresse MAC de la trame sera celle de la dernière
passerelle...
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine
qui fait la maligne.
Sur l'interface LAN, ça peut être utile de les laisser, non ?
Tes tables de routage internes sont à ce point mal faites que tu as
besoin de les corriger à coups de redirect ?
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le
même lien ethernet. Les redirects émis par la passerelle par défaut sont
alors bien pratiques pour éviter de modifier à la main les tables de
routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur
sans protocole de routage :)
Quel est l'intérêt de logger ces paquets, à part savoir qu'il y en a ?
Quel est l'intérêt de loguer des
Des quoi ?
à part savoir que ça remonte des informations ?
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets martiens, mais on le savait déjà sans log. Quelle information supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Ceux qui arrivent par ppp0 n'ont pas d'adresse MAC, donc impossible de connaître leur origine.
Comme pour tout paquet venant d'un autre réseau que le réseau attaché, puisqu'alors l'adresse MAC de la trame sera celle de la dernière passerelle...
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine qui fait la maligne.
Sur l'interface LAN, ça peut être utile de les laisser, non ?
Tes tables de routage internes sont à ce point mal faites que tu as besoin de les corriger à coups de redirect ?
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Cedric Blancher
Le Thu, 02 Dec 2004 13:58:09 +0100, a écrit :
Des quoi ?
Paquets :)
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets martiens, mais on le savait déjà sans log. Quelle information supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Comment tu sais qu'il y en a si tu ne logues pas ?
Pour rejoindre la problématique soulevée par Dominique, le logging par Netfilter sera plus parlant que celui du log_martians, voire complet si on utilise ULOG.
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine qui fait la maligne.
Et ? Donc tu lui trouves une utilité sur certaines interfaces ? Pourquoi faire un exception pour ppp0 ? Je veux dire, lorsque tu vas lancer ton script pour placer ces paramètres, qu'est-ce que tu gagnes à faire un branch pour ne pas le faire pour les interfaces PPP ? Idem pour des règles Netfilter d'ailleurs...
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Je ne vois vraiment pas où est le problème. Pourquoi l'IP que tes machines ont comme passerelle par défaut ne pointerait-elle pas vers la vraie passerelle par défaut ?
-- BOFH excuse #299:
The data on your hard drive is out of balance.
Le Thu, 02 Dec 2004 13:58:09 +0100, Pascal@plouf a écrit :
Des quoi ?
Paquets :)
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets
martiens, mais on le savait déjà sans log. Quelle information
supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Comment tu sais qu'il y en a si tu ne logues pas ?
Pour rejoindre la problématique soulevée par Dominique, le logging par
Netfilter sera plus parlant que celui du log_martians, voire complet si on
utilise ULOG.
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine
qui fait la maligne.
Et ? Donc tu lui trouves une utilité sur certaines interfaces ? Pourquoi
faire un exception pour ppp0 ? Je veux dire, lorsque tu vas lancer ton
script pour placer ces paramètres, qu'est-ce que tu gagnes à faire un
branch pour ne pas le faire pour les interfaces PPP ? Idem pour des
règles Netfilter d'ailleurs...
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le
même lien ethernet. Les redirects émis par la passerelle par défaut
sont alors bien pratiques pour éviter de modifier à la main les tables
de routage de toutes les machines. Ce n'est qu'un petit réseau
d'amateur sans protocole de routage :)
Je ne vois vraiment pas où est le problème. Pourquoi l'IP que tes
machines ont comme passerelle par défaut ne pointerait-elle pas vers la
vraie passerelle par défaut ?
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets martiens, mais on le savait déjà sans log. Quelle information supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Comment tu sais qu'il y en a si tu ne logues pas ?
Pour rejoindre la problématique soulevée par Dominique, le logging par Netfilter sera plus parlant que celui du log_martians, voire complet si on utilise ULOG.
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine qui fait la maligne.
Et ? Donc tu lui trouves une utilité sur certaines interfaces ? Pourquoi faire un exception pour ppp0 ? Je veux dire, lorsque tu vas lancer ton script pour placer ces paramètres, qu'est-ce que tu gagnes à faire un branch pour ne pas le faire pour les interfaces PPP ? Idem pour des règles Netfilter d'ailleurs...
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Je ne vois vraiment pas où est le problème. Pourquoi l'IP que tes machines ont comme passerelle par défaut ne pointerait-elle pas vers la vraie passerelle par défaut ?
-- BOFH excuse #299:
The data on your hard drive is out of balance.
T0t0
"" wrote in message news:con3el$2av0$
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Oui, mais là, tu laisses la possibilité à n'importe quel utilisateur interne de faire passer le traffic par sa machine (même si le arp cache poisonning cher à Cédric ferait l'affaire ;-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Pascal@plouf" <pascal@plouf.invalid> wrote in message
news:con3el$2av0$1@biggoron.nerim.net
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le
même lien ethernet. Les redirects émis par la passerelle par défaut sont
alors bien pratiques pour éviter de modifier à la main les tables de
routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur
sans protocole de routage :)
Oui, mais là, tu laisses la possibilité à n'importe quel utilisateur
interne de faire passer le traffic par sa machine (même si le arp cache
poisonning cher à Cédric ferait l'affaire ;-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Oui, mais là, tu laisses la possibilité à n'importe quel utilisateur interne de faire passer le traffic par sa machine (même si le arp cache poisonning cher à Cédric ferait l'affaire ;-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Pascal
Cedric Blancher wrote:
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets martiens, mais on le savait déjà sans log. Quelle information supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Comment tu sais qu'il y en a si tu ne logues pas ?
Au début, je les ai loggés. J'ai vu qu'il y en avait régulièrement, puis j'ai arrêté.
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine qui fait la maligne.
Et ? Donc tu lui trouves une utilité sur certaines interfaces ?
Oui, bien sûr. Si cette interface ne débouche pas sur internet mais sur un réseau connu ou des machines qu'on connaît, on peut agir sur leur responsable pour faire cesser le "trouble".
Pourquoi faire un exception pour ppp0 ?
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas identifiable.
Je veux dire, lorsque tu vas lancer ton script pour placer ces paramètres, qu'est-ce que tu gagnes à faire un branch pour ne pas le faire pour les interfaces PPP ?
Je choisis de logger un type de paquet sur une interface spécifique si je trouve un intérêt à le faire. Comme expliqué plus haut, je n'en vois aucun à logger les paquets martiens sur une interface PPP qui reçoit le trafic d'internet.
Idem pour des règles Netfilter d'ailleurs...
Je le fais déjà par force pour mes règles iptables : toutes les règles concernant les interfaces PPP sont créées/supprimées par des scripts lancés par ip-up et ip-down. Je ne peux pas utiliser "ppp+", car mes différentes interfaces PPP ont des rôles différents et donc des règles iptables spécifiques. Et je ne peux pas compter sur l'ordre de création de ces interfaces pour déterminer leurs noms.
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Je ne vois vraiment pas où est le problème. Pourquoi l'IP que tes machines ont comme passerelle par défaut ne pointerait-elle pas vers la vraie passerelle par défaut ?
Les machines ont la bonne passerelle :) mais pas de route directe déclarée vers l'autre sous-réseau. Elles utilisent donc la passerelle de leur route par défaut. Sans redirect, tout le trafic entre les deux sous-réseaux passe inutilement par la passerelle. Si par contre le premier paquet émis par une machine d'un sous-réseau à une machine de l'autre via la passerelle par défaut déclenche l'envoi par la passerelle d'un ICMP redirect à la machine émettrice et que celle-ci en tient compte, les paquets suivants seront envoyés directement à la machine destinataire.
Cedric Blancher wrote:
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets
martiens, mais on le savait déjà sans log. Quelle information
supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Comment tu sais qu'il y en a si tu ne logues pas ?
Au début, je les ai loggés. J'ai vu qu'il y en avait régulièrement, puis
j'ai arrêté.
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine
qui fait la maligne.
Et ? Donc tu lui trouves une utilité sur certaines interfaces ?
Oui, bien sûr. Si cette interface ne débouche pas sur internet mais sur
un réseau connu ou des machines qu'on connaît, on peut agir sur leur
responsable pour faire cesser le "trouble".
Pourquoi faire un exception pour ppp0 ?
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir
de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas
identifiable.
Je veux dire, lorsque tu vas lancer ton
script pour placer ces paramètres, qu'est-ce que tu gagnes à faire un
branch pour ne pas le faire pour les interfaces PPP ?
Je choisis de logger un type de paquet sur une interface spécifique si
je trouve un intérêt à le faire. Comme expliqué plus haut, je n'en vois
aucun à logger les paquets martiens sur une interface PPP qui reçoit le
trafic d'internet.
Idem pour des règles Netfilter d'ailleurs...
Je le fais déjà par force pour mes règles iptables : toutes les règles
concernant les interfaces PPP sont créées/supprimées par des scripts
lancés par ip-up et ip-down. Je ne peux pas utiliser "ppp+", car mes
différentes interfaces PPP ont des rôles différents et donc des règles
iptables spécifiques. Et je ne peux pas compter sur l'ordre de création
de ces interfaces pour déterminer leurs noms.
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le
même lien ethernet. Les redirects émis par la passerelle par défaut
sont alors bien pratiques pour éviter de modifier à la main les tables
de routage de toutes les machines. Ce n'est qu'un petit réseau
d'amateur sans protocole de routage :)
Je ne vois vraiment pas où est le problème. Pourquoi l'IP que tes
machines ont comme passerelle par défaut ne pointerait-elle pas vers la
vraie passerelle par défaut ?
Les machines ont la bonne passerelle :) mais pas de route directe
déclarée vers l'autre sous-réseau. Elles utilisent donc la passerelle de
leur route par défaut. Sans redirect, tout le trafic entre les deux
sous-réseaux passe inutilement par la passerelle. Si par contre le
premier paquet émis par une machine d'un sous-réseau à une machine de
l'autre via la passerelle par défaut déclenche l'envoi par la passerelle
d'un ICMP redirect à la machine émettrice et que celle-ci en tient
compte, les paquets suivants seront envoyés directement à la machine
destinataire.
Bon, je précise ma pensée. Les logs diront qu'il y a des paquets martiens, mais on le savait déjà sans log. Quelle information supplémentaire cela apporte-t-il, et quelle action peut en dépendre ?
Comment tu sais qu'il y en a si tu ne logues pas ?
Au début, je les ai loggés. J'ai vu qu'il y en avait régulièrement, puis j'ai arrêté.
Au moins on connait l'adresse MAC de cette passerelle, ou de la machine qui fait la maligne.
Et ? Donc tu lui trouves une utilité sur certaines interfaces ?
Oui, bien sûr. Si cette interface ne débouche pas sur internet mais sur un réseau connu ou des machines qu'on connaît, on peut agir sur leur responsable pour faire cesser le "trouble".
Pourquoi faire un exception pour ppp0 ?
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas identifiable.
Je veux dire, lorsque tu vas lancer ton script pour placer ces paramètres, qu'est-ce que tu gagnes à faire un branch pour ne pas le faire pour les interfaces PPP ?
Je choisis de logger un type de paquet sur une interface spécifique si je trouve un intérêt à le faire. Comme expliqué plus haut, je n'en vois aucun à logger les paquets martiens sur une interface PPP qui reçoit le trafic d'internet.
Idem pour des règles Netfilter d'ailleurs...
Je le fais déjà par force pour mes règles iptables : toutes les règles concernant les interfaces PPP sont créées/supprimées par des scripts lancés par ip-up et ip-down. Je ne peux pas utiliser "ppp+", car mes différentes interfaces PPP ont des rôles différents et donc des règles iptables spécifiques. Et je ne peux pas compter sur l'ordre de création de ces interfaces pour déterminer leurs noms.
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Je ne vois vraiment pas où est le problème. Pourquoi l'IP que tes machines ont comme passerelle par défaut ne pointerait-elle pas vers la vraie passerelle par défaut ?
Les machines ont la bonne passerelle :) mais pas de route directe déclarée vers l'autre sous-réseau. Elles utilisent donc la passerelle de leur route par défaut. Sans redirect, tout le trafic entre les deux sous-réseaux passe inutilement par la passerelle. Si par contre le premier paquet émis par une machine d'un sous-réseau à une machine de l'autre via la passerelle par défaut déclenche l'envoi par la passerelle d'un ICMP redirect à la machine émettrice et que celle-ci en tient compte, les paquets suivants seront envoyés directement à la machine destinataire.
Pascal
T0t0 wrote:
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Oui, mais là, tu laisses la possibilité à n'importe quel utilisateur interne de faire passer le traffic par sa machine (même si le arp cache poisonning cher à Cédric ferait l'affaire ;-)
J'ai écrit "Ce n'est qu'un petit réseau d'amateur", à usage domestique privé. Pas un repaire de pirates :)
T0t0 wrote:
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le
même lien ethernet. Les redirects émis par la passerelle par défaut sont
alors bien pratiques pour éviter de modifier à la main les tables de
routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur
sans protocole de routage :)
Oui, mais là, tu laisses la possibilité à n'importe quel utilisateur
interne de faire passer le traffic par sa machine (même si le arp cache
poisonning cher à Cédric ferait l'affaire ;-)
J'ai écrit "Ce n'est qu'un petit réseau d'amateur", à usage domestique
privé. Pas un repaire de pirates :)
Je peux par exemple à l'occasion superposer deux sous-réseaux sur le même lien ethernet. Les redirects émis par la passerelle par défaut sont alors bien pratiques pour éviter de modifier à la main les tables de routage de toutes les machines. Ce n'est qu'un petit réseau d'amateur sans protocole de routage :)
Oui, mais là, tu laisses la possibilité à n'importe quel utilisateur interne de faire passer le traffic par sa machine (même si le arp cache poisonning cher à Cédric ferait l'affaire ;-)
J'ai écrit "Ce n'est qu'un petit réseau d'amateur", à usage domestique privé. Pas un repaire de pirates :)
Cedric Blancher
Le Thu, 02 Dec 2004 21:24:58 +0100, a écrit :
Oui, bien sûr. Si cette interface ne débouche pas sur internet mais sur un réseau connu ou des machines qu'on connaît, on peut agir sur leur responsable pour faire cesser le "trouble".
Pas un repaire de pirates, hein ?
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas identifiable.
Donc en gros, tu ne logues que ce que tu peux identifier. Personnellement, je logue le trafic que je n'aime pas. L'identification, c'est secondaire.
Les machines ont la bonne passerelle :) mais pas de route directe déclarée vers l'autre sous-réseau. Elles utilisent donc la passerelle de leur route par défaut. Sans redirect, tout le trafic entre les deux sous-réseaux passe inutilement par la passerelle. Si par contre le premier paquet émis par une machine d'un sous-réseau à une machine de l'autre via la passerelle par défaut déclenche l'envoi par la passerelle d'un ICMP redirect à la machine émettrice et que celle-ci en tient compte, les paquets suivants seront envoyés directement à la machine destinataire.
Un jour, il faudra que tu penses à revoir ton plan d'adressage, et tout passer en DHCP...
--
j'ai beau préparé une session express, elle ne se garde pas et qd je fais ouvrir je reçois toutes les cauchonneries des usa comment faire pour garder seulement les newgroupes qui m'interressent :-@ -+-TGV in : Guide du Neuneu d'Usenet - Yankee go home -+-
Le Thu, 02 Dec 2004 21:24:58 +0100, Pascal@plouf a écrit :
Oui, bien sûr. Si cette interface ne débouche pas sur internet mais sur
un réseau connu ou des machines qu'on connaît, on peut agir sur leur
responsable pour faire cesser le "trouble".
Pas un repaire de pirates, hein ?
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir
de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas
identifiable.
Donc en gros, tu ne logues que ce que tu peux identifier. Personnellement,
je logue le trafic que je n'aime pas. L'identification, c'est secondaire.
Les machines ont la bonne passerelle :) mais pas de route directe
déclarée vers l'autre sous-réseau. Elles utilisent donc la passerelle
de leur route par défaut. Sans redirect, tout le trafic entre les deux
sous-réseaux passe inutilement par la passerelle. Si par contre le
premier paquet émis par une machine d'un sous-réseau à une machine de
l'autre via la passerelle par défaut déclenche l'envoi par la
passerelle d'un ICMP redirect à la machine émettrice et que celle-ci
en tient compte, les paquets suivants seront envoyés directement à la
machine destinataire.
Un jour, il faudra que tu penses à revoir ton plan d'adressage, et tout
passer en DHCP...
--
j'ai beau préparé une session express, elle ne se garde pas et qd je
fais ouvrir je reçois toutes les cauchonneries des usa comment faire
pour garder seulement les newgroupes qui m'interressent :-@
-+-TGV in : Guide du Neuneu d'Usenet - Yankee go home -+-
Oui, bien sûr. Si cette interface ne débouche pas sur internet mais sur un réseau connu ou des machines qu'on connaît, on peut agir sur leur responsable pour faire cesser le "trouble".
Pas un repaire de pirates, hein ?
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas identifiable.
Donc en gros, tu ne logues que ce que tu peux identifier. Personnellement, je logue le trafic que je n'aime pas. L'identification, c'est secondaire.
Les machines ont la bonne passerelle :) mais pas de route directe déclarée vers l'autre sous-réseau. Elles utilisent donc la passerelle de leur route par défaut. Sans redirect, tout le trafic entre les deux sous-réseaux passe inutilement par la passerelle. Si par contre le premier paquet émis par une machine d'un sous-réseau à une machine de l'autre via la passerelle par défaut déclenche l'envoi par la passerelle d'un ICMP redirect à la machine émettrice et que celle-ci en tient compte, les paquets suivants seront envoyés directement à la machine destinataire.
Un jour, il faudra que tu penses à revoir ton plan d'adressage, et tout passer en DHCP...
--
j'ai beau préparé une session express, elle ne se garde pas et qd je fais ouvrir je reçois toutes les cauchonneries des usa comment faire pour garder seulement les newgroupes qui m'interressent :-@ -+-TGV in : Guide du Neuneu d'Usenet - Yankee go home -+-
Pierre LALET
wrote:
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas identifiable.
Parce que tu considères l'adresse MAC comme un identifiant fiable ?
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Pascal@plouf wrote:
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir
de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas
identifiable.
Parce que tu considères l'adresse MAC comme un identifiant fiable ?
pierre
--
Pierre LALET
http://pierre.droids-corp.org/
Droids Corporation & Team rstack
French Honeynet Project
Parce qu'ici c'est l'interface vers internet. Les paquets peuvent venir de n'importe où et n'ont pas d'adresse MAC, donc la source n'est pas identifiable.
Parce que tu considères l'adresse MAC comme un identifiant fiable ?
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Pascal
Pierre LALET wrote:
Parce que tu considères l'adresse MAC comme un identifiant fiable ?
Dans certains cas, oui.
Pierre LALET wrote:
Parce que tu considères l'adresse MAC comme un identifiant fiable ?
