ICMP logging question

ICMP logging question

[Chris Brenton]

Greets all,

I have a question regarding some ICMP packets I've recorded. Here is the
iptables log entry:

May  2 13:07:45 gw1 kernel:  DROP_INPUT  IN=eth0 OUT=
MAC=00:e0:29:85:f0:b0:00:00:0c:84:63:04:08:00 SRC=143.248.4.1
DST=64.179.20.65 LEN=56 TOS=0x00 PREC=0xC0 TTL=236 ID=18683 PRO
TO=ICMP TYPE=11 CODE=0 [SRC=64.179.20.65 DST=200.223.0.232 LEN=40
TOS=0x00 PREC=0x00 TTL=0 ID=15436 PROTO=TCP INCOMPLETE [8 bytes] ]

and here is the Snort decode:

[**] ICMP Time-To-Live Exceeded in Transit (Undefined Code!) [**]
05/02-13:07:45.122521 143.248.4.1 -> 64.179.20.65
ICMP TTL:236 TOS:0xC0 ID:18683 IpLen:20 DgmLen:56
Type:11  Code:0  TTL EXCEEDED IN TRANSIT
00 00 00 00 45 00 00 28 3C 4C 00 00 00 06 5F C9  ....E..(<L...._.
40 B3 14 41 C8 DF 00 E8 1C 75 1A AE 1D E1 7F A8  @..A.....u......

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

My question is regarding the decode of the alleged TCP packet (I say
alleged as it was spoofed. I think this is a covert zombie communication
channel) that generated the ICMP error. 

What exactly does "incomplete" mean? Does this simply mean that only 8
bytes of the 20 were present for decoding? If so, why do only certain
type 11's get labeled as "incomplete"?

iptables used to decode the original source and destination ports as
part of the log entry. Has this feature gone away?

Thanks in advance for any help,
Chris

Re: ICMP logging question

[Philip Craig]

Chris Brenton wrote:
> Greets all,
> 
> I have a question regarding some ICMP packets I've recorded. Here is the
> iptables log entry:
> 
> May  2 13:07:45 gw1 kernel:  DROP_INPUT  IN=eth0 OUT=
> MAC=00:e0:29:85:f0:b0:00:00:0c:84:63:04:08:00 SRC=143.248.4.1
> DST=64.179.20.65 LEN=56 TOS=0x00 PREC=0xC0 TTL=236 ID=18683 PRO
> TO=ICMP TYPE=11 CODE=0 [SRC=64.179.20.65 DST=200.223.0.232 LEN=40
> TOS=0x00 PREC=0x00 TTL=0 ID=15436 PROTO=TCP INCOMPLETE [8 bytes] ]
> 
> and here is the Snort decode:
> 
> [**] ICMP Time-To-Live Exceeded in Transit (Undefined Code!) [**]
> 05/02-13:07:45.122521 143.248.4.1 -> 64.179.20.65
> ICMP TTL:236 TOS:0xC0 ID:18683 IpLen:20 DgmLen:56
> Type:11  Code:0  TTL EXCEEDED IN TRANSIT
> 00 00 00 00 45 00 00 28 3C 4C 00 00 00 06 5F C9  ....E..(<L...._.
> 40 B3 14 41 C8 DF 00 E8 1C 75 1A AE 1D E1 7F A8  @..A.....u......
> 
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> My question is regarding the decode of the alleged TCP packet (I say
> alleged as it was spoofed. I think this is a covert zombie communication
> channel) that generated the ICMP error. 

Given that there's only 56 bytes in the ICMP packet, and 40 bytes in the
original TCP packet, all of which are headers, that packet by itself
would be a very low bandwidth covert channel.  What makes you think it is?

> What exactly does "incomplete" mean? Does this simply mean that only 8
> bytes of the 20 were present for decoding? If so, why do only certain
> type 11's get labeled as "incomplete"?

It means that only 8 bytes of the TCP header are present.  It only
happens for type 11's that are not including the full header.  Whether
or not the full header is included is dependent on the router
generating the ICMP message.

> iptables used to decode the original source and destination ports as
> part of the log entry. Has this feature gone away?

No, the feature is still there, but it only prints out the ports when
it has a full TCP header.  While it would be possible to print the
ports from just the first 8 bytes of the TCP header, iptables never
has AFAIK.  From the snort decode, it looks like the source port is
7285 and the destination port is 6830.

-- 
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com

Re: ICMP logging question

[Chris Brenton]

On Tue, 2004-05-04 at 23:09, Philip Craig wrote:
>
> Given that there's only 56 bytes in the ICMP packet, and 40 bytes in the
> original TCP packet, all of which are headers, that packet by itself
> would be a very low bandwidth covert channel.  What makes you think it is?

Going off topic just a little here...
The pattern is nearly identical to what we documented here:
http://archives.neohapsis.com/archives/incidents/2000-01/0005.html

The major difference is these packets target an actual IP address rather
than x.x.x.0. This tells me it may be a variation off the original tool
adapted for a different OS (original zombie ran on SunOS). Just trying
to ID the tool.

> No, the feature is still there, but it only prints out the ports when
> it has a full TCP header.  While it would be possible to print the
> ports from just the first 8 bytes of the TCP header, iptables never
> has AFAIK. 

Think I figured it out. Check out the following:

Oct 30 22:36:53 gw2 kernel:  DROP  IN=eth0 OUT=eth0 SRC=207.88.240.101
DST=12.33.247.252 LEN=56 TOS=0x00 PREC=0x00 TTL=243 ID=0 PROTO=ICMP
TYPE=3 CODE=1 [SRC=12.33.247.252 DST=194.102.91.1 LEN=40 TOS=0x00
PREC=0x00 TTL=24 ID=41546 PROTO=TCP SPT=31632 DPT=4160 WINDOW=63498
RES=0x09 ACK RST SYN FIN URGP=0]

Port numbers decoded off a 56 byte packet but it has the "let's pretend
the sequence number field is the flag field" bug. I'm guessing when the
bug was fixed, the change was made so port numbers were no longer
translated when only 8 bytes of the TCP header are present.

Kind of a bummer to lose the additional info. May be able to fix this
with ulog.

Thanks for the re!
Chris