{"id":90,"date":"2025-06-14T17:19:23","date_gmt":"2025-06-14T17:19:23","guid":{"rendered":"https:\/\/epbrtcybersecurityportfolio.xyz\/?p=90"},"modified":"2025-06-14T17:20:50","modified_gmt":"2025-06-14T17:20:50","slug":"ipv4","status":"publish","type":"post","link":"https:\/\/epbrtcybersecurityportfolio.xyz\/?p=90","title":{"rendered":"IPv4"},"content":{"rendered":"\n

Lab 1.4 \u2013 IPv4 Packet Analysis<\/h3>\n\n\n\n

This lab focused on examining network traffic at the IPv4 layer<\/strong>, with an emphasis on identifying abnormal or suspicious behavior within the packet capture. <\/p>\n\n\n\n

Lab Setup<\/strong><\/p>\n\n\n\n

For this exercise, I used the capture file called ipv4.pcap<\/code>.<\/p>\n\n\n\n

Once downloaded, I opened the file in Wireshark and began my analysis.<\/p>\n\n\n\n

Exercise 1 \u2013 Analyzing the First IPv4 Packet<\/h3>\n\n\n\n

a) What version of IP is the first packet?<\/strong><\/p>\n\n\n\n

We can find this either by looking at the Ethernet header or the IP header. Looking at the IP Header, the IP version is located in the higher-order nibble of the 0 byte offset. We can see there that this is an IPv4 packet.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

b) What is the IP Time To Live value, in decimal, in this packet?<\/strong><\/p>\n\n\n\n

To answer this, I examined the IPv4 header<\/strong> of the first packet in the ipv4.pcap<\/code> file. I specifically looked at the Time To Live (TTL)<\/strong> field, which determines how many hops (routers) the packet can pass through before being discarded.<\/p>\n\n\n\n

The TTL field is located 8 bytes into the IP header, but Wireshark conveniently displays this value directly in the decoded packet details. In this case, the TTL value was 64<\/strong>, which is a common default for Linux-based systems.<\/p>\n\n\n\n

This value can also give clues about the operating system or network behavior based on how far the packet has traveled.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

c) What is the source IP address, in hexadecimal, in the first packet?<\/strong><\/p>\n\n\n\n

To find the source IP address in hexadecimal, I examined the IPv4 header<\/strong> in the first packet of the ipv4.pcap<\/code> capture. The source IP address is located between bytes 12 and 15<\/strong> from the start of the IP header.<\/p>\n\n\n\n

Wireshark makes this easy by displaying both the decimal and hexadecimal representations. For the first packet, the source IP is 192.168.11.65<\/strong> in decimal, which corresponds to 0xc0 0xa8 0x0b 0x41<\/strong> in hexadecimal.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

d) What is the destination IP address, in hexadecimal, in the first packet?<\/strong><\/p>\n\n\n\n

To find the destination IP address in hexadecimal, I examined the IPv4 header of the first packet in the ipv4.pcap<\/code> file. According to the IP header structure, the destination IP is stored between bytes 16 and 19<\/strong> from the start of the IP header.<\/p>\n\n\n\n

Wireshark clearly shows this value in both hexadecimal and decimal. In this case, the destination IP is 192.168.1.1<\/strong>, which corresponds to the hexadecimal representation 0xc0 0xa8 0x01 0x01<\/strong>.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Exercise 2 \u2013 Identifying Abnormalities in the IPv4 Header<\/h3>\n\n\n\n

In this exercise, I examined the second packet<\/strong> in the ipv4.pcap<\/code> capture and identified two key problems with its IP header.<\/p>\n\n\n\n

Problem 1: Invalid IP Version<\/strong>
The first issue is that the IP header lists version 8<\/strong>, which is not a valid or supported IP version. Only versions 4<\/strong> and 6<\/strong> are in use today. Because of this, Wireshark marks the packet in red<\/strong> and does not attempt to decode it further.<\/p>\n\n\n\n

