UDP-ICMP

This lab focused on analyzing packet behavior related to UDP and ICMP. It was designed to help understand how certain traffic patterns can trigger ICMP error messages and under what conditions those messages should or shouldn’t appear.

Exercise 1 – Investigating ICMP Echo Requests

Task:
The first six records in the capture are grouped in pairs. Each pair includes one packet that would normally trigger an ICMP error, followed by a response or lack of one. According to RFC 1122 and the ICMP protocol, the goal is to determine whether these ICMP errors should be generated, and if not, why.

Records 1 and 2:

We see an echo request sent to the address 255.255.255.255 (the broadcast address) and a destination unreachable (Host unreachable) response sent from 192.168.11.1. An echo request sent to the broadcast address should not generate an ICMP error message and it would be an open door for DDOS attacks or broadcast storm to happen.

Records 3 and 4:

Record 3 has a More Fragment flag set and a fragment offset of 32 in its IP header which means it is part of fragment train. We are missing the fragment with offset 0 (which would be the first fragment for this given train) and the rest of the fragments located before and after offset 32. Without these missing fragments, the receiving host would not be able to reassemble these records. The ICMP message received in record 4, “TTL exceeded”, should only be sent if the fragment with offset 0 was received which is not the case here. In normal traffic condition, this message would not be generated.

Records 5 and 6:

in Record 5 we see 192.168.11.65 sending an ICMP message Type 3 code 1: Destination Unreachable (Host Unreachable) to 192.168.11.1. Normally, this type of message is sent as a response to packet sent to a host that cannot be reached but in this case it is not a response. Record 6 is also an ICMP error message for Host Unreachable. An ICMP error message should never be sent as a response to another ICMP error message otherwise this would generate an endless loop.

Exercise 2 – ICMP Echo Request Activity (Packets 12–35)

Analyze packets 12 through 35 in the capture file to determine the nature of the observed activity and identify the likely operating system generating the ICMP echo requests.

We see sets of 3 Echo Requests being sent from 192.168.11.48 to 68.85.138.249. The first set of 3 has a TTL of 1 and then this TTL gets incremented by 1 every set. These records get an ICMP error message TTL exceeded up until record 31 where the response is an echo reply. This tells us that the host is located 4 hops away from the sender and we can map all the routers passed along the way. The behavior observed corresponds to a Windows tracert using ICMP to identify all the routers along the path from 192.168.11.46 to 68.85.138.249. The tracert command on non-Windows systems typically uses UDP packets instead of ICMP.

What are the intermediate routers that appear along the path?

We can easily find this data by looking at the IP addresses sending these ICMP error messages:

• 192.168.11.1 (records 13, 15 , 17)
• 192.168.1.1 (records 19, 21, 23)
• 69.250.56.1 (records 25, 27, 29)

Exercise 3 – Find the packet number that caused an ICMP error.

a) Identify the packet that triggered the ICMP error message “time to live exceeded (fragment reassembly timeout)” in record 11.

Looking at the ICMP portion of record 11, we can find an embedded IP packet that represents part of the original offending packet. Filtering on a unique field in this embedded IP packet like the checksum, we can find the related packet:

Record 7 is the offending packet:

b) Identify the packet number that triggered the ICMP error message “port unreachable” in record 36.

We apply the same type of filtering that was used in the previous question to record 36:

Record 8 is the packet that generated the ICMP error message in record 36.

Exercise 4 – ICMP echo requests and replies found in records 37–46 are all related. What is this activity?

Each reply receives several echo requests from what appears to be the same IP address. Why is there an imbalance. One echo request should only be answered by one echo reply. We also see a lot of data being carried in both these echo requests and replies packets:

This mismatch between echo requests and replies and the amount/type of data caried by these ICMP packets are one of the telltale signs of an ICMP tunnel. This is an example of ptunnel that uses ICMP as a tunnel for other protocols, in this case SSH.