unexpected ICMP host unreachable - no worries?

unexpected ICMP host unreachable - no worries?

Post by The Ambivalent DM » Fri, 29 Mar 2002 10:13:02



Okay, I've seen quite a few of these coming from
107.ATM2-0.BR5.CHI2.ALTER.NET and more recently
ix-8-0-1.bb8.newyork.teleglobe.net:

SRC=204.255.169.17 DST=(my host) LEN=56 TOS=0x00 PREC=0x00 TTL=242 ID=0
PROTO=ICMP TYPE=3 CODE=1 [SRC=(my host) DST=(a target?) LEN=40 TOS=0x00
PREC=0x00 TTL=27 ID=22372 PROTO=TCP INCOMPLETE [8 bytes] ]

Host unreachable for some machine somewhere - but of course the machine
getting these hasn't been trying to reach the address in question. As an
experiment I logged the traffic on the machine that's getting this - sure
enough, these turn up out of the blue. They also appear to have the wrong
characteristics to have originated on the machine in question, but that's a
minor matter.

What I'm guessing is that this is nothing more than me picking up the
background from large attacks bounced off these routers and I'm getting
occasional fallout when the target goes down and a packet with a random
spoofed source address happens to coincide with that of one of my machines.

To ease my mind - sound likely? Anyone else seeing this at the moment?

--
DMZ  mhm33x4

<this mind left intentionally blank>

 
 
 

unexpected ICMP host unreachable - no worries?

Post by Tim Hayne » Fri, 29 Mar 2002 16:59:23



Quote:> SRC=204.255.169.17 DST=(my host) LEN=56 TOS=0x00 PREC=0x00 TTL=242 ID=0
> PROTO=ICMP TYPE=3 CODE=1 [SRC=(my host) DST=(a target?) LEN=40 TOS=0x00
> PREC=0x00 TTL=27 ID=22372 PROTO=TCP INCOMPLETE [8 bytes] ]

> Host unreachable for some machine somewhere - but of course the machine
> getting these hasn't been trying to reach the address in question. As an
> experiment I logged the traffic on the machine that's getting this - sure
> enough, these turn up out of the blue. They also appear to have the wrong
> characteristics to have originated on the machine in question, but that's
> a minor matter.

You don't have to be aiming for the *machine* in question, but for a
network behind it.

More importantly, what OS is the box that's giving these packets off? 'Cos
I thought normally you'd expect to see headers from the originating packet
copied inside the ICMP error packet, but it's not playing ball on this
occasion, hence the `INCOMPLETE'.

~Tim
--
  07:57:20 up 141 days,  9:37,  3 users,  load average: 0.15, 0.12, 0.09

http://piglet.is.dreaming.org     |The apple must fall to the ground

 
 
 

unexpected ICMP host unreachable - no worries?

Post by The Ambivalent DM » Fri, 29 Mar 2002 18:43:03




> > SRC=204.255.169.17 DST=(my host) LEN=56 TOS=0x00 PREC=0x00 TTL=242 ID=0
> > PROTO=ICMP TYPE=3 CODE=1 [SRC=(my host) DST=(a target?) LEN=40 TOS=0x00
> > PREC=0x00 TTL=27 ID=22372 PROTO=TCP INCOMPLETE [8 bytes] ]

> > Host unreachable for some machine somewhere - but of course the machine
> > getting these hasn't been trying to reach the address in question. As an
> > experiment I logged the traffic on the machine that's getting this -
sure
> > enough, these turn up out of the blue. They also appear to have the
wrong
> > characteristics to have originated on the machine in question, but
that's
> > a minor matter.

> You don't have to be aiming for the *machine* in question, but for a
> network behind it.

The destination address of the originating packet would be a single host. No
traffic - nada, zilch, not a single packet left the machine that had
recieved this error response from the router - hence it was unexpected.

Having now logged traffic for all machines on my network, it appears that
it's not alone - every machine is getting these unexpected ICMP packets from
various routers, at around 5 minute intervals. I know what you're thinking -
my network is being used as an amplifier in an attack. I've already
considered this - from various firewall and configuration rules, and more
importantly from looking at the logs and raw traffic, I can't see this as
being a possibility.

Quote:> More importantly, what OS is the box that's giving these packets off?

I've no idea, since I'm assuming the box giving the originating packets off
is spoofing its source address. As for the router, no idea there, either. My
machine getting the response posted at the top is a 2.4 linux kernel with a
modified network stack, and the originating packet has a TTL far too low to
have come from it.

Quote:> 'Cos
> I thought normally you'd expect to see headers from the originating packet
> copied inside the ICMP error packet, but it's not playing ball on this
> occasion, hence the `INCOMPLETE'.

