Common TCP/IP Attack Methods

This article mainly reviews common attacks on TCP/IP, aiming to provide at least a basic understanding.

Introduction

1 IP Spoofing

What is IP?

In a network, every device is assigned an address. This address is like a home address for a person, consisting of a number and a room. The number represents the subnet, while the room number corresponds to a specific computer within that subnet. This overall address is known as the IP address.

What can we infer from an IP address?

With an IP address, we can determine the location of the server being accessed. The message is sent to the server after passing through the subnet’s hub and the nearest router, and then routing to the next router until reaching the destination.

IP Header Format

IP Spoofing Technique

Deception, trickery, entrapment!

The IP spoofing technique involves forging the IP address of a host. By disguising the IP address, one host can impersonate another host, often one that has certain privileges or is trusted by other hosts.

Suppose there is a legitimate user (1.1.1.1) who has established a normal connection with the server. An attacker constructs TCP data for the attack, masquerading their IP as 1.1.1.1, and sends a TCP segment with the RST flag to the server. Upon receiving such data, the server believes the connection from 1.1.1.1 is erroneous and clears the established connection from its buffer.

At this point, if the legitimate user 1.1.1.1 sends legitimate data again, the server no longer has that connection, and the user must re-establish the connection. During the attack, a large number of forged IP addresses are sent to the target with RST data, preventing the server from servicing legitimate users. Although IP address spoofing attacks are quite difficult to execute, we must be aware that such attacks are widespread and often the starting point for intrusions.

2 SYN Flooding

Overview of SYN Flooding

Denial of Service attacks (DDoS) have been a threat since the 1970s, causing immeasurable losses to organizations worldwide. SYN Flood is one of the most classic DDoS attack methods on the internet, first appearing around 1999, with Yahoo being one of the most famous victims. SYN Flood attacks exploit vulnerabilities in the TCP three-way handshake, allowing attackers to render the target server unresponsive at a low cost, making it difficult to trace.

SYN flood is a common DOS (Denial of Service) and DDos (Distributed Denial of Service) attack method. It utilizes TCP protocol vulnerabilities to send a large number of forged TCP connection requests, exhausting the attacked party’s CPU or memory resources, ultimately leading to the inability to provide normal services.

Principle of TCP SYN Flood Attack

The TCP SYN Flood attack leverages the TCP three-way handshake (SYN -> SYN/ACK -> ACK). Suppose the connection initiator is A and the receiver is B, where B listens for connection requests from A on a certain port (Port). The process is illustrated in the diagram below, with A on the left and B on the right.

A first sends a SYN (Synchronization) message to B, requesting B to prepare to receive data; upon receiving it, B responds with a SYN-ACK (Synchronization-Acknowledgement) message to A. This message serves two purposes:

To confirm to A that it is ready to receive data,
And to request A to also prepare to receive data. At this point, B has confirmed its readiness to receive data from A and is waiting for A’s confirmation, putting the connection in a half-open state.

A then sends an ACK (Acknowledgement) message back to B, confirming its readiness to receive data, completing the three-way handshake and establishing the connection.

Notice that the key point is whether both parties have entered a state of readiness to receive messages as per each other’s requests. This state is confirmed mainly by the sequence number that both parties will use, as TCP requires sequence numbers to ensure messages arrive in order at the receiving application.

TCP is a duplex connection, supporting bidirectional communication, meaning both parties can send messages to each other simultaneously. The SYN and SYN-ACK messages establish a unidirectional communication channel from A to B (B learns A’s sequence number); the SYN-ACK and ACK messages establish a unidirectional communication channel from B to A (A learns B’s sequence number).

The above discussion assumes honest communication under normal circumstances.

However, in reality, network instability may cause packet loss, preventing handshake messages from reaching the other party, or the other party may deliberately delay or fail to send handshake confirmation messages.

Assuming B provides services through a certain TCP port, upon receiving A’s SYN message, B actively responds with a SYN-ACK message, putting the connection in a half-open state. Since B is uncertain whether its SYN-ACK message or A’s ACK message may be lost in transit, it sets a timer for each pending half-open connection. If the timer expires without receiving A’s ACK message, B will resend the SYN-ACK message to A until the retries exceed a certain number, at which point it will give up.

