So to start, there was this string of UDP packets going outbound to an ip address on port 111. If you were to google search port 111 you'd see that one possibility is Sun Remote Procedure Calls. Let's take a bit of a deeper dive into these packets.
You can see above that WireShark has actually used the Ethernet Frame (layer 2) to determine the MAC addresses of the source & destination. MAC Addresses are unique identifiers for devices, and are useful because you can do a google search and determine based on the MAC address what vendor / company made the device and likely what type of device it may be. So how did Wireshark determine these MAC Addresses? Well below you'll see that HEX interpretation of the first several bytes in the Ethernet Header.
This is Layer 2, so we're talking about devices or usually MAC Addresses. If you were to read about Ethernet Frames you'd see that the 1st 6 octets (2 hex digits) there make up the Destination MAC Address (in this case ending with :41:16) and the 2nd 6 octets make up the Source MAC Address (in this case ending with :48:c3). You'll also notice the next 2 octets (81 00) tell you the Ethernet Type which in this case indicates 802.1Q which is used to define standards for VLAN tagging ( the practice of inserting a ID into a packet header to identify which VLAN the packet belongs to ). The next portion of what Wireshark shows you is the 802.1Q information.
Above you see that Wireshark identified that the VLAN tagging says Priority is default, CFI (format indicator) is canonical, and the ID is 6. You will see it also says that this is IPv4. But how did Wireshark know all that?
Well, above are the HEX values that wireshark analyzed.
0 ==> The first HEX digit (4 bits) is split. The 1st 3 bits indicate Priority and the value 0 in this case is default (Best Effort). The last bit is the format indicator, in this case 0 (Canonical)
0 06 ==> The next 3 HEX digits (1.5 octets) make up the VLAN identifier (for the tagging we said above). In this case converting HEX to decimal is simple 0x16^2+0x16^1+6x16^0 equals 6 as the ID.
08 00 ==> The final 2 octets are for the EtherType, in this case 0x0800 which defines that this is IPv4 (e.g. ip normal addresses such as 171.70.71.72) .
Next Wireshark displays you the IP header information (Layer 3).
Above you can see that wireshark was able to determine that this is IPv4, the protocol is UDP, and determine the source & destination IP address. Again though, how did Wireshark determine that?
Above is the HEX interpretation of the IPv4 Header. This is layer 3 so you'll see below that we're talking about IP addresses communicating.
4 ==> The 1st HEX digit indicates the IP protocol version, in this case simply IPv4.
5 ==> The next HEX digit indicates the length of this IP header we are in (5 * 32 = 160 bits = 20 bytes = 5 words).
00 ==> The next octet used to be type of service, but has been redefined as Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) for new technologies and doesn't apply here so it's 0.
00 54 ==> The next 2 octets define the total length of the entire packet (including header & data), which in this case 5x16^1+4x16^0=84 bytes.
0e b8 ==> The next 2 octets define an identifier for this packet in case of fragmentation where they have to be re-assembled (3768).
00 00 ==> the next 2 octets define information about a fragment if the packet needed to be broken up. The 1st 3 bits are flags that define if you should fragment or not. The remaining 13 bits define the fragment offset which tells the re-assembler how far from the beginning of the fragment you are away. In this case everything is 0 so this would be the first fragment.
1a ==> The next octet defines the time to live, which is a way to prevent infinite loops when routing packets. Every time a packet is routed to another device this count is decremented. If it hits 0, the packet is discarded (and assumed to be in an infinite loop). You can usually guess what Operating System sent a packet by it's TTL. Linux TTLs start at 64 and count down to zero. Windows TTLs start at 32 and count down to zero. Most of the time packets should reach their destination in very few hops, well before the TTL expires. Thus in this case the TTL is (1x16^1+10x16^0=26). 26 would indicate that this is likely a windows system that sent this packet since 32-26=6 hops which is probably an average acceptable value. If the number was in the 50s or 60s it might indicate it's a Linux device that sent it.
11 ==> The next octet defines the protocol (1x16^1+1x16^0=17). In this case 17 is defined by IP protocol as a UDP packet.
2c 64 ==> The next 2 octets are a header checksum (11364), which can be used by some devices that are routing packets to determine if this packet has been tampered with or modified.
XX XX a1 80 ==> The next 4 octets are probably what you're usually after, the source ip, or who sent this packet! (a1=161,80=128 == XX.XX.161.128)
XX XX 0f 1a ==> The next 4 octets are also extremely useful, destination ip, or who this packet is supposed to go to! (0f=15,1a=26 == XX.XX.15.26)
Next we'll look at the UDP header.
Above is the UDP packet, which is Layer 4, so you'll see information about which ports the 2 devices will use to communicate with eachother. Wireshark above shows you that the source port is 899 and the destination port is 111. It also tells you the length of the udp packet and gives you another checksum for validation. But again how does Wireshark know this?
03 83 ==> The first 2 octets are used to calculate the source port. In this case 3x16^2+8x16^1+3x16^0 equals 899.
00 6f ==> The second 2 octets calculate the destination port. In this case 6x16^1+15x16^0 equals 111.
00 40 ==> The 3rd 2 octets tell you the length of this udp header plus data. In this case 4x16^1+0x16^0 equals 64 bits which is 8 bytes or 2 words.
9c d0 ==> The checksum again is a value that can be used to determine if this packet was modified or tampered with (40144).
Next we'll look at the RPC data for the remote procedure call.
Above Wireshark has determine this UDP packet is a Remote Procedure call which is part of layer 5, the session layer. So it's going to manage the session where the calling system is making a request to the receiving system and getting a response back. Above you can see that Wireshark determined RPC version 2 is being used, a procedure is being called, the program the procedure is in is Portmap, the Portmap version is 2, the procedure requested in that Portmap program is called GETPORT, and no credentials or verification is being performed. But how does Wireshark know all that?
57 47 f6 f2 ==> The first 4 octets give the remote procedure call a unique transaction id for tracking.
00 00 00 00 ==> The next 4 octets define whether is a call CALL or REPLY, in this case 0 = call.
00 00 00 02 ==> The next 4 octets define the version of RPC which in this case is 2.
00 01 86 a0 ==> The next 4 octets define which program contains the procedure being requested. In this case program 100000 is portmap. Other example programs could be things like nfs, status, lock manager, or mount.
00 00 00 02 ==> The next 4 octets define program version , in tihs case it's saying Portmap is version 2.
00 00 00 03 ==> The next 4 octets define which procedure in the program (portmap) is being requested. In this case procedure 3 is GETPORT, so it's requesting a which port is used. Other procedures could be things like SET , UNSET, and DUMP a port.
00 00 00 00 00 00 00 00 ==> The next 8 octets are used to pass Credentials (optional) when making a call to a procedure. If it's all 0s like in this case, then it's null or no authorization is used, essentially a anonymous request.
00 00 00 00 00 00 00 00 ==> The final 8 octets are also used. If this is a call to a procedure that requires credentials, then the credentials and this verifier token are passed. If it's not used it'll be all 0s again.
Finally let's take a look at the Portmap procedure call.
Above wireshark has determined that inside this UDP Remote procedure call, the program being called is Portmap, and it's calling the GETPORT procedure. This procedure is used to find out the port number assigned to a particular program. But how does wireshark know this final layer 7 application layer information?
02 22 22 22 ==> In the first 4 octets, this identifier is used to identify which unique program the requestor is asking for the port number of. So basically the requesting system wants to make a remote call to a program on the receiving system, but the requesting system doesn't know which port to use, so it's first using this portmap program to ask, "hey, which port is program 02 22 22 22 using?" The system will respond either with a port number if the program is running, or with a failure if the program doesn't exist.
00 00 00 01 ==> In the next 4 octets, it's saying that the requestor is requesting a port number for version 1 of the progrma.
00 00 00 06 ==> In the next 4 octets, it's saying that the requestor is requesting the TCP port for the program, the protocol number 6 in this case maps to TCP.
00 00 00 00 ==> The final 4 octets are empty in a call like this, but in a response would be filled with the actual port number the program is using for version 1 tcp.
Hopefully this walk-through was useful in getting a better understanding of how Wireshark works , how the different layers of the OSI model are utilized, and how to do basic packet analysis.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment