Re: [Full-Disclosure] Odd packet?

From: Maarten (fulldisc_at_ultratux.org)
Date: 05/26/04

  • Next message: Maarten: "Re: [Full-Disclosure] Odd packet?"
    To: full-disclosure@lists.netsys.com
    Date: Wed, 26 May 2004 01:10:47 +0200
    
    

    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
    

  • Next message: Maarten: "Re: [Full-Disclosure] Odd packet?"

    Relevant Pages

    • Re: DNS Amplification Attacks... and a trivial proposal
      ... A new DNS/UDP packet/message type is defined. ... highly abbreviated DNS/UDP response packets would all have the TC ... so the DDoS victim should, be able to squeeze that out, I think. ... B (i.e. one of the unwitting DNS servers that are participating as ...
      (comp.protocols.dns.bind)
    • Re: FW: [Full-Disclosure] Question for DNS pros
      ... most sites use local forwarding DNS servers that do the ... What is strange, though, is the fact that the load-balancer sent those ... packets without actually receiving a request. ... load-balancer is just unsolicited probes. ...
      (Full-Disclosure)
    • IE6 Search Hijack
      ... The pc with XP Pro was then always trying to send tcp packets to IP ... Specified my ISP's DNS Servers in the Network and Internet ... I did this because the symptoms seemed DNS related. ... Adjusted Windows XP DNS Cache Settings. ...
      (microsoft.public.windows.inetexplorer.ie6.browser)
    • Re: Misconfigured DNS, firewall too tight or (spoofed?) attack?
      ... > messages of my first post. ... >> Within 10 seconds there were about 900 packets blocked. ... Check out the source of the packets, see if they're all DNS servers. ... you're being used as a fake source for scanning DNS servers. ...
      (comp.security.firewalls)
    • Re: DNS with IPTables Problem
      ... the traffic from the real world to the DNS servers and ... back is not related to the firewall being worked on at this point. ... the privately addressed network. ... Packets that pass through the firewall ...
      (comp.os.linux.security)