> -----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
most likely firewalls
> 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
that would look about right
> -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-
i believe this to be true as well
> -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
most likly nmap
> -Any wild-ass guesses about the decoy
address selection mechanism.
well this depends really. A script kiddie dosnt
know how to correctly use decoy ip's, and will
most likely pick at random. A better attacker
will actually read the manual on decoy hosts, and
choose one's which are down, thus unable to
packets. My personal favorite is to use
firewalled hosts that "drop" all unacceptible
packets. Which is virtually dead.
what you are seeing is someone picked you (prolly
out of a hat) to be a decoy, they portscanned a
box which was firewalled with rules "deny". which
sends a lovely icmp type 3 error back to the host
(and decoys). I would grab all the logs of these
errors for 2 reasons. A to alert the host that
sent the icmp errors, as to notify him of the port
scan. Second, to make certain he cant use his
logs (which includes you as a decoy) as someone
port scanning them. The proof of portscan wouldnt
be a big deal if it just stoped at portscanning,
most likely he found something interesting and is
already defacing their site. So if they use the
port scan as foresics, you need to protect
yourself from suspect and aid in catching the true
intruder.
> 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
>
>
iD8DBQE525JYG3kIaxeRZl8RAsULAJ9jq6Sgpb8yqCxRSTvL9A
2jToAnKACfac38
> voRz9D5fRSMJ4TeHxvCvSAg=
> =Cs7O
> -----END PGP SIGNATURE-----
>
>
Received on Oct 11 2000
Intro
