Security Incidents mailing list archives

RE: Localhost packets on WAN


From: "James C Slora Jr" <Jim.Slora () phra 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.


Current thread: