Bonjour,
Je me suis, enfin, plongé corps et âme dans iptables.
Dans cette aventure, je suis tombé sur un patch netfilter (TTL) qui
rajoute une cible à iptables permettant de modifier à la volée la valeur
du TTL (entre autres).
Problème, je n'ai pas l'impression que celui-ci soit appliqué au noyau
Debian.
Mieux (pire ?), le paquet kernel-patch-ttl ne semble s'appliquer qu'au
noyau <= 2.4.24 et >=2.4.4. Or, Sarge est en 2.4.27 ou en 2.6
Ma question est donc la suivante: le patch étant dans le "base
repository" de patch-o-matic, est-il intégré d'office dans le noyau ou
y-a-t-il un problème dessus ?
Pour info, la commande suivante:
iptables -t mangle -A POSTROUTING -p all -j TTL --ttl-set 128
me renvoie:
iptables: No chain/target/match by that name
Je suis en noyau 2.6.
Merci de votre aide.
@+
JB
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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,
JB - DUF a écrit :
Je me suis, enfin, plongé corps et âme dans iptables.
Bravo o/
Dans cette aventure, je suis tombé sur un patch netfilter (TTL) qui rajoute une cible à iptables permettant de modifier à la volée la valeur du TTL (entre autres).
Que j'utilise pour compenser un bug bénin des LNS de mon FAI qui "oublient" de décrémenter le TTL dans un sens, de même que son équivalent HL (HOPLIMIT) en IPv6.
Problème, je n'ai pas l'impression que celui-ci soit appliqué au noyau Debian. Mieux (pire ?), le paquet kernel-patch-ttl ne semble s'appliquer qu'au noyau <= 2.4.24 et >=2.4.4. Or, Sarge est en 2.4.27 ou en 2.6
En effet.
Ma question est donc la suivante: le patch étant dans le "base repository" de patch-o-matic, est-il intégré d'office dans le noyau ou y-a-t-il un problème dessus ?
A ma connaissance il n'est pas intégré au noyau standard, du moins pas dans les 2.4 que j'utilise. Et je ne le vois pas dans le contenu des noyaux 2.6 de testing.
Je te suggère de faire comme moi : utiliser directement les patches contenus dans le patch-o-matic-ng qui s'appliquent à tous les noyaux 2.4 récents et 2.6.
Il faut *impérativement* piocher dans les "daily snapshots" http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/) et oublier les dernières versions stables du pom et du pom-ng car celles-ci sont vieilles et contiennent nombre de bugs. En particulier un bug affecte les cibles TTL et HL : l'option --dec-ttl incrémente le TTL au lieu de le décrémenter, idem pour l'option --dec-hl de HL en IPv6. Le bug est cependant trivial à corriger (un + à changer en -).
Un snapshot est publié chaque jour ou presque, mais ça ne veut pas dire qu'il y des changements chaque jour. J'en profite pour faire un peu de pub pour cette page que je mets à jour quasi-quotidiennement aussi :
qui liste les modifications du pom-ng au jour le jour. Ça ne dit pas en quoi consiste les changements mais juste quels sont les patches affectés.
Pour info, la commande suivante: iptables -t mangle -A POSTROUTING -p all -j TTL --ttl-set 128
C'est assez moyen pour faire des traceroutes, ça. :
me renvoie: iptables: No chain/target/match by that name
Je suis en noyau 2.6.
Vérifie si /lib/modules/<version>/kernel/net/ipv4/netfilter/ipt_TTL.ko (ou .o pour les 2.4) existe et/ou si le fichier de configuration du noyau /boot/config-<version> contient l'option CONFIG_IP_NF_TARGET_TTL=m ou y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
JB - DUF a écrit :
Je me suis, enfin, plongé corps et âme dans iptables.
Bravo o/
Dans cette aventure, je suis tombé sur un patch netfilter (TTL) qui
rajoute une cible à iptables permettant de modifier à la volée la valeur
du TTL (entre autres).
Que j'utilise pour compenser un bug bénin des LNS de mon FAI qui
"oublient" de décrémenter le TTL dans un sens, de même que son équivalent
HL (HOPLIMIT) en IPv6.
Problème, je n'ai pas l'impression que celui-ci soit appliqué au noyau
Debian.
Mieux (pire ?), le paquet kernel-patch-ttl ne semble s'appliquer qu'au
noyau <= 2.4.24 et >=2.4.4. Or, Sarge est en 2.4.27 ou en 2.6
En effet.
Ma question est donc la suivante: le patch étant dans le "base
repository" de patch-o-matic, est-il intégré d'office dans le noyau ou
y-a-t-il un problème dessus ?
A ma connaissance il n'est pas intégré au noyau standard, du moins pas
dans les 2.4 que j'utilise. Et je ne le vois pas dans le contenu des
noyaux 2.6 de testing.
Je te suggère de faire comme moi : utiliser directement les patches
contenus dans le patch-o-matic-ng qui s'appliquent à tous les noyaux 2.4
récents et 2.6.
Il faut *impérativement* piocher dans les "daily snapshots"
http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/) et oublier les
dernières versions stables du pom et du pom-ng car celles-ci sont
vieilles et contiennent nombre de bugs. En particulier un bug affecte les
cibles TTL et HL : l'option --dec-ttl incrémente le TTL au lieu de le
décrémenter, idem pour l'option --dec-hl de HL en IPv6. Le bug est
cependant trivial à corriger (un + à changer en -).
Un snapshot est publié chaque jour ou presque, mais ça ne veut pas dire
qu'il y des changements chaque jour. J'en profite pour faire un peu de
pub pour cette page que je mets à jour quasi-quotidiennement aussi :
qui liste les modifications du pom-ng au jour le jour. Ça ne dit pas en
quoi consiste les changements mais juste quels sont les patches affectés.
Pour info, la commande suivante:
iptables -t mangle -A POSTROUTING -p all -j TTL --ttl-set 128
C'est assez moyen pour faire des traceroutes, ça. :
me renvoie:
iptables: No chain/target/match by that name
Je suis en noyau 2.6.
Vérifie si /lib/modules/<version>/kernel/net/ipv4/netfilter/ipt_TTL.ko
(ou .o pour les 2.4) existe et/ou si le fichier de configuration du noyau
/boot/config-<version> contient l'option CONFIG_IP_NF_TARGET_TTL=m ou y.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Je me suis, enfin, plongé corps et âme dans iptables.
Bravo o/
Dans cette aventure, je suis tombé sur un patch netfilter (TTL) qui rajoute une cible à iptables permettant de modifier à la volée la valeur du TTL (entre autres).
Que j'utilise pour compenser un bug bénin des LNS de mon FAI qui "oublient" de décrémenter le TTL dans un sens, de même que son équivalent HL (HOPLIMIT) en IPv6.
Problème, je n'ai pas l'impression que celui-ci soit appliqué au noyau Debian. Mieux (pire ?), le paquet kernel-patch-ttl ne semble s'appliquer qu'au noyau <= 2.4.24 et >=2.4.4. Or, Sarge est en 2.4.27 ou en 2.6
En effet.
Ma question est donc la suivante: le patch étant dans le "base repository" de patch-o-matic, est-il intégré d'office dans le noyau ou y-a-t-il un problème dessus ?
A ma connaissance il n'est pas intégré au noyau standard, du moins pas dans les 2.4 que j'utilise. Et je ne le vois pas dans le contenu des noyaux 2.6 de testing.
Je te suggère de faire comme moi : utiliser directement les patches contenus dans le patch-o-matic-ng qui s'appliquent à tous les noyaux 2.4 récents et 2.6.
Il faut *impérativement* piocher dans les "daily snapshots" http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/) et oublier les dernières versions stables du pom et du pom-ng car celles-ci sont vieilles et contiennent nombre de bugs. En particulier un bug affecte les cibles TTL et HL : l'option --dec-ttl incrémente le TTL au lieu de le décrémenter, idem pour l'option --dec-hl de HL en IPv6. Le bug est cependant trivial à corriger (un + à changer en -).
Un snapshot est publié chaque jour ou presque, mais ça ne veut pas dire qu'il y des changements chaque jour. J'en profite pour faire un peu de pub pour cette page que je mets à jour quasi-quotidiennement aussi :
qui liste les modifications du pom-ng au jour le jour. Ça ne dit pas en quoi consiste les changements mais juste quels sont les patches affectés.
Pour info, la commande suivante: iptables -t mangle -A POSTROUTING -p all -j TTL --ttl-set 128
C'est assez moyen pour faire des traceroutes, ça. :
me renvoie: iptables: No chain/target/match by that name
Je suis en noyau 2.6.
Vérifie si /lib/modules/<version>/kernel/net/ipv4/netfilter/ipt_TTL.ko (ou .o pour les 2.4) existe et/ou si le fichier de configuration du noyau /boot/config-<version> contient l'option CONFIG_IP_NF_TARGET_TTL=m ou y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal
Re,
a écrit :
Ma question est donc la suivante: le patch étant dans le "base repository" de patch-o-matic, est-il intégré d'office dans le noyau ou y-a-t-il un problème dessus ?
A ma connaissance il n'est pas intégré au noyau standard, du moins pas dans les 2.4 que j'utilise. Et je ne le vois pas dans le contenu des noyaux 2.6 de testing.
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Re,
Pascal@plouf a écrit :
Ma question est donc la suivante: le patch étant dans le "base
repository" de patch-o-matic, est-il intégré d'office dans le noyau ou
y-a-t-il un problème dessus ?
A ma connaissance il n'est pas intégré au noyau standard, du moins pas
dans les 2.4 que j'utilise. Et je ne le vois pas dans le contenu des
noyaux 2.6 de testing.
Précision : la position de l'équipe de développement de Netfilter est
clairement de ne pas intégrer le patch TTL dans les sources des noyaux
officiels, c'est exposé là (attention, URL long) :
Ma question est donc la suivante: le patch étant dans le "base repository" de patch-o-matic, est-il intégré d'office dans le noyau ou y-a-t-il un problème dessus ?
A ma connaissance il n'est pas intégré au noyau standard, du moins pas dans les 2.4 que j'utilise. Et je ne le vois pas dans le contenu des noyaux 2.6 de testing.
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
JB - DUF
a écrit : <SNIP...>
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
Bonsoir, Merci de ta réponse. Pour répondre à tes 2 mails (je sais, c'est pas top pour le suivi mais bon...):
J'avais vu que l'intégration de la cible TTL n'était pas conseillée par l'équipe de développement de Netfilter mais il s'agit ici autant de découvrir les capacités de Netfilter que de les faire découvrir: je mets au point une "formation" pour le boulot qui se veut générique sur les firewall. En l'occurence, il s'agit d'en montrer les capacités. Netfilter/Iptable me paraissait un bon exemple (c'est gratuit et puissant). L'idée de montrer la cible TTL est de prouver que l'on peut faire un début de normalisation de paquet (ne pas montrer le nombre de 'hop' du réseau interne par exemple).
Pour le reste, ben je vais sauter à pied joint sur pom-ng ;-) Merci pour les infos. @+ JB
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal@plouf a écrit :
<SNIP...>
Précision : la position de l'équipe de développement de Netfilter est
clairement de ne pas intégrer le patch TTL dans les sources des noyaux
officiels, c'est exposé là (attention, URL long) :
Bonsoir,
Merci de ta réponse.
Pour répondre à tes 2 mails (je sais, c'est pas top pour le suivi mais
bon...):
J'avais vu que l'intégration de la cible TTL n'était pas conseillée par
l'équipe de développement de Netfilter mais il s'agit ici autant de
découvrir les capacités de Netfilter que de les faire découvrir: je mets
au point une "formation" pour le boulot qui se veut générique sur les
firewall. En l'occurence, il s'agit d'en montrer les capacités.
Netfilter/Iptable me paraissait un bon exemple (c'est gratuit et
puissant). L'idée de montrer la cible TTL est de prouver que l'on peut
faire un début de normalisation de paquet (ne pas montrer le nombre de
'hop' du réseau interne par exemple).
Pour le reste, ben je vais sauter à pied joint sur pom-ng ;-)
Merci pour les infos.
@+
JB
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
Bonsoir, Merci de ta réponse. Pour répondre à tes 2 mails (je sais, c'est pas top pour le suivi mais bon...):
J'avais vu que l'intégration de la cible TTL n'était pas conseillée par l'équipe de développement de Netfilter mais il s'agit ici autant de découvrir les capacités de Netfilter que de les faire découvrir: je mets au point une "formation" pour le boulot qui se veut générique sur les firewall. En l'occurence, il s'agit d'en montrer les capacités. Netfilter/Iptable me paraissait un bon exemple (c'est gratuit et puissant). L'idée de montrer la cible TTL est de prouver que l'on peut faire un début de normalisation de paquet (ne pas montrer le nombre de 'hop' du réseau interne par exemple).
Pour le reste, ben je vais sauter à pied joint sur pom-ng ;-) Merci pour les infos. @+ JB
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Frédéric Massot
JB - DUF wrote:
L'idée de montrer la cible TTL est de prouver que l'on peut faire un début de normalisation de paquet (ne pas montrer le nombre de 'hop' du réseau interne par exemple).
Bonjour,
Je profite de ce fil pour poser quelques questions sur Netfilter et la normalisation de paquet :o)
- Qu'entend t'on par normalisation de paquet ? - Est-ce que Netfilter peut normaliser les paquets, je crois que IP Filter le peut ?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
JB - DUF wrote:
L'idée de montrer la cible TTL est de prouver que l'on peut
faire un début de normalisation de paquet (ne pas montrer le nombre de
'hop' du réseau interne par exemple).
Bonjour,
Je profite de ce fil pour poser quelques questions sur Netfilter et la
normalisation de paquet :o)
- Qu'entend t'on par normalisation de paquet ?
- Est-ce que Netfilter peut normaliser les paquets, je crois que IP
Filter le peut ?
L'idée de montrer la cible TTL est de prouver que l'on peut faire un début de normalisation de paquet (ne pas montrer le nombre de 'hop' du réseau interne par exemple).
Bonjour,
Je profite de ce fil pour poser quelques questions sur Netfilter et la normalisation de paquet :o)
- Qu'entend t'on par normalisation de paquet ? - Est-ce que Netfilter peut normaliser les paquets, je crois que IP Filter le peut ?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
David Dumortier
Le Thu May 26 2005 à 12:58:47PM +0200, dit :
Re,
[...]
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
Question : alors à quoi correspond/sert ipt_ttl.ko ?
-- David Dumortier
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Thu May 26 2005 à 12:58:47PM +0200, Pascal@plouf dit :
Re,
[...]
Précision : la position de l'équipe de développement de Netfilter est
clairement de ne pas intégrer le patch TTL dans les sources des noyaux
officiels, c'est exposé là (attention, URL long) :
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
Question : alors à quoi correspond/sert ipt_ttl.ko ?
-- David Dumortier
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal
David Dumortier a écrit :
Le Thu May 26 2005 à 12:58:47PM +0200, dit :
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
Question : alors à quoi correspond/sert ipt_ttl.ko ?
Ce module correspond à l'option du noyau CONFIG_IP_NF_MATCH_TTL et gère la concordance (ou "match") ttl. Celle-ci sert à sélectionner les paquets IP en fonction de leur TTL alors que le module ipt_TTL qui correspond à l'option CONFIG_IP_NF_TARGET_TTL gère la cible TTL qui sert à modifier le TTL du paquet. Cf. man iptables. Contrairement à la cible TTL, la concordance ttl est intégrée au noyau depuis longtemps.
Exemple :
iptables -m ttl --ttl 1 [...]
sélectionne les paquets ayant un TTL égal à 1.
Par convention, les concordances de Netfilter sont écrites en minuscules (state, ttl, tos, mark, mss...) alors que les cibles sont en majuscules (REJECT, TTL, TOS, MARK, TCPMSS...). Cela se retrouve dans le nom des modules du noyau ipt_*.(k)o et des bibliothèques d'iptables correspondantes libipt_*.so.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
David Dumortier a écrit :
Le Thu May 26 2005 à 12:58:47PM +0200, Pascal@plouf dit :
Précision : la position de l'équipe de développement de Netfilter est
clairement de ne pas intégrer le patch TTL dans les sources des noyaux
officiels, c'est exposé là (attention, URL long) :
Question : alors à quoi correspond/sert ipt_ttl.ko ?
Ce module correspond à l'option du noyau CONFIG_IP_NF_MATCH_TTL et gère
la concordance (ou "match") ttl. Celle-ci sert à sélectionner les paquets
IP en fonction de leur TTL alors que le module ipt_TTL qui correspond à
l'option CONFIG_IP_NF_TARGET_TTL gère la cible TTL qui sert à modifier le
TTL du paquet. Cf. man iptables. Contrairement à la cible TTL, la
concordance ttl est intégrée au noyau depuis longtemps.
Exemple :
iptables -m ttl --ttl 1 [...]
sélectionne les paquets ayant un TTL égal à 1.
Par convention, les concordances de Netfilter sont écrites en minuscules
(state, ttl, tos, mark, mss...) alors que les cibles sont en majuscules
(REJECT, TTL, TOS, MARK, TCPMSS...). Cela se retrouve dans le nom des
modules du noyau ipt_*.(k)o et des bibliothèques d'iptables
correspondantes libipt_*.so.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Précision : la position de l'équipe de développement de Netfilter est clairement de ne pas intégrer le patch TTL dans les sources des noyaux officiels, c'est exposé là (attention, URL long) :
Question : alors à quoi correspond/sert ipt_ttl.ko ?
Ce module correspond à l'option du noyau CONFIG_IP_NF_MATCH_TTL et gère la concordance (ou "match") ttl. Celle-ci sert à sélectionner les paquets IP en fonction de leur TTL alors que le module ipt_TTL qui correspond à l'option CONFIG_IP_NF_TARGET_TTL gère la cible TTL qui sert à modifier le TTL du paquet. Cf. man iptables. Contrairement à la cible TTL, la concordance ttl est intégrée au noyau depuis longtemps.
Exemple :
iptables -m ttl --ttl 1 [...]
sélectionne les paquets ayant un TTL égal à 1.
Par convention, les concordances de Netfilter sont écrites en minuscules (state, ttl, tos, mark, mss...) alors que les cibles sont en majuscules (REJECT, TTL, TOS, MARK, TCPMSS...). Cela se retrouve dans le nom des modules du noyau ipt_*.(k)o et des bibliothèques d'iptables correspondantes libipt_*.so.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
JB - DUF
Frédéric Massot a écrit :
JB - DUF wrote:
L'idée de montrer la cible TTL est de prouver que l'on peut faire un début de normalisation de paquet (ne pas montrer le nombre de 'hop' du réseau interne par exemple).
Bonjour,
Je profite de ce fil pour poser quelques questions sur Netfilter et la normalisation de paquet :o)
- Qu'entend t'on par normalisation de paquet ?
La normalisation de paquet, très rapidement, est l'opération qui consiste à modifier les paquets afin de les rendre les plus "anonymes" possible. Par exemple, en ce qui concerne le TTL qui est le point qui me préoccupe, lorsque ton paquet sort de ton réseau interne_super_bien_protégé_avec_plein_de_routeur, le TTL est décrementé d'autant de hop. L'idée est alors de modifier le TTL du paquet à la volée pour le faire sortir "comme neuf", c-a-d comme s'il n'y avait qu'une seule machine (le firewall) sur la connexion. Une autre application, mais là je ne crois pas qu'il y ait quoi que ce soit d'opérationnel, pourrait être de revoir les numéros de séquences TCP afin de masquer la présence d'un OS dnas les numéros de séquence TCP sont particulièrement prévisible (non, non, je ne donnerai aucun nom :-D ) Ca c'est pour le sens sortant. Mais cela peut avoir un intérêt pour le sens entrant car cela permet de définir un format de paquet précis (pas de fragmentation par exemple) en entrée, d'adapter au besoin les paquets, et d'avoir un réseau "plus propre"... en tout cas au contenu plus prévisible (mais pas forcément moins dangereux, cf. couche 7)
Enfin, dans les 2 sens, cela peut permettre de remettre à des valeurs par défaut des champs dont on sait qu'ils ne servent à rien... sauf de canal caché (payload d'icmp echo-request / reply par exemple) et donc, limiter la fuite d'information (cf. un des derniers MISC sur le sujet et je n'ai pas d'action chez eux ;-) )
Bref, le champ d'application est assez vaste et comme on s'y intéresse pas mal au boulot, je m'entraîne ;-)
- Est-ce que Netfilter peut normaliser les paquets, je crois que IP Filter le peut ?
Tout dépend ce qu'on sous-entend par normaliser, le champ d'application est très vaste (les champs des paquets aussi ;), cf. ci-dessus
@+ JB
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Frédéric Massot a écrit :
JB - DUF wrote:
L'idée de montrer la cible TTL est de prouver que l'on peut faire un
début de normalisation de paquet (ne pas montrer le nombre de 'hop' du
réseau interne par exemple).
Bonjour,
Je profite de ce fil pour poser quelques questions sur Netfilter et la
normalisation de paquet :o)
- Qu'entend t'on par normalisation de paquet ?
La normalisation de paquet, très rapidement, est l'opération qui
consiste à modifier les paquets afin de les rendre les plus "anonymes"
possible. Par exemple, en ce qui concerne le TTL qui est le point qui me
préoccupe, lorsque ton paquet sort de ton réseau
interne_super_bien_protégé_avec_plein_de_routeur, le TTL est décrementé
d'autant de hop. L'idée est alors de modifier le TTL du paquet à la
volée pour le faire sortir "comme neuf", c-a-d comme s'il n'y avait
qu'une seule machine (le firewall) sur la connexion.
Une autre application, mais là je ne crois pas qu'il y ait quoi que ce
soit d'opérationnel, pourrait être de revoir les numéros de séquences
TCP afin de masquer la présence d'un OS dnas les numéros de séquence TCP
sont particulièrement prévisible (non, non, je ne donnerai aucun nom :-D )
Ca c'est pour le sens sortant.
Mais cela peut avoir un intérêt pour le sens entrant car cela permet de
définir un format de paquet précis (pas de fragmentation par exemple) en
entrée, d'adapter au besoin les paquets, et d'avoir un réseau "plus
propre"... en tout cas au contenu plus prévisible (mais pas forcément
moins dangereux, cf. couche 7)
Enfin, dans les 2 sens, cela peut permettre de remettre à des valeurs
par défaut des champs dont on sait qu'ils ne servent à rien... sauf de
canal caché (payload d'icmp echo-request / reply par exemple) et donc,
limiter la fuite d'information (cf. un des derniers MISC sur le sujet et
je n'ai pas d'action chez eux ;-) )
Bref, le champ d'application est assez vaste et comme on s'y intéresse
pas mal au boulot, je m'entraîne ;-)
- Est-ce que Netfilter peut normaliser les paquets, je crois que IP
Filter le peut ?
Tout dépend ce qu'on sous-entend par normaliser, le champ d'application
est très vaste (les champs des paquets aussi ;), cf. ci-dessus
@+
JB
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
L'idée de montrer la cible TTL est de prouver que l'on peut faire un début de normalisation de paquet (ne pas montrer le nombre de 'hop' du réseau interne par exemple).
Bonjour,
Je profite de ce fil pour poser quelques questions sur Netfilter et la normalisation de paquet :o)
- Qu'entend t'on par normalisation de paquet ?
La normalisation de paquet, très rapidement, est l'opération qui consiste à modifier les paquets afin de les rendre les plus "anonymes" possible. Par exemple, en ce qui concerne le TTL qui est le point qui me préoccupe, lorsque ton paquet sort de ton réseau interne_super_bien_protégé_avec_plein_de_routeur, le TTL est décrementé d'autant de hop. L'idée est alors de modifier le TTL du paquet à la volée pour le faire sortir "comme neuf", c-a-d comme s'il n'y avait qu'une seule machine (le firewall) sur la connexion. Une autre application, mais là je ne crois pas qu'il y ait quoi que ce soit d'opérationnel, pourrait être de revoir les numéros de séquences TCP afin de masquer la présence d'un OS dnas les numéros de séquence TCP sont particulièrement prévisible (non, non, je ne donnerai aucun nom :-D ) Ca c'est pour le sens sortant. Mais cela peut avoir un intérêt pour le sens entrant car cela permet de définir un format de paquet précis (pas de fragmentation par exemple) en entrée, d'adapter au besoin les paquets, et d'avoir un réseau "plus propre"... en tout cas au contenu plus prévisible (mais pas forcément moins dangereux, cf. couche 7)
Enfin, dans les 2 sens, cela peut permettre de remettre à des valeurs par défaut des champs dont on sait qu'ils ne servent à rien... sauf de canal caché (payload d'icmp echo-request / reply par exemple) et donc, limiter la fuite d'information (cf. un des derniers MISC sur le sujet et je n'ai pas d'action chez eux ;-) )
Bref, le champ d'application est assez vaste et comme on s'y intéresse pas mal au boulot, je m'entraîne ;-)
- Est-ce que Netfilter peut normaliser les paquets, je crois que IP Filter le peut ?
Tout dépend ce qu'on sous-entend par normaliser, le champ d'application est très vaste (les champs des paquets aussi ;), cf. ci-dessus
@+ JB
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
