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.
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.
intéressant et, ouf, rassurant :)
Ceci dit, le paquet à destination de 127.0.0.1 et ayant pour IP source 172.3.0.x , paquet qui est une ouverture de session TCP (SYN) doit être pris normalement en compte par le noyau ("netstat --inet" doit indiquer une connexion SYN_RECV) ce qui peut conduire par abus de ce type de paquet à un déni de service (hors syncookies ou autre fonctionnalité du même genre activé sur la cible). C'est vraisemblablement la réponse (SYN+ACK) qui n'est pas émise vers l'interface physique mais via l'interface loopback vue que l'IP source est 127.0.0.1 et là ça ne risque pas de sortir de l'hôte attaqué.
merci d'avoir réalisé ce test, que je n'ai pas les moyens de faire sur mes serveurs en production.
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.
intéressant et, ouf, rassurant :)
Ceci dit, le paquet à destination de 127.0.0.1 et ayant pour IP source
172.3.0.x , paquet qui est une ouverture de session TCP (SYN) doit être
pris normalement en compte par le noyau ("netstat --inet" doit indiquer
une connexion SYN_RECV) ce qui peut conduire par abus de ce type de
paquet à un déni de service (hors syncookies ou autre fonctionnalité du
même genre activé sur la cible). C'est vraisemblablement la réponse
(SYN+ACK) qui n'est pas émise vers l'interface physique mais via
l'interface loopback vue que l'IP source est 127.0.0.1 et là ça ne
risque pas de sortir de l'hôte attaqué.
merci d'avoir réalisé ce test, que je n'ai pas les moyens de faire sur
mes serveurs en production.
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.
intéressant et, ouf, rassurant :)
Ceci dit, le paquet à destination de 127.0.0.1 et ayant pour IP source 172.3.0.x , paquet qui est une ouverture de session TCP (SYN) doit être pris normalement en compte par le noyau ("netstat --inet" doit indiquer une connexion SYN_RECV) ce qui peut conduire par abus de ce type de paquet à un déni de service (hors syncookies ou autre fonctionnalité du même genre activé sur la cible). C'est vraisemblablement la réponse (SYN+ACK) qui n'est pas émise vers l'interface physique mais via l'interface loopback vue que l'IP source est 127.0.0.1 et là ça ne risque pas de sortir de l'hôte attaqué.
merci d'avoir réalisé ce test, que je n'ai pas les moyens de faire sur mes serveurs en production.
Cordialement, Joe The Perfide.
Pascal Hambourg
Joe The Smoe a écrit :
Le 28/05/2014 02:18, Francois Lafont a écrit :
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.
Ceci dit, le paquet à destination de 127.0.0.1 et ayant pour IP source 172.3.0.x , paquet qui est une ouverture de session TCP (SYN) doit être pris normalement en compte par le noyau ("netstat --inet" doit indiquer une connexion SYN_RECV)
Non, le paquet est considéré comme "martien" et détruit avant d'atteindre la couche TCP.
ce qui peut conduire par abus de ce type de paquet à un déni de service (hors syncookies ou autre fonctionnalité du même genre activé sur la cible).
Aucun risque de ce côté.
C'est vraisemblablement la réponse (SYN+ACK) qui n'est pas émise vers l'interface physique mais via l'interface loopback vue que l'IP source est 127.0.0.1 et là ça ne risque pas de sortir de l'hôte attaqué.
Le routage et la sélection de l'interface de sortie par défaut se basent uniquement sur l'adresse de destination, pas l'adresse source. Cette adresse étant extérieure, si un tel paquet devait être émis il serait routé par l'interface physique. Mais là encore il serait bloqué à cause de son adresse source en 127.0.0.0/8. Je l'ai vérifié.
Joe The Smoe a écrit :
Le 28/05/2014 02:18, Francois Lafont a écrit :
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.
Ceci dit, le paquet à destination de 127.0.0.1 et ayant pour IP source
172.3.0.x , paquet qui est une ouverture de session TCP (SYN) doit être
pris normalement en compte par le noyau ("netstat --inet" doit indiquer
une connexion SYN_RECV)
Non, le paquet est considéré comme "martien" et détruit avant
d'atteindre la couche TCP.
ce qui peut conduire par abus de ce type de
paquet à un déni de service (hors syncookies ou autre fonctionnalité du
même genre activé sur la cible).
Aucun risque de ce côté.
C'est vraisemblablement la réponse
(SYN+ACK) qui n'est pas émise vers l'interface physique mais via
l'interface loopback vue que l'IP source est 127.0.0.1 et là ça ne
risque pas de sortir de l'hôte attaqué.
Le routage et la sélection de l'interface de sortie par défaut se basent
uniquement sur l'adresse de destination, pas l'adresse source. Cette
adresse étant extérieure, si un tel paquet devait être émis il serait
routé par l'interface physique. Mais là encore il serait bloqué à cause
de son adresse source en 127.0.0.0/8. Je l'ai vérifié.
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.
Ceci dit, le paquet à destination de 127.0.0.1 et ayant pour IP source 172.3.0.x , paquet qui est une ouverture de session TCP (SYN) doit être pris normalement en compte par le noyau ("netstat --inet" doit indiquer une connexion SYN_RECV)
Non, le paquet est considéré comme "martien" et détruit avant d'atteindre la couche TCP.
ce qui peut conduire par abus de ce type de paquet à un déni de service (hors syncookies ou autre fonctionnalité du même genre activé sur la cible).
Aucun risque de ce côté.
C'est vraisemblablement la réponse (SYN+ACK) qui n'est pas émise vers l'interface physique mais via l'interface loopback vue que l'IP source est 127.0.0.1 et là ça ne risque pas de sortir de l'hôte attaqué.
Le routage et la sélection de l'interface de sortie par défaut se basent uniquement sur l'adresse de destination, pas l'adresse source. Cette adresse étant extérieure, si un tel paquet devait être émis il serait routé par l'interface physique. Mais là encore il serait bloqué à cause de son adresse source en 127.0.0.0/8. Je l'ai vérifié.
Francois Lafont
Bonsoir,
Le 28/05/2014 10:01, Pascal Hambourg 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.
Oui, ce fil m'a permis de découvrir également cette « siouxerie » supplémentaire. En même temps, le fait que par défaut une interface puisse répondre à une requête ARP qui ne la concerne pas directement est assez cohérent avec le modèle « faible » choisi par le noyau Linux.
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.
Ok, tant pis. Merci beaucoup pour toutes ces précisions.
À+
-- François Lafont
Bonsoir,
Le 28/05/2014 10:01, Pascal Hambourg 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.
Oui, ce fil m'a permis de découvrir également cette « siouxerie »
supplémentaire. En même temps, le fait que par défaut une interface
puisse répondre à une requête ARP qui ne la concerne pas directement
est assez cohérent avec le modèle « faible » choisi par le noyau
Linux.
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.
Ok, tant pis.
Merci beaucoup pour toutes ces précisions.
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.
Oui, ce fil m'a permis de découvrir également cette « siouxerie » supplémentaire. En même temps, le fait que par défaut une interface puisse répondre à une requête ARP qui ne la concerne pas directement est assez cohérent avec le modèle « faible » choisi par le noyau Linux.
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.
Ok, tant pis. Merci beaucoup pour toutes ces précisions.
