How many SYN Flood attacks have you suffered?

Team: http://www.ph4nt0m.org
Author: Yun Shu (http://www.icylife.net)
Date: 2007-12-07

This is a fun article. It does not describe the principles of SYN Flood attacks, nor describe attack defense solutions. Here, I will talk about several details that are usually hidden by the device manufacturer or intentionally or unintentionally. If you are thinking about buying a device to defend against attacks, I hope this article will help you-at least when negotiating with the vendor, you will know what problems to ask and won't be easily fooled.

1. Ethernet padding

In the current SYN Flood Program, to improve the sending efficiency, no optional fields are filled when the header is filled. Therefore, the length of the IP header is exactly 20 bytes (Byte), as shown below:
Typedef struct ip_hdr
{
Unsigned char h_verlen;
Unsigned char tos;
Unsigned short total_len;
Unsigned short ident;
Unsigned short frag_and_flags;
Unsigned char ttl;
Unsigned char proto;
Unsigned short checksum;
Unsigned int sourceIP;
Unsigned int destIP;
} IP_HEADER;

Similarly, for the TCP header, the length is also 20 bytes, as shown in the figure below:
Typedef struct tcp_hdr
{
Unsigned short th_sport;
Unsigned short th_dport;
Unsigned int th_seq;
Unsigned int th_ack;
Unsigned char th_lenres;
Unsigned char th_flag;
Unsigned short th_win;
Unsigned short th_sum;
Unsigned short th_urp;
} TCP_HEADER;

That is to say, the attacker fills in a 40-byte packet and starts sending. However, for Ethernet, the minimum packet length must reach 46 bytes, while our packet size is only 40 bytes. Therefore, the NIC will perform some processing when sending the packet. We add the 40-byte IP header to the end of the TCP Header packet, and we will be filled with six zeros by the NIC to meet the minimum packet length requirements. At this time, the entire data packet is a 14-byte Ethernet header, a 20-byte IP header, and a 20-byte TCP header, in addition, the six bytes of 0 filled due to minimum packet length requirements are 60 bytes in total. However, this is not complete yet, because the CRC test is required during Ethernet transmission. Before sending data, the NIC checks the data packets, append the 4-byte CRC value to the end of the header. At this time, our data packet length is no longer 40 bytes, but 64 bytes. The data packet structure is as follows:
| 14-byte Ethernet header | 20-byte IP Address Header | 20-byte TCP Header | 6-byte padding | 4-byte verification |
| Target MAC address | source MAC address | Upper-layer protocol type | IP Address Header | TCP Header | Ethernet padding | CRC test |

After all these work is done, the Nic starts to send packets. Unfortunately, you cannot see this process when using a common packet capture tool, such as TcpDump and WireShark, on the attack initiator, this process can only be easily verified by packet capture on the attacked host. However, when the attacker uses a class tool to capture packets, it is obvious that only the SYN Packet of the IP header and TCP header is sent to the attacked machine, there will be 6 more bytes of 0 filling later, which is the minimum packet length of Ethernet. Unfortunately, the 4-byte CRC check is discarded after the NIC receives the packet inspection and cannot be captured by common tools on the attacked side.

That is to say, when your 40-byte packet arrives at the attacked machine Nic, it is no longer 40 bytes, but 64 bytes.

Ii. Ethernet Transmission

Just now we talked about the operations such as the NIC padding of packets during sending, But we haven't finished yet. Let's take a look at the transmission process of attack packets on the network. Because the attack packet is small, it is far from enough 1500 bytes of the maximum transmission unit (MTU), so it will not be split. Are these packets transmitted together tightly together with one package, just like the canned package on the Production Pipeline? In fact, this is not the case.

During transmission over Ethernet, there are also preamble and inter-frame gap ). The forward code occupies 8 bytes (byte) and 64 bit. The first 7 bytes of the forward code are separated by 10, 10, and 1. However, the eighth byte is changed to 10101011. When the host detects two consecutive 1 bytes, it will know that data is followed by the target MAC address, and so on. That is to say, the forward guide code tells the host to prepare for receiving data. The frame spacing is the gap between Ethernet data packets. The frame spacing is 12 bytes (bytes) and 96 bits. Therefore, the data structure during network transmission is as follows:

| 8-byte authorization code | 6-byte MAC address | 6-byte source MAC address | 2-byte upper-layer protocol type | 20-byte IP header | 20-byte TCP Header | 6-byte Ethernet padding | 4-byte CRC test | 12-byte frame spacing |

That is to say, the bandwidth occupied by a SYN Packet during network transmission is actually 84 bytes.

3. Mbps or Mbps

With the above basics, we can start to discuss the line speed of network security devices. Here, the security devices can be Anti-DDOS devices, IDS, IPS, and other devices. When the minimum SYN packet that only fills the IP header and TCP Header runs on the Ethernet, the maximum PPS supported is 100*10 ^ 6/(8*(64 + 8 + 12) = 148809 pps, 1488090 Mbit network, and the maximum PPS supported is pps.

When vendors advertise their security devices, does their data comply with them? How is the maximum traffic supported by their IDS calculated? What content does it contain? Is the line rate advertised by their Anti-DDOS devices in line with the actual situation? Is it true that it can defend against corresponding PPS attacks? When you talk to others, your IDS shows that you have suffered N Gbit SYN Flood attacks and PPS reaches N million, are you really under a major attack?

Iv. Summary and reference

This is some notes from last year's anti-DDOS project. If there are not many things today and Friday, I will sort them out, which may be helpful to some friends.

1. http://www.ietf.org/rfc/rfc894.txt, which depends on the length of the entire package and the length of the entire package.
2. http://www.ietf.org/rfc/rfc2544.txt, which is related to the pre-guide code, frames, and PPS.
3. Explanation of TCP/IP