eBay PIRATE, faux formulaire PayPal

Stephane Catteau

06/06/2008 à 01:39

Sylvain SF n'était pas loin de dire :

Ou, dans le cas d'un réseau,

et dans le cas d'un non-réseau, discuter d'un serveur http
ou d'un fichier hosts aurait quel sens ??

Pas besoin d'un réseau pour communiquer avec le serveur HTTP en écoute
sur l'adresse de loopback. Même chose pour le fichier hosts qui doit
être configuré si le-dit serveur a des hôtes virtuels.
Cela dit, la plus part des lecteurs auront compris qu'il fallait lire
"réseau local", tellement il est évident que la discussion tourne
autour d'ordinateur reliés à un réseau global que l'on nomme internet.

configurer la passerelle pour envoyer un reset à toute connexion
vers cette adresse.

aucun intérêt, si ce n'est de plomber une config. déjà foireuse
(genre serveur http mal configuré).

Ah ? Voyons voir :

1) Renvoyer sur l'adresse de loopback par défaut (127.0.0.1) empèche
d'avoir un serveur HTTP en écoute sur la machine, ou force celui-ci à
renvoyer un code de statut 404 à chaque fois.
2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1

Ca fait déjà deux bonnes raisons.

3) Quelque soit la configuration et le système d'exploitation des
machines présentes sur le LAN, il suffit de copier le fichier host pour
que le filtrage soit effectif sur la machine, ce qui ne marche pas avec
l'adresse de loopback à cause des deux raisons précédentes.
4) Ca marche aussi avec un filtre IP situé sur la machine, il suffit
de lui dire de bloquer les paquets à destination de la-dite adresse IP
unique.
5) Hormis sur la passerelle elle-même, on n'a pas besoin de tenir
compte de cette politique de filtrage lorsque l'on modifie la
configuration des postes du LAN. Notament lorsque l'on y ajoute un
serveur HTTP pour bosser plus facilement.

Je suis sûr qu'en réfléchissant bien on pourrait en trouver d'autres.

Stephane Catteau

06/06/2008 à 01:40

Paul Gaborit n'était pas loin de dire :

Ou plus simplement, utiliser une autre adresse locale comme
127.0.100.13...
Oui, mais certains systèmes traitent tout 127/8 comme

l'adresse de loopback, Linux, par exemple, contrairement
à OpenBSD.

Bien sûr. Mais le serveur Web local, lui, n'écoute généralement que
sur 127.0.0.1. Il ne recevra donc pas les requêtes.

Ca dépend, je me souviens d'avoir vu passer une distrib Apache
configurée par défaut pour écouter sur 127/8.

Thierry B\.

06/06/2008 à 11:05

--{ Paul Gaborit a plopé ceci: }--

Oui, mais certains systèmes traitent tout 127/8 comme
l'adresse de loopback, Linux, par exemple, contrairement
à OpenBSD.

Bien sûr. Mais le serveur Web local, lui, n'écoute généralement que
sur 127.0.0.1. Il ne recevra donc pas les requêtes.

Je ne pense pas. Sur une Debian que j'ai ici, par défaut, on a:

:~$ head -3 /etc/apache2/sites-enabled/000-default
NameVirtualHost *
<VirtualHost *>

Et si je me souviens bien, c'est pareil dans Slackware.

--
Enhance your /karma/: use a _free_ operating system *NOW*

Sylvain SF

07/06/2008 à 03:20

Stephane Catteau wrote on 06/06/2008 01:39:

[..., ..., ...]

hmmm, le point énoncé par Olivier est bien: est-ce qu'un etc/host
rempli d'alias tous résolus par 127.0.0.1 n'est pas génant pour
un serveur http répondant sur 127.0.0.1; si j'ai bien compris.

ma réponse "serveur http mal configuré" ne te plait pas.

