Computer network - packet capture and analysis

Packet capture and analysis

Table of contents

1. Purpose of the experiment

2. Experimental content

3. Experimental environment

4. Experimental steps and process


1. Purpose of the experiment

Learn to install and use protocol analysis software, master basic datagram capture, filtering and protocol analysis skills, and be able to analyze captured data packets.

2. Experimental content

Install and use protocol analysis software, learn how to capture data packets and analyze the captured data packets.

3. Experimental environment

  1. Windows operating system; Internet connection
  2. Packet capture software Wireshark.

4. Experimental steps and process

  1. Use of WireShark
    1. Select interface filter

After installing Wireshark, open Wireshark, you can see the interface shown in Figure 1, prompting us to select the filter of the corresponding interface, here I choose "Ethernet" to capture packets

Figure 1 Select interface filter

    1. Interface of Wireshark

After opening Wireshark, you can see the interface as shown in Figure 2. The interface of Wireshark is mainly divided into the following parts:

  1. Display filter: mainly used to filter packets
  2. Packet List: Display all captured packets, source and destination addresses, and port numbers. Different colors represent different packet types and states
  3. Packet Details: Displays the contents of the packet and various fields
  4. Hexadecimal data: display the original packet data in hexadecimal
  5. Address bar: Display packet statistics and miscellaneous

Figure 2 Wireshark main interface

      

    1. Wireshark filter

In the previous section, we introduced the interface of Wireshark and its various functions, and then we will focus on the functions of filters in Wireshark. Filters can quickly and accurately find the information we need in a large amount of data.

Figure 3 capture filter

There are mainly two types of filters, the display filter on the main interface in Figure 2 and the capture filter on Figure 3. Display filters are used to display the desired records among the captured records. The capture filter is mainly used to filter the packets to be captured, so as not to capture too many records.

Figure 4 shows the filter

       As shown in Figure 4, the display filter implements filtering . Specifically, the following rules can be used to filter:

  1. Protocol filtering: such as tcp, only display the tcp protocol
  2. IP filtering: If ip.src==192.168.1.102, it will display the packets whose source address is 192.168.1.102, and if ip.dst==192.168.1.102, it will display the packets whose destination address is 192.168.1.102.
  3. Port filtering: such as tcp.port == 80, only display the packets of the tcp protocol whose port is 80, or tcp.srcport == 80, only display the packets whose source port of the TCP protocol is 80
  4. Http filtering: such as http.request.method="GET", only display the packets of HTTP GET method.

In addition, filter expressions can be combined with logical operators or, and, etc. to achieve more complex filtering effects.

    1. Packet Details

Packet details are the most important in the packet capture process, it includes the following five fields:

  1. Frame: Overview of data frames at the physical layer
  2. Ethernet II: Data link layer Ethernet frame header information
  3. Internet Protocol Version 4: Internet layer IP packet header information
  4. Transmission Control Protocol: The data segment header information of the transport layer T, here is TCP
  5. Hypertext Transfer Protocol: Application layer information, here is the HTTP protocol

Figure 5 Packet details

       As shown in Figure 5, you can see the detailed information of a certain packet. The length of the packet, data link layer information, etc. will be displayed.

Figure 6 Packet details correspond to hexadecimal

       As shown in Figure 6, for each piece of data in the packet, you can click on the corresponding data to display the corresponding byte segment from the original hexadecimal file below. Next, we will introduce each type of packet separately.

  1. DNS analysis
    1. www.szu.edu.cn

Domain Name System (English: Domain Name System, abbreviation: DNS) is a service of the Internet. As a distributed database that maps domain names and IP addresses to each other, it can make it easier for people to access the Internet. DNS uses UDP port 53. In http://www.szu.edu.cn/board/, the www.szu.edu.cn domain name requires DNS resolution to obtain the corresponding ip address before accessing network resources.

First check the domain name resolution through DNS packet capture. Open Wireshark to capture the packets of the network card. Then ping the domain name www.szu.edu.cn. According to the previous experiment, the ping operation first needs to analyze the domain name, and then access and get a reply through the ip address. The ip after domain name resolution is obtained through ping, as shown in Figure 7.

Figure 7 Get the resolved ip address by ping

Next, open Wireshark and enter DNS in the filter box to filter out the packets resolved by DNS, as shown in Figure 8. From the results, there are exactly two DNS resolution packets, corresponding to the sending and replying of the resolution request respectively.

Figure 8 Screening DNS results

