Preface
This case originates from Sharkfest 2017’s “Digging Deep – Exploring Real-Life Case Studies,” authored by Sake Blok, a core developer of Wireshark and an expert in network protocol fault analysis. A recent discussion with a friend about this case led to the examination of the relevant data packets, allowing for a detailed analysis of the issues surrounding TCP SYN Flood attacks.
The original file is a PDF file, and case00 has only two pages, one describing the problem and the other describing the solution. There is actually no analysis process.
Background
The customer called on Sunday night and said that their entire network infrastructure was down. The author, as an engineer for F5 load balancing equipment, analyzed and handled the failure.
The illustrations shared in the article are as follows:
The infrastructure reported by the customer is out of service, which is described in the cited case. Combined with the diagram, from my personal understanding, the author briefly expressed that the customer’s Web service website could not be opened.
Problem Analysis
The basic information of the packet trace file is as follows:
$ capinfos case00.pcapng
File name: case00.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Packet size limit: inferred: 104 bytes
Number of packets: 2593
File size: 243 kB
Data size: 179 kB
Capture duration: 25.932148 seconds
First packet time: 2013-04-22 03:09:01.023908
Last packet time: 2013-04-22 03:09:26.956056
Data byte rate: 6921 bytes/s
Data bit rate: 55 kbps
Average packet size: 69.22 bytes
Average packet rate: 99 packets/s
SHA256: e37150bc622eb9c27d26ee694dedef28ec33ed97c3cc2ddbeb1d00e5ce207070
RIPEMD160: 34196064244bf3df09825d5f508b813ec5bf7fd5
SHA1: 74506abbff434e7b9d5149001122d9f5e8d911b7
Strict time order: False
Capture comment: Sanitized by TraceWrangler v0.6.2 build 799
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Number of stat entries = 0
Number of packets = 2593
$The basic judgment is that the data packet capture should be tcpdump, and the corresponding truncation is done, the size is 104 bytes. The number of packets is 2593, the capture time is about 26 seconds, the average rate is 55 kbps, and the data packet file is processed by anonymization tools.
The expert information prompts a lot of information, including Error and Warning levels, including prompts of IPv4 length exceeding, non-SYN data packets containing MSS options, checksum errors, sessions using the same port, etc. The last prompt shows the number of SYN data packets, 1396, which exceeds 50% of the total number of captured data packets, and is basically suspected of a SYN Flood attack.
The actual data packet information is as follows:
TCP DUP ACK、TCP Out Of Order、TCP Retransmission
The first thing you can see in the trace file is a large number of TCP DUP ACK, disordered order and retransmission phenomena, including a large number of red and black marks displayed in the right sidebar. There are indeed many problems. But are there actually any problems? In fact, there are no problems.
If you look carefully at the context of the packets with TCP DUP ACK, disorder and retransmission, you will find that they all appear in pairs and the information is basically the same. Combined with the description that the author is an F5 load balancing engineer, it means that the trace file was captured on the F5 device and the packets in both directions are captured. This will cause the same packet to be captured once when it comes in and once when it goes out . This will cause Wireshark to prompt that there are TCP DUP ACK, disorder and retransmission, but in fact it can be understood that the packets are captured repeatedly.
Taking data packets No. 1 and No. 2 as an example, in fact, when they are transmitted through the F5 device, only a few fields such as the source and destination MAC addresses and ip.ttl have changed. The same ip.id also shows that they are actually the same data packet.
2. TCP SYN FlooD
TCP: Connection establish request (SYN): server port 80There are as many as 1,396 problematic SYN packets in the expert information . By tcp.connection.syndisplaying the filter conditions, you can filter out all problematic SYN packets at once.
The same is true for session statistics, which come from many different source IPs initiating requests to the web service 31.151.1.21 port 80.
In fact, sharp-eyed students should be able to see the abnormality of this SYN packet from above. It does not have the TCP Options field like the common TCP three-way handshake packet.
At the same time, through tcp.seq_raw == 0filtering, it can be seen that the TCP Seq Num of up to 1391 data packets is really 0, not relatively 0. In addition, the Win window size of 5840 remains unchanged. All these phenomena can be judged as SYN Flood attacks, all of which are forged and unconventional SYN data packets.
How was the attack finally resolved in the case? The author performed security filtering on the F5 device based on the characteristics of the TCP SYN packets in the trace file. The filtering conditions are as follows:
host 31.151.1.21 and tcp[13]=2 and tcp[12]&0xf0=0x50
Host 31.151.1.21 represents the destination IP.
TCP [13]=2 represents the value of TCP flags syn position 1, which is 2.
TCP [12]&0xf0=0x50 represents a TCP header length of 20 bytes, which means there are no TCP Options.After the above processing, the customer’s Web service returned to normal.
Summary of the problem
Of course, because there are many ways to attack SYN Flood, security protection cannot be solved by the methods mentioned in this case alone. We can only analyze specific problems. This case mainly starts from the perspective of network data packet analysis, and after layers of judgment and analysis, it was successfully solved.