soit quelque chose m'échappe, soit un serveur du big-tinternet
ne réponds jamais sur 127.0.0.1, ni n'est une machine où l'on
butine en voulant éviter les fournisseurs pourris, un serveur
intranet sur un LAN non plus; le seul cas qui pourrait matcher
est la machine de Mme Michu sur laquelle son fils a installé
une mauvaise compile http-blog-slideshow-php et formant un
réseau d'une machine (hormi la truc-box dont personne ne sait
qu'elle sert de DHCP et gateway).

merci de m'instruire si j'ai oublié un cas digne d'intérêt,
pour l'heure je n'y vois d'un sujet troll hors charte et
sans aucun intérêt.

Ca fait déjà deux bonnes raisons.

donc non.

Sylvain.

Stephane Catteau

07/06/2008 à 16:39

Sylvain SF n'était pas loin de dire :

hmmm, le point énoncé par Olivier est bien: est-ce qu'un etc/host
rempli d'alias tous résolus par 127.0.0.1 n'est pas génant pour
un serveur http répondant sur 127.0.0.1; si j'ai bien compris.

La question est beaucoup plus précise qu'un simple "est-ce génant".
Olivier Miakinen s'interrogeait sur la possible surcharge du serveur
(et donc du système) et sur la possibilité que le serveur réponde à la
requête par l'envoie de données.
Mais au cas où tu ne l'aurais pas remarqué, il s'est passé plein de
choses depuis, lorsque je suis intervenu la discussion en était aux
autres méthodes de filtrage par le biais du fichier host.

ma réponse "serveur http mal configuré" ne te plait pas.

Disons que si tu veux répondre au message d'Olivier, fait le en
réponse au message d'Olivier, et non en réponse à mon message qui
traite d'autre chose.

soit quelque chose m'échappe, soit un serveur du big-tinternet
ne réponds jamais sur 127.0.0.1,

Quelque chose t'échappe. Le serveur peut parfaitement être configuré
pour que mod_status (ou l'équivalent si ce n'est pas un Apache) ne
réponde que sur l'interface de loopback.

ni n'est une machine où l'on butine en voulant éviter les fournisseurs
pourris, un serveur intranet sur un LAN non plus;

Ca se discute. Avec l'arrivé des dédiés à bas coût, certaines
personnes utilisent leur dédié comme serveur HTTP autant que comme
proxy pour eux-mêmes. C'est rare, mais ce n'est pas impossible. Quant à
ce qu'il en est des LAN, il y a nettement plus de machines qui font
serveur HTTP et proxy sur un LAN que de machine répondant au point
précédent.
Là où cela se discute, c'est évidement sur le fait qu'une telle
machine puisse ou non être considérée comme "butinant"

le seul cas qui pourrait matcher
est la machine de Mme Michu sur laquelle son fils a installé
une mauvaise compile http-blog-slideshow-php et formant un
réseau d'une machine (hormi la truc-box dont personne ne sait
qu'elle sert de DHCP et gateway).