First check the data packets sent for DNS resolution, as shown in Figure 9. First, from the perspective of the Internet layer, DNS resolution uses the ipv4 protocol, and a DNS resolution request is sent to 223.5.5.5 (Alibaba Cloud Public DNS). As can be seen from the transport layer, the UDP protocol (User Datagram System) is used, and the port uses port 53. Next is the detailed information of the DNS protocol: the first is the Transaction ID identification field, with a length of 2 bytes, which is used to identify which request message the DNS response message is in response to. The second is the Flags field, with a length of 2 bytes. Detailed data can be obtained by analyzing the information of different bits:

  1. Response: query/response, 1 is response, 0 is query.
  2. Opcode: query or response type, where 0 means standard, 1 means reverse, and 2 means server status request.
  3. Truncated: Truncated, 1 means more than 512 bytes and has been truncated, 0 means no truncation occurred.
  4. TC: truncation, 1 means more than 512 bytes and has been truncated, 0 means no truncation occurred.
  5. zero: All 0 reserved fields.
  6. Recursion: Whether you want to get a recursive answer.

After analyzing the above information, it can be known that the data packet is a standard DNS request and has not been truncated, and it is hoped to get a recursive answer.

Next is the request part. The field Queries is the body part of the query or response, which is divided into Name, Type, and Class. Name is the domain name that needs to be requested, and the variable length ends with 0; Type is the query type, here is the host A record; in the last Class, IN means Internet data.

Figure 9 Sending DNS request packets

Next, analyze the DNS packet in the reply part, as shown in Figure 10. It can be seen that the Transaction ID is still the mark at the time of sending, which is used to indicate that this is the mark that replied to the request at that time; the change of Response from 0 to 1 indicates that this is the DNS of the reply; the newly added Recursion available is 1 to indicate that the server can Use recursive query; the Reply Code is all 0 data means that there is no error. Compared with the request, there is one more Answers in the reply. Since the ping operation only requests one domain name, there is only one table name in Answers, and the domain name has only one resolution. Check the domain name parsed in Answers, you can see that the name of the domain name is www.szu.edu.cn, the Type is A indicating that this is an Ipv4 address, the Class is In indicating that this is Internet data, Time to Live (time to live TTL ) indicates the life cycle of the resource record, the time from fetching the record to erasing the record cache, here is 9 minutes and 26 seconds. Data length (resource data length) is in bytes, where 4 means that the length of the IP address is 4 bytes, that is, the length of the parsed ip. Addr (resource data): The returned IP address 210.39.4.1 is the result we want, and the ip is consistent with the information in the ping command line.

Figure 10 DNS reply

    1. www.youku.com

Open Wireshark to capture the data packets of the network card, and then use the ping command to test the connectivity of the domain name www.youku.com (relevant operations are omitted).

Open Wireshark, enter DNS in the filter box to filter out the DNS request packets, and get two packets as shown in Figure 11, representing the DNS request and reply respectively.

Figure 11 Filtered DNS-related packets

First open the requested packet, as shown in Figure 12. It can be seen from the results that the protocol uses UDP and the port is 53; the request is sent to 223.5.5.5 (Alibaba Cloud Public DNS); the Transaction ID of the packet is 0x6cea. From the Flags field, it can be concluded that it is a requested data packet, the request is a standard query, not truncated, and a recursive query is requested. Then get the resolution of only one domain name requested from the Queries field, the type is ipv4, and it is a network data type.

Figure 12 DNS resolution request packet

Next, analyze the responses obtained, as shown in Figure 13. It can be seen that the Transaction ID is still the mark at the time of sending, which is used to indicate that this is the mark that replied to the request at that time; the change of Response from 0 to 1 indicates that this is the DNS of the reply; the newly added Recursion available is 1 to indicate that the server can Use recursive query; the Reply Code is all 0 data means that there is no error.

Looking at the domain name resolved in Answers, you can see that, first, an item of type CNME is returned. CAME is the standardized name, that is, www.youku.com can be standardized as ipv6-aserver-heyi.m.taobao.com. Then, analyze ipv6-aserver-heyi.m.taobao.com again, and get the second item that is also CNME. The project standardized the name again, and standardized ipv6-aserver-heyi.m.taobao.com to ipv6-aserver-heyi.m.taobao.com.gds.alibabadns.com. At this time, domain name resolution is performed again to obtain the third item. At this time, the return is finally the Ipv4 address of A, the Class is In to indicate that this is an Internet data, and the Time to Live (TTL) indicates the life cycle of the resource record, the time from fetching the record to erasing the record cache, 21 seconds here. Data length (resource data length) is in bytes, where 4 means that the length of the IP address is 4 bytes, that is, the length of the parsed ip. Addr (resource data): The returned IP address 106.11.35.97.

