Tcpdump packet capture (http request packet capture)

tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0x4745 is the first two letters "GE" of "GET"

0x4854 is the first two letters "HT" of "HTTP"

Explanation: Under normal circumstances: a normal TCP connection will have three stages: 1. TCP three-way handshake; 2. Data transmission; 3. TCP waved four times

Several concepts inside:

• SYN: (Synchronize Sequence Number, Synchronize Sequence Numbers)
• ACK: (confirmation number, Acknowledgment Number)
• FIN: (end flag, FINish)

TCP three-way handshake (create OPEN)

1. The client initiates a request to establish a TCP connection with the service, here is SYN(J)
2. After receiving the creation request from the client, the server returns two messages: SYN(K) + ACK(J+1)
3. After the client receives the ACK information from the server and successfully verified (J and J+1), it returns a message: ACK(K+1)
4. After the server receives the client's ACK information verification successfully (K and K+1), it will no longer return information, and then enter the data communication stage

data communication

1. Client/server read/write packets

TCP four-way handshake (close finish)

1. The client initiates a close request and sends a message: FIN(M)
2. After receiving the message, the server first returns ACK (M+1), indicating that it has received the message.
3. Before the server is ready to close, it finally sends a FIN(N) message to the client, asking if the client is ready to close
4. After receiving the message sent by the server, the client returns a confirmation message: ACK(N+1)
5. Finally, when both the server and the client are confirmed, each closes or recycles the corresponding TCP connection.

Detailed status description (and linux related parameter adjustment)

1. SYN_SEND
   • The client tries to connect to the server through the open method. That is, the TCP three-way handshake is being uploaded... After the first step in the re-upload cancellation, pay attention to the client status
   • sysctl -w net.ipv4.tcp_syn_retries = 2 , as a client, you can set the number of retries of SYN packets, the default is 5 times (about 180s). Quote from the principal: only retry 2 times, modern network is enough
2. SYN_RECEIVED
   • After the service accepts the SYN of the creation request, that is, the TCP three-way handshake is uploading... Step 2 in the re-upload cancellation, before sending the ACK packet
   • Pay attention to the status of the server. Generally, about 15 are normal. If it is too large, it is suspected of being attacked by SYN_FLOOD
   • sysctl -w net.ipv4.tcp_max_syn_backlog=4096 , set the number of waiting queues in this state, the default is 1024, it can properly prevent syn-flood after increasing it, see man 7 tcp is uploading... re-upload to cancel
   • sysctl -w net.ipv4.tcp_syncookies=1 , open syncookie, provide a mechanism to temporarily swap out the syn link when the syn backlog queue is insufficient
   • sysctl -w net.ipv4.tcp_synack_retries = 2, as the number of retries for the server to return the ACK packet, the default is 5 times (about 180s). Quote from the principal: only 2 retries, modern network is enough
3. ESTABLISHED
   • The status after the client receives the ACK packet from the server, and the server will be ESTABLISHED after sending the ACK within a certain period of time
   • sysctl -w net.ipv4.tcp_keepalive_time = 1200, the default is 7200 seconds (2 hours), the system will perform a heartbeat check for idle links, if it exceeds net.ipv4.tcp_keepalive_probes * net.ipv4.tcp_keepalive_intvl = default 11 minutes, terminate the corresponding tcp link, the frequency of heartbeat check can be adjusted appropriately
   • Current online monitoring warning: 600 , critical : 800
4. FIN_WAIT1
   • The party that actively closes, after sending the FIN request, that is, the TCP four-way handshake is uploading... the first step of re-uploading cancellation
5. CLOSE_WAIT
   • The party that is passively closed, after receiving the FIN from the client, is uploading during the TCP four-way handshake... re-uploading and canceling the second step
6. FIN_WAIT2
   • The party that actively closes, after receiving the ACK from the passive close party, that is, the TCP four-way handshake is uploading... the second step of re-uploading and canceling
   • sysctl -w net.ipv4.tcp_fin_timeout=30, you can set the timeout period after the passive close party returns FIN, effectively recycle the link, and avoid syn-flood.
7. LASK_ACK
   • The party that is passively closed initiates a FIN request after a period of time after sending the ACK (to ensure that the client has received it). That is, the TCP four-way handshake is uploading... the third step of re-uploading cancellation
8. TIME_WAIT
   • The party that closes actively sends ACK after receiving the FIN packet of passive close. That is, the TCP four-way handshake is being uploaded... the fourth step of the re-upload cancellation
   • sysctl -w net.ipv4.tcp_tw_recycle = 1 , 打开快速回收TIME_WAIT，Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation)
   • sysctl -w net.ipv4.tcp_tw_reuse =1, quickly recycle and reuse the TIME_WAIT link, it seems to conflict with tw_recycle, recycle if it cannot be reused?
   • net.ipv4.tcp_max_tw_buckets: The maximum number of connections in the time_wait state, the default is 180000.

Related instructions:

