RE: Localhost packets on WAN

From: James C Slora Jr (Jim.Slora_at_phra.com)
Date: 10/01/04

  • Next message: Kirby Angell: "Data Cha0s PHP script attempt" 
    To: "'Incidents List'" <incidents@securityfocus.com>
Date: Fri, 1 Oct 2004 09:44:42 -0400

    I apologize to the list for inflaming this topic with unclear language and a
    couple of factually incorrect misstatements in previous posts.

    I believe that I have a worthwhile point to make that was not effectively
    conveyed previously, and I ask that we start fresh.

    To clarify:

    These localhost-sourced packets cannot indicate a Blaster infection on the
    LAN because they occur on the WAN interface and have come in through the
    upstream router.

    They could be Blaster blowback from a remote network's infection, but they
    could also be any number of other things too.

    For this traffic to occur, the following conditions could apply:

    - A remote machine has traffic for certain sites redirected to localhost.
    This can be cause by misguided configuration or by any number of worms,
    bots, adware infections, etc.

    - The remote machine is generating SYNs to TCP 80 with a spoofed source IP
    address. Again, any number of DoS tools or infections (including Blaster)
    can generate that traffic.

    - One or more of the SYN targets happens to resolve to the localhost address
    based on the first condition.

    - Localhost traffic is not filtered on egress from the remote network.

    - Localhost traffic is not filtered by the upstream of the recipient of the
    RST ACK packet.

    Several tools could also generate the packets directly, but there probably
    would not be much point to this. It is easy to come up with other scenarios
    that could cause the traffic too.

    Given the large number of possibilities and given the fact that the packets
    come from a network outside the recipient's ability to monitor, asserting
    that these packets are from Blaster is akin to asserting that any IIS
    directory traversal attack is probably Nimda.

    My upstream on the network I previously mentioned has filtered, and
    continues to filter, localhost and other bogon traffic. Only one set of
    traffic with a very low assumed hop-count (based on TTL 125) is bypassing
    this filtering. I should have considered that this machine may be inside the
    upstream's filtering point for bogon traffic. Notifying the ISP was still
    the correct choice in my opinion because one possibility is that the traffic
    is passing contrary to the intentions of the ISP.

  • Next message: Kirby Angell: "Data Cha0s PHP script attempt"

    Relevant Pages

    • Re: [Full-disclosure] ICMP Security Vulnerabilities - NEW (cough)
      ... egress filtering based on the ICMP payload. ... When a host receives the request, ... >Allow the outbound echo request and inbound echo reply. ... >sender to slow down the rate it is sending packets. ...
      (Bugtraq)
    • Re: [Full-disclosure] ICMP Security Vulnerabilities - NEW (cough)
      ... egress filtering based on the ICMP payload. ... When a host receives the request, ... >Allow the outbound echo request and inbound echo reply. ... >sender to slow down the rate it is sending packets. ...
      (Full-Disclosure)
    • Re: spoofed packets to RFC 1918 addresses
      ... If there was widespread use of iingress/egress filtering we would probably ... > However, if the packets have a destination address in the RFC1918 space, I ... > your firewall or a compromise of something on the outside of your firewall. ... > and tracking system please see: http://aris.securityfocus.com ...
      (Incidents)
    • [patch] gsoc project: improving layer2 filtering
      ... This summer I was working on improving layer2 filtering (my mentor is ... +Table entry can contain optional ethernet address. ... further packets matching the rule that would ... +When enabled a special tag containing MAC header is appended to incoming ...
      (freebsd-net)
    • Compatibility problem: DFE-570TX (dc(4)) & Linksys router/switch
      ... Connect the router directly to a port on the Ethernet ... packets transmitted, 0 packets received, 100% packet loss ... tcpdump: listening on dc2 ... localhost# tcpdump -lni dc2 ...
      (freebsd-net)