Je ne vois pas comment il pourrait en être autrement pour un datagramme qui vient de l'extérieur. D'un point de vue ethernet, le réseau se limite entre ton ordinateur et la freebox.
Euh non, du point de vue réseau la freebox est un pont transparent. Donc le trafic réseau aura comme adresse source le concentrateur de free.
Jonathan ILIAS <ismael.ilias@wanadoo.fr> écrivait :
Je ne vois pas comment il pourrait en être autrement pour un
datagramme qui vient de l'extérieur. D'un point de vue ethernet, le
réseau se limite entre ton ordinateur et la freebox.
Euh non, du point de vue réseau la freebox est un pont
transparent. Donc le trafic réseau aura comme adresse source le
concentrateur de free.
Je ne vois pas comment il pourrait en être autrement pour un datagramme qui vient de l'extérieur. D'un point de vue ethernet, le réseau se limite entre ton ordinateur et la freebox.
Euh non, du point de vue réseau la freebox est un pont transparent. Donc le trafic réseau aura comme adresse source le concentrateur de free.
Thomas Labourdette
Bonjour, In article <070920030920072740%, Ronald Van Assche wrote:
Moi du coup, je vais mettre la regle en ### dans snort, sinon ca pollue mes logs.
En parlant de log, je n'arrive pas à les tracer avec netfilter. Voici le début de la chaine INPUT
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 127.0.0.1 127.0.0.1 0 0 LOG all -- ppp0 * 127.0.0.1 0.0.0.0/0 0 0 DROP all -- ppp0 * 127.0.0.1 0.0.0.0/0
Snort les voies et je vois les trames avec tcpdump.
rp_filter sur l'interface ppp0 est à 0 (pas de spoofprotect). Linux kernel 2.4.17.
Qu'elle est l'erreur dans ma chaine INPUT ?
Tant que j'y suis, y a-t-il une option à configurer pour avoir les /log_martians/ ? La mise à 1 de net/ipv4/conf/all/log_martians ne détecte pas les paquets ayant pour source 127.0.0.1.
Merci. -- Thomas Labourdette Est ce que les grands brules ont une reduction au crematorium ?
Bonjour,
In article <070920030920072740%ronald@branlos.org>, Ronald Van Assche wrote:
Moi du coup, je vais mettre la regle en ### dans snort, sinon ca
pollue mes logs.
En parlant de log, je n'arrive pas à les tracer avec netfilter.
Voici le début de la chaine INPUT
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 127.0.0.1 127.0.0.1
0 0 LOG all -- ppp0 * 127.0.0.1 0.0.0.0/0
0 0 DROP all -- ppp0 * 127.0.0.1 0.0.0.0/0
Snort les voies et je vois les trames avec tcpdump.
rp_filter sur l'interface ppp0 est à 0 (pas de spoofprotect). Linux
kernel 2.4.17.
Qu'elle est l'erreur dans ma chaine INPUT ?
Tant que j'y suis, y a-t-il une option à configurer pour avoir les
/log_martians/ ? La mise à 1 de net/ipv4/conf/all/log_martians ne
détecte pas les paquets ayant pour source 127.0.0.1.
Merci.
--
Thomas Labourdette
Est ce que les grands brules ont une reduction au crematorium ?
Bonjour, In article <070920030920072740%, Ronald Van Assche wrote:
Moi du coup, je vais mettre la regle en ### dans snort, sinon ca pollue mes logs.
En parlant de log, je n'arrive pas à les tracer avec netfilter. Voici le début de la chaine INPUT
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 127.0.0.1 127.0.0.1 0 0 LOG all -- ppp0 * 127.0.0.1 0.0.0.0/0 0 0 DROP all -- ppp0 * 127.0.0.1 0.0.0.0/0
Snort les voies et je vois les trames avec tcpdump.
rp_filter sur l'interface ppp0 est à 0 (pas de spoofprotect). Linux kernel 2.4.17.
Qu'elle est l'erreur dans ma chaine INPUT ?
Tant que j'y suis, y a-t-il une option à configurer pour avoir les /log_martians/ ? La mise à 1 de net/ipv4/conf/all/log_martians ne détecte pas les paquets ayant pour source 127.0.0.1.
Merci. -- Thomas Labourdette Est ce que les grands brules ont une reduction au crematorium ?
Bruno Hardy
Dominique Ottello wrote:
Dominique Ottello écrivait :
Idem pour moi : Freebox sur carte Ethernet et pourtant les logs de Lokk'n'Stop foisonnent, depuis le 26 août 2003, de
D xxx 'Stateful Packet Inspection' 127.0.0.1 TCP
avec toujours comme source Src:www-http et des numéros variables de ports destinataires comme 1489, 1140, 1518, 1955, 1082, 1134, 1935
En fouillant un peu plus profondément, il s'avère que les adresses MAC source et destination sont toujours les mêmes et sont, pour la destination celle de ma carte Ethernet et comme source celle de la Freebox ADSL.
Et, la date du 26 août 2003 correspond à celle d'activation de la fonction téléphone de ma Freebox par demande d'affectation d'un numéro.
Idem pour moi, sous Mandrake 9.0. Et chez FreeAdsl en IP/ADSL. En scannant mes logs, il apparait que ces trames sont apparus le 25 aout à 20H14.
[ /root]# tail -20 /var/log/messages Sep 8 23:26:56 routeur kernel: device ppp0 entered promiscuous mode Sep 8 23:27:22 routeur kernel: martian source 82.65.120.212 from 127.0.0.1, on dev ppp0 Sep 8 23:27:22 routeur kernel: ll header: 45:00:00:28:cf:da:00:00 Sep 8 23:27:25 routeur kernel: martian source 82.65.120.212 from 127.0.0.1, on dev ppp0 Sep 8 23:27:25 routeur kernel: ll header: 45:00:00:28:26:8f:00:00 Sep 8 23:27:30 routeur kernel: martian source 82.65.120.212 from 127.0.0.1, on dev ppp0 Sep 8 23:27:30 routeur kernel: ll header: 45:00:00:28:2d:e4:00:00 Sep 8 23:28:11 routeur kernel: device ppp0 left promiscuous mode [ /root]#
Pas d'explications, même avec ethereal. D'autant plus que les trames envoyées par 127.0.0.1 sur le port 80 sont toujours pour envoyer un RESET. Encore plus bizarre, un tcpdump sur lo ne voit rien :
[ /root]# tcpdump -i lo tcpdump: listening on lo
0 packets received by filter 0 packets dropped by kernel [ /root]#
si ce n'est pas "grave", comment arrêter de logguer, ça me pourrit mes logs ? en modifiant /etc/sysctl ? net.ipv4.conf.all.log_martians=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.default.rp_filter=1
Idem pour moi : Freebox sur carte Ethernet et pourtant les logs de
Lokk'n'Stop foisonnent, depuis le 26 août 2003, de
D xxx 'Stateful Packet Inspection' 127.0.0.1 TCP
avec toujours comme source Src:www-http et des numéros variables de
ports destinataires comme 1489, 1140, 1518, 1955, 1082, 1134, 1935
En fouillant un peu plus profondément, il s'avère que les adresses MAC
source et destination sont toujours les mêmes et sont, pour la
destination celle de ma carte Ethernet et comme source celle de la
Freebox ADSL.
Et, la date du 26 août 2003 correspond à celle d'activation de la
fonction téléphone de ma Freebox par demande d'affectation d'un numéro.
Idem pour moi, sous Mandrake 9.0. Et chez FreeAdsl en IP/ADSL.
En scannant mes logs, il apparait que ces trames sont apparus
le 25 aout à 20H14.
[root@routeur /root]# tail -20 /var/log/messages
Sep 8 23:26:56 routeur kernel: device ppp0 entered promiscuous mode
Sep 8 23:27:22 routeur kernel: martian source 82.65.120.212 from 127.0.0.1,
on dev ppp0
Sep 8 23:27:22 routeur kernel: ll header: 45:00:00:28:cf:da:00:00
Sep 8 23:27:25 routeur kernel: martian source 82.65.120.212 from 127.0.0.1,
on dev ppp0
Sep 8 23:27:25 routeur kernel: ll header: 45:00:00:28:26:8f:00:00
Sep 8 23:27:30 routeur kernel: martian source 82.65.120.212 from 127.0.0.1,
on dev ppp0
Sep 8 23:27:30 routeur kernel: ll header: 45:00:00:28:2d:e4:00:00
Sep 8 23:28:11 routeur kernel: device ppp0 left promiscuous mode
[root@routeur /root]#
Pas d'explications, même avec ethereal.
D'autant plus que les trames envoyées par 127.0.0.1 sur le port 80 sont
toujours pour envoyer un RESET.
Encore plus bizarre, un tcpdump sur lo ne voit rien :
[root@routeur /root]# tcpdump -i lo
tcpdump: listening on lo
0 packets received by filter
0 packets dropped by kernel
[root@routeur /root]#
si ce n'est pas "grave", comment arrêter de logguer, ça me pourrit mes logs
?
en modifiant /etc/sysctl ?
net.ipv4.conf.all.log_martians=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
Idem pour moi : Freebox sur carte Ethernet et pourtant les logs de Lokk'n'Stop foisonnent, depuis le 26 août 2003, de
D xxx 'Stateful Packet Inspection' 127.0.0.1 TCP
avec toujours comme source Src:www-http et des numéros variables de ports destinataires comme 1489, 1140, 1518, 1955, 1082, 1134, 1935
En fouillant un peu plus profondément, il s'avère que les adresses MAC source et destination sont toujours les mêmes et sont, pour la destination celle de ma carte Ethernet et comme source celle de la Freebox ADSL.
Et, la date du 26 août 2003 correspond à celle d'activation de la fonction téléphone de ma Freebox par demande d'affectation d'un numéro.
Idem pour moi, sous Mandrake 9.0. Et chez FreeAdsl en IP/ADSL. En scannant mes logs, il apparait que ces trames sont apparus le 25 aout à 20H14.
[ /root]# tail -20 /var/log/messages Sep 8 23:26:56 routeur kernel: device ppp0 entered promiscuous mode Sep 8 23:27:22 routeur kernel: martian source 82.65.120.212 from 127.0.0.1, on dev ppp0 Sep 8 23:27:22 routeur kernel: ll header: 45:00:00:28:cf:da:00:00 Sep 8 23:27:25 routeur kernel: martian source 82.65.120.212 from 127.0.0.1, on dev ppp0 Sep 8 23:27:25 routeur kernel: ll header: 45:00:00:28:26:8f:00:00 Sep 8 23:27:30 routeur kernel: martian source 82.65.120.212 from 127.0.0.1, on dev ppp0 Sep 8 23:27:30 routeur kernel: ll header: 45:00:00:28:2d:e4:00:00 Sep 8 23:28:11 routeur kernel: device ppp0 left promiscuous mode [ /root]#
Pas d'explications, même avec ethereal. D'autant plus que les trames envoyées par 127.0.0.1 sur le port 80 sont toujours pour envoyer un RESET. Encore plus bizarre, un tcpdump sur lo ne voit rien :
[ /root]# tcpdump -i lo tcpdump: listening on lo
0 packets received by filter 0 packets dropped by kernel [ /root]#
si ce n'est pas "grave", comment arrêter de logguer, ça me pourrit mes logs ? en modifiant /etc/sysctl ? net.ipv4.conf.all.log_martians=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.default.rp_filter=1
Regis ARCHAMBAULT
a écrit:
[à propos de trafic loopback=>interface externe]
Pas d'explications, même avec ethereal.
Il y en a peut-être une ici: <URL:http://snurl.com/2adq> Ca viendrait du ver Blaster.
D'autant plus que les trames envoyées par 127.0.0.1 sur le port 80 sont toujours pour envoyer un RESET.
Cohérent avec l'explication ci-dessus.
Encore plus bizarre, un tcpdump sur lo ne voit rien :
Ca me paraît normal vu que les paquets arrivent sur ppp0.
si ce n'est pas "grave", comment arrêter de logguer, ça me pourrit mes logs ? en modifiant /etc/sysctl ? net.ipv4.conf.all.log_martians=1
Oui, et echo 0 > /proc/sys/net/ipv4/conf/all/log_martians devrait le faire aussi sans avoir à rebooter.
-- BOFH excuse #1:
clock speed
<hbruno@free.fr> a écrit:
[à propos de trafic loopback=>interface externe]
Pas d'explications, même avec ethereal.
Il y en a peut-être une ici: <URL:http://snurl.com/2adq>
Ca viendrait du ver Blaster.
D'autant plus que les trames envoyées par 127.0.0.1 sur le port 80 sont
toujours pour envoyer un RESET.
Cohérent avec l'explication ci-dessus.
Encore plus bizarre, un tcpdump sur lo ne voit rien :
Ca me paraît normal vu que les paquets arrivent sur ppp0.
si ce n'est pas "grave", comment arrêter de logguer, ça me pourrit mes logs
?
en modifiant /etc/sysctl ?
net.ipv4.conf.all.log_martians=1
Oui, et
echo 0 > /proc/sys/net/ipv4/conf/all/log_martians
devrait le faire aussi sans avoir à rebooter.
Il y en a peut-être une ici: <URL:http://snurl.com/2adq> Ca viendrait du ver Blaster.
D'autant plus que les trames envoyées par 127.0.0.1 sur le port 80 sont toujours pour envoyer un RESET.
Cohérent avec l'explication ci-dessus.
Encore plus bizarre, un tcpdump sur lo ne voit rien :
Ca me paraît normal vu que les paquets arrivent sur ppp0.
si ce n'est pas "grave", comment arrêter de logguer, ça me pourrit mes logs ? en modifiant /etc/sysctl ? net.ipv4.conf.all.log_martians=1
Oui, et echo 0 > /proc/sys/net/ipv4/conf/all/log_martians devrait le faire aussi sans avoir à rebooter.
-- BOFH excuse #1:
clock speed
nico
Bonjour, visiblement depuis deux semaines certaines personnes abonnées au FAI Free rencontre ce problème, d'après ce fil de discussion. Je suis egalement abonné à Free (50h en Numeris) et j'ai egalement ces logs intempestifs dans mon syslog. Là où cela est vraiment génant, c'est que vu que mon interface ippp0 voit du traffic, elle ne raccroche pas automatiquement comme elle le faisait avant !!
J'ai appelé Free (20 min d'attente :-( ) en leur demandant s'ils n'avaient pas bricolé un truc sur leurs routeurs, mais bien sûr "cela ne vient pas de chez eux"
Pour ceux qui voudraient envoyer un mail :
nico
Bonjour,
visiblement depuis deux semaines certaines personnes abonnées au FAI
Free rencontre ce problème, d'après ce fil de discussion. Je suis
egalement abonné à Free (50h en Numeris) et j'ai egalement ces logs
intempestifs dans mon syslog. Là où cela est vraiment génant, c'est que
vu que mon interface ippp0 voit du traffic, elle ne raccroche pas
automatiquement comme elle le faisait avant !!
J'ai appelé Free (20 min d'attente :-( ) en leur demandant s'ils
n'avaient pas bricolé un truc sur leurs routeurs, mais bien sûr "cela
ne vient pas de chez eux"
Pour ceux qui voudraient envoyer un mail : hotline@free.Fr
Bonjour, visiblement depuis deux semaines certaines personnes abonnées au FAI Free rencontre ce problème, d'après ce fil de discussion. Je suis egalement abonné à Free (50h en Numeris) et j'ai egalement ces logs intempestifs dans mon syslog. Là où cela est vraiment génant, c'est que vu que mon interface ippp0 voit du traffic, elle ne raccroche pas automatiquement comme elle le faisait avant !!
J'ai appelé Free (20 min d'attente :-( ) en leur demandant s'ils n'avaient pas bricolé un truc sur leurs routeurs, mais bien sûr "cela ne vient pas de chez eux"
Pour ceux qui voudraient envoyer un mail :
nico
Philippe Ladame
En nico a écrit récemment :
J'ai appelé Free (20 min d'attente :-( ) en leur demandant s'ils n'avaient pas bricolé un truc sur leurs routeurs, mais bien sûr "cela ne vient pas de chez eux"
Effectivement. C'est avec une connexion Wanadoo que j'ai constaté le phénomène que j'évoquais.
-- Cordialement Philippe Ladame
En <20030912190906.7121e678.stealthy@directbox.com> nico a écrit
récemment :
J'ai appelé Free (20 min d'attente :-( ) en leur demandant s'ils
n'avaient pas bricolé un truc sur leurs routeurs, mais bien sûr "cela
ne vient pas de chez eux"
Effectivement. C'est avec une connexion Wanadoo que j'ai constaté le
phénomène que j'évoquais.
J'ai appelé Free (20 min d'attente :-( ) en leur demandant s'ils n'avaient pas bricolé un truc sur leurs routeurs, mais bien sûr "cela ne vient pas de chez eux"
Effectivement. C'est avec une connexion Wanadoo que j'ai constaté le phénomène que j'évoquais.