1. After receiving the FIN request from the passive closing party, the active closing party changes its state from FIN_WAIT2 to TIME_WAIT after successfully sending an ACK to the other party, and must wait for twice the MSL (Maximum Segment Lifetime, MSL is a datagram The time that can exist in the internetwork) After the time, both parties can change the status to CLOSED to close the connection. At present, the time to maintain the TIME_WAIT state in RHEL is 60 seconds
2. The keepAlive strategy can effectively avoid three-way handshake and four-way close

Other network important parameters

net.ipv4.tcp_rmem parameter

• Default: min=4096 default=87380 max=4194304

net.ipv4.tcp_wmem parameter

• Default: min=4096 default=16384 max=4194304

---

tcpdump

Tcpdump is a packet capture tool that comes with the linux system. It is mainly through the command line. It is more suitable for online server capture operations. If it is windows or ubuntu, you can choose some graphical tools. Ubuntu recommends using wireshark. The installation method It's very simple, just sudo apt.

Command line format:

tcpdump [ -adeflnNOpqStvx ] [ -c number ] [ -F filename ] [ -i network interface ] [ -r filename ] [ -s snaplen ] [ -T type ] [ -w filename ] [expression ]

Common parameters:

-l makes standard output buffered;
-n does not convert network addresses to names;

-c After receiving the specified number of packets, tcpdump will stop;
-i specifies the network interface to monitor; (if not specified, it may be monitored on the default network card, you need to specify the network card bound to a specific IP)
-w directly The package is written into the file, but not analyzed and printed out;
-s specifies the size of the recorded package, the common -s 0 represents the maximum value of 65535, half of the Linux transmission minimum unit MTU is 1500, which is enough

-X directly output package data data, which is not set by default, and can only be output by specifying the file with -w

Common expressions:

1. Keywords about types, mainly including host, net, port
2. The keywords of the transmission direction mainly include src , dst ,dst or src, dst and src
3. Protocol keywords, mainly including fddi, ip, arp, rarp, tcp, udp and other types
4. Logical operation, negation operation is 'not ' '! ', and operation is 'and', '&&'; or operation is 'or', '||'
5. Other important keywords are as follows: gateway, broadcast, less, greater

Practical examples:

1. HTTP packet capture (directly output package data on the terminal)

tcpdump tcp port 80 -n -X -s 0 specifies port 80 for output

2. Capture the specified file of http package data to output package

tcpdump tcp port 80 -n -s 0 -w /tmp/tcp.cap

The corresponding /tmp/tcp.cap can basically see the information with the naked eye, such as http Header, content information, etc.

3. Combining pipe flow

tcpdump tcp port 80 -n -s 0 -X -l | grep xxxx

This enables string matching filtering of packets in real time

4. mod_proxy reverse proxy packet capture

Online server apache+jetty, a reverse proxy through apache mod_proxy, 80 apache port, 7001 jetty port

Apache port data capture: tcpdump tcp port 80 -n -s 0 -X -i eth0 Note: Specify the eth0 network interface

Jetty port data capture: tcpdump tcp port 7001 -n -s 0 -X -i lo Note: Specify the Loopback network interface

5. Only monitor specific ip hosts

tcpdump tcp host 10.16.2.85 and port 2100 -s 0 -X　

You need to use a combination of tcp expressions, here is the host instruction to only listen to the ip

Tips:

1. Can be combined with tcpdump (command) + wireshark (graphical)

operate:　

• • Perform tcpdump -w /tmp/tcp.cap on the server to specify the output external file
  • scp /tmp/tcp.cap copy the file to your local
  • wireshark & ​​start wireshark
  • Open the copied file through File -> Open, so that you can use it for packet analysis
  • The rest is very convenient

tcpdump  -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854 -vvv

13:45:34.199147 IP (tos 0x0, ttl 64, id 40098, offset 0, flags [DF], proto TCP (6), length 3545)
    host-11-11-35-35.65530 > 11.18.11.18.http: Flags [P.], cksum 0x8c84 (incorrect -> 0x1d14), seq 2648134490:2648137995, ack 3508301428, win 15, length 3505: HTTP, length: 3505
  GET /static/js/chunk-55fc74fe.31902c3d.js HTTP/1.0
  Host: zb.ik.com
  X-Real-IP: 11.22.162.12
  X-Forwarded-For: 11.22.162.12
  Connection: close
  sec-ch-ua: "Google Chrome";v="105", "Not)A;Brand";v="8", "Chromium";v="105"
  sec-ch-ua-mobile: ?0
  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
  sec-ch-ua-platform: "macOS"
  Accept: */*
  Sec-Fetch-Site: same-origin
  Sec-Fetch-Mode: no-cors
  Sec-Fetch-Dest: script
  Referer: https://zb.ik.com/
  Accept-Encoding: gzip, deflate, br
  Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  Cookie: www.likecs.com|t_331182531_|tuguan; areaId=1;  
  X-Jdlb-Client-Port: 5604
  J-Forwarded-For: 10.0.16.131
  X-Original-To: 178.20.36.249