How Hackers Overcome TCP/IP!

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 the home address of Xiaolan, “number room“, where the number corresponds to the entire subnet, and the “room” corresponds to the computers assigned within that subnet. Therefore, the overall address is called an IP address.

What can we know through an IP address?

By knowing the IP address, we can determine the location of the server being accessed, allowing us to send messages to it. Generally, the message sent by the sender first goes through the hub of the subnet, forwarded to the nearest router, and then accesses the next router based on the routing position until it reaches the destination.

IP Header Format

IP Spoofing Technology

Deception, trickery, entrapment!

IP spoofing technology refers to the technique of forging the IP address of a certain host. By disguising its IP address, a host can impersonate another host, which often has certain privileges or is trusted by other hosts.

Assume a legitimate user (1.1.1.1) has established a normal connection with the server. The attacker constructs TCP data for the attack, disguising 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 there is an error in the connection from 1.1.1.1 and clears the established connection from the buffer.

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

2 SYN Flooding

Overview of SYN Flooding

Denial of Service attacks (DDoS) have been around since the 1970s and continue to wreak havoc today, 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 at that time. SYN Flood attacks exploit the flaws in the TCP three-way handshake, allowing attackers to incapacitate the target server at a low cost and making it difficult to trace.

SYN Flood is a common method of DOS (Denial of Service) and DDos (Distributed Denial of Service) attacks. It involves sending a large number of forged TCP connection requests that exhaust the CPU or memory resources of the attacked party, ultimately leading to the inability of the attacked party to provide normal services.

Principle of TCP SYN Flood Attack

TCP SYN Flood attacks utilize the TCP three-way handshake (SYN -> SYN/ACK -> ACK). Assuming that A is the connection initiator and B is the connection receiver, B listens to connection requests from A on a specific port (Port), as shown 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 be ready to receive data; B, upon receipt, responds with a SYN-ACK (Synchronization-Acknowledgement) message to A. This message serves two purposes:

• To confirm to A that B is ready to receive data,

• At the same time, it requests A to also be ready to receive data. At this point, B has confirmed to A that it is ready to receive, and is waiting for A’s confirmation, putting the connection in a half-open state; A then sends an ACK (Acknowledgement) message to B, confirming that it is also ready to receive data. At this point, the three-way handshake is complete, and the connection is established.

Notice that the key point is whether both parties have entered the state of being able to receive messages according to each other’s requests. The confirmation of this state mainly relies on the sequence numbers that both parties will use. To ensure that messages arrive at the receiving party’s upper-layer application in the order sent, TCP uses sequence numbers to mark the order of message transmission.

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

The above discussion assumes that both parties are honest and communication occurs under normal circumstances.

However, in reality, the network may be unstable, leading to packet loss, causing handshake messages to fail to reach the other party, or the other party may deliberately not follow the rules, delaying or not sending handshake confirmation messages.

Assuming B provides services through a certain TCP port, when B receives A’s SYN message, it actively responds with a SYN-ACK message, putting the connection into a half-open state. Since B is unsure whether its SYN-ACK message or A’s ACK message may get lost in transit, it will set a Timer for each half-open connection. If it does not receive A’s ACK message after a certain amount of time, it will resend the SYN-ACK message to A until it exceeds a certain number of retries before giving up.

B needs to allocate kernel resources to maintain half-open connections. When B faces a massive number of connections from A, as shown in the figure, the SYN Flood attack occurs. The attacking party A can control a botnet to send a large number of SYN messages to B without responding to the ACK messages, or simply forge the Source IP in the SYN messages, causing the SYN-ACK messages sent by B to vanish, resulting in B being overwhelmed by a large number of half-open connections that cannot be completed, until resources are exhausted and it stops responding 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 UDP Flood attack work?

UDP Flood primarily exploits the steps taken by servers to respond to 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 on that port, the server responds using an ICMP (ping) packet to notify the sender that the destination is unreachable.

For example, suppose today Xiaolan wants to contact the hotel. The hotel receptionist first checks the list of rooms to ensure Xiaolan is in a guest room before transferring the call to her.

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