Problem 2: Invalid Header Checksum<\/strong>
After inspecting the raw packet bytes, I found another issue in bytes 10 and 11<\/strong>, which represent the IP header checksum. The value was 0x0000<\/code>, which is invalid and indicates the packet may have been corrupted or crafted improperly.<\/p>\n\n\n\n

Impact<\/strong>
Both of these abnormalities would cause the packet to be dropped immediately<\/strong> by the first router or system it attempts to pass through. This exercise helped me understand how malformed packets are detected and discarded at the network layer.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Exercise 3 \u2013 Hex Analysis Using tcpdump<\/h3>\n\n\n\n

In this part of the lab, I used the tcpdump<\/code> command-line tool to inspect raw packet data and answer questions related to the third packet<\/strong> in the ipv4.pcap<\/code> capture.<\/p>\n\n\n\n

To extract the first few packets in hexadecimal format, I ran:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

a) What version of IP is this packet?<\/strong> What is the header length if the packet ?<\/strong><\/p>\n\n\n\n

By looking at the raw hexadecimal output of the third packet, I found it starts with the byte 0x45. This first byte breaks down into two nibbles:<\/p>\n\n\n\n

    \n
  • 4<\/strong> \u2192 IP version<\/li>\n\n\n\n
  • 5<\/strong> \u2192 header length <\/li>\n<\/ul>\n\n\n\n

    So, the version number of this packet is IPv4<\/strong>, as indicated by the high-order nibble of the first byte.<\/p>\n\n\n\n

    The header length field is in units of double word so it has to be multiplied by 4 to be converted to a length of 20 bytes.<\/p>\n\n\n\n

    b) What is the embedded protocol in this packet, according to the IP header?<\/strong><\/p>\n\n\n\n

    To determine the embedded protocol, I examined byte offset 9<\/strong> in the IP header of the third packet. This byte indicates which protocol is encapsulated within the IPv4 packet.<\/p>\n\n\n\n

    Using the tcpdump<\/code> output, I located the value at this offset. For this packet, the value was 0x01<\/strong>, which corresponds to ICMP (Internet Control Message Protocol)<\/strong>.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Exercise 4 \u2013 Calculating ICMP Header and Data Length<\/h3>\n\n\n\n

    In this task, I analyzed the fourth packet<\/strong> in the ipv4.pcap<\/code> file to determine how many bytes were used by the ICMP header and data<\/strong>, following the IPv4 header.<\/p>\n\n\n\n

    To do this, I used two values from the IP header:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
      \n
    • Total Length<\/strong>: 68 bytes (it is found in the 3rd byte offset of the IP Header \/\/ it has a hexadecimal value of 0x44)<\/li>\n\n\n\n
    • Header Length<\/strong>: 20 bytes (which is shown as a value of 5<\/code> in the header, multiplied by 4)<\/li>\n<\/ul>\n\n\n\n

      By subtracting the IP header length from the total IP datagram size:
      68 - 20 = 48 bytes<\/code><\/p>\n\n\n\n

      So, the ICMP header and data together occupy 48 bytes<\/strong> in this packet.<\/p>\n\n\n\n

      <\/p>\n","protected":false},"excerpt":{"rendered":"

      Lab 1.4 \u2013 IPv4 Packet Analysis This lab focused on examining network traffic at the IPv4 layer, with an emphasis on identifying abnormal or suspicious behavior within the packet capture. Lab Setup For this exercise, I used the capture file called ipv4.pcap. Once downloaded, I opened the file in Wireshark and began my analysis. Exercise […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[7,3,6],"class_list":["post-90","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-ipv4","tag-tcpdump","tag-wireshark"],"_links":{"self":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/90","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=90"}],"version-history":[{"count":5,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/90\/revisions"}],"predecessor-version":[{"id":106,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/90\/revisions\/106"}],"wp:attachment":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=90"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=90"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=90"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}