To help A connect smoothly, B needs to allocate kernel resources to maintain half-open connections. When B faces a massive number of connection requests from A, as illustrated, the SYN Flood attack occurs. The attacking party A can control bots to send a large number of SYN messages to B without responding to ACK messages or simply forge the source IP in the SYN messages, causing B’s SYN-ACK messages to vanish, resulting in B being overwhelmed with half-open connections that cannot be completed until resources are exhausted, ceasing to respond to normal connection requests.

3 UDP Flooding

UDP flooding is also a type of denial-of-service attack that sends a large number of User Datagram Protocol (UDP) packets to the target server, aiming to overwhelm the device’s processing and response capabilities. Firewalls protecting the target server may also become exhausted due to UDP flooding, leading to denial of service for legitimate traffic.

How does a UDP Flood attack work?

UDP Flood primarily exploits the steps taken by the server to respond to incoming UDP packets sent to one of its ports. Normally, when a server receives a UDP packet on a specific port, it goes through two steps:

The server first checks if there is a program running that is listening for requests on the specified port.
If no program is receiving packets at that port, the server responds with an ICMP (ping) packet to notify the sender that the destination is unreachable.

For example, suppose today a person wants to contact a hotel, the hotel receptionist first checks the list of rooms to ensure the guest is present before transferring the call.

First, the receptionist receives a call requesting connection to a specific room. The receptionist then needs to check the list of all rooms to ensure the guest is available and willing to answer the call. If all phone lines suddenly light up at that moment, the receptionist will quickly become overwhelmed.

When the server receives each new UDP packet, it processes the request through the above steps, utilizing server resources during the process. Each UDP packet sent will contain the source device’s IP address. During this type of DDoS attack, attackers typically do not use their real IP addresses but spoof the source IP address of the UDP packets to prevent their true location from being exposed and potentially saturate the response packets from the target server.

As the target server utilizes resources to check and respond to each received UDP packet, when it receives a large volume of UDP packets, its resources can quickly become exhausted, leading to denial of service for legitimate traffic.

How to mitigate UDP flood attacks?

Most operating systems impose limits on the response rate of ICMP packets to interrupt DDoS attacks that require ICMP responses. One downside of this mitigation is that during an attack, legitimate packets may also get filtered. If the capacity of UDP Flood is high enough to saturate the state table of the target server’s firewall, any mitigations occurring at the server level will be insufficient to cope with upstream bottlenecks.

4 TCP Reset Attack

In a TCP reset attack, the attacker sends forged messages to one or both parties of the communication, instructing them to disconnect immediately, thereby interrupting the connection between the two parties. Normally, if a client detects that the incoming segment is incorrect for the relevant connection, TCP will send a reset segment, leading to a rapid teardown of the TCP connection.

The TCP reset attack exploits this mechanism by sending forged reset segments to trick both parties into prematurely closing the TCP connection. If the forged reset segment is completely convincing, the receiver will believe it is valid and close the TCP connection, preventing it from being used for further information exchange. The server can create a new TCP connection to restore communication, but may still be reset by the attacker. Fortunately, the attacker requires some time to assemble and send the forged segments, so generally, this attack is only lethal to long connections; for short connections, the information exchange may be completed before the attack occurs.

In a sense, forging TCP segments is relatively easy, as TCP/IP has no built-in method to verify the identity of the server. Some special IP extension protocols (like IPSec) can indeed verify identity, but they are not widely used. Clients can only receive segments and, where possible, use higher-level protocols (like TLS) to verify the server’s identity. However, this method does not apply to TCP reset packets, as they are part of the TCP protocol itself and cannot be verified with higher-level protocols.

5 Simulation Attack

The following experiment is conducted on the OSX system; please test on other systems accordingly.

Now, let’s summarize what needs to be done to forge a TCP reset packet:

Sniff the exchanged information between both parties.
Intercept a packet with the ACK flag set to 1 and read its ACK number.
Forge a TCP reset packet (set the RST flag to 1) with the sequence number equal to the intercepted packet’s ACK number. This is ideally the case, assuming the information exchange speed is not very fast. In most cases, to increase the success rate, multiple reset packets with different sequence numbers can be sent continuously.
Send the forged reset packet to one or both parties to interrupt the connection.

For simplicity in the experiment, we can use a local computer to communicate with itself via localhost and then perform a TCP reset attack on itself. The following steps are needed:

Establish a TCP connection between two terminals.
Write an attack program that can sniff the data exchanged between both terminals.
Modify the attack program to forge and send reset packets.

