From: Philip Craig <philipc@snapgear.com>
To: Chris Brenton <cbrenton@chrisbrenton.org>
Cc: netfilter@lists.netfilter.org
Subject: Re: ICMP logging question
Date: Wed, 05 May 2004 13:09:10 +1000 [thread overview]
Message-ID: <40985AD6.8070101@snapgear.com> (raw)
In-Reply-To: <1083632597.2068.194.camel@grendel>
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
next prev parent reply other threads:[~2004-05-05 3:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-04 1:03 ICMP logging question Chris Brenton
2004-05-05 3:09 ` Philip Craig [this message]
2004-05-05 10:35 ` Chris Brenton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40985AD6.8070101@snapgear.com \
--to=philipc@snapgear.com \
--cc=cbrenton@chrisbrenton.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.