How NetGuard Works

Typically, DDoS attackers control numerous botnets (often called "zombie") to launch various attacks on the target server.

Regardless of the attack type, the goal is to disrupt communication between legitimate users and the app server.

We will discuss two common types of attacks and how NetGuard counters them.

Types of DDoS Attacks

UDP Amplification Attack

UDP is commonly used in network attacks because it doesn’t require a connection to send or receive data and can spoof source addresses.

Attackers spoof the victim server's address and send numerous queries to high-bandwidth servers with protocol flaws (e.g., DNS servers). These servers then send the query results to the victim’s server. The response size is often much larger than the request, allowing attackers to use relatively small bandwidth to launch large-scale attacks.

These attacks can consume bandwidth from tens of Gbps to hundreds of Gbps. Even if the victim’s server doesn’t have open ports, the data floods into the data center, potentially affecting all servers in the facility. To handle this, data centers often limit the defense capacity per server or IP, disconnecting the victim server once the limit is reached, until the attack subsides.

TCP Connection Attack

TCP requires a connection to send and receive data, and source addresses cannot be spoofed. Despite this, TCP attacks are still common.

Each TCP connection consumes CPU, memory, and network resources on the server, so the number of simultaneous connections a server can handle is limited. Attackers control numerous botnets to initiate TCP connections with the victim’s server. Sometimes, they keep these connections open without sending data; other times, they rapidly open and close connections.

In either case, this exhausts the server's resources, preventing legitimate users from connecting.

How NetGuard Works

Changing the Data Path

After integrating the NetGuard SDK, the data flow between your app and server is as follows:

1. The SDK starts and binds to a loopback IP address (e.g. 127.0.0.1).
2. The client connects directly to this loopback IP, not the App Server.
3. The SDK relays the data to the Forwarding Server.
4. The Forwarding Server relays the data to the Persistence Server.
5. The Persistence Server forwards the data to the App Server.
6. The Persistence Server receives data from the App Server
7. The Persistence Server sends data to the Forwarding Server.
8. The Forwarding Server sends the data to the NetGuard SDK.
9. The SDK forwards the data to the client App.

The Process Overview

Client App <--> NetGuard SDK <--> Forwarding Server (Gateway) <--> Persistence Server (Shield) <--> Developer's Server

Mathematical Techniques

Before attacking the target server, attackers must identify its IP address. Thus, the first step of NetGuard is to hide the real server IP.

In the NetGuard dashboard, you can add up to 30 forwarding server IP addresses. Developers need to deploy the forwarding server program on these IP addresses. When users start the app with the NetGuard SDK, the SDK fetches 4 IP addresses from the Defender's servers. This mathematical approach allows developers to create up to 27,405 unique IP address combinations.

$$C_{30}^4=\frac{30!}{4!(30-4)!}=27405$$

When attackers analyze the app, they only get one set of these IP addresses. Even if they manage to take down all IP addresses in this set, other users remain unaffected because they are assigned a different set of 4 IP addresses. Therefore, the affected user count is only ¹/_27,405 of the total.

Please Note

1. Only developers using Self-hosted Servers are subject to the 30 IP address limit
2. Developers who join the Shared Defense Plan are not subject to this restriction
3. Developers using Private Deployment of NetGuard are not subject to this restriction.

Maintaining User Sessions

NetGuard uses a customized protocol based on TCP. When a user disconnects from the server for any reason, NetGuard instantly selects another IP address from the 4 provided and continues data transmission from where it left off. This process is transparent to both developers and users; once the NetGuard SDK and servers are integrated, no additional actions are needed. Users can continue to send and receive data as usual.

Limiting TCP Connections

NetGuard's server can limit the number of concurrent TCP connections and connection frequency per IP address (or even per device) as needed, ensuring that a large volume of invalid TCP connections does not overwhelm the app server.

Please Note

Self-hosted servers can only limit concurrent connections per IP and device, not connection frequency

Next Steps

1. To save costs or avoid technical details, join our Shared Defense Plan.
2. To set up your own NetGuard server, read the Self-Hosted Server section.
3. If you’ve joined the Shared Defense Plan or Set up Your Own Server, integrate the NetGuard SDK.