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 Flow

Once the NetGuard SDK is integrated, traffic between your app and your server is rerouted through the following components:

How The Data Flows

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

1. The SDK starts and binds to a loopback address (e.g., 127.0.0.1).
2. The app connects to the loopback address.
3. The SDK forwards traffic to the Forwarding Server.
4. The Forwarding Server forwards traffic to the Persistence Server.
5. The Persistence Server forwards traffic to the App Server.
6. The App Server forwards traffic to the Persistence Server.
7. The Persistence Server forwards traffic to the Forwarding Server.
8. The Forwarding Server forwards traffic to the SDK.
9. The SDK forwards traffic to the app.

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 $\frac{1}{27405}$ of the total.

Please Note

1. Only developers using Self-hosted Defence are subject to the 30 IP address limit
2. 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 Defence can only limit concurrent connections per IP and device, not connection frequency

Next Steps

• To protect your privacy or offer DDoS protection to others, choose Private Deployment.
• You can also Build Your Own Defence if you have sufficient funds and experience.
• Read the Developer Documentation to integrate the NetGuard SDK.