Let’s begin the experiment.

Establishing a TCP Connection

You can use the netcat tool to establish a TCP connection, which is pre-installed on many operating systems. Open the first terminal window and run the following command:

$ nc -nvl 8000

This command starts a TCP service listening on port 8000. Then open the second terminal window and run the following command:

$ nc 127.0.0.1 8000

This command attempts to establish a connection with the service above. Typing some characters in one of the windows will send them via the TCP connection to the other window, where they will be printed out.

Traffic Sniffing

Write an attack program using the Python networking library scapy to read the data exchanged between the two terminal windows and print it to the terminal. The code is relatively long; below is a part of it, and the complete code can be found in the background response to TCP attacks. The core of the code is calling scapy sniffing method:

This code instructs scapy to sniff packets on the lo0 network interface and log detailed information about all TCP connections.

iface: Instructs scapy to listen on the lo0 (localhost) network interface.
lfilter: This is a filter that tells scapy to ignore all packets that do not belong to the specified TCP connection (both parties being localhost and having port number 8000).
prn: scapy uses this function to process all packets that meet the lfilter rules. The above example simply prints the packets to the terminal; the function will be modified later to forge reset packets.
count: The number of packets that need to be sniffed before the scapy function returns.

Sending Forged Reset Packets

Now let’s modify the program to send forged TCP reset packets for the TCP reset attack. Based on the above interpretation, we only need to modify the prn function to check the packets, extract necessary parameters, and use these parameters to forge and send TCP reset packets.

For example, suppose this program intercepts a packet from (src_ip, src_port) to (dst_ip, dst_port), where the packet’s ACK flag is set to 1 and the ACK number is 100,000. The attack program then needs to:

Since the forged packet is a response to the intercepted packet, the source IP/Port of the forged packet should be the destination IP/Port of the intercepted packet, and vice versa.
Set the RST flag of the forged packet to 1 to indicate that this is a reset packet.
Set the sequence number of the forged packet to the ACK number of the intercepted packet, as this is the expected next sequence number for the sender.
Call scapy‘s send method to send the forged packet to the sender of the intercepted packet.

For my program, I just need to uncomment this line and comment out the line above it to execute the full attack. Following the steps in method 1, set up the TCP connection, open a third window to run the attack program, and then input some strings in one of the TCP connection terminals, and you will find that the TCP connection has been interrupted!

Further Experiments

You can continue using the attack program to experiment by adjusting the sequence number of the forged packets to see what happens, checking if it indeed needs to match the ACK number of the intercepted packet exactly.
Open Wireshark to listen on the lo0 network interface and use the filter ip.src == 127.0.0.1 && ip.dst == 127.0.0.1 && tcp.port == 8000 to filter out irrelevant data. You can see all the details of the TCP connection.
Send data streams more quickly over the connection to make the attack harder to execute.

6 Man-in-the-Middle Attack

For example, a character writes a letter to confess their feelings to another, but a third party intercepts and alters the letter, causing disruptions between them. This third party is the man-in-the-middle, executing a man-in-the-middle attack. Now let’s discuss what a man-in-the-middle attack is.

What is a Man-in-the-Middle Attack?

The man-in-the-middle attack, abbreviated as MITM attack, refers to an attacker creating independent connections with both ends of the communication and exchanging the data they receive, making both ends believe they are having a private conversation with each other, while in reality, the entire session is fully controlled by the attacker. Here is a diagram:

From this diagram, we can see that the man-in-the-middle is the attacker. This principle has many practical applications; for example, when browsing unsafe websites on a mobile device, the device may warn you that the site may contain viruses and ask whether to continue accessing it or take other actions.

Principle of Man-in-the-Middle Attack

For instance, if I sign a labor contract with a company, each party has a copy. If someone alters the contract content, how can I verify its authenticity? I would have to seek a professional institution for authentication, which naturally incurs costs.

In the security field, there is a saying: We cannot eliminate cybercrime; we can only find ways to increase its cost. Since we cannot eliminate such situations, we should find ways to raise the cost of committing crimes. Today, we will simply understand some basic network security knowledge, which is also a frequent interview topic.

To avoid situations where both parties cannot trust each other’s words, both parties introduce a third-party organization to hold the original contract. As long as this organization does not betray its trust, the contract remains relatively secure.

What if the third-party organization has internal issues or leaks?