Figure 13 DNS resolution reply packet

    1. www.sina.com.cn

Open Wireshark to capture the data packets of the network card, and then use the ping command to test the connectivity of the domain name www.sina.com.cn, as shown in Figure 14.

Figure 14 ping operation

Open Wireshark, enter DNS in the filter box to filter out the DNS request packets, and get two packets as shown in Figure 15, representing the DNS request and reply respectively.

Figure 15 Screening DNS packets

First open the requested packet, as shown in Figure 16. It can be seen from the results that the protocol uses UDP and the port is 53; the request is sent to 223.5.5.5 (Alibaba Cloud Public DNS); the Transaction ID of the packet is 0x96c7. From the Flags field, it can be concluded that it is a requested data packet, the request is a standard query, not truncated, and a recursive query is requested. Then get the resolution of only one domain name requested from the Queries field, the type is ipv4, and it is a network data type.

Figure 16 DNS resolution request packet

Next, analyze the answers obtained, as shown in Figure 17. It can be seen that the Transaction ID is still the mark at the time of sending, which is used to indicate that this is the mark that replied to the request at that time; the change of Response from 0 to 1 indicates that this is the DNS of the reply; the newly added Recursion available is 1 to indicate that the server can Use recursive query; the Reply Code is all 0 data means that there is no error.

Figure 17 DNS resolution reply packet 1

Looking at the domain name resolved in Answers (Figure 18), we can see that, first, an item of type CNME is returned. CAME is the standardized name, that is, www.sina.com.cn can be standardized as spool.grid.sinaedge.com. Then, analyze spool.grid.sinaedge.com again to get the second project which is also CNME. The project standardized the name again, and normalized spool.grid.sinaedge.com to ww1.sinaimg.cn.w.alikunlun.com. At this time, domain name resolution is performed again to obtain the remaining 13 items. At this time, all returned are Ipv4 addresses of type A, and Class of In indicates that this is Internet data. It can be found that the ping command only operates on the first ipv4 address at the end. DNS resolves a domain name into multiple ips, so that once one of the ips goes down, you can quickly access other ips to connect, which increases the reliability of the service.

Figure 18 The domain name resolved by Answers

  1. HTTP

Hypertext Transfer Protocol (Hypertext Transfer Protocol, HTTP) is a simple request-response protocol, which usually runs on TCP, and the port number is generally 80 . It specifies what kind of messages the client may send to the server and what kind of responses it may get.

Since www.szu.edu.cn, www.youku.com, www.sina.com.cn and many other websites have adopted the more secure https protocol, the website for testing the http protocol uses the student apartment management center http ://gyzx.szu.edu.cn/.

First open Wireshark to capture the data packets of the network card, and then open http://gyzx.szu.edu.cn/ in the browser. Then return to Wireshark, enter http in the filter box to filter the data packets, and get two data packets, which represent the http request and reply respectively, as shown in Figure 19.

Figure 19 http request and reply

First, let's observe the data packet of the http request, as shown in Figure 20.

Figure 20 http request

It can be seen from the transport layer that http uses the tcp protocol and the port is 80. At the application layer, you can see the message format of the http protocol. First, the data packet uses the GET method, and the protocol is HTTP 1.1. HTTP1.0 defines three request methods: GET, POST and HEAD methods. HTTP1.1 adds five new request methods: OPTIONS, PUT, PATCH, DELETE, TRACE and CONNECT methods.

Table 1 http request method

GET

Request the specified page information and return the entity body.

HEAD

Similar to a GET request, except that there is no specific content in the returned response, which is used to obtain the header

POST

Submit data to a specified resource to process a request (such as submitting a form or uploading a file). Data is included in the request body. POST requests may result in the creation of new resources and/or the modification of existing resources.

PUT

The data sent from the client to the server replaces the content of the specified document.

DELETE

Requests the server to delete the specified page.

CONNECT

Reserved in the HTTP/1.1 protocol for proxy servers that can pipe connections into.

OPTIONS

Allows clients to view server performance.

TRACE

Echoes the requests received by the server, mainly for testing or diagnosis.

