Bonjour à tous,
Comment cela se fait-il que je puisse consulter la
page http//172.31.0.1 en étant sur l'hôte M alors
que l'ip forwarding n'est même pas activé sur R ?
Bonjour à tous,
Comment cela se fait-il que je puisse consulter la
page http//172.31.0.1 en étant sur l'hôte M alors
que l'ip forwarding n'est même pas activé sur R ?
Bonjour à tous,
Comment cela se fait-il que je puisse consulter la
page http//172.31.0.1 en étant sur l'hôte M alors
que l'ip forwarding n'est même pas activé sur R ?
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Pour linux, tu peux configurer cette fonction avec iptables, ici un
exemple très simplifié et aux erreurs de syntaxe probables près :
iptables -I INPUT -i eth0 -d 192.168.0.0/24 -j ACCEPT
iptables -I INPUT -i eth1 -d 172.31.0.0/16 -j ACCEPT
iptables -I INPUT -j LOG --log-level 5 --log-prefix "Spoofing "
iptables -I INPUT -j DROP
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Pour linux, tu peux configurer cette fonction avec iptables, ici un
exemple très simplifié et aux erreurs de syntaxe probables près :
iptables -I INPUT -i eth0 -d 192.168.0.0/24 -j ACCEPT
iptables -I INPUT -i eth1 -d 172.31.0.0/16 -j ACCEPT
iptables -I INPUT -j LOG --log-level 5 --log-prefix "Spoofing "
iptables -I INPUT -j DROP
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Pour linux, tu peux configurer cette fonction avec iptables, ici un
exemple très simplifié et aux erreurs de syntaxe probables près :
iptables -I INPUT -i eth0 -d 192.168.0.0/24 -j ACCEPT
iptables -I INPUT -i eth1 -d 172.31.0.0/16 -j ACCEPT
iptables -I INPUT -j LOG --log-level 5 --log-prefix "Spoofing "
iptables -I INPUT -j DROP
Le 26/05/2014 08:34, Joe The Smoe a écrit :pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Ben zut alors. J'ai appris quelque chose. Je ne trouve vraiment
pas ça logique. Pour moi, si l'interface eth0 reçoit un paquet
à destination de l'IP de eth1 qui n'est pas sur le même réseau
IP, il faut forcément router/forwarder le paquet de eth0 vers
eth1. Mais force est de constater que c'est toi qui as raison
bien sûr. Je trouve cela intellectuellement très perturbant.
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Ok. En revanche le terme de "session" m'échappe un peu.
C'est au sens du modèle OSI ou un truc dans le genre ?
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Pour linux, tu peux configurer cette fonction avec iptables, ici un
exemple très simplifié et aux erreurs de syntaxe probables près :
iptables -I INPUT -i eth0 -d 192.168.0.0/24 -j ACCEPT
iptables -I INPUT -i eth1 -d 172.31.0.0/16 -j ACCEPT
iptables -I INPUT -j LOG --log-level 5 --log-prefix "Spoofing "
iptables -I INPUT -j DROP
Ok, je vois l'idée.
Merci pour les explications, je crois que j'aurais pu chercher
longtemps tellement j'étais persuadé que l'IP forwarding était
nécessaire dans ce cas de figure.
--
François
Le 26/05/2014 08:34, Joe The Smoe a écrit :
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Ben zut alors. J'ai appris quelque chose. Je ne trouve vraiment
pas ça logique. Pour moi, si l'interface eth0 reçoit un paquet
à destination de l'IP de eth1 qui n'est pas sur le même réseau
IP, il faut forcément router/forwarder le paquet de eth0 vers
eth1. Mais force est de constater que c'est toi qui as raison
bien sûr. Je trouve cela intellectuellement très perturbant.
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Ok. En revanche le terme de "session" m'échappe un peu.
C'est au sens du modèle OSI ou un truc dans le genre ?
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Pour linux, tu peux configurer cette fonction avec iptables, ici un
exemple très simplifié et aux erreurs de syntaxe probables près :
iptables -I INPUT -i eth0 -d 192.168.0.0/24 -j ACCEPT
iptables -I INPUT -i eth1 -d 172.31.0.0/16 -j ACCEPT
iptables -I INPUT -j LOG --log-level 5 --log-prefix "Spoofing "
iptables -I INPUT -j DROP
Ok, je vois l'idée.
Merci pour les explications, je crois que j'aurais pu chercher
longtemps tellement j'étais persuadé que l'IP forwarding était
nécessaire dans ce cas de figure.
--
François
Le 26/05/2014 08:34, Joe The Smoe a écrit :pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Ben zut alors. J'ai appris quelque chose. Je ne trouve vraiment
pas ça logique. Pour moi, si l'interface eth0 reçoit un paquet
à destination de l'IP de eth1 qui n'est pas sur le même réseau
IP, il faut forcément router/forwarder le paquet de eth0 vers
eth1. Mais force est de constater que c'est toi qui as raison
bien sûr. Je trouve cela intellectuellement très perturbant.
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Ok. En revanche le terme de "session" m'échappe un peu.
C'est au sens du modèle OSI ou un truc dans le genre ?
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Pour linux, tu peux configurer cette fonction avec iptables, ici un
exemple très simplifié et aux erreurs de syntaxe probables près :
iptables -I INPUT -i eth0 -d 192.168.0.0/24 -j ACCEPT
iptables -I INPUT -i eth1 -d 172.31.0.0/16 -j ACCEPT
iptables -I INPUT -j LOG --log-level 5 --log-prefix "Spoofing "
iptables -I INPUT -j DROP
Ok, je vois l'idée.
Merci pour les explications, je crois que j'aurais pu chercher
longtemps tellement j'étais persuadé que l'IP forwarding était
nécessaire dans ce cas de figure.
--
François
Ok. En revanche le terme de "session" m'échappe un peu.
C'est au sens du modèle OSI ou un truc dans le genre ?
Oui, c'est un abus de langage. J'aurais dû écrire "Pour un processus,
n'écouter que sur telle ou telle interface, signifie que le noyau ne lui
enverra pas les données issues des paquets d'une session TCP créée à
destination du même port mais dont l'adresse IP de destination est
celle d'une autre interface, c'est tout".
Je ne suis pas sûr que ce soit plus facile à comprendre mais c'est
probablement plus correct. :-)
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination
de 127.0.0.1 depuis une hôte qui ne dispose pas de cette plage d'adresse
en loopback mais possède une route statique 127.0.0.1/32 vers un
équipement avec lequel il partage un subnet IP. Il peut alors, si rien
n'est fait pour l'en empêcher ouvrir une session TCP vers un service qui
n'est en écoute que sur l'adresse 127.0.0.1 (lo0) de cette victime.
Si ça fonctionne, ce n'est pas possible à exploiter à travers Internet,
mais sur un réseau local, LAN Ethernet d'entreprise par exemple, ou un
hotspot WiFi si l'AP WiFi autorise les hôtes à communiquer entre eux,
j'en ai des frissons car peu de distro (Debian par exemple) ne
positionnent par défaut d'anti-spoofing tel décrit plus haut...
Ok. En revanche le terme de "session" m'échappe un peu.
C'est au sens du modèle OSI ou un truc dans le genre ?
Oui, c'est un abus de langage. J'aurais dû écrire "Pour un processus,
n'écouter que sur telle ou telle interface, signifie que le noyau ne lui
enverra pas les données issues des paquets d'une session TCP créée à
destination du même port mais dont l'adresse IP de destination est
celle d'une autre interface, c'est tout".
Je ne suis pas sûr que ce soit plus facile à comprendre mais c'est
probablement plus correct. :-)
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination
de 127.0.0.1 depuis une hôte qui ne dispose pas de cette plage d'adresse
en loopback mais possède une route statique 127.0.0.1/32 vers un
équipement avec lequel il partage un subnet IP. Il peut alors, si rien
n'est fait pour l'en empêcher ouvrir une session TCP vers un service qui
n'est en écoute que sur l'adresse 127.0.0.1 (lo0) de cette victime.
Si ça fonctionne, ce n'est pas possible à exploiter à travers Internet,
mais sur un réseau local, LAN Ethernet d'entreprise par exemple, ou un
hotspot WiFi si l'AP WiFi autorise les hôtes à communiquer entre eux,
j'en ai des frissons car peu de distro (Debian par exemple) ne
positionnent par défaut d'anti-spoofing tel décrit plus haut...
Ok. En revanche le terme de "session" m'échappe un peu.
C'est au sens du modèle OSI ou un truc dans le genre ?
Oui, c'est un abus de langage. J'aurais dû écrire "Pour un processus,
n'écouter que sur telle ou telle interface, signifie que le noyau ne lui
enverra pas les données issues des paquets d'une session TCP créée à
destination du même port mais dont l'adresse IP de destination est
celle d'une autre interface, c'est tout".
Je ne suis pas sûr que ce soit plus facile à comprendre mais c'est
probablement plus correct. :-)
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination
de 127.0.0.1 depuis une hôte qui ne dispose pas de cette plage d'adresse
en loopback mais possède une route statique 127.0.0.1/32 vers un
équipement avec lequel il partage un subnet IP. Il peut alors, si rien
n'est fait pour l'en empêcher ouvrir une session TCP vers un service qui
n'est en écoute que sur l'adresse 127.0.0.1 (lo0) de cette victime.
Si ça fonctionne, ce n'est pas possible à exploiter à travers Internet,
mais sur un réseau local, LAN Ethernet d'entreprise par exemple, ou un
hotspot WiFi si l'AP WiFi autorise les hôtes à communiquer entre eux,
j'en ai des frissons car peu de distro (Debian par exemple) ne
positionnent par défaut d'anti-spoofing tel décrit plus haut...
On va dire pour l'instant que je retiens ceci :
- Même si l'ip forwarding n'est pas activé, il est
possible d'atteindre un service qui écoute sur une adresse
donnée même en passant par une interface qui ne possède pas
l'adresse en question.
- En revanche, ça ne semble pas possible quand le service
tourne sur une adresse appartenant à une interface de
loopback.
Voilà ce que je conclus de ces quelques tests.
On va dire pour l'instant que je retiens ceci :
- Même si l'ip forwarding n'est pas activé, il est
possible d'atteindre un service qui écoute sur une adresse
donnée même en passant par une interface qui ne possède pas
l'adresse en question.
- En revanche, ça ne semble pas possible quand le service
tourne sur une adresse appartenant à une interface de
loopback.
Voilà ce que je conclus de ces quelques tests.
On va dire pour l'instant que je retiens ceci :
- Même si l'ip forwarding n'est pas activé, il est
possible d'atteindre un service qui écoute sur une adresse
donnée même en passant par une interface qui ne possède pas
l'adresse en question.
- En revanche, ça ne semble pas possible quand le service
tourne sur une adresse appartenant à une interface de
loopback.
Voilà ce que je conclus de ces quelques tests.
On va dire pour l'instant que je retiens ceci :
- Même si l'ip forwarding n'est pas activé, il est
possible d'atteindre un service qui écoute sur une adresse
donnée même en passant par une interface qui ne possède pas
l'adresse en question.
- En revanche, ça ne semble pas possible quand le service
tourne sur une adresse appartenant à une interface de
loopback.
Voilà ce que je conclus de ces quelques tests.
On va dire pour l'instant que je retiens ceci :
- Même si l'ip forwarding n'est pas activé, il est
possible d'atteindre un service qui écoute sur une adresse
donnée même en passant par une interface qui ne possède pas
l'adresse en question.
- En revanche, ça ne semble pas possible quand le service
tourne sur une adresse appartenant à une interface de
loopback.
Voilà ce que je conclus de ces quelques tests.
On va dire pour l'instant que je retiens ceci :
- Même si l'ip forwarding n'est pas activé, il est
possible d'atteindre un service qui écoute sur une adresse
donnée même en passant par une interface qui ne possède pas
l'adresse en question.
- En revanche, ça ne semble pas possible quand le service
tourne sur une adresse appartenant à une interface de
loopback.
Voilà ce que je conclus de ces quelques tests.
Ton idée pleine de perfidie ;-)
m'a donné envie de tester car
effectivement, ça fait un peu peur cette histoire. Et globalement,
je ne suis pas arrivé à contacter l'hôte.
On va dire que c'est plutôt rassurant même si au final je ne
peux pas dire grand chose vu que je n'ai pas réussi à faire
partir le moindre paquet avec 127.0.0.1 comme IP de destination.
Y aurait-il des mécanismes au sein du noyau qui empêcheraient
une telle chose... Là ça me dépasse.
Ton idée pleine de perfidie ;-)
m'a donné envie de tester car
effectivement, ça fait un peu peur cette histoire. Et globalement,
je ne suis pas arrivé à contacter l'hôte.
On va dire que c'est plutôt rassurant même si au final je ne
peux pas dire grand chose vu que je n'ai pas réussi à faire
partir le moindre paquet avec 127.0.0.1 comme IP de destination.
Y aurait-il des mécanismes au sein du noyau qui empêcheraient
une telle chose... Là ça me dépasse.
Ton idée pleine de perfidie ;-)
m'a donné envie de tester car
effectivement, ça fait un peu peur cette histoire. Et globalement,
je ne suis pas arrivé à contacter l'hôte.
On va dire que c'est plutôt rassurant même si au final je ne
peux pas dire grand chose vu que je n'ai pas réussi à faire
partir le moindre paquet avec 127.0.0.1 comme IP de destination.
Y aurait-il des mécanismes au sein du noyau qui empêcheraient
une telle chose... Là ça me dépasse.
Le 26/05/2014 06:29, Francois Lafont a écrit :Comment cela se fait-il que je puisse consulter la
page http//172.31.0.1 en étant sur l'hôte M alors
que l'ip forwarding n'est même pas activé sur R ?
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Le 26/05/2014 06:29, Francois Lafont a écrit :
Comment cela se fait-il que je puisse consulter la
page http//172.31.0.1 en étant sur l'hôte M alors
que l'ip forwarding n'est même pas activé sur R ?
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
Le 26/05/2014 06:29, Francois Lafont a écrit :Comment cela se fait-il que je puisse consulter la
page http//172.31.0.1 en étant sur l'hôte M alors
que l'ip forwarding n'est même pas activé sur R ?
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Pour un processus, n'écouter que sur telle ou telle interface, signifie
que le noyau ne lui enverra pas les demandes de session à destination
des autres interfaces, c'est tout.
Pour le noyau de bon nombre de systèmes (Linux, mais aussi des
routeurs), par défaut il n'y a "d'anti-spoofing", fonction qu'on trouve
classiquement sur les firewalls.
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination
de 127.0.0.1
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination
de 127.0.0.1
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination
de 127.0.0.1
Le 26/05/2014 08:34, Joe The Smoe a écrit :pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Ben zut alors. J'ai appris quelque chose. Je ne trouve vraiment
pas ça logique. Pour moi, si l'interface eth0 reçoit un paquet
à destination de l'IP de eth1 qui n'est pas sur le même réseau
IP, il faut forcément router/forwarder le paquet de eth0 vers
eth1.
Le 26/05/2014 08:34, Joe The Smoe a écrit :
pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Ben zut alors. J'ai appris quelque chose. Je ne trouve vraiment
pas ça logique. Pour moi, si l'interface eth0 reçoit un paquet
à destination de l'IP de eth1 qui n'est pas sur le même réseau
IP, il faut forcément router/forwarder le paquet de eth0 vers
eth1.
Le 26/05/2014 08:34, Joe The Smoe a écrit :pas besoin d'IP forward pour qu'une machine accepte une session à
destination d'une de ses adresses IP, même si celle-ci se trouve "de
l'autre côté" (i.e.: l'IP cible n'est pas celle de l'interface par
laquelle la session arrive à la machine).
Ben zut alors. J'ai appris quelque chose. Je ne trouve vraiment
pas ça logique. Pour moi, si l'interface eth0 reçoit un paquet
à destination de l'IP de eth1 qui n'est pas sur le même réseau
IP, il faut forcément router/forwarder le paquet de eth0 vers
eth1.