Even though we have provided the original contract to the third-party organization, to prevent internal personnel from making alterations, what measures should be taken?

One feasible method is to introduce a hashing algorithm. The contract and its hash are stored together. To simplify the understanding of hashing, think of the hash as a function that encrypts the original text and produces a unique hash value. If the original text changes even slightly, the hash value will change.

What common hashing algorithms are there?

Currently, commonly used hashing algorithms include Message-Digest Algorithm and Secure Hash Algorithm (SHA). MD5 converts an arbitrary length document into a 128-bit hash value, but it was proven in 2004 to be susceptible to collisions, meaning two different original texts can produce the same hash. This effectively gives hackers a backdoor to easily forge hashes.

Therefore, in most cases, the SHA algorithm is preferred.

What to do if there’s an insider threat?

It seems secure, but theoretically, it is possible for an employee to have both the rights to modify the contract and the hash, making it only a matter of time before issues arise. After all, no system can completely prevent employees from accessing sensitive information unless sensitive information does not exist at all. So, can we consider storing the contract and the hash separately?

How to ensure that employees cannot modify the contract?

This is indeed challenging, but there are more solutions than difficulties. We can store the contract with both parties and the hash with a third-party organization, further complicating potential tampering.

What if an employee colludes with a user?

It seems that relying on a third-party organization is still risky, as it poses significant threats. Therefore, we need to seek new solutions, leading to the emergence of digital signatures and certificates.

Digital Certificates and Signatures

SHA algorithm, then encrypts the hash with their private key to obtain a digital signature. Sum provides Mike with the original contract, the signature, and the public key.

If Sum wants to prove that the contract is Mike’s, they will use Mike’s public key to decrypt the signature and obtain the hash x, then calculate the SHA hash of the original text to get y. If x and y match, then the data has not been tampered with.

In this process, Mike cannot modify Sum’s contract because altering the contract requires changing both the original text and the hash, which necessitates the private key that only Sum possesses, while the public key is shared with others.

In summary, data encrypted with a public key can only be decrypted with the corresponding private key, and vice versa. This constitutes asymmetric encryption.

Symmetric and Asymmetric Encryption

Privacy protection? It’s not to scare everyone; information is transparent, but it’s best to maintain personal privacy. Today, we will learn about symmetric and asymmetric encryption.

First, read this character “钥”, which is pronounced “yao”; I used to think it was “yue”.

Symmetric Encryption

Symmetric encryption, as the name implies, is when both the encrypting and decrypting parties use the same key (secret key). Specifically, the sender uses the corresponding encryption algorithm and secret key to encrypt the information to be sent; for the receiver, the decryption algorithm and the same key are used to unlock the information, allowing them to read it.

Common Symmetric Encryption Algorithms

DES uses a key that appears to be 64 bits, but only 56 bits are actually used in the algorithm; the remaining 8 bits can be used for parity and are discarded in the algorithm. Therefore, DES has an effective key length of 56 bits, commonly referred to as having a key length of 56 bits. Assuming the key is 56 bits long, using a brute-force attack would require a time equivalent to about a year if executed once per nanosecond. Of course, no one actually does this. DES is no longer considered a secure encryption method due to its short key length.

IDEA

International Data Encryption Algorithm. The key length is 128 bits, with the advantage of having no patent restrictions.

After DES was cracked, AES was introduced shortly after, offering three key lengths: 128, 192, and 256 bits. To ensure performance is not significantly affected, 128 bits is usually chosen.

SM1 and SM4

The previous algorithms are all foreign; in our country, we have independently researched the national encryption algorithms SM1 and SM4. These algorithms are state standards with publicly available algorithms, benefiting from strong national support and recognition.

Let’s summarize the various algorithms.

Asymmetric Algorithms

In symmetric encryption, the sender and receiver use the same secret key. In asymmetric encryption, the sender and receiver use different keys. The main problem it addresses is preventing key leakage during the key negotiation process. For example, in symmetric encryption, if a person sends a message and reveals that the password is 123balala, it is easy for others to intercept that password. In asymmetric encryption, if the same person reveals the password, it is useless for the man-in-the-middle since they do not possess the private key. Thus, asymmetric keys primarily solve the key distribution problem. Here is a diagram:

We often use asymmetric encryption, such as when setting up a big data platform with multiple servers, where key distribution is involved. For example, setting up a Docker cluster also involves relevant asymmetric encryption algorithms.