PATCH

Complementary to the PUT method for partial updates to known resources.

As you can see from the Connection, the request is keep-alive, that is, a permanent connection. This is beneficial to use the same TCP connection to receive when there are many pictures and other resources in the webpage you visit, instead of establishing a TCP/IP connection for each file. User-Agent represents the detailed information of the accessed client. Accept-Encoding: gzip, deflate indicates the encoding format supported by the browser. Here is the compression encoding method. It is guessed that the server sends all the files requested by the browser as compressed files. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 indicates the language type supported by the browser, and supports zh-CN,zh,en. Then send zh-CN and zh languages ​​first, because their weight is 0.9.

Next, analyze the reply of the http protocol, as shown in Figure 21.

Figure 21 http reply

By directly analyzing the http protocol of the application layer, it can be seen that the reply also uses http1.1, and the Status is 200, indicating that the client request is successful. Several common status codes are as follows.

  1. 200: The client request is successful, which is the most common status.
  2. 302: Redirect.
  3. 404: The requested resource does not exist, which is the most common status.
  4. 400: The client request has a syntax error and cannot be understood by the server.
  5. 401: The request is unauthorized.
  6. 403: The server received the request but refused to provide the service.
  7. 500: Internal server error, which is the most common status.
  8. 503: The server is currently unable to process the client's request.

Content-Length indicates the content length. Content-Type indicates what MIME type the following document belongs to. The default is text/plain, but it usually needs to be explicitly specified as text/html. Date is the current GMT time. The final line-based text data is the returned webpage content, and the browser presents the webpage to the user after parsing the html language.

  1. TCP

Transmission Control Protocol (TCP, Transmission Control Protocol) is a transmission protocol specially designed to provide reliable end-to-end byte streams on unreliable Internet networks. The application layer sends a data stream represented by 8-bit bytes for inter-network transmission to the TCP layer, and then TCP divides the data stream into message segments of appropriate length. After that, TCP passes the result packet to the IP layer, which then transmits the packet to the TCP layer of the receiving entity through the network. In order to ensure that no packet loss occurs, TCP gives each packet a sequence number, and the sequence number also ensures that the packets transmitted to the receiving end entity are received in order. The receiving entity then sends back a corresponding acknowledgment (ACK) for the successfully received packet; if the sending entity does not receive an acknowledgment within a reasonable round-trip delay (RTT), the corresponding packet is assumed to be was lost and retransmitted. TCP uses a checksum function to check whether the data has errors, and the checksum is calculated when sending and receiving.

Next, observe the TCP connection by opening the website www.szu.edu.cn. First open Wireshark to capture data packets of the network card, and then open www.suz.edu.cn in the browser. It can be seen from Figure 7 that the ip address after domain name resolution is 210.39.4.1, so enter "ip.addr == 210.39.4.1" in the filter box of Wireshark to filter the data packets. The result obtained is shown in Figure 22.

Figure 22 TCP packet

    1. TCP establishment

The first three data packets in Figure 22 establish a connection for the TCP three-way handshake protocol. When the active party sends a SYN connection request, it waits for the other party to reply SYN+ACK, and finally executes ACK confirmation for the other party's SYN. This method of establishing a connection can prevent erroneous connections. The flow control protocol used by TCP is a variable-size sliding window protocol.

The process of TCP three-way handshake is as follows:

  1. The client sends a SYN (SEQ=x) message to the server and enters the SYN_SEND state.
  2. The server receives the SYN message, responds with a SYN (SEQ=y) ACK (ACK=x+1) message, and enters the SYN_RECV state.
  3. The client receives the SYN message from the server, responds with an ACK (ACK=y+1) message, and enters the Established state.

The three-way handshake is completed, the TCP client and server successfully establish a connection, and data transmission can begin.

First, let’s analyze the first handshake. The data packet is shown in Figure 23. It can be seen that the TCP port is 443 because the webpage opened using the HTTPS protocol. Src is the client, and Dst is the ip after the accessed domain name, so this is the data sent by the client to the server. It can be seen that the client sets the Flags flag SYN to 1, randomly generates a value Sequence Number = 0 as the sequence number, and sends the data packet to the server. The client enters the SYN_SENT state and waits for the server to confirm. In fact, the Wireshark tool has optimized it for us. By default, it shows that the sequence number seq is a relative value, not the real value. The real value is in the Sequence Number (raw), and the value is 1136243156.

Figure 23 TCP first handshake

