On Tuesday 25 May 2004 23:10, Valentino Squilloni - Ouz wrote:
On Tue, 25 May 2004, Maarten wrote:
Not saying what you see must be wrong but, if your routing / packetfilter
/ kernelsettings were properly configured you would not ever get these
packets as they would be dropped before they would reach your machine.
That's true. But maybe the OP dropped those packets (perhaps he does't
know :-); i think so because he's speaking of logs.
Possible... but we lack evidence now so there is little point in guessing.
Especially 127.x.x.x is not routed by any ISP which is worth their name.
But I've seen a lot of times those packet, especially the last year with
blaster and DNS servers which resolved microsoftupdate.com in 127.0.0.1 to
try to stop the DOS generated by blaster.
Okay, let's analyse what you say here. Say your machine is looking for
microsoftupdate.com. It asks a DNS server and the reply is: 127.0.0.1.
So then your machine starts connecting with... 127.0.0.1. Whether it will
succeed in that or not is wholly dependant on whether your local box is
running a http server, but that is beside the point: in this scenario, at no
point will you see 127.0.0.1 at your _outside_ interface, incoming nor
outgoing...
In that case you saw packets coming to your ppp0, tun0 or whatsoever
coming from 127.0.0.1:80
Not according to my analysis above. The DNS answers "127.0.0.1" but the packet
headers of said answer still carry legal IP addresses; your own address and
the DNS servers' address. The 127.0.0.1 packets will never leave your box.
In any and all cases the statement above about your uplink ISP that should
never route localhost addresses also still holds true.
Maarten
Ouz
--
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