Common Asymmetric Encryption Algorithms

RSA (RSA Encryption Algorithm)

The advantage is its relatively fast performance; however, achieving high encryption difficulty requires a long key.

Based on elliptic curves, it is currently the strongest asymmetric encryption algorithm.

Also based on elliptic curve problems, with the greatest advantage being national recognition and strong support.

Comparing the three algorithms:

Hash Algorithms

This is a concept that should be more familiar; for example, we often use MD5 checksums. In many cases, MD5 is not used for encryption but to obtain a unique ID. In system development, user passwords are often stored as their hash values.

Common Hashing Algorithms

MD5 can generate a 128-bit message digest, and it is currently a widely used hashing algorithm. You can refer to various application scenarios independently. However, due to its algorithmic flaws, its uniqueness has been compromised, so I do not recommend continuing to use MD5 unless the length is constrained (32 characters).

Secure Hash Algorithm. **SHA** has two versions: SHA1 and SHA2. The algorithm’s concept involves receiving a plaintext message and converting it into a ciphertext in a non-reversible manner, which can be simply understood as taking a string of input (called pre-image or message) and converting it into a shorter, fixed-length output sequence, known as the hash value (also called message digest or message authentication code).

The national encryption algorithm SM3 has encryption strength comparable to that of SHA-256. It mainly receives national support.

Summary:

In conclusion, in most cases, symmetric encryption is used, providing good security. For distributed key distribution, consider asymmetric encryption. If reversible computation is not needed, use hash algorithms. Recently, I have been looking into this area, and I hope to gain insights into information security, so I won’t have to buy shampoo in the future. Thank you for reading!

There is still a question: if Sum denies having given Mike the public key and contract, what then?

Thus, it is essential for Sum to maintain a strong reputation in what they have done, which leads to the introduction of third-party institutions and certificate mechanisms.

The credibility of certificates arises from the issuing party’s trustworthiness. If Sum wants Mike to acknowledge their public key, Sum will not directly give it to Mike but will provide a certificate containing the public key, issued by a third-party organization. If Mike also trusts this organization, and the law recognizes it, then a trust relationship is established.

As shown in the above diagram, Sum submits their application to the institution, generating the original text of the certificate. The institution signs Sum’s application with its private key (first calculating the hash of the original text, then encrypting it), obtaining a certificate with signature information. Mike receives the signed certificate, decrypts it using the public key of the third-party institution, and obtains the hash and original text of Sum’s certificate. With Sum’s certificate’s hash and original text, Mike can then perform signature verification. If verification passes, Mike can confirm that Sum’s certificate was indeed issued by the third-party institution.

Using this mechanism, neither party can deny the contract. The core of this solution lies in requiring third-party credit service institutions to provide credit backing. This creates a fundamental trust chain; if the trust in the third-party institution collapses, for example, due to a hacker attack, the entire trust chain is broken.

To strengthen this trust chain, we need to create a longer trust chain, avoiding single-point trust risks.

As shown in the diagram, a root certificate authority with the best reputation provides the root certificate, which then issues certificates to secondary institutions; the secondary institutions issue certificates to tertiary institutions, and finally, the tertiary institutions issue Sum’s certificate.

To verify the legitimacy of Sum’s certificate, one must use the public key in the tertiary institution’s certificate to decrypt the digital signature of Sum’s certificate.

To verify the legitimacy of the tertiary institution’s certificate, one must use the secondary institution’s certificate to decrypt the digital signature of the tertiary institution’s certificate.

To verify the legitimacy of the secondary institution’s certificate, one must use the root certificate for decryption.

This constitutes a relatively longer trust chain. If any party attempts to cheat, it is exceedingly difficult unless all institutions in the chain collude to commit fraud.

How to avoid Man-in-the-Middle Attacks?

Now that we understand the principle of man-in-the-middle attacks and their dangers, let’s look at how to avoid them. We have all encountered situations like this:

In many cases, encountering this interface indicates a man-in-the-middle attack, necessitating timely monitoring of security certificates. The well-known GitHub website has also suffered from man-in-the-middle attacks:

To avoid man-in-the-middle attacks, the main methods currently available are:

Clients should not easily trust certificates: because these certificates may very well be from a man-in-the-middle.
Apps can embed certificates locally in advance: meaning we have some certificates stored locally, so other certificates cannot take effect.

7 DDoS

From the above descriptions, it is clear that many types of attacks are related to DDoS attacks, so let’s summarize the relevant content of these attacks briefly.

In fact, global internet companies have all suffered from numerous DDoS attacks.

In 2018, GitHub was hit with a bandwidth attack of up to 1.35Tbps in an instant. This DDoS attack can be considered one of the largest and most powerful DDoS attacks in internet history. After the attack on GitHub, DDoS attacks began targeting Google, Amazon, and even Pornhub within a week. Subsequent DDoS attacks reached bandwidths of up to 1Tbps.

What exactly is a DDoS attack?

DDoS stands for Distributed Denial of Service, which translates to distributed denial of service. It refers to multiple attackers at different locations simultaneously launching attacks on one or multiple targets, constituting a distributed, coordinated large-scale attack. A single DoS attack typically employs a one-to-one approach, exploiting network protocols and operating system vulnerabilities, using deception and impersonation strategies to conduct network attacks, overwhelming website servers with numerous requests for replies, consuming network bandwidth or system resources, leading to network or system overload, and ultimately halting normal network services.

For example:

I run a hotpot restaurant with fifty seats, known for its high-quality ingredients and fair prices. My restaurant is always bustling, while the one across the street has no customers. To counter me, the owner of the other restaurant gathers fifty people to sit in my restaurant without ordering, preventing other customers from dining.

The above example illustrates a typical DDoS attack, wherein attackers utilize “zombie computers” to send a large number of requests to the target website in a short period, consuming the target’s host resources and rendering it unable to provide normal services. Online gaming, internet finance, and other fields are high-frequency targets for DDoS attacks.

There are many attack methods, such as ICMP Flood, UDP Flood, NTP Flood, SYN Flood, CC Attack, DNS Query Flood, etc.

Implementing DDoS Attacks using SYN Flood

SYN Flood is an attack method that exploits the vulnerabilities of the TCP protocol by sending a large number of forged TCP connection requests, thereby exhausting the resources of the attacked party (CPU overload or insufficient memory).

Establishing a TCP connection normally requires three-way handshake: the client sends SYN packets, the server receives the request and responds, and the client sends a confirmation packet, completing the connection.

SYN Flood occurs when a user sends a packet to the server and then suddenly crashes or disconnects, causing the server to respond with an acknowledgment packet but not receive the client’s confirmation packet (the third handshake cannot be completed). In this case, the server typically retries and waits for a while before discarding the incomplete connection.

One user encountering an issue that causes the server to wait for a thread is not a significant problem, but malicious attackers simulating this situation on a large scale can lead the server to consume vast resources maintaining tens of thousands of half-open connections, often resulting in the inability to attend to normal requests, or even crashing. From the perspective of legitimate customers, the website appears unresponsive and inaccessible.

How to respond to DDoS attacks?

High Defense Servers

Returning to the hotpot restaurant example, high defense servers are like hiring two security guards to protect the restaurant from rowdy customers and regularly patrol the area to prevent disturbances.

High defense servers refer to servers capable of independently hardening against attacks of over 50Gbps, helping websites resist denial-of-service attacks, and regularly scanning network nodes. This option is excellent but expensive.

Blacklists

Faced with rowdy customers in the restaurant, I might take their pictures and ban them from the establishment. However, this method may also prevent individuals who resemble them from entering. This is the principle behind blacklists, which operates on the basis of “better to wrongly ban a thousand than to let one through,” potentially blocking legitimate traffic and impacting normal operations.

DDoS Cleaning

DDoS cleaning is like observing customers who enter the restaurant but do not order food and kicking them out.

DDoS cleaning involves real-time monitoring of user request data to promptly detect DOS attacks and other abnormal traffic, cleaning out such traffic without affecting normal business operations.

CDN Acceleration

CDN acceleration can be understood as moving the hotpot restaurant online to offer takeaway services, preventing rowdy customers from locating the restaurant or causing disturbances.

In reality, CDN services distribute website access traffic across various nodes, thereby hiding the true IP of the website. Even when facing DDoS attacks, traffic can be spread across multiple nodes, preventing the origin from crashing.

Conclusion

Computer networking involves many knowledge points; this article has merely touched upon some. A deeper understanding requires referring to relevant literature. If you can answer questions about DDoS or TCP-related attack techniques during an interview, that would be great!