Then comes the second handshake, as shown in Figure 24. It can be seen that the Src of the data packet is the server, and the Dst is the client, indicating that this is the data sent by the server to the client. Observe at this time that SYN is still 1. Then, the server sets the Acknowledgment Number to the client's sequence number seq plus 1, that is, 0+1=1, and the ACK becomes 1 (the real value is 1136243157 = 1136243156 + 1), indicating that the server has received the TCP request. At this time, seq is randomly generated by the server with a relative value of 0 (the actual value is 1721425601).

Figure 24 TCP second handshake

Next is the third TCP handshake, as shown in Figure 25. It can be seen that the Src of the data packet is the client, and the Dst is the server. This is the data packet sent by the client. In the third handshake, the client checks whether the sequence number Seq is correct after receiving the packet sent by the server in the second handshake, that is, the sequence number Seq sent for the first time plus 1 (X+1= 0+1=1) . And whether the flag bit ACK is 1. If it is correct, the client will send another data packet to the server, SYN=0, ACK=1, confirm the sequence number Ack=Y+1=0+1=1, and add 1 to the sequence number Seq sent by the server to the server. The other party sends the sequence number Seq as X+1=0+1=1. After receiving it, the client confirms the serial number value and ACK=1. At this point, a TCP connection is established and data can be transmitted.

Figure 25 TCP third handshake

    1. data transmission

In the data transmission phase, the data reliability is still guaranteed between the server and the client through the values ​​of Seq and Ack. The specific operation is shown in Figure 26.

Figure 26 TCP data transmission process

Since there are a lot of data packets in data transmission, for a more intuitive observation, you can open the statistics-traffic graph in Wireshark, as shown in Figure 27. As can be seen in the figure, the server and the client have been communicating without termination. At the same time, because the number of data packets sent or received is not fixed, the values ​​of Seq and Ack vary.

Figure 27 TCP transmission data

    1. waved four times

Establishing a connection requires a three-way handshake, and terminating a connection requires a four-way handshake, which is caused by the half-close of TCP. The specific process is as follows.

(1) Client A sends a FIN to close the data transfer from client A to server B.

(2) Server B receives the FIN, and it sends back an ACK, confirming that the serial number is the received serial number plus 1. Like SYN, a FIN will occupy a sequence number.

(3) Server B closes the connection with client A and sends a FIN to client A.

(4) Client A sends back an ACK message for confirmation, and sets the confirmation sequence number to the received sequence number plus 1.

The specific captured data packets are shown in the red box in Figure 28. First, the first line indicates that the client sends a FIN request to the server; then, in the second line, the server sends an ACK reply to the client, indicating that the server has received the end request; then, in the third line, the service The end sends FIN to the client, and the table name server has closed the communication; in the fourth line, the client receives the closing information from the server, so it also closes the communication itself, and at the same time, sends the information that it has received the closing communication to the server with ACK end. At this point, the entire TCP connection has been completely closed

Figure 28 TCP waved four times

  1. UDP

UDP is the abbreviation of User Datagram Protocol. The Chinese name is User Datagram Protocol. It is a connectionless transport layer protocol in the OSI reference model, providing transaction-oriented simple and unreliable information transmission services. The UDP protocol, like the TCP protocol, is used to process data packets. In the OSI model, both are located at the transport layer, which is the upper layer of the IP protocol. UDP has the disadvantages of not providing data packet grouping, assembling and sorting of data packets, that is to say, after the message is sent, it is impossible to know whether it has arrived safely and completely.

 Next, use the process of logging in to QQ to capture UDP packets for analysis. First open Wireshark to capture data packets on the network card, then log in to QQ, and enter OICQ in the Wireshark filter box to filter. The OICQ protocol is the protocol used by QQ when communicating with the server, usually based on the UDP protocol. After filtering, many packets of OICQ protocol are obtained, as shown in Figure 29.

Figure 29 OICQ packet

Next, open a packet at random, as shown in Figure 30. It can be seen that this is a data packet sent from the server to the client, and the transport layer uses the UDP protocol. Compared with the TCP protocol, the message of the UDP protocol is very simple, because the UDP message does not guarantee reachability, and is suitable for applications with high data flow. Then the application layer protocol is the OICQ protocol, this part of the protocol is completely defined by QQ, and contains the information needed for QQ communication.

Figure 30 OICQ packet details

Guess you like

Origin blog.csdn.net/m0_46326495/article/details/123789347