An ICMP Type 3 Signature

["Stephen P. Berry" <spb () MESHUGGENEH NET>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Here's another one of those overwritten network traffic analysis
pattern matches that I like to post periodically.

This one consists of a bunch of ICMP type 3 (host unreachable)
packets.  The source addresses of thse packets tend to be
border or edge routers at ISPs and suchlike.  Before I get
into what's interesting (and distinguishing) about this particular
pattern, here's an example:

18:16:36.779894 207.88.240.101 > a.b.c.d: icmp: host 194.102.148.213 unreachable
   4500 0038 0000 0000 f601 704b cf58 f065
   .... .... 0301 681d 0000 0000 4500 0028
   6a37 0000 1806 4ca2 .... .... c266 94d5
   0449 0028 2837 6839
18:22:42.611841 207.88.240.101 > i.j.k.l: icmp: host 194.102.148.213 unreachable
   4500 0038 0000 0000 f801 a39e cf58 f065
   .... .... 0301 62d2 0000 0000 4500 0028
   50e4 0000 1806 9b48 .... .... c266 94d5
   089b 0121 2837

I've included the source address and the `unreachable' address, although
they vary from incident to incident.

Interesting features about this traffic:

        -ICMP unreachable messages are supposed to contain the IP
         header and (at least) the first 8 bytes of the original datagram
         which caused the ICMP unreachable message to be sent.
         The addresses in the included portions of the datagrams
         match the destination addresses of the ICMP unreachable
         messages.  Translation:  these look like valid, unmunged
         ICMP unreachable messages
        -The length of the data portion of the IP datagram which
         generated the ICMP error is not constant[0]
        -Neither of the destination addresses (a.b.c.d and i.j.k.l in
         the above example) had sent any traffic to 194.102.148.213 in
         the two hours prior to receiving the ICMP datagrams (two hours
         is as far back as I looked---they've probably -never- sent
         anything to 194.102.148.213).  In fact i.j.k.l was an
         unused address that wasn't sending or receiving -anything-
        -The two destination addresses in the example above are in
         fact in different 8-bit networks (different class As, if
         you prefer)
        -The value of the portion of the TCP sequence number in the
         included datagram is always the same.  When the entire SN is
         included, the whole thing matches
        -The TCP source and destination ports in the included datagram
         are not constant
        -The source address of the ICMP messages is generally a
         border or edge router, but not one between the destination
         address of the ICMP message and the `unreachable' host
        -The destination addresses of the ICMP messages seem to be
         fairly random but nothing approaching truly random.  I.e.,
         in the example above two hosts on different (and not sequential)
         8-bit networks got hit.  Sometimes a half dozen or so hosts
         on a single 24-bit network will see this sort of traffic,
         but not sequentially or in any other order I can make out.
         Perhaps a scanner which takes a list of address/mask pairs
         as input and picks decoy addresses randomly from the
         networks in that list?


My hunch is that what I'm seeing is the result of someone scanning
multiple target hosts (in the example above 194.102.148.213) using
the destination addresses of multiple unrelated machines (a.b.c.d
and i.j.k.l in this example) as decoy addresses.

What I'd be interested in, then, is:

        -The opinions of anyone who thinks that -isn't- what I'm
         seeing
        -Any suggestions on what the tool being used is
        -Any wild-ass guesses about the decoy address selection mechanism.
         It really doesn't look like it's targeted traffic, but I
         always like to have a specific mechanism to explain the behaviour of
         anomalous traffic (that doesn't involve the whims of a
         bad guy with a grudge)

The best way I've been able to correlate these incidents has been
to match/sort the first 16 bits of the TCP seq number in the
included datagram of ICMP host unreachable messages.

Good hunting.





- -Steve

- -----
0     I doubt that this has anything to do with the posited scanner;
      it's probably strictly due to the behaviour of the routers
      generating the ICMP datagrams.  But I don't know that for a fact,
      so I'm including the variability of the length as an interesting
      feature anyway.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE525JYG3kIaxeRZl8RAsULAJ9jq6Sgpb8yqCxRSTvL9A2jToAnKACfac38
voRz9D5fRSMJ4TeHxvCvSAg=
=Cs7O
-----END PGP SIGNATURE-----