Tu considères que le seul cas où la question "est-ce dérangeant si je
met 127.0.0.1 dans mon fichier host pour filtrer les sites de pub" est
la machine isolée d'un particulier dont le fils/mari/copain/frère
aurait installé par erreur un serveur HTTP dessus ?
C'est oublier tous les particuliers qui ont volontairement installé un
serveur HTTP sur leur machine pour créer tranquillement leur site, et
il suffit de jeter un oeil sur les statistiques de téléchargement de
sites comme easyphp pour se rendre compte qu'ils sont légion. C'est
oublier aussi que ce n'est pas parce que l'on dispose d'un LAN et d'un
serveur HTTP sur celui-ci que l'on n'a aucune raison d'installer un
serveur HTTP sur son poste de travail. S'affranchir du transfert vers
le serveur (via ftp, scp ou autre on s'en fiche) est un apport
indéniable du point de vue du confort, et il n'y a guère que les barbus
qui aiment écrire leurs pages sous Vi/Emacs par le biais d'une session
SSH. C'est oublier enfin que grâce aux box les réseaux familiaux sont
de plus en plus fréquent et que, bien qu'étant des LAN, ceux-ci ne sont
constitué que des postes de travail des différents membres de la
famille.

merci de m'instruire si j'ai oublié un cas digne d'intérêt,
pour l'heure je n'y vois d'un sujet troll hors charte et
sans aucun intérêt.

Serviteur.

Sylvain SF n'était pas loin de dire :

hmmm, le point énoncé par Olivier est bien: est-ce qu'un etc/host
rempli d'alias tous résolus par 127.0.0.1 n'est pas génant pour
un serveur http répondant sur 127.0.0.1; si j'ai bien compris.

La question est beaucoup plus précise qu'un simple "est-ce génant".
Olivier Miakinen s'interrogeait sur la possible surcharge du serveur
(et donc du système) et sur la possibilité que le serveur réponde à la
requête par l'envoie de données.
Mais au cas où tu ne l'aurais pas remarqué, il s'est passé plein de
choses depuis, lorsque je suis intervenu la discussion en était aux
autres méthodes de filtrage par le biais du fichier host.

ma réponse "serveur http mal configuré" ne te plait pas.

Disons que si tu veux répondre au message d'Olivier, fait le en
réponse au message d'Olivier, et non en réponse à mon message qui
traite d'autre chose.

soit quelque chose m'échappe, soit un serveur du big-tinternet
ne réponds jamais sur 127.0.0.1,

Quelque chose t'échappe. Le serveur peut parfaitement être configuré
pour que mod_status (ou l'équivalent si ce n'est pas un Apache) ne
réponde que sur l'interface de loopback.

ni n'est une machine où l'on butine en voulant éviter les fournisseurs
pourris, un serveur intranet sur un LAN non plus;

Ca se discute. Avec l'arrivé des dédiés à bas coût, certaines
personnes utilisent leur dédié comme serveur HTTP autant que comme
proxy pour eux-mêmes. C'est rare, mais ce n'est pas impossible. Quant à
ce qu'il en est des LAN, il y a nettement plus de machines qui font
serveur HTTP et proxy sur un LAN que de machine répondant au point
précédent.
Là où cela se discute, c'est évidement sur le fait qu'une telle
machine puisse ou non être considérée comme "butinant"

le seul cas qui pourrait matcher
est la machine de Mme Michu sur laquelle son fils a installé
une mauvaise compile http-blog-slideshow-php et formant un
réseau d'une machine (hormi la truc-box dont personne ne sait
qu'elle sert de DHCP et gateway).

Tu considères que le seul cas où la question "est-ce dérangeant si je
met 127.0.0.1 dans mon fichier host pour filtrer les sites de pub" est
la machine isolée d'un particulier dont le fils/mari/copain/frère
aurait installé par erreur un serveur HTTP dessus ?
C'est oublier tous les particuliers qui ont volontairement installé un
serveur HTTP sur leur machine pour créer tranquillement leur site, et
il suffit de jeter un oeil sur les statistiques de téléchargement de
sites comme easyphp pour se rendre compte qu'ils sont légion. C'est
oublier aussi que ce n'est pas parce que l'on dispose d'un LAN et d'un
serveur HTTP sur celui-ci que l'on n'a aucune raison d'installer un
serveur HTTP sur son poste de travail. S'affranchir du transfert vers
le serveur (via ftp, scp ou autre on s'en fiche) est un apport
indéniable du point de vue du confort, et il n'y a guère que les barbus
qui aiment écrire leurs pages sous Vi/Emacs par le biais d'une session
SSH. C'est oublier enfin que grâce aux box les réseaux familiaux sont
de plus en plus fréquent et que, bien qu'étant des LAN, ceux-ci ne sont
constitué que des postes de travail des différents membres de la
famille.

merci de m'instruire si j'ai oublié un cas digne d'intérêt,
pour l'heure je n'y vois d'un sujet troll hors charte et
sans aucun intérêt.

Serviteur.

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain SF n'était pas loin de dire :

hmmm, le point énoncé par Olivier est bien: est-ce qu'un etc/host
rempli d'alias tous résolus par 127.0.0.1 n'est pas génant pour
un serveur http répondant sur 127.0.0.1; si j'ai bien compris.

La question est beaucoup plus précise qu'un simple "est-ce génant".
Olivier Miakinen s'interrogeait sur la possible surcharge du serveur
(et donc du système) et sur la possibilité que le serveur réponde à la
requête par l'envoie de données.
Mais au cas où tu ne l'aurais pas remarqué, il s'est passé plein de
choses depuis, lorsque je suis intervenu la discussion en était aux
autres méthodes de filtrage par le biais du fichier host.

ma réponse "serveur http mal configuré" ne te plait pas.

Disons que si tu veux répondre au message d'Olivier, fait le en
réponse au message d'Olivier, et non en réponse à mon message qui
traite d'autre chose.

soit quelque chose m'échappe, soit un serveur du big-tinternet
ne réponds jamais sur 127.0.0.1,

Quelque chose t'échappe. Le serveur peut parfaitement être configuré
pour que mod_status (ou l'équivalent si ce n'est pas un Apache) ne
réponde que sur l'interface de loopback.

ni n'est une machine où l'on butine en voulant éviter les fournisseurs
pourris, un serveur intranet sur un LAN non plus;

Ca se discute. Avec l'arrivé des dédiés à bas coût, certaines
personnes utilisent leur dédié comme serveur HTTP autant que comme
proxy pour eux-mêmes. C'est rare, mais ce n'est pas impossible. Quant à
ce qu'il en est des LAN, il y a nettement plus de machines qui font
serveur HTTP et proxy sur un LAN que de machine répondant au point
précédent.
Là où cela se discute, c'est évidement sur le fait qu'une telle
machine puisse ou non être considérée comme "butinant"

le seul cas qui pourrait matcher
est la machine de Mme Michu sur laquelle son fils a installé
une mauvaise compile http-blog-slideshow-php et formant un
réseau d'une machine (hormi la truc-box dont personne ne sait
qu'elle sert de DHCP et gateway).

Tu considères que le seul cas où la question "est-ce dérangeant si je
met 127.0.0.1 dans mon fichier host pour filtrer les sites de pub" est
la machine isolée d'un particulier dont le fils/mari/copain/frère
aurait installé par erreur un serveur HTTP dessus ?
C'est oublier tous les particuliers qui ont volontairement installé un
serveur HTTP sur leur machine pour créer tranquillement leur site, et
il suffit de jeter un oeil sur les statistiques de téléchargement de
sites comme easyphp pour se rendre compte qu'ils sont légion. C'est
oublier aussi que ce n'est pas parce que l'on dispose d'un LAN et d'un
serveur HTTP sur celui-ci que l'on n'a aucune raison d'installer un
serveur HTTP sur son poste de travail. S'affranchir du transfert vers
le serveur (via ftp, scp ou autre on s'en fiche) est un apport
indéniable du point de vue du confort, et il n'y a guère que les barbus
qui aiment écrire leurs pages sous Vi/Emacs par le biais d'une session
SSH. C'est oublier enfin que grâce aux box les réseaux familiaux sont
de plus en plus fréquent et que, bien qu'étant des LAN, ceux-ci ne sont
constitué que des postes de travail des différents membres de la
famille.

merci de m'instruire si j'ai oublié un cas digne d'intérêt,
pour l'heure je n'y vois d'un sujet troll hors charte et
sans aucun intérêt.

Serviteur.

Pascal Hambourg

08/06/2008 à 13:36

Salut,

2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1

Jamais vu ça. Tu aurais un exemple ?

Thierry B\.

08/06/2008 à 14:26

--{ Pascal Hambourg a plopé ceci: }--

2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1

Jamais vu ça. Tu aurais un exemple ?

~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386
~ $ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 14:44:18 2008
~ $ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
telnet: connect to address 127.0.0.2: Network is unreachable

:/d2b/tth/Essais/Csound$ uname -a
Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux
:/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 13:48:12 2008
:/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
Connected to 127.0.0.2.
Sun Jun 8 13:48:21 2008

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

JKB

08/06/2008 à 14:42

Le 08-06-2008, à propos de
Re: Qui pirate qui ??,
Thierry B. écrivait dans fr.comp.securite :

--{ Pascal Hambourg a plopé ceci: }--

2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1

Jamais vu ça. Tu aurais un exemple ?

~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386
~ $ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 14:44:18 2008
~ $ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
telnet: connect to address 127.0.0.2: Network is unreachable

Même chose avec un NetBSD/sparc32.

:/d2b/tth/Essais/Csound$ uname -a
Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux
:/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 13:48:12 2008
:/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
Connected to 127.0.0.2.
Sun Jun 8 13:48:21 2008

Juste pour apporter de l'eau au moulin :

$ telnet 127.0.0.1
%TELNET-I-TRYING, Trying ... 127.0.0.1
%TELNET-E-CONNFAIL, Failed to connect to remote host
-SYSTEM-F-REJECT, connect to network object rejected
$ telnet 127.0.0.2
%TELNET-I-TRYING, Trying ... 127.0.0.2
Interrupt

$ show system
OpenVMS V7.3 on node ...
...
...

La question est donc : pourquoi Linux fait-il cela ? Le problème
vient du masque du loopback (255.0.0.0), mais quel est le
comportement 'officiel' ?

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Pascal Hambourg

08/06/2008 à 15:50

Thierry B. écrivait dans fr.comp.securite :

--{ Pascal Hambourg a plopé ceci: }--

2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1

Jamais vu ça. Tu aurais un exemple ?

~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386

C'est pas Linux, je zappe.

:/d2b/tth/Essais/Csound$ uname -a
Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux
:/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 13:48:12 2008
:/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
Connected to 127.0.0.2.
Sun Jun 8 13:48:21 2008

Et en quoi cela permet-il de conclure que Linux traduit 127.0.0.2 en
127.0.0.1 ? Tout ce que je vois, c'est une connexion à 127.0.0.2. Un
netstat montrerait une connexion à 127.0.0.2. Ce n'est pas comme lorsque
on spécifie 0.0.0.0 comme destination, que Linux traduit effectivement
en 127.0.0.1.

La question est donc : pourquoi Linux fait-il cela ? Le problème
vient du masque du loopback (255.0.0.0), mais quel est le
comportement 'officiel' ?

Lorsqu'on configure une adresse et un masque de sous-réseau IP à
l'interface de loopback, Linux considère que tout le sous-réseau est une
destination locale, et pas seulement l'adresse configurée. Donc quand on
configure 127.0.0.1/8 sur l'interface de loopback, tout 127.0.0.0/8 est
considéré comme une destination locale, et pas seulement 127.0.0.1. Par
conséquent une socket qui écoute sur 0.0.0.0 (toutes les adresses
locales) accepte les connexions sur n'importe quelle adresse dans
127.0.0.0/8. Si on configure 127.0.0.1/32 sur l'interface de loopback,
alors seule 127.0.0.1 sera une destination locale. Rien à voir avec une
quelconque traduction. Ce n'est pas un problème, c'est par conception.

Je pense qu'il n'y a pas de comportement officiel. RFC 3330 stipule
seulement :

" 127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback, but
no addresses within this block should ever appear on any network anywhere."

Thierry B. écrivait dans fr.comp.securite :

--{ Pascal Hambourg a plopé ceci: }--

2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1

Jamais vu ça. Tu aurais un exemple ?

tth@puce ~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386

C'est pas Linux, je zappe.

tth@flo:/d2b/tth/Essais/Csound$ uname -a
Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux
tth@flo:/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 13:48:12 2008
tth@flo:/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
Connected to 127.0.0.2.
Sun Jun 8 13:48:21 2008

Et en quoi cela permet-il de conclure que Linux traduit 127.0.0.2 en
127.0.0.1 ? Tout ce que je vois, c'est une connexion à 127.0.0.2. Un
netstat montrerait une connexion à 127.0.0.2. Ce n'est pas comme lorsque
on spécifie 0.0.0.0 comme destination, que Linux traduit effectivement
en 127.0.0.1.

La question est donc : pourquoi Linux fait-il cela ? Le problème
vient du masque du loopback (255.0.0.0), mais quel est le
comportement 'officiel' ?

Lorsqu'on configure une adresse et un masque de sous-réseau IP à
l'interface de loopback, Linux considère que tout le sous-réseau est une
destination locale, et pas seulement l'adresse configurée. Donc quand on
configure 127.0.0.1/8 sur l'interface de loopback, tout 127.0.0.0/8 est
considéré comme une destination locale, et pas seulement 127.0.0.1. Par
conséquent une socket qui écoute sur 0.0.0.0 (toutes les adresses
locales) accepte les connexions sur n'importe quelle adresse dans
127.0.0.0/8. Si on configure 127.0.0.1/32 sur l'interface de loopback,
alors seule 127.0.0.1 sera une destination locale. Rien à voir avec une
quelconque traduction. Ce n'est pas un problème, c'est par conception.

Je pense qu'il n'y a pas de comportement officiel. RFC 3330 stipule
seulement :

" 127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback, but
no addresses within this block should ever appear on any network anywhere."

Vous avez filtré cet utilisateur ! Consultez son message

Thierry B. écrivait dans fr.comp.securite :

--{ Pascal Hambourg a plopé ceci: }--

2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1

Jamais vu ça. Tu aurais un exemple ?

~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386

C'est pas Linux, je zappe.

:/d2b/tth/Essais/Csound$ uname -a
Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux
:/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 13:48:12 2008
:/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
Connected to 127.0.0.2.
Sun Jun 8 13:48:21 2008

Et en quoi cela permet-il de conclure que Linux traduit 127.0.0.2 en
127.0.0.1 ? Tout ce que je vois, c'est une connexion à 127.0.0.2. Un
netstat montrerait une connexion à 127.0.0.2. Ce n'est pas comme lorsque
on spécifie 0.0.0.0 comme destination, que Linux traduit effectivement
en 127.0.0.1.

La question est donc : pourquoi Linux fait-il cela ? Le problème
vient du masque du loopback (255.0.0.0), mais quel est le
comportement 'officiel' ?

Lorsqu'on configure une adresse et un masque de sous-réseau IP à
l'interface de loopback, Linux considère que tout le sous-réseau est une
destination locale, et pas seulement l'adresse configurée. Donc quand on
configure 127.0.0.1/8 sur l'interface de loopback, tout 127.0.0.0/8 est
considéré comme une destination locale, et pas seulement 127.0.0.1. Par
conséquent une socket qui écoute sur 0.0.0.0 (toutes les adresses
locales) accepte les connexions sur n'importe quelle adresse dans
127.0.0.0/8. Si on configure 127.0.0.1/32 sur l'interface de loopback,
alors seule 127.0.0.1 sera une destination locale. Rien à voir avec une
quelconque traduction. Ce n'est pas un problème, c'est par conception.

Je pense qu'il n'y a pas de comportement officiel. RFC 3330 stipule
seulement :

" 127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback, but
no addresses within this block should ever appear on any network anywhere."

Thierry B\.

08/06/2008 à 18:30

--{ Pascal Hambourg a plopé ceci: }--

Et en quoi cela permet-il de conclure que Linux traduit 127.0.0.2 en
127.0.0.1 ? Tout ce que je vois, c'est une connexion à 127.0.0.2. Un
netstat montrerait une connexion à 127.0.0.2. Ce n'est pas comme lorsque
on spécifie 0.0.0.0 comme destination, que Linux traduit effectivement
en 127.0.0.1.

Exact, je vais regarder de plus prèt. Effectivement, il va bien
en 127.0.0.2 et désolé pour le dérangement...

--
awk 'ORS=NR%10?"n":"nn"'

eBay PIRATE, faux formulaire PayPal

10 réponses

Veuillez sélectionner un problème