When the server receives each new UDP packet, it will process the request through these steps, utilizing server resources in the process. Each UDP message sent will include the IP address of the source device. During this type of DDoS attack, the attacker typically does not use their real IP address but instead forges the source IP address of the UDP packets, preventing the attacker’s true location from being exposed and potentially overwhelming the response data packets from the target server.

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

How to mitigate UDP flood attacks?

Most operating systems limit the response rate of ICMP packets to interrupt DDoS attacks that require ICMP responses. One drawback of this mitigation is that during the attack, legitimate packets may also be filtered. If the capacity of the 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 handle 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 immediately disconnect, thereby interrupting the connection between the two parties. Under normal circumstances, if a client discovers that an arriving segment is incorrect for the related connection, TCP will send a reset segment, leading to a rapid teardown of the TCP connection.

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

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

5 Simulated Attack

The following experiment was conducted on OSX; please test on other systems yourself.

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

• Sniff the exchanged information between the two communicating parties.

• Intercept a segment with the ACK flag set to 1 and read its ACK number.

• Forge a TCP reset segment (RST flag set to 1) with a sequence number equal to the intercepted packet’s ACK number. This is the ideal scenario, assuming the exchange of information 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 required:

• Establish a TCP connection between two terminals.

• Write an attack program that can sniff the data exchanged between the two terminal windows.

• Modify the attack program to forge and send reset packets.

Now, let’s officially start the experiment.

Establishing 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 will start a TCP service listening on port 8000. Next, open a second terminal window and run the following command:

$ nc 127.0.0.1 8000

This command will attempt to establish a connection with the service above. Typing some characters in one window will send them via the TCP connection to the other window and print them out.

Sniffing Traffic

Write an attack program using the Python network 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, with the core of the code calling the sniffing method of scapy:

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

• iface: Tells 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 are localhost and the port number is 8000).

• prn: scapy uses this function to process all packets that match 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 to sniff before the scapy function returns.

Sending Forged Reset Packets

Now we will 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 the necessary parameters, and use these parameters to forge and send TCP reset packets.

For example, suppose the program intercepted a packet from (src_ip,src_port) to (dst_ip,dst_port), where the ACK flag was set to 1 and the ACK number was 100,000. The attacking program’s next steps are:

• 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 it is a reset packet.

• Set the sequence number of the forged packet to the ACK number of the intercepted packet, as this is the sequence number the sender expects to receive next.

• Use 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 to conduct a full attack. Following the steps in method 1 to set up the TCP connection, open a third window to run the attack program, and then input some strings in one of the terminals of the TCP connection. You will find that the TCP connection is interrupted!

Further Experiments

1. You can continue using the attack program for experiments, adjusting the sequence number of the forged packet by adding or subtracting 1 to see what happens and whether it indeed needs to match the intercepted packet’s ACK number exactly.

2. Open Wireshark to monitor 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.

3. Send data streams more quickly over the connection to make the attack harder to execute.

6 Man-in-the-Middle Attack

In a classic scenario, Pigsy wants to confess to Xiaolan, so he writes her a letter. However, a third party, Blackie, intercepts this letter and modifies it, causing chaos between them. This meddler is the man-in-the-middle, implementing a man-in-the-middle attack. Now, let’s continue discussing what a man-in-the-middle attack is.

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

A man-in-the-middle attack (MITM attack) refers to a scenario where an attacker independently establishes connections with both ends of a communication and exchanges the data received, making both ends believe they are directly communicating through a private connection, while in fact, the entire session is fully controlled by the attacker. Let’s illustrate this with a diagram:

From this diagram, we can see that the man-in-the-middle is the attacker. Through this principle, there are many practical applications. For instance, when you browse an unhealthy website on your phone, it may prompt you that the site might contain viruses and ask if you want to continue or take other actions, etc.

Principle of Man-in-the-Middle Attack