Attempting to contact the destination address contained in the originating
packet gives the same INCOMPLETE response - but with the expected much
higher TTL, and DF set. I'm still guessing that I'm seeing the fallout from
a spoofed source address here.

--
DMZ  mhm33x4

<this mind left intentionally blank>

 
 
 

unexpected ICMP host unreachable - no worries?

Post by Tim Hayne » Fri, 29 Mar 2002 19:15:13



Quote:>> You don't have to be aiming for the *machine* in question, but for a
>> network behind it.

> The destination address of the originating packet would be a single host.

Indeed.

Quote:> No traffic - nada, zilch, not a single packet left the machine that had
> recieved this error response from the router - hence it was unexpected.

I see. Truly untracked then? Not aiming for something behind this router
(bearing in mind it might not be on the same logical network address-range,
of course)?

Quote:> Having now logged traffic for all machines on my network, it appears that
> it's not alone - every machine is getting these unexpected ICMP packets
> from various routers, at around 5 minute intervals. I know what you're
> thinking - my network is being used as an amplifier in an attack. I've
> already considered this - from various firewall and configuration rules,
> and more importantly from looking at the logs and raw traffic, I can't
> see this as being a possibility.

You might be, but wouldn't you expect more traffic than just an occasional
packet?

Quote:>> More importantly, what OS is the box that's giving these packets off?

> I've no idea, since I'm assuming the box giving the originating packets
> off is spoofing its source address. As for the router, no idea there,
> either. My machine getting the response posted at the top is a 2.4 linux
> kernel with a modified network stack, and the originating packet has a
> TTL far too low to have come from it.

I get TTLs of 242 pinging 204.255.169.17.

I've also taken the liberty of running a very selective port-scan, finding
nothing conclusive at all - too many fingerprint matches.

