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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
