- \n
- A client sends the server a SYN packet\u2014a connection request from its source port to a server\u2019s destination port.<\/li>\n
- The server responds with a SYN\/ACK packet, acknowledging the receipt of the connection request.<\/li>\n
- The client receives the SYN\/ACK packet and responds with an ACK packet of its own.<\/li>\n<\/ol>\n
After the connection is established, TCP works by breaking down transmitted data into segments, each of which is packaged into a datagram and sent to its destination.<\/p>\n
TCP header structure<\/h2>\n
TCP wraps each data packet with a header containing 10 mandatory fields totaling 20 bytes (or octets). Each header holds information about the connection and the current data being sent.<\/p>\n
The 10 TCP header fields are as follows:<\/p>\n
- \n
- Source port<\/strong>\u00a0\u2013 The sending device\u2019s port.<\/li>\n
- Destination port<\/strong>\u00a0\u2013 The receiving device\u2019s port.<\/li>\n
- Sequence number<\/strong>\u00a0\u2013 A device initiating a TCP connection must choose a random initial sequence number, which is then incremented according to the number of transmitted bytes.<\/li>\n
- Acknowledgment number<\/strong>\u00a0\u2013 The receiving device maintains an acknowledgment number starting with zero. It increments this number according to the number of bytes received.<\/li>\n
- TCP data offset<\/strong>\u00a0\u2013 This specifies the size of the TCP header, expressed in 32-bit words. One word represents four bytes.<\/li>\n
- Reserved data<\/strong>\u00a0\u2013 The reserved field is always set to zero.<\/li>\n
- Control flags<\/strong>\u00a0\u2013 TCP uses nine control flags to manage data flow in specific situations, such as the initiating of a reset.<\/li>\n
- Window size TCP checksum<\/strong>\u00a0\u2013 The sender generates a checksum and transmits it in every packet header. The receiving device can use the checksum to check for errors in the received header and payload.<\/li>\n
- Urgent pointer<\/strong>\u00a0\u2013 If URG control flag is set, this value indicates an offset from the sequence number, indicating the last urgent data byte.<\/li>\n
- mTCP optional data<\/strong>\u00a0\u2013 These are optional fields for setting maximum segment sizes, selective acknowledgments and enabling window scaling for more efficient use of high-bandwidth networks.<\/li>\n<\/ol>\n
TCP DDoS vulnerabilities and methods of mitigation<\/h2>\n
TCP is vulnerable to several types of\u00a0DDoS attacks<\/a>, including:<\/p>\n
SYN flood<\/h3>\n
SYN floods<\/a>\u00a0occur during the initial stage of a three-way handshake by sending TCP connection requests (SYN packets) to every port on a target machine faster than it can process the requests. The server attempts to process the attacker\u2019s fake SYN requests and becomes unresponsive to legitimate TCP requests, preventing the completion of the handshake.<\/p>\n
![\"SYN](\"https:\/\/www.imperva.com\/learn\/wp-content\/uploads\/sites\/13\/2019\/01\/syn-flood.jpg\")
SYN flood attack progression.<\/small><\/p>\nThis causes the targeted machine to exhaust all of its available ports. In many cases, SYN packets are the go-to payload and are used simply to saturate a target\u2019s network pipe.<\/p>\n
There are several ways to mitigate SYN floods, including:<\/p>\n
- \n
- Micro-blocks<\/strong>\u00a0\u2013 The server allocates a micro-record in its memory for each SYN request instead of a complete connection object, thus reducing potential resource strain from too many requests.<\/li>\n
- SYN cookies<\/strong>\u00a0\u2013 The server uses cryptographic hashing to verify a TCP request before allocating memory.<\/li>\n
- RST cookies<\/strong>\u00a0\u2013 The server intentionally sends an incorrect response after the initial SYN request. If the client is legitimate, the server receives an RST packet, telling the server something is wrong.<\/li>\n
- TCP stack tweaking<\/strong>\u00a0\u2013 You can decrease the timeout for releasing memory allocated to a connection, or selectively drop incoming connections.<\/li>\n<\/ol>\n
Note that in addition to the \u201cclassic\u201d SYN flood attack method, many DDoS offenders use fake SYN payloads to mount generic network layer assaults \u2013 the type that simply aims to cause network congestion with an overload of fake packets. Mitigating these attacks requires the ability to scale up network resources on demand, e.g., using a cloud mitigation solution.<\/p>\n
STOMP DDoS attack<\/h3>\n
STOMP is a text-based protocol that allows applications to communicate with message brokers using TCP. In a STOMP DDoS attack, perpetrators use a botnet to open large numbers of TCP handshakes with applications. The attackers then send junk data disguised as STOMP TCP requests, saturating the network. If the server is prepared to parse STOMP requests, the attack can also exhaust server resources.<\/p>\n
TCP fragmentation (Teardrop)<\/h3>\n
A teardrop attack is a type of\u00a0IP fragmentation<\/a>\u00a0attack that targets the TCP\/IP reassembly mechanism, occurring after a three-way handshake has been completed and data is being transmitted. It involves an attacker deliberately sending data packets with defective segment offset fields, preventing the receiver from correctly putting together the fragmented data. Data packets overlap and quickly overwhelm the victim\u2019s servers.<\/p>\n
Preventing TCP fragmentation attacks requires the inspection of incoming packets using routers, secure proxies or a\u00a0cloud-based DDoS protection service<\/a>. Packets with incorrect fragmentation are then detected and dropped before they reach your server.<\/p>\n
- SYN cookies<\/strong>\u00a0\u2013 The server uses cryptographic hashing to verify a TCP request before allocating memory.<\/li>\n
- Destination port<\/strong>\u00a0\u2013 The receiving device\u2019s port.<\/li>\n
- Source port<\/strong>\u00a0\u2013 The sending device\u2019s port.<\/li>\n