Quote:>> 'Cos I thought normally you'd expect to see headers from the originating
>> packet copied inside the ICMP error packet, but it's not playing ball on
>> this occasion, hence the `INCOMPLETE'.

> Attempting to contact the destination address contained in the
> originating packet gives the same INCOMPLETE response - but with the
> expected much higher TTL, and DF set. I'm still guessing that I'm seeing
> the fallout from a spoofed source address here.

If the TTLs aren't the same in the packets you're getting and when you
contact the box yourself, you have some spoofing on your paws. Happy
hackin' :)

~Tim
--

How to get to Sesame Street?                |http://spodzone.org.uk/

 
 
 

unexpected ICMP host unreachable - no worries?

Post by RainbowHa » Fri, 29 Mar 2002 20:46:27


< The Ambivalent DMZ
8<

Quote:>SRC=204.255.169.17 DST=(my host) LEN=56 TOS=0x00 PREC=0x00 TTL=242 ID=0
>PROTO=ICMP TYPE=3 CODE=1 [SRC=(my host) DST=(a target?) LEN=40 TOS=0x00
>PREC=0x00 TTL=27 ID=22372 PROTO=TCP INCOMPLETE [8 bytes] ]
8<
>What I'm guessing is that this is nothing more than me picking up the
>background from large attacks bounced off these routers and I'm getting
>occasional fallout when the target goes down and a packet with a random
>spoofed source address happens to coincide with that of one of my machines.

I'm not seeing this at the moment but we have discussed about it at
this February. More details are <http://groups.google.com/> this NG
thread subject "ICMP type 3, an attack?". Here is my summary.

1) Backscatter of router DoS attack
2) Covert channel to control distributed scanner|attacker
3) any other suggestions?

1) Backscatter of router DoS attack
If 204.255.169.17 is Cisco 12000 series router, the offender attacked
the router. They known that 'a target?' don't exist. They flooded
spoofed SRC TCP packets to non-existed host 'a target?' sitting 5 hops
away from 204.255.169.17. You observed ICMP backscatter traffic.
http://www.cisco.com/warp/public/707/GSR-unreachables-pub.shtml
|The performance of Cisco 12000 series routers can be degraded when
|they have to send a large number of ICMP Unreachable packets....
|the processing of the replies can saturate the CPU....Exploitation of
|this vulnerabilities may lead to the Denial-of-Service. The router's
|performance will degrade and, in the worst case scenario, the router
|will stop forwarding packets.

2) Covert channel to control distributed scanner|attacker
I'm guessing this packet is remote controlling command to distributed
scanner|attacker mimic usual ICMP3-1 packet.

Trend of DDoS agents communicate to master using IRC protocol but clean
`netstat` command easily detect established TCP IRC port. Classical DDoS
agents used ICMP echo reply like TFN 1999 by Mixter. If filter out ICMP
0, it only affect ping application. Most stateless firewall pass through
ICMP destination unreachable packet and not log usually. If filter out,
regular ICMP 3 packets will un-reach and affect many applications using
network. If you are using stateful firewall don't worry. But an admin
who are not careful think ICMP backscatter traffic and think not so
important for me and ignore it if they see this logs (offender used
social engineering). The advantage of ICMP protocol is that it can
broadcast to send command. And the pattern oriented NetworkIDS like
`snort` can't divide (detect) regular ICMP3 and imitated ICMP3.

I make a hypothesis that this log is imitated regular ICMP destination
unreachable packet. This packet is Cooperated Distributed Scan or DDoS
controlling command from master to agents. Quoted [] part is a subliminal
command and specify scanning pattern or attack pattern. And perhaps there
are another stegographic (hides messages inside of messages, hiding data
in other data) encrypted items and trigger. The purpose of offender is to
transmit command to agents and masqueraded as normal ICMP traffic (covert
data tunneling). I guess this is a more sophisticated variant of TFN.

The sleep time for scrambling incidents handling. The incidents handler
easily relate that outgoing scan or outbound flood packets after detect
incoming ICMP destination unreachable packet. But sleeping after incoming
ICMP 3, they relate this difficult. Maybe SPT, DPT or ID fields are sleep
time parameter.

I guess [... SYN ACK ...] mean type of TCP flags for flood or scan and
TOS field mean type of protocol for flood or scan.
example of TFN : ICMP flood, SYN flood, UDP flood, and Smurf

[master] broadcast spoofed ICMP3 packets (command to agents)
 |
 V
[agent], [agent],... watch ICMP3 packet
 | send flood packets or scan after sleep
 |
 V
[target]

--
Best Regards, RainbowHat. I support FULL DISCLOSURE.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7

 
 
 

unexpected ICMP host unreachable - no worries?

Post by RainbowHa » Sun, 31 Mar 2002 03:51:01


< The Ambivalent DMZ




>>>SRC=204.255.169.17 DST=(my host) LEN=56 TOS=0x00 PREC=0x00 TTL=242 ID=0
>>>PROTO=ICMP TYPE=3 CODE=1 [SRC=(my host) DST=(a target?) LEN=40 TOS=0x00
>>>PREC=0x00 TTL=27 ID=22372 PROTO=TCP INCOMPLETE [8 bytes] ]

INCOMPLETE [8 bytes] mean the following TCP parts lost;

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

My guess is 204.255.169.17 was too busy but I'm not sure.

Quote:>Having now logged traffic for all machines on my network, it appears that
>it's not alone - every machine is getting these unexpected ICMP packets from
>various routers, at around 5 minute intervals.

Dose 5 minute intervals mean per your network or per one machine?
Dose all packets indicate INCOMPLETE? Is TTL same in originating
packets? I'd like to know other packet log samples. Could you
please post a few samples?

Quote:>Attempting to contact the destination address contained in the originating
>packet gives the same INCOMPLETE response - but with the expected much
>higher TTL, and DF set. I'm still guessing that I'm seeing the fallout from
>a spoofed source address here.

If you ping to 204.255.169.17 and result is TTL=~242, I guess this
ICMP packet (not originating packet) was not spoofed 90%. I guess
originating packet was spoofed according to above higher TTL and DF.
Higher TTL and DF set that is your real packet.

--
Best Regards, RainbowHat. I support FULL DISCLOSURE.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7

 
 
 

unexpected ICMP host unreachable - no worries?

Post by RainbowHa » Mon, 08 Apr 2002 17:43:52


< The Ambivalent DMZ

Quote:>>>>>SRC=204.255.169.17 DST=(my host) LEN=56 TOS=0x00 PREC=0x00 TTL=242
>>>>>ID=0 PROTO=ICMP TYPE=3 CODE=1 [SRC=(my host) DST=(a target?) LEN=40
>>>>>TOS=0x00 PREC=0x00 TTL=27 ID=22372 PROTO=TCP INCOMPLETE [8 bytes] ]

Passive fingerprint of 204.255.169.17: Cisco, Solaris, Linux or other.
LEN=40 of originating packet mean this packet didn't have TCP and IP
options (record route, source routing,...). I'm interesting IP and TCP
checksum field.

Quote:>My guess would be a deliberate flood, not necessarily against the router.

Do you mean offender crafted INCOMPLETE packets and attacked INCOMPLETE
packets flood DoS? I wonder why were your ping packets same responded
INCOMPLETE below.

Quote:>Yes. Also, attempting to ping the "target" also returned INCOMPLETE in
>an ICMP 3/1 response from the router at the time.
>Unfortunately, the samples weren't retained and although I've attempted
>to capture some more, there's been no continued activity. From the
>samples I do have from the one machine, all packets were essentially
>identical with a decreasing ID number in the returned original packet
>(decimal as shown on x86 linux, small sample below):

Mar 28   difft           hexb hexl deci  diffi
01:09:54        ID=9828  2664 6426 25638    
01:14:40 +04:46 ID=8548  2164 6421 25633   -5
01:19:25 +04:45 ID=7268  1c64 641c 25628   -5
01:24:10 +04:45 ID=5988  1764 6417 25623   -5
01:28:55 +04:45 ID=4708  1264 6412 25618   -5
01:43:11 +14:16 ID=868   0364 6403 25603  -15
01:47:56 +04:45 ID=65124 fe64 64fe 25854 +251
01:52:41 +04:45 ID=63844 f964 64f9 25849   -5
02:16:27 +24:46 ID=57444 e064 64e0 25824  -25
02:30:42 +14:15 ID=53604 d164 64d1 25809  -15
02:35:28 +04:46 ID=52324 cc64 64cc 25804   -5
02:40:13 +04:45 ID=51044 c764 64c7 25799   -5
02:44:58 +04:45 ID=49764 c264 64c2 25794   -5
02:49:42 +04:44 ID=48484 bd64 64bd 25789   -5
02:54:27 +04:45 ID=47204 b864 64b8 25784   -5
02:59:13 +04:46 ID=45924 b364 64b3 25779   -5
03:03:58 +04:45 ID=44644 ae64 64ae 25774   -5
03:08:42 +04:44 ID=43364 a964 64a9 25769   -5
03:46:43 +38:01 ID=33124 8164 6481 25729  -40
03:56:13 +09:30 ID=30564 7764 6477 25719  -10

Looks they activated other network something at Mar 28 01:47:56.

04:45 = 285 seconds; 25719 / 5 ~= 5144
5144 * 285 = 1466040 seconds = 24434 minutes ~= 407 hours = 16.9 days
Mar 28 + 16.9 days = April 14th
Not much April 2nd. Perhaps they stopped just one month.

65535 - 25719 = 39816; 39816 / 5 ~= 7963
7963 * 285 = 2269455 seconds ~= 37824 minutes ~= 630 hours = 26.25 days
Mar 28 - 26.25 days = March 2nd
Looks they probed one month March 2nd to April 2nd.

25719 - 22372 = 3347; 3347 / 5 ~= 669
669 * 285 = 190665 seconds ~= 3178 minutes ~= 53 hours ~= 2.2 days
Mar 28 - 2.2 days = March 26th
Your initial post was March 28th. I guess you found March 26th.

Apr 2 - Mar 28 = 5 days = 120 hours = 7200 minutes = 432000 seconds
432000 / 285 ~= 1516; 1516 * 5 = 7580; 25719 - 7580 = 18139 IPID
Looks they stopped IPID ~= 18139 on April 2nd.

Quote:>It suggests the original packets came from a single machine.

Yes, agreed. If not crafted packets, I guess they used the box which
little endian Intel, monotonically decreasing IP ID, initial TTL 30
(or 32), located 3 (5) hops away from 204.255.169.17. Looks obsolete
OS. It seems the offender used 5 kind of spoofed IP (one was yours)
and sent 1 packet per minute regularly. It smells they measured or
probed something about network (example: round trip time for load
balancing, indirectly idle host probe,...). If this is a attack, this
is a bandwidth saving ecological INCOMPLETE packets flood DoS attack.

Passive OS fingerprint: Alcatel (Xylan) OmniStack 5024, Chorus MiX
V.3.2 r4.1.5 COMP-386, DC-OSx V1.1-95 Pyramid/NILE, DEC Pathworks V5,
HP/UX V9.0x or other.

Quote:>Again, yes - I'm fairly confident of this now. The only question that
>remains though is had anyone else with a stateful firewall seen this?
>March 20th and 28th were peak activity, and I've not seen any since
>the 2nd now.

Was the offenders holiday Wed and Thu? If they used 5 kind of spoofed
IP, it's very difficult to find same logs.

(5 IPs) ^ (subscribe c.o.l.s) ^ (stateful firewall) ^ (watch logs)

How about to contact mails to upper stream of 204.255.169.17 and (a
target?). Perhaps the following incidents data base will help you.
If you will find the some evidence, please post here. I'm interesting.

http://dshield.org/ http://incidents.org/ http://mynetwatchman.com/

--
Best Regards, RainbowHat. I support FULL DISCLOSURE.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7

 
 
 

1. ICMP Destination Unreachable (Host Unreachable) [**] [Solved!!!]

Hello to you all.

I had some problems with the IDS alerts in snort regarding the subject
of this post.

 ICMP Destination Unreachable (Host Unreachable) [**]

Well, it seems to be solved here, and I did solve it like this.

1. go to your adsl/router
2. fill in dns properties from your dhcp dns server the correct dns
domain name of your host.
3. save this configuration.

And you are not longer troubled with the ICMP unreachable host
messages.

It is finally a bit quiet in te logs, and also the spp portscan
activities are gone.

Still I am curious how this exactly works, and if my solution helped
some of you, and if it is a correct solution I have applied???

Because maybe I am introducing a security related flaw, what I don't
like ofcourse, because maybe it was alright that the Snort IDS was
generating these alerts.

Well, I hope some of you will send a reply to me with some
backgrounds, and some advice if neccesary.

Just send a copy to my e-mail address if it helped you, or you have
something to say about this post.

Have a nice day you all!

Wouter Jan Wessels.

2. Video 4 Linux API info?

3. ICMP HOST cannot build IP Header address to echo ICMP HOST

4. Bash can't find a file that ls can (newbie)

5. Unauthorised ICMP Host Unreachable.

6. Linux Adduser for Solaris?

7. Linux gateway not returning ICMP HOST or NETWORK UNREACHABLE

8. redhat problem: "login incorrect"

9. Linux 2.0.32 gateway not sending ICMP HOST UNREACHABLE

10. Worry, worry, worry... but not here.

11. Unreachable hosts becomes reachable again but my host doesn't know about it.

12. DesDestination Host Unreachabletination Host Unreachable

13. host unreachable followup: hosts now reachable but windowsmachine can not see linuxmachine