Re: ICMP Scan

[Chris Brenton <cbrenton () chrisbrenton org>]

On Tue, 2004-03-23 at 11:03, tim logan wrote:
> I saw this traffic last night on an IDS system inside a firewall.  Can 
> somebody shed some light on it? 

Per chance do you have full decodes? The payload should contain the
packet that supposedly elicited this response. You can decode the
payload and match this against your outbound logs.

I'm guessing you will not find a match however. The size seems a bit odd
to me. If memory servers its should be 56 bytes, not 112 bytes.

> 19:05:40.869387 68.186.254.202 > 1.2.3.4: icmp: 68.186.254.202 
> unreachable - need to frag (ttl 109, id 23236, len 112)

<snip>

> 19:05:40.896473 68.186.254.202 > 1.2.3.4: icmp: 68.186.254.202 
> unreachable - need to frag [ttl 1] (id 23236, len 112)

This looks a little bit like a reverse traceroute in that the TTL is
decrementing instead of incrementing. It would not be an effective trace
pattern however as any host receiving this unsolicited would quietly
drop it, pretty much the same effect as if it was being dropped by a
firewall (IP hosts don't respond to ICMP errors).

So choices are:
1) Lame attempt at tracing and the purp has not figured out it will not
work (seen this lots of times in the wild)
2) Some type of zombie communication. That would explain the over-sized
payload, but not the decrementing TTL's.

A full decode might be more helpful,
Chris



---------------------------------------------------------------------------
Free 30-day trial: firewall with virus/spam protection, URL filtering, VPN,
wireless security

Protect your network against hackers, viruses, spam and other risks with Astaro
Security Linux, the comprehensive security solution that combines six
applications in one software solution for ease of use and lower total cost of
ownership.

Download your free trial at 
http://www.securityfocus.com/sponsor/Astaro_incidents_040301
----------------------------------------------------------------------------