Gracias a todos por las respuestas. Respecto al mail de Cristoph me gustar�a replicar, jeje.
>> Desde hace alg�n tiempo me salen repetidamente estos mensajes en el >> var/log/syslog y en la pantalla. > >> >Mar 24 02:15:56 puck kernel: martian source X.X.X.181 from 127.0.0.1, on dev eth0 >> Mar 24 02:15:56 puck kernel: ll header: 00:40:f4:74:47:cd:00:02:fc:85:30:70:08:00 > >"martians" son paquetes de datos que vienen de un lugar desde donde no >pueden venir. La interface local lookback (127.0.0.1) no emite ningun >paquete con el IP x.x.x.181, sin embargo el kernel ha recebido un >paquete que parece haber salido de 127.0.0.1 pero tiene como remitente >una direci�n diferente. Como has tapado los d�gitos con x.x.x supongo >que conoces esta direcci�n, talvez es la de tu interface interna o >externa. Esto huele a un problema de configuraci�n. Algun NAT o >redireccionamiento que en este caso particular no hace sentido al >kernel. pues yo creo al 99'99% que no es fallo m�o ;) Aunque, como ves, dejo algo de duda. B�sicamente porque s�lo me sale desde hace poco tiempo, y llevo el firewall-proxy funcionando m�s de dos a�os. El mensaje que me llega a syslog es este: Mar 24 02:15:56 puck kernel: martian source X.X.X.181 from 127.0.0.1, on dev eth0 Mar 24 02:15:56 puck kernel: ll header: 00:40:f4:74:47:cd:00:02:fc:85:30:70:08:00 Donde X.X.X.181 es la direcci�n de mi interfaz eth0, una direcci�n que me asigna mi ISP v�a DHCP, pongo las X porque quiero discrecci�n ;)� Los mensajes quieren decir que me llegan paquetes al eth0 con estos detalles: @IP origen: 127.0.0.1 @MAC origen: 00:02:fc:85:30:70 @IP destino: X.X.X.181 <-- mi IP en eth0 @MAC destino: 00:40:f4:74:47:cd <-- mi MAC en eth0 Como he dicho, la MAC origen la he localizado en una m�quina de la red de mi ISP. Es decir, los paquetes me llegan desde fuera!, no s� como decirlo. >> El ordenador hace proxy (iptables-NAT) con eth0 la salida a internet >> y eth1 conectado a la red privada. > >Aqui puede estar el problema. Revisa tus reglas para ver si aplican a >situaciones no pretendidas. Adjunto mi script de firewall-nat. Aunque no tengo nada estra�o: algunas redirecciones, alguna redirecci�n tambi�n, permito s�lo ssh cerrando lo dem�s.redirecci�n tambi�n. >> He estado investigando y los martians son paquetes con direcci�n >> imposible, en este caso los recibo en eth0, conteniendo como >> direcci�n origen la direcci�n de loopback 127.0.0.1. > >Esto es correcto. Probablemente sea el resultado de un error en alguna >regla. En esto discrepo. He snifado con tcpdump y he instalado snort para ver los logs. Los paquetes se reciben en eth0, desde fuera, estoy seguro y los logs me lo confirman. Adem�s, vienen desde una MAC que he localizado en un hosts de la red mi ISP. >> S� si pongo "echo 0 > /proc/sys/net/ipv4/conf/all/log_martians" >> desactivar� los mensajes, pero lo que me gustar�a saber es si existe >> otra forma de solventar el problema o averiguar un poco m�s acerca >> de qu� est� pasando. > >Bueno, si el coche hace un ruido raro, yo tambi�n subo la r�dio Pero >yo creo que deberias mirarte lo que has hecho. Aplicando tu s�mil: he revisado el coche, le he puesto chivatos y nada. Por �ltimo he puesto un silenciador. >> He probado a poner reglas en el iptables que me rechacen estos >> paquetes pero se ve que no llega a iptables, los mensajes son del >> propio kernel y es este el que los rechaza. > >Estoy 99% seguro que la fuente de estos marcionos eres t� mismo. A esto ya te he contestado. >> Trasteando con ettercap he visto que MAC origen 00:02:fc:85:30:70 >> corresponde a la direcci�n X.X.X.1, que parece ser el gateway que me >> da mi ISP (menta). Pero en las tablas arp aparece esto: > >> docsX-X.menta.net (X.X.X.1) at 00:02:FC:85:30:54 [ether] on eth0 > >Nunca confies en ning�n IP/MAC que pertenece a alguien fuera de tu >control, especialmente a un ISP grande, porque muchas veces hacen un >load balancing o algunos obst�culos para que no puedas hacer lo que no >quieren que hagas. Durante un tiempo, a la Telef�nica aqui le gustaba >causar un flip/flop, o sea que un IP cambia de MAC y vuelta a la MAC >anterior un poco mas tarde (ciclicamente). Tampoco puedes asumir que >la respuesta de un paquete viene por el mismo camino en que se fue la >pregunta. Esto est� explicitamente permitido en los protocolos IP. Tomo nota. >> Es decir, una mac distinta para la misma ip. No s� si alguien est� >> intentando suplantar la mac o es problema del cable-modem... > >Tienes control sobre tus m�quinas. No puede controlar la MAC de >otros. Una MAC puede estar para mas que un IP y un IP en mas de un >MAC. Esto no es ninguna violaci�n de los est�ndares. Bueno, por lo general 1 IP <-> 1 MAC. Si bien es cierto que existen Proxys ARP y que, por otro lado, puedes configurar una ethernet con m�s de una IP. Pero si cuando env�as una petici�n ARP s�lo una contesta, cuando lo hacen 2 mal asunto, querr�a decir que alguien est� intentando spoofear. >> Hasta ahora s�lo he desactivado los mensajes porque era muy molesto, >> pero me interesar�a saber si existe otra posiblidad de solventar el >> problema. La situaci�n es muy extra�a y quisiera saber si alguno de >> vosotros os habe�s encontrado en circustancias parecidas y si lo >> habe�s solucionado de otra forma. Otra cosa que no entiendo es que >> hace el gateway de mi ISP enviandome estos paquetes... > >Si. Piensa-te bien como funcionan tus reglas de NAT. De lo que dices >es el primer punto donde miraria yo. Mis reglas NAT son una regla solamente. No creo que el enmascaramiento tenga m�s historia. Adem�s, el enmascaramiento consigue que mi proxy act�e como intermediario, si fuese problema de las reglas NAT estos mensajes se trasladar�an dentro mi propia LAN. Vuelvo a repetir, el problema es que recibo paquetes desde el exterior, en mi eth0, con direcci�n IP de origen 127.0.0.1, que es imposible. Buscando por internet a bastante gente le pasa y suele corresponder con alg�n graciosillo que se est� intentando divertir. No s� que tienen que ver mis reglas en esto y, la verdad, tampoco s� como tendr�a que configurar IPTABLES para conseguir el mismo efecto, por criterios de simplicidad sigo pensanso que no es mi problema. ;) A�n as� adjunto mi script por si so�s capaces de ver algo que pueda ser el origen del problema, en cuyo caso tendr� que retractarme de todo lo dicho. Casi que prefiero que sea eso, as� lo solucionar�a de forma m�s f�cil. >Christoph Simon Angel Viudez
