Traffic analysis of weird packets
One night I encountered some ICMP
(For more explanation on ICMP see below)
traffic destined for my machine
which I really couldnt place. Becomming suspicious over what was going on,
I decided to capture these packets with tcpdump.
I let tcpdump dump the data link layer and
let tcpdump print each packet in hex and in ascii too, to
be able to analyse these packets completly.
below is one of these packets dumped by tcpdump.
The rest of the ICMP packets I received were all the same kind,
same addresses. Therefore analysing just one of these packets
is enough to see what's this about in this case.
Let's start the analysis in detail:
23:52:35.812013 Dest_Mac_addr Src_Mac_addr 0800 70: xxxx xxxx > yyyy yyyy
: icmp: host zzzz zzzz unreachable - admin prohibited filter (ttl 253
, id 37201)
0x0000 4500 0038 9151 0000 fd01 a6e0 xxxx xxxx E..8.Q.........V
0x0010 yyyy yyyy 030d 595f 0000 0000 4500 0028 ..}...Y_....E..(
0x0020 dc41 0000 3d06 1b42 yyyy yyyy zzzz zzzz .A..=..B..}.....
0x0030 0118 a27b 0000 0000
This is the output from tcpdump on one of these packets.
The data link layer contains the 48 bits Destination MAC
(Media Access Control) address,
the 48 bits Source MAC address and the ether type, which is 0800
in this case which indicates IP.
To continue this analysis with the hex dump,
some knowledge of IPv4 is needed. For the IP (INTERNET PROTOCOL)
header, all the information is decribed in
RFC 791.
RFC stands for Request for Comment which contain
the standards for the internet and much more.
Section 3.1 from
RFC 791 specifies the Internet Header Format which
is printed in hex by tcpdump, the length of
the IP header is 20 bytes (160 bits):
4500 0038 9151 0000 fd01 a6e0 xxxx xxxx
yyyy yyyy
4 = Version is 4 (4 bits)
5 = IHL (Internet Header Length) = 5 (4 bits)
00 = 0 (8 bits Type of Service)
0038 = 8 + 48 = 56 (16 bits total length in bytes, so the total
length is 56 bytes)
9151 = 1 + 80 + 256 + 36864 = 37201 (16 bits Identification)
0000 = 3 bits flas + 13 bit fragment offset, all 0, so no fragments)
fd = 13 + 240 = 253 (8 bits TTL (Time to Live))
01 = 1 = (8 bits protocol number, 1 = ICMP (
RFC 1700))
a6e0 = 0 + 224 + 1536 + 40960 = 42720 (16 bit hdr checksum)
xxxx xxxx = 32 bits source ip address
yyyy yyyy = 32 bits destination address
RFC 1700 specifies all the Assigned Numbers.
So in there you can find which numbers stands for which protocol.
The next bits represent the ICMP part of the packet.
ICMP stands for INTERNET CONTROL MESSAGE PROTOCOL
and is described in several RFC's.
The first one is
RFC 792.
The second one needed for this packet is
RFC 1812
for it describes an ICMP code which is defined later the the types
and codes defined in
RFC 792.
030d 595f 0000 0000
03 = 3 (8 bits ICMP type, so ICMP type = 3)
0d = 13 + 0 = 13 (8 bits ICMP code, so ICMP code = 13)
595f = 15 + 80 + 2304 + 20480 = 22879 (16 bits checksum)
0000 0000 = 32 bits unused
Next in this kind of ICMP message follows
the original IP header and 64 bits of the data of the original
packet which was send, which caused machine xxxx xxxx to
send the ICMP Destination Unreachable packet as a response to yyyy yyyy,
the original sender.
4500 0028
dc41 0000 3d06 1b42 yyyy yyyy zzzz zzzz
The first 16 bits are same as in the first IP header.
0028 = 8 + 32 = 40 (16 bits total length, so the total length is 40 bytes)
dc41 = 1 + 64 + 3072 + 53248 = 56385 (16 bits Identification)
0000 = no fragments
3d = 13 + 48 = 61 (8 bits TTL, so TTL = 61)
06 = 6 + 0 = 6 (8 bits protocol number, number 6 is TCP
(RFC 1700))
1b42 = 2 + 64 + 2816 + 4096 = 6978 (16 bits header checksum)
yyyy yyyy is 32 bits source address
zzzz zzzz is 32 bits destination address
Finally, 0118 a27b 0000 0000
represend the 64 bits data header after the
IP header, since the protocol is TCP, it means the first 64 bits (8 bytes)
of the TCP header:
0118 = 8 + 16 + 256 = 280 (16 bits source port, so source port = 280)
a27b = 11 + 112 + 512 + 40960 = 41595 (16 bits destination port)
0000 0000 = 0 is 32 bits sequence number ...
Now we analysed all the hex output of the packet and we can draw
conclusions:
yyyy yyyy received an ICMP type 3 code 13 from xxxx xxxx (since only routers
may issue an icmp type 3 code 13, xxxx xxxx is a router)
Meaning: Destination Unreachable: "Communication Administratively Prohibited".
The TTL in the ICMP message from xxxx xxxx was 253, most likely the
TTL which was set by router xxxx xxxx is 255. The fact that the TTL has
decreased by 2, means that there are 2 hobs between me and that router.
According the data in the ICMP packet yyyy yyyy send out a TCP package
from port 280 to
zzzz zzzz on port 41595
With sequence number 0. However, on it's way the packet had to pass
the router xxxx xxxx which didnt allow traffic to
zzzz zzzz on port 41595 and therefore send the
discussed ICMP packet as return.
yyyy yyyy received more of these packets with exactly
the same IP addresses and source and destination ports.
Also other ports came into question in other packets exactly like these.
However, every single time the sequence numer was 0, in each of these packets.
yyyy yyyy is the IP of one of my own machines.
But this got me confused since I am sure I never send out such a packet
to that machine I aint run services on port 280.
The other possibility is that my machine could be hacked and
another process was doing this. Since I'm sure I aint being hacked
this also cannot be the case. I checked my machine out again to see
whether I missed some stuff, but no ... nothing like that.
Another very odd thing is that the sequence number was every time 0 according
to the data part of the ICMP header, which contained the IP header of the packet
which was originally send,
in every ICMP packet like that I received.
This leaves one option open, which is that another machine
send out spoofed packets to zzzz zzzz as if they originated from my IP address.
This aint the first time I encoutered packets like these.
In the period June and July 2001 in Virginia in the States,
I also encountered a lot of ICMP traffic destined for my machine there.
On the IP Filter
(one of the best firewall's) mailing list more people started asking questions
over similar packets.
Click
here
for the archive, and look for Strange Log Entries.
The question and answers start
here.
Spoofing still happens a lot. We just saw an example of that.
In fact, it's still a big problem on the internet as we know it today.
Another example is (D)DOS ((Distributed) Denial of Service) attacks,
which often happen from
spoofed IP addresses, making it tougher to trace them back to there
origin. Hence, there are still a lot of incomplete configured routers
active on the web which dont check whether the packet to forward with
source address yyyy yyyy can indeed originate from the interface
it receives it from, or whether it's a spoofed packet and should be
discarded. This is called Network Ingress Filtering and is
described in
RFC 2267.