J'ai bien apache2 qui n'écoute a priori que sur eth1.
Mais pourtant, il semble que non. En effet, si, sur la
machine M, j'indique la route suivante :
sudo ip route add 172.31.0.0/16 via 192.168.0.45 dev eth0
J'indique donc à cet hôte M que pour atteindre les IPs du
VLAN 1, il faut passer par l'interface eth0 de l'hôte R, ce
qui ne devrait pas marcher vu que sur R l'ip forwarding n'est
pas activé. Et bien, à ma grande surprise, si j'ouvre alors
un navigateur sur M et que je consulte l'adresse :
http:// 172.31.0.1
je tombe bien sur la page Web par défaut de l'hôte R.
Si je fais un tcpdump de eth1 sur R, c'est le néant.
Rien ne s'affiche au niveau du tcpdump de eth1 quand
je consulte la page ci-dessus. En revanche, un tcpdump
sur eth0 de R me montre bien que c'est l'interface eth0
qui reçoit et répond aux requêtes http.
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 ?
Est-ce que apache2 écoute toujours sur eth0 malgré
la conf que j'ai mise ? Si oui, comment le forcer
à n'écouter *que* sur l'interface eth1 ?
Dans le même ordre d'idée, je suis surpris que,
sur l'hôte M, je puisse réussir un :
ping -n 172.31.0.1
(une fois la route précédente ajoutée bien sûr)
Comment est-ce possible alors que, encore une fois,
l'ip forwarding n'est pas activé sur la machine R.
Pour moi, le paquet devrait arriver sur eth0 de R
et, ne pouvant être relayé à eth1 de R, le paquet
devrait être détruit avec du coup une absence de réponse
au ping. Pour le ping (comme pour http) je ne vois aucun
trafic sur eth1 (mais sur eth0 oui).
Je trouve ça quand même un peu fort de café d'arriver à
contacter l'IP de eth1 de R (via un ping ou via http) sans
voir le moindre trafic sur eth1 avec tcpdump.
Cf. weak vs. strong host model. <http://en.wikipedia.org/wiki/Host_model> (pas de page fr désolé)
Modèle fort : l'adresse appartient à l'interface. Modèle faible : l'adresse appartient au noeud.
Le modèle "faible" est plus robuste en cas de coupure d'un lien : les paquets à destination de l'adresse correspondante peuvent encore arriver par un autre lien.
J'ai testé l'option du noyau donc il est question dans le lien afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc. for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2 qui tourne exclusivement sur une « adresse associée à l'interface de l'autre côté » (voir mon premier message si l'expression semble un peu elliptique).
Est-ce normal ?
-- François Lafont
Merci Pascal pour tous ces éclaircissements.
Le 27/05/2014 09:37, Pascal Hambourg a écrit :
Cf. weak vs. strong host model.
<http://en.wikipedia.org/wiki/Host_model> (pas de page fr désolé)
Modèle fort : l'adresse appartient à l'interface.
Modèle faible : l'adresse appartient au noeud.
Le modèle "faible" est plus robuste en cas de coupure d'un lien : les
paquets à destination de l'adresse correspondante peuvent encore arriver
par un autre lien.
J'ai testé l'option du noyau donc il est question dans le lien
afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc.
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2
qui tourne exclusivement sur une « adresse associée à l'interface de
l'autre côté » (voir mon premier message si l'expression semble un
peu elliptique).
Cf. weak vs. strong host model. <http://en.wikipedia.org/wiki/Host_model> (pas de page fr désolé)
Modèle fort : l'adresse appartient à l'interface. Modèle faible : l'adresse appartient au noeud.
Le modèle "faible" est plus robuste en cas de coupure d'un lien : les paquets à destination de l'adresse correspondante peuvent encore arriver par un autre lien.
J'ai testé l'option du noyau donc il est question dans le lien afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc. for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2 qui tourne exclusivement sur une « adresse associée à l'interface de l'autre côté » (voir mon premier message si l'expression semble un peu elliptique).
Est-ce normal ?
-- François Lafont
Francois Lafont
Le 27/05/2014 11:38, Francois Lafont a écrit :
J'ai testé l'option du noyau don*t* il est question dans le lien afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc. for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2 qui tourne exclusivement sur une « adresse associée à l'interface de l'autre côté » (voir mon premier message si l'expression semble un peu elliptique).
Est-ce normal ?
J'ai oublié de préciser qu'il s'agit d'une Debian Wheezy de base avec le noyau 3.2 donc.
-- François Lafont
Le 27/05/2014 11:38, Francois Lafont a écrit :
J'ai testé l'option du noyau don*t* il est question dans le lien
afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc.
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2
qui tourne exclusivement sur une « adresse associée à l'interface de
l'autre côté » (voir mon premier message si l'expression semble un
peu elliptique).
Est-ce normal ?
J'ai oublié de préciser qu'il s'agit d'une Debian Wheezy de base
avec le noyau 3.2 donc.
J'ai testé l'option du noyau don*t* il est question dans le lien afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc. for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2 qui tourne exclusivement sur une « adresse associée à l'interface de l'autre côté » (voir mon premier message si l'expression semble un peu elliptique).
Est-ce normal ?
J'ai oublié de préciser qu'il s'agit d'une Debian Wheezy de base avec le noyau 3.2 donc.
-- François Lafont
Joe The Smoe
Le 27/05/2014 09:43, Pascal Hambourg a écrit :
Joe The Smoe a écrit :
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination de 127.0.0.1
Non, pas avec Linux. Sa couche IP élimine les paquets avec une source ou destination dans 127.0.0.0/8 reçus ou émis sur une interface non loopback, en conformité avec les RFC disant que ce genre de paquet ne devrait jamais apparaître en dehors d'un hôte. Il me semble qu'il y a eu des patches pour désactiver ce comportement, notamment dans le cas d'utilisation de machines virtuelles (on ne sort pas vraiment de l'hôte dans ce cas).
j'ai pourtant pu faire émettre sur le réseau par un noyau Linux 3.2.57 des paquets à destination de 127.0.0.1, voir mon message de ce matin.
En revanche il y a assez longtemps j'avais constaté que l'adresse de loopback ::1 en IPv6 n'était pas limitée de la même façon. Je n'ai pas revérifié avec un noyau plus récent.
Le 27/05/2014 09:43, Pascal Hambourg a écrit :
Joe The Smoe a écrit :
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination
de 127.0.0.1
Non, pas avec Linux. Sa couche IP élimine les paquets avec une source ou
destination dans 127.0.0.0/8 reçus ou émis sur une interface non
loopback, en conformité avec les RFC disant que ce genre de paquet ne
devrait jamais apparaître en dehors d'un hôte. Il me semble qu'il y a eu
des patches pour désactiver ce comportement, notamment dans le cas
d'utilisation de machines virtuelles (on ne sort pas vraiment de l'hôte
dans ce cas).
j'ai pourtant pu faire émettre sur le réseau par un noyau Linux 3.2.57
des paquets à destination de 127.0.0.1, voir mon message de ce matin.
En revanche il y a assez longtemps j'avais constaté que l'adresse de
loopback ::1 en IPv6 n'était pas limitée de la même façon. Je n'ai pas
revérifié avec un noyau plus récent.
le plus drôle c'est que ça doit pouvoir aussi fonctionner à destination de 127.0.0.1
Non, pas avec Linux. Sa couche IP élimine les paquets avec une source ou destination dans 127.0.0.0/8 reçus ou émis sur une interface non loopback, en conformité avec les RFC disant que ce genre de paquet ne devrait jamais apparaître en dehors d'un hôte. Il me semble qu'il y a eu des patches pour désactiver ce comportement, notamment dans le cas d'utilisation de machines virtuelles (on ne sort pas vraiment de l'hôte dans ce cas).
j'ai pourtant pu faire émettre sur le réseau par un noyau Linux 3.2.57 des paquets à destination de 127.0.0.1, voir mon message de ce matin.
En revanche il y a assez longtemps j'avais constaté que l'adresse de loopback ::1 en IPv6 n'était pas limitée de la même façon. Je n'ai pas revérifié avec un noyau plus récent.
Joe The Smoe
Le 27/05/2014 08:02, Erwan David a écrit :
Francois Lafont écrivait :
[...]
C'est plus compliqué que ça : là tu as constaté une limitation de ta machine d'attaque.
Par contre si la machine attaquée reçoit un paquet sur une interface externe à destination de 127.0.0.1, que se passe-t-il (on la supposera configurée de manière standard)
1) en TCP : même si le SYN est accepté, le SYN-ACK ne repartira pas à l'attaquant
Qu'est qui l'en empêcherait ?
2) en UDP : les réponses ne partiront pas à l'attaquant.
Pourquoi ? Moi, je ne vois pas ...
Le risque reste donc sur les attaques en UDP ne nécessitant pas de réponse de l'attaqué, et il y en a (principalement des dénis de service, mais rien n'empêche que ça laisse un service normalement sécurisé dans un état vulnérable, permettant ensuite une exploitation d'une autre faille).
Il faudrait donc voir en travaillant directement au niveau de la trame ethernet (il faudra mettre la mac destinatioon à la main, arp ne répondra pas pour un 127.0.0.1) pour envoyer à une machine un paquet portant l'adresse destination 127.0.0.1 et voir s'il est droppé ou pas.
Pas besoin de travailler directement au niveau de la trame Ethernet : si l'attaquant a une route vers 127.0.0.1 ayant pour gateway l'IP de la cible (disons 192.168.6.1) dans le LAN, il n'y a pas de requète ARP vers 127.0.0.1, la requête ARP est vers 192.168.6.1, le paquet IP arrive donc avec une IP destination de 127.0.0.1 et en adresse MAC destination celle de la carte réseau physique de la cible, ce qui est tout à fait fonctionnel.
pour le paquet retour, c'est l'IP source de l'attaquant (192.168.6.20 par exemple) qui est utilisée elle est routable vers le LAN peu importe l'IP source du paquet IP (ici 127.0.0.1)
On peut donc *à priori* monter une session TCP vers 127.0.0.1 d'une autre machine, tel que rapporté dans mon message de ce matin (changer l'IP de la loopback sur l'attaquant et ajouter une route statique vers la cible). Malheureusement je ne peux pas supprimer les filtrage iptables sur cette machine cible pour connaître la réponse à ce type d'attaque.
Personnellement je vais ajouter ça dans mes règles de firewall...
Suite sur fr.comp.securite pour discuter de ce type d'attaque.
Résumé pour les lecteurs de fr.comp.securite : - on constate qu'une machine linux répond par défaut à toutes ses IP sur toutes ses interfaces - peut-on ainsi atteindre un service qui n'écouterait que sur 127.0.0.1 ?
C'est plus compliqué que ça : là tu as constaté une limitation de ta
machine d'attaque.
Par contre si la machine attaquée reçoit un paquet sur une interface
externe à destination de 127.0.0.1, que se passe-t-il (on la supposera
configurée de manière standard)
1) en TCP : même si le SYN est accepté, le SYN-ACK ne repartira pas à
l'attaquant
Qu'est qui l'en empêcherait ?
2) en UDP : les réponses ne partiront pas à l'attaquant.
Pourquoi ? Moi, je ne vois pas ...
Le risque reste donc sur les attaques en UDP ne nécessitant pas de
réponse de l'attaqué, et il y en a (principalement des dénis de service,
mais rien n'empêche que ça laisse un service normalement sécurisé dans
un état vulnérable, permettant ensuite une exploitation d'une autre
faille).
Il faudrait donc voir en travaillant directement au niveau de la trame
ethernet (il faudra mettre la mac destinatioon à la main, arp ne
répondra pas pour un 127.0.0.1) pour envoyer à une machine un paquet
portant l'adresse destination 127.0.0.1 et voir s'il est droppé ou pas.
Pas besoin de travailler directement au niveau de la trame Ethernet :
si l'attaquant a une route vers 127.0.0.1 ayant pour gateway l'IP de la
cible (disons 192.168.6.1) dans le LAN, il n'y a pas de requète ARP vers
127.0.0.1, la requête ARP est vers 192.168.6.1, le paquet IP arrive donc
avec une IP destination de 127.0.0.1 et en adresse MAC destination celle
de la carte réseau physique de la cible, ce qui est tout à fait fonctionnel.
pour le paquet retour, c'est l'IP source de l'attaquant (192.168.6.20
par exemple) qui est utilisée elle est routable vers le LAN peu importe
l'IP source du paquet IP (ici 127.0.0.1)
On peut donc *à priori* monter une session TCP vers 127.0.0.1 d'une
autre machine, tel que rapporté dans mon message de ce matin (changer
l'IP de la loopback sur l'attaquant et ajouter une route statique vers
la cible). Malheureusement je ne peux pas supprimer les filtrage
iptables sur cette machine cible pour connaître la réponse à ce type
d'attaque.
Personnellement je vais ajouter ça dans mes règles de firewall...
Suite sur fr.comp.securite pour discuter de ce type d'attaque.
Résumé pour les lecteurs de fr.comp.securite :
- on constate qu'une machine linux répond par défaut à toutes ses IP sur
toutes ses interfaces
- peut-on ainsi atteindre un service qui n'écouterait que sur
127.0.0.1 ?
C'est plus compliqué que ça : là tu as constaté une limitation de ta machine d'attaque.
Par contre si la machine attaquée reçoit un paquet sur une interface externe à destination de 127.0.0.1, que se passe-t-il (on la supposera configurée de manière standard)
1) en TCP : même si le SYN est accepté, le SYN-ACK ne repartira pas à l'attaquant
Qu'est qui l'en empêcherait ?
2) en UDP : les réponses ne partiront pas à l'attaquant.
Pourquoi ? Moi, je ne vois pas ...
Le risque reste donc sur les attaques en UDP ne nécessitant pas de réponse de l'attaqué, et il y en a (principalement des dénis de service, mais rien n'empêche que ça laisse un service normalement sécurisé dans un état vulnérable, permettant ensuite une exploitation d'une autre faille).
Il faudrait donc voir en travaillant directement au niveau de la trame ethernet (il faudra mettre la mac destinatioon à la main, arp ne répondra pas pour un 127.0.0.1) pour envoyer à une machine un paquet portant l'adresse destination 127.0.0.1 et voir s'il est droppé ou pas.
Pas besoin de travailler directement au niveau de la trame Ethernet : si l'attaquant a une route vers 127.0.0.1 ayant pour gateway l'IP de la cible (disons 192.168.6.1) dans le LAN, il n'y a pas de requète ARP vers 127.0.0.1, la requête ARP est vers 192.168.6.1, le paquet IP arrive donc avec une IP destination de 127.0.0.1 et en adresse MAC destination celle de la carte réseau physique de la cible, ce qui est tout à fait fonctionnel.
pour le paquet retour, c'est l'IP source de l'attaquant (192.168.6.20 par exemple) qui est utilisée elle est routable vers le LAN peu importe l'IP source du paquet IP (ici 127.0.0.1)
On peut donc *à priori* monter une session TCP vers 127.0.0.1 d'une autre machine, tel que rapporté dans mon message de ce matin (changer l'IP de la loopback sur l'attaquant et ajouter une route statique vers la cible). Malheureusement je ne peux pas supprimer les filtrage iptables sur cette machine cible pour connaître la réponse à ce type d'attaque.
Personnellement je vais ajouter ça dans mes règles de firewall...
Suite sur fr.comp.securite pour discuter de ce type d'attaque.
Résumé pour les lecteurs de fr.comp.securite : - on constate qu'une machine linux répond par défaut à toutes ses IP sur toutes ses interfaces - peut-on ainsi atteindre un service qui n'écouterait que sur 127.0.0.1 ?
Joe The Smoe
Le 27/05/2014 09:37, Pascal Hambourg a écrit :
Joe The Smoe a écrit :
Le 26/05/2014 06:29, Francois Lafont a écrit :
[...]
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.
La plupart des processus utilisateur ouvrent des sockets "normales" qui écoutent sur des adresses, pas des interfaces.
oui, c'est un abus de langage ... et ça fonctionne de la même façon avec des sockets "normales" qui sont associée à telle adresse IP.
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.
Cela n'a pas grand-chose à voir avec le spoofing (usurpation d'adresse source).
c'est pourtant le terme "antispoofing" qui est utilisé sur les firewalls check points par exemple, fonction permettant de dropper les paquets arrivant par une interface où on ne les attend pas.
Cdlt, Joe the Shmoe.
Le 27/05/2014 09:37, Pascal Hambourg a écrit :
Joe The Smoe a écrit :
Le 26/05/2014 06:29, Francois Lafont a écrit :
[...]
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.
La plupart des processus utilisateur ouvrent des sockets "normales" qui
écoutent sur des adresses, pas des interfaces.
oui, c'est un abus de langage ... et ça fonctionne de la même façon avec
des sockets "normales" qui sont associée à telle adresse IP.
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.
Cela n'a pas grand-chose à voir avec le spoofing (usurpation d'adresse
source).
c'est pourtant le terme "antispoofing" qui est utilisé sur les firewalls
check points par exemple, fonction permettant de dropper les paquets
arrivant par une interface où on ne les attend pas.
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.
La plupart des processus utilisateur ouvrent des sockets "normales" qui écoutent sur des adresses, pas des interfaces.
oui, c'est un abus de langage ... et ça fonctionne de la même façon avec des sockets "normales" qui sont associée à telle adresse IP.
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.
Cela n'a pas grand-chose à voir avec le spoofing (usurpation d'adresse source).
c'est pourtant le terme "antispoofing" qui est utilisé sur les firewalls check points par exemple, fonction permettant de dropper les paquets arrivant par une interface où on ne les attend pas.
Cdlt, Joe the Shmoe.
Pascal Hambourg
Francois Lafont a écrit :
Le 27/05/2014 09:37, Pascal Hambourg a écrit :
Cf. weak vs. strong host model. <http://en.wikipedia.org/wiki/Host_model> (pas de page fr désolé)
Modèle fort : l'adresse appartient à l'interface. Modèle faible : l'adresse appartient au noeud.
Le modèle "faible" est plus robuste en cas de coupure d'un lien : les paquets à destination de l'adresse correspondante peuvent encore arriver par un autre lien.
J'ai testé l'option du noyau donc il est question dans le lien afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc. for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2 qui tourne exclusivement sur une « adresse associée à l'interface de l'autre côté » (voir mon premier message si l'expression semble un peu elliptique).
Est-ce normal ?
Tu as mal compris ce qui est écrit dans la page, dont il faut retenir : "This is not quite the same as the strong host model"
A ta décharge la formulation est assez ambigüe. Ce n'est *pas du tout* la même chose. Ce paramètre vérifie juste l'adresse source, pas l'adresse destination.
Francois Lafont a écrit :
Le 27/05/2014 09:37, Pascal Hambourg a écrit :
Cf. weak vs. strong host model.
<http://en.wikipedia.org/wiki/Host_model> (pas de page fr désolé)
Modèle fort : l'adresse appartient à l'interface.
Modèle faible : l'adresse appartient au noeud.
Le modèle "faible" est plus robuste en cas de coupure d'un lien : les
paquets à destination de l'adresse correspondante peuvent encore arriver
par un autre lien.
J'ai testé l'option du noyau donc il est question dans le lien
afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc.
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2
qui tourne exclusivement sur une « adresse associée à l'interface de
l'autre côté » (voir mon premier message si l'expression semble un
peu elliptique).
Est-ce normal ?
Tu as mal compris ce qui est écrit dans la page, dont il faut retenir :
"This is not quite the same as the strong host model"
A ta décharge la formulation est assez ambigüe. Ce n'est *pas du tout*
la même chose. Ce paramètre vérifie juste l'adresse source, pas
l'adresse destination.
Cf. weak vs. strong host model. <http://en.wikipedia.org/wiki/Host_model> (pas de page fr désolé)
Modèle fort : l'adresse appartient à l'interface. Modèle faible : l'adresse appartient au noeud.
Le modèle "faible" est plus robuste en cas de coupure d'un lien : les paquets à destination de l'adresse correspondante peuvent encore arriver par un autre lien.
J'ai testé l'option du noyau donc il est question dans le lien afin de passer en "strong host model" :
# Flemme de chercher si le all l'emporte sur les autres etc. for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
mais d'après mes tests, j'arrive quand même à atteindre le apache2 qui tourne exclusivement sur une « adresse associée à l'interface de l'autre côté » (voir mon premier message si l'expression semble un peu elliptique).
Est-ce normal ?
Tu as mal compris ce qui est écrit dans la page, dont il faut retenir : "This is not quite the same as the strong host model"
A ta décharge la formulation est assez ambigüe. Ce n'est *pas du tout* la même chose. Ce paramètre vérifie juste l'adresse source, pas l'adresse destination.
et sur 192.168.6.1: tcpdump -i eth0 -n tcp port 23 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:51:23.877745 IP 192.168.6.20.58974 > 127.0.0.1.23: Flags [S], seq 3693925555, win 14600, options [mss 1460,sackOK,TS val 3246587 ecr 0,nop,wscale 5], length 0
Cela me surprend beaucoup, mais effectivement je peux le reproduire.
Je n'ai pas pu aller plus loin du fait de la configuration iptables qui interdit justement ce type d'usurpation, mais j'ai bien réussi à faire sortir des paquets d'une machine Linux à destination de 127.0.0.1. Reste à savoir si une telle victime répondra normalement à de tels paquets (?)
Normalement non.
Sinon, je te confirme que faire un shutdown de l'interface loopback ne permet pas à la route statique 127.0.0.1 ajoutée d'être utilisé, il faut bien changer l'adresse IP de l'interface loopback pour que cette route soit utilisée.
En effet, sinon la route locale vers cette adresse a la priorité.
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.
Source ou destination ?
Y aurait-il des mécanismes au sein du noyau qui empêcheraient une telle chose... Là ça me dépasse.
Normalement oui. Un paramètre sysctl net/ipv4/conf/<if>/route_localnet a été ajoutée au noyau 3.6 pour permettre de désactiver la protection (mais il est désactivé par défaut) :
commit d0daebc3d622f95db181601cb0c4a0781f74f758 Author: Thomas Graf Date: Tue Jun 12 00:44:01 2012 +0000
ipv4: Add interface option to enable routing of 127.0.0.0/8
Routing of 127/8 is tradtionally forbidden, we consider packets from that address block martian when routing and do not process corresponding ARP requests.
This is a sane default but renders a huge address space practically unuseable.
The RFC states that no address within the 127/8 block should ever appear on any network anywhere but it does not forbid the use of such addresses outside of the loopback device in particular. For example to address a pool of virtual guests behind a load balancer.
This patch adds a new interface option 'route_localnet' enabling routing of the 127/8 address block and processing of ARP requests on a specific interface.
Note that for the feature to work, the default local route covering 127/8 dev lo needs to be removed.
J'ai noté que contrairement à une interface physique, ajouter un sous-réseau sur une interface loopback tel 127.0.0.0/8 n'induit aucune nouvelle route dans la table de routage. Il y a bien au niveau du noyau un comportement différent vis à vis de ce type d'interface.
En fait une route est bien créée, mais dans la table "local", pas dans la table "main" dont le contenu est seul affiché par défaut.
et sur 192.168.6.1:
tcpdump -i eth0 -n tcp port 23
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:51:23.877745 IP 192.168.6.20.58974 > 127.0.0.1.23: Flags [S], seq
3693925555, win 14600, options [mss 1460,sackOK,TS val 3246587 ecr
0,nop,wscale 5], length 0
Cela me surprend beaucoup, mais effectivement je peux le reproduire.
Je n'ai pas pu aller plus loin du fait de la configuration iptables qui
interdit justement ce type d'usurpation, mais j'ai bien réussi à faire
sortir des paquets d'une machine Linux à destination de 127.0.0.1. Reste
à savoir si une telle victime répondra normalement à de tels paquets (?)
Normalement non.
Sinon, je te confirme que faire un shutdown de l'interface loopback ne
permet pas à la route statique 127.0.0.1 ajoutée d'être utilisé, il faut
bien changer l'adresse IP de l'interface loopback pour que cette route
soit utilisée.
En effet, sinon la route locale vers cette adresse a la priorité.
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.
Source ou destination ?
Y aurait-il des mécanismes au sein du noyau qui empêcheraient
une telle chose... Là ça me dépasse.
Normalement oui.
Un paramètre sysctl net/ipv4/conf/<if>/route_localnet a été ajoutée au
noyau 3.6 pour permettre de désactiver la protection (mais il est
désactivé par défaut) :
commit d0daebc3d622f95db181601cb0c4a0781f74f758
Author: Thomas Graf <tgraf@suug.ch>
Date: Tue Jun 12 00:44:01 2012 +0000
ipv4: Add interface option to enable routing of 127.0.0.0/8
Routing of 127/8 is tradtionally forbidden, we consider
packets from that address block martian when routing and do
not process corresponding ARP requests.
This is a sane default but renders a huge address space
practically unuseable.
The RFC states that no address within the 127/8 block should
ever appear on any network anywhere but it does not forbid
the use of such addresses outside of the loopback device in
particular. For example to address a pool of virtual guests
behind a load balancer.
This patch adds a new interface option 'route_localnet'
enabling routing of the 127/8 address block and processing
of ARP requests on a specific interface.
Note that for the feature to work, the default local route
covering 127/8 dev lo needs to be removed.
J'ai noté que contrairement à une interface physique, ajouter un
sous-réseau sur une interface loopback tel 127.0.0.0/8 n'induit aucune
nouvelle route dans la table de routage. Il y a bien au niveau du noyau
un comportement différent vis à vis de ce type d'interface.
En fait une route est bien créée, mais dans la table "local", pas dans
la table "main" dont le contenu est seul affiché par défaut.
et sur 192.168.6.1: tcpdump -i eth0 -n tcp port 23 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:51:23.877745 IP 192.168.6.20.58974 > 127.0.0.1.23: Flags [S], seq 3693925555, win 14600, options [mss 1460,sackOK,TS val 3246587 ecr 0,nop,wscale 5], length 0
Cela me surprend beaucoup, mais effectivement je peux le reproduire.
Je n'ai pas pu aller plus loin du fait de la configuration iptables qui interdit justement ce type d'usurpation, mais j'ai bien réussi à faire sortir des paquets d'une machine Linux à destination de 127.0.0.1. Reste à savoir si une telle victime répondra normalement à de tels paquets (?)
Normalement non.
Sinon, je te confirme que faire un shutdown de l'interface loopback ne permet pas à la route statique 127.0.0.1 ajoutée d'être utilisé, il faut bien changer l'adresse IP de l'interface loopback pour que cette route soit utilisée.
En effet, sinon la route locale vers cette adresse a la priorité.
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.
Source ou destination ?
Y aurait-il des mécanismes au sein du noyau qui empêcheraient une telle chose... Là ça me dépasse.
Normalement oui. Un paramètre sysctl net/ipv4/conf/<if>/route_localnet a été ajoutée au noyau 3.6 pour permettre de désactiver la protection (mais il est désactivé par défaut) :
commit d0daebc3d622f95db181601cb0c4a0781f74f758 Author: Thomas Graf Date: Tue Jun 12 00:44:01 2012 +0000
ipv4: Add interface option to enable routing of 127.0.0.0/8
Routing of 127/8 is tradtionally forbidden, we consider packets from that address block martian when routing and do not process corresponding ARP requests.
This is a sane default but renders a huge address space practically unuseable.
The RFC states that no address within the 127/8 block should ever appear on any network anywhere but it does not forbid the use of such addresses outside of the loopback device in particular. For example to address a pool of virtual guests behind a load balancer.
This patch adds a new interface option 'route_localnet' enabling routing of the 127/8 address block and processing of ARP requests on a specific interface.
Note that for the feature to work, the default local route covering 127/8 dev lo needs to be removed.
J'ai noté que contrairement à une interface physique, ajouter un sous-réseau sur une interface loopback tel 127.0.0.0/8 n'induit aucune nouvelle route dans la table de routage. Il y a bien au niveau du noyau un comportement différent vis à vis de ce type d'interface.
En fait une route est bien créée, mais dans la table "local", pas dans la table "main" dont le contenu est seul affiché par défaut.
$ ip route show table local
Francois Lafont
Le 28/05/2014 00:37, Pascal Hambourg a écrit :
Tu as mal compris ce qui est écrit dans la page, dont il faut retenir : "This is not quite the same as the strong host model"
A ta décharge la formulation est assez ambigüe. Ce n'est *pas du tout* la même chose. Ce paramètre vérifie juste l'adresse source, pas l'adresse destination.
Ah ok, au temps pour moi. Mais alors sur ma petite Debian Wheezy, je n'ai pas moyen de faire en sorte que le noyau suive par défaut le modèle dit « fort »... sauf en faisant des petites règles iptables à la mano ?
-- François Lafont
Le 28/05/2014 00:37, Pascal Hambourg a écrit :
Tu as mal compris ce qui est écrit dans la page, dont il faut retenir :
"This is not quite the same as the strong host model"
A ta décharge la formulation est assez ambigüe. Ce n'est *pas du tout*
la même chose. Ce paramètre vérifie juste l'adresse source, pas
l'adresse destination.
Ah ok, au temps pour moi. Mais alors sur ma petite Debian
Wheezy, je n'ai pas moyen de faire en sorte que le noyau
suive par défaut le modèle dit « fort »... sauf en faisant
des petites règles iptables à la mano ?
Tu as mal compris ce qui est écrit dans la page, dont il faut retenir : "This is not quite the same as the strong host model"
A ta décharge la formulation est assez ambigüe. Ce n'est *pas du tout* la même chose. Ce paramètre vérifie juste l'adresse source, pas l'adresse destination.
Ah ok, au temps pour moi. Mais alors sur ma petite Debian Wheezy, je n'ai pas moyen de faire en sorte que le noyau suive par défaut le modèle dit « fort »... sauf en faisant des petites règles iptables à la mano ?
et sur 192.168.6.1: tcpdump -i eth0 -n tcp port 23 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:51:23.877745 IP 192.168.6.20.58974 > 127.0.0.1.23: Flags [S], seq 3693925555, win 14600, options [mss 1460,sackOK,TS val 3246587 ecr 0,nop,wscale 5], length 0
Cela me surprend beaucoup, mais effectivement je peux le reproduire.
Pareil, je suis arrivé finalement à le reproduis avec ça :
ip address add 128.0.0.1/8 dev lo scope host ip address del 127.0.0.1/8 dev lo
À partir de là, je peux envoyer des paquets dont l'ip de destination est 127.0.0.1. Dans mon, ces paquets partent directement vers la passerelle par défaut 172.31.0.1 (vu que je n'ajoute pas de route), passerelle obtenue par DHCP sur eth0.
J'ai mis un apache2 qui écoute sur localhost au niveau de la passerelle. Je peux donc envoyer des requêtes à ce serveur http avec des paquets dont l'ip de destination est 127.0.0.1, les paquets arrivent bien mais, fort heureusement, le serveur apache ne répond pas.
et sur 192.168.6.1:
tcpdump -i eth0 -n tcp port 23
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:51:23.877745 IP 192.168.6.20.58974 > 127.0.0.1.23: Flags [S], seq
3693925555, win 14600, options [mss 1460,sackOK,TS val 3246587 ecr
0,nop,wscale 5], length 0
Cela me surprend beaucoup, mais effectivement je peux le reproduire.
Pareil, je suis arrivé finalement à le reproduis avec ça :
ip address add 128.0.0.1/8 dev lo scope host
ip address del 127.0.0.1/8 dev lo
À partir de là, je peux envoyer des paquets dont
l'ip de destination est 127.0.0.1. Dans mon, ces
paquets partent directement vers la passerelle
par défaut 172.31.0.1 (vu que je n'ajoute pas de
route), passerelle obtenue par DHCP sur eth0.
J'ai mis un apache2 qui écoute sur localhost au
niveau de la passerelle. Je peux donc envoyer
des requêtes à ce serveur http avec des paquets
dont l'ip de destination est 127.0.0.1, les
paquets arrivent bien mais, fort heureusement,
le serveur apache ne répond pas.
et sur 192.168.6.1: tcpdump -i eth0 -n tcp port 23 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:51:23.877745 IP 192.168.6.20.58974 > 127.0.0.1.23: Flags [S], seq 3693925555, win 14600, options [mss 1460,sackOK,TS val 3246587 ecr 0,nop,wscale 5], length 0
Cela me surprend beaucoup, mais effectivement je peux le reproduire.
Pareil, je suis arrivé finalement à le reproduis avec ça :
ip address add 128.0.0.1/8 dev lo scope host ip address del 127.0.0.1/8 dev lo
À partir de là, je peux envoyer des paquets dont l'ip de destination est 127.0.0.1. Dans mon, ces paquets partent directement vers la passerelle par défaut 172.31.0.1 (vu que je n'ajoute pas de route), passerelle obtenue par DHCP sur eth0.
J'ai mis un apache2 qui écoute sur localhost au niveau de la passerelle. Je peux donc envoyer des requêtes à ce serveur http avec des paquets dont l'ip de destination est 127.0.0.1, les paquets arrivent bien mais, fort heureusement, le serveur apache ne répond pas.
-- François Lafont
Pascal Hambourg
Francois Lafont a écrit :
Ah ok, au temps pour moi. Mais alors sur ma petite Debian Wheezy, je n'ai pas moyen de faire en sorte que le noyau suive par défaut le modèle dit « fort »... sauf en faisant des petites règles iptables à la mano ?
Il y a des paramètres sysctl par interface dans /proc/sys/net/ipv4/conf qui permettent de modifier le comportement par défaut face aux requêtes ARP, comme ignorer celles pour des adresses autres que l'interface d'arrivée. Mais cela n'affecte pas le comportement de la couche IP qui continue à accepter les paquets IP reçus par une interface avec l'adresse de destination d'une autre interface. A ma connaissance la seule solution contre cela est le filtrage.
Francois Lafont a écrit :
Ah ok, au temps pour moi. Mais alors sur ma petite Debian
Wheezy, je n'ai pas moyen de faire en sorte que le noyau
suive par défaut le modèle dit « fort »... sauf en faisant
des petites règles iptables à la mano ?
Il y a des paramètres sysctl par interface dans /proc/sys/net/ipv4/conf
qui permettent de modifier le comportement par défaut face aux requêtes
ARP, comme ignorer celles pour des adresses autres que l'interface
d'arrivée. Mais cela n'affecte pas le comportement de la couche IP qui
continue à accepter les paquets IP reçus par une interface avec
l'adresse de destination d'une autre interface. A ma connaissance la
seule solution contre cela est le filtrage.
Ah ok, au temps pour moi. Mais alors sur ma petite Debian Wheezy, je n'ai pas moyen de faire en sorte que le noyau suive par défaut le modèle dit « fort »... sauf en faisant des petites règles iptables à la mano ?
Il y a des paramètres sysctl par interface dans /proc/sys/net/ipv4/conf qui permettent de modifier le comportement par défaut face aux requêtes ARP, comme ignorer celles pour des adresses autres que l'interface d'arrivée. Mais cela n'affecte pas le comportement de la couche IP qui continue à accepter les paquets IP reçus par une interface avec l'adresse de destination d'une autre interface. A ma connaissance la seule solution contre cela est le filtrage.
