Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

RE: Localhost packets on WAN

Subject: RE: Localhost packets on WAN
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.

<Prev in Thread] Current Thread [Next in Thread>