For example, I signed a labor contract with the company, and each person has a copy. If someone alters the contract content, how can I confirm its authenticity? I would have to find a professional institution for verification, 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 will find ways to increase the cost of committing crimes. Today, we will briefly understand some basic network security knowledge, which is also a high-frequency interview topic.

To avoid the situation where both parties’ words are not credible, a third-party institution is introduced, which holds the original contract. As long as this institution does not act dishonestly, the contract remains relatively secure.

What if there are internal threats in the third-party institution?

Even if we provide the original contract to a third-party institution, to prevent internal personnel from tampering, what measures should be taken?

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

What are some commonly used hashing algorithms?

Currently, commonly used encryption algorithms include message digest algorithms and secure hashing algorithms (SHA). MD5 converts an arbitrary length text into a 128-bit hash value, but in 2004, MD5 was proven to be prone to collisions, meaning two original texts can produce the same hash. This essentially gives hackers a backdoor to easily forge hashes.

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

What to do if there’s an insider threat?

It seems secure in theory, as it prevents tampering with the contract. However, if a certain employee has the authority to modify both the contract and the hash, it is only a matter of time before they cause trouble, as no system can completely prevent employees from accessing sensitive information unless sensitive information does not exist at all. Therefore, can we consider storing the contract and its hash separately?

How to ensure that employees cannot modify the contract?

This is indeed quite difficult, but there are more solutions than difficulties. We can keep the contract with both parties and store the hash with a third-party institution, further increasing the difficulty of tampering.

What if an employee colludes with a user?

It seems that relying on a third-party institution is still not very effective, as there is still a significant risk. Therefore, new solutions must be sought, leading to the emergence of digital signatures and certificates.

Digital Certificates and Signatures

Similarly, for example, if Sum and Mike sign a contract, Sum first calculates the hash of the contract using the SHA algorithm and then encrypts the hash with his private key, producing a digital signature. Sum provides Mike with the original contract, the signature, and the public key.

If Sum wants to prove that the contract belongs to Mike, he must use Mike’s public key to decrypt the signature and obtain the hash x, then Mike calculates the SHA hash of the original text Y, and finally compares x and y. If they are equal, the data is considered unaltered.

In this process, Mike cannot modify Sum’s contract because modifying the contract requires changing both the original text and the hash. Changing the hash requires providing Mike’s private key, which is unique to Sum, while the public key is the password Sum shares with others.

In summary, data encrypted with a public key can only be decrypted with the corresponding private key, and data encrypted with a private key can only be decrypted with the corresponding public key. This is known as asymmetric encryption.

Symmetric vs. Asymmetric Encryption

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

Everyone should read this character “key” as “yao”; I used to do the same, but it is actually pronounced “yue”.

Symmetric Encryption

As the name implies, in symmetric encryption, both the encrypting and decrypting parties use the same key (secret key). Specifically, the sender encrypts the information to be sent using the corresponding encryption algorithm and secret key; for the receiver, the decryption algorithm and the same secret key are used to unlock the information, thus enabling them to read it.

Common Symmetric Encryption Algorithms

• DES

DES uses a key that is superficially 64 bits long, 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. Thus, the effective key length of DES is 56 bits, which is commonly referred to as the key length of DES. Assuming a 56-bit key, the number of keys is 2 to the power of 56, meaning that it would take nearly a year to execute decryption if done every nanosecond. Of course, no one does that. DES is no longer considered a secure encryption method primarily due to its short key length of 56 bits.

• IDEA

International Data Encryption Algorithm. The key length is 128 bits, and its advantage is that it is not subject to patent restrictions.

• AES

After DES was cracked, AES was launched shortly thereafter, offering three lengths for selection: 128 bits, 192 bits, and 256 bits. To ensure performance is not significantly affected, 128 bits is sufficient.

• SM1 and SM4

These previous algorithms are all foreign; we have independently researched the national secret algorithms SM1 and SM4. Both are national standards, and the algorithms are open. Their advantage is that they have strong support and recognition from the state.

Let’s summarize a few:

Asymmetric Algorithms

In symmetric encryption, the sender and receiver use the same secret key. In asymmetric encryption, the sender and receiver use different keys. This primarily addresses the issue of preventing leaks during key negotiation. For instance, in symmetric encryption, Xiaolan encrypts the message to be sent and then tells you the password is 123balala. For others, it is easy to intercept the password. In the case of asymmetric encryption, Xiaolan can tell everyone that the password is 123balala, but for a man-in-the-middle, even if they obtain it, it is useless without the private key. Thus, asymmetric keys mainly solve the problem of key distribution. The following diagram illustrates this:

In fact, we frequently use asymmetric encryption, such as when setting up a big data platform with multiple servers, which involves key distribution for password-free logins. Similarly, when setting up a Docker cluster, related asymmetric encryption algorithms are also used.

Common Asymmetric Encryption

• RSA (RSA Encryption Algorithm)

The advantage is that it is relatively fast; however, to achieve a high level of encryption difficulty, a very long key is needed.

• ECC

Based on elliptic curves, it is currently the asymmetric encryption algorithm with the highest encryption strength.

• SM2

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

Comparison of the three:

Hash Algorithms

Everyone should be more familiar with this, such as when we use MD5 checksums. Often, I use it not for encryption but to obtain a unique ID. In the process of system development, when storing various password information of users, it is common to store the hash value.

Common Hashes

• MD5

MD5 can generate a 128-bit message digest and is currently a widely used hash algorithm. You can refer to various application scenarios yourself. Although its uniqueness has been compromised due to algorithmic flaws, in most scenarios, this does not pose a security issue. However, if the length is not limited (32 characters), I still do not recommend continuing to use MD5.

• SHA

Secure Hash Algorithm. SHA is divided into SHA1 and SH2 versions. The idea of this algorithm is to receive a plaintext segment and convert it into a segment (usually smaller) in an irreversible manner. It can also be simply understood as taking a string of input (called pre-image or information) and converting it into a shorter, fixed-length output sequence known as a hash value (also called a message digest or information authentication code).

• SM3

National secret algorithm SM3. Its encryption strength is similar to that of SHA-256. It is primarily supported by the state.

Conclusion:

In summary, in most cases, symmetric encryption is used, which provides good security. If key distribution is needed in a distributed manner, consider asymmetric encryption. If reversible computation is not required, then hash algorithms are suitable. As I have had some needs in this area recently, I have reviewed some materials on it. I have fallen into the information security field, and I hope I won’t have to buy shampoo in the future. Thank you all for reading!

There are still questions; if Sum denies giving Mike his public key and contract, he will be in trouble.

Therefore, it is necessary for Sum to have sufficient credibility regarding what he has done. This brings in the third-party credit service institution and certificate mechanism.

The credibility of a certificate is because the issuer of the certificate possesses credibility. Therefore, if Sum wants Mike to acknowledge his public key, he will not directly give the public key to Mike but will provide a certificate containing the public key issued by a third-party institution. If Mike also trusts this institution, and it is recognized by law, then the trust relationship is established.

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

By employing this mechanism, neither party can deny the contract. The core of this solution lies in the need for a third-party credit service institution to provide credit endorsement. This forms a basic trust chain; if the trust of the third-party institution collapses, such as being hacked, the entire trust chain will break.

To reinforce this trust chain, we need to create a longer trust chain that avoids single-point trust risks.

In the diagram, the root certificate authority with the highest credibility provides the root certificate, which then issues certificates for secondary institutions; the secondary institution issues certificates for tertiary institutions; finally, the tertiary institution issues Sum’s certificate.

To verify the legality of Sum’s certificate, the public key in the tertiary institution’s certificate must be used to decrypt the digital signature of Sum’s certificate.

To verify the legality of the tertiary institution’s certificate, the secondary institution’s certificate is used to decrypt the digital signature of the tertiary institution’s certificate.

To verify the legality of the secondary institution’s certificate, the root certificate is used to decrypt.

This forms a relatively long trust chain. If any party tries to cheat, it is very difficult unless all institutions in the chain collude to commit fraud.

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

Knowing the principle of man-in-the-middle attacks and their dangers, let’s see how to avoid them. I believe we have all encountered situations like the one below:

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

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

• Clients should not easily trust certificates: because these certificates may very likely be from a man-in-the-middle.

• Apps can pre-embed certificates locally: meaning we have some certificates in advance, so that other certificates cannot take effect.

7 DDoS

Based on the descriptions above, many types of attacks are essentially DDoS attacks, so let’s briefly summarize the related content of this attack.

In fact, major companies across the global internet have suffered from numerous DDoS attacks.

In 2018, GitHub experienced 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 GitHub was attacked, just a week later, DDoS attacks began targeting Google, Amazon, and even Pornhub, among other websites. Subsequent DDoS attack bandwidth also reached as high as 1Tbps.

What exactly is a DDoS attack?

DDoS stands for Distributed Denial of Service, which translates to 分布式拒绝服务. It refers to multiple attackers from different locations simultaneously attacking one or several targets, constituting a distributed, collaborative large-scale attack. A single DoS attack typically adopts a one-to-one approach, exploiting flaws in network protocols and operating systems, using deception and disguise strategies to conduct network attacks, flooding the website server with a large number of requests for replies, consuming network bandwidth or system resources, leading to network or system overload and ultimately paralyzing the service.

For instance,

I run a hotpot restaurant with fifty seats, and due to the high quality of the ingredients, I attract many customers, while the hotpot restaurant across the street has no customers. To deal with me, the owner of the other restaurant calls fifty people to sit in my restaurant without ordering, preventing other customers from eating.

The example above illustrates a typical DDoS attack, where the attacker uses “zombies” to send a large number of requests to the target website in a short time, massively consuming the target website’s host resources, rendering it unable to provide normal services. Industries such as online gaming and internet finance are particularly vulnerable to DDoS attacks.

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

Implementation principle of DDoS attack using SYN Flood

SYN Flood is an attack method that exploits the flaws in the TCP protocol by sending a large number of forged TCP connection requests to exhaust the resources of the attacked party (full CPU or insufficient memory).

Establishing a normal TCP connection requires a three-way handshake: the client sends a SYN packet, the server receives the request and returns a packet indicating acceptance, and the client returns a confirmation to complete the connection.

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

When a single user experiences an anomaly that causes a server thread to wait for a moment, it is not a big issue. However, if a malicious attacker simulates this situation on a large scale, the server ends up consuming a lot of resources to maintain tens of thousands of half-open connections, often neglecting normal customer requests and even crashing. From the perspective of normal customers, the website becomes unresponsive and inaccessible.

How to respond to DDoS attacks?

• High Defense Servers

Using the hotpot restaurant example, a high-defense server is like hiring two security guards to protect the restaurant from rogue disturbances and regularly patrol the vicinity to prevent harassment.

A high-defense server refers to a server capable of independently defending against over 50Gbps of attacks, helping websites resist denial of service attacks, regularly scanning the network’s main nodes, etc. This is a good solution but can be expensive.

• Blacklists

Faced with troublemakers in the restaurant, I might angrily take their photos and ban them from entering. However, sometimes people who look similar may also be barred. This is the principle of setting up a blacklist, which operates on the principle of “better to mistakenly ban a thousand than to let one through,” potentially blocking legitimate traffic and affecting normal business.

• DDoS Cleaning

DDoS cleaning is like noticing a customer who enters the restaurant but does not order for a few minutes, prompting me to kick them out.

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

• CDN Acceleration

CDN acceleration can be understood as moving my hotpot restaurant online for takeout services, making it difficult for troublemakers to locate the restaurant.

In reality, CDN services distribute website access traffic across various nodes, thereby hiding the website’s real IP address. Even when facing DDoS attacks, traffic can be distributed across multiple nodes to prevent the origin from crashing.

Conclusion

Computer networks involve many knowledge points, and this article has merely touched on them. A deeper understanding requires everyone to read relevant books. After reading this, when the interviewer asks about DDoS or TCP-related attack techniques, I hope you can provide answers. See you in the next article!