How to Stop a DDoS Attack: Complete Defense Guide for Linux Servers

Anatomy of an attack: What are you facing?

Before discussing how to block a DDoS attack, it is critical to understand that not all attacks are the same. A DDoS attack aims to overwhelm server, network, or application resources by flooding them with fake traffic from multiple compromised devices (botnets).

We can classify threats into three main categories:

• Volumetric Attacks (Layer 3/4):They aim to saturate bandwidth. Common examples are UDP Floods and DNS Amplification. Here, the amount of data is the weapon.
• Protocol Attacks (Layer 3/4): They exploit weaknesses in TCP/IP protocols. The most notorious is the SYN Flood, which exhausts server resources by leaving "open" connections waiting.
• Application Attacks (Layer 7): The most insidious. They look like legitimate traffic (HTTP GET/POST requests) but aim to exhaust CPU and RAM by making the server work on heavy requests. Examples: HTTP Flood and Slowloris.

Detection: How to Identify a DDoS Attack on Linux

The first step in stopping an attack is to recognize it early. Often, the first signs are unexplained slowdowns, 503 (Service Unavailable) errors, or a sudden spike in CPU load.

On a Linux server, you can use CLI tools to diagnose the situation in real time:

• htop: To monitor CPU load and processes.
• netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n: To count connections by IP address and detect "top talkers".
• tcpdump: To analyze network packets and identify abnormal patterns (e.g., suspicious UDP packets or SYNs without ACKs).
• Log Analysis: Check access logs (Apache/Nginx) for suspicious User-Agents or repetitive requests to a single endpoint.

Kernel-Hardening: The first line of defense

By default, Linux distributions are configured for compatibility, not for resisting a siege. By modifying the kernel parameters via sysctl, we can make the TCP/IP stack much more robust, especially against SYN Floods.

Here are some key directives to include in /etc/sysctl.conf:

# Enable SYN Cookies to prevent socket exhaustion.
net.ipv4.tcp_syncookies = 1

# Protection against IP Spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Reduce the waiting time for FIN (connection closure) packets.
net.ipv4.tcp_fin_timeout = 15

# Increase the queue of incoming connections (backlog).
net.core.netdev_max_backlog = 2000        

To delve deeper into kernel parameters, the official documentation of Linux Kernel Networking is the definitive resource.

Application-Level Defense: Configuring Nginx

Layer 7 attacks are difficult to block with a traditional firewall because they use valid TCP connections. This is where the Web Server comes in. Nginx, due to its event-driven architecture, is excellent at handling (and discarding) massive traffic.

1. Rate Limiting)

This technique limits the number of requests a single IP can make in a second. It is effective against scraping or brute-force bots. Add this in the http block of your nginx.conf:

limit_req_zone $binary_remote_addr zone=ddos_limit:10m rate=10r/s;

server {
    location / {
        # burst=20 handles natural peaks, nodelay processes immediately without waiting
        limit_req zone=ddos_limit burst=20 nodelay;
        limit_req_status 429; # Too Many Requests
    }
}        

2. Limit Aggressive Connections and Timeouts

To combat slow attacks like Slowloris, we need to tell Nginx to close connections that don't send data quickly.

server {
    # Limit simultaneous connections per IP.
    limit_conn_zone $binary_remote_addr zone=addr_conn:10m;
    limit_conn addr_conn 10;

    # Aggressive timeouts to close "slow" connections.
    client_body_timeout 10s;
    client_header_timeout 10s;
}

Firewalls and Routers: Network-Level Protection

At the server level, tools such as iptables or the more modern nftables are essential for filtering unwanted traffic. However, manual rule management during an attack is complex.

We recommend using tools such as Fail2Ban or CrowdSec. These tools scan logs in real time and dynamically update firewall rules to ban IPs that exhibit malicious behavior.

Critical Note on the Router:If the volumetric attack exceeds your bandwidth capacity (e.g., you receive 10Gbps on a 1Gbps line), no configuration on the server will be able to save you. The "pipe" is full. In this case, you have to intervene upstream, at the ISP or Router level, by requesting a Blackhole Routing (null routing) for the attacked IP, but sacrificing the reachability of that IP.

When On-Premise is not enough: Cloud and Hybrid Solutions

For massive or globally distributed attacks, the only real solution is to absorb the traffic through immense networks. Services such as Cloudflare, Akamai or AWS Shield act as a shield.

These services use Anycast networks to spread traffic across global data centers, mitigating the attack before it reaches your server. A best practice is to configure your Linux server's firewall to accept only traffic from your CDN provider's IPs, thus hiding your "Origin IP" from attackers.

Frequently Asked Questions (FAQ)

Is it possible to "reverse" (reverse) a DDoS attack against the hacker?

Technically no, and legally it is not recommended. Attempting to "hack back" is illegal. The correct strategy is to mitigate the attack and report the IPs to the appropriate authorities or ISPs.

How long does a DDoS attack usually last?

The duration is variable. It can range from a few minutes (to test defenses) to days at a time. Most modern attacks are short but intense (burst attacks).

How do I stop a DDoS attack on my home or business router?

If the attack saturates bandwidth, the only effective action is to contact your Internet Service Provider (ISP) to request upstream filtering or change your public IP address.

Are there tools to mitigate DDoS automatically?

Yes, software such as Fail2Ban (local) or services such as Cloudflare (cloud) automate blocking. However, a manual tuning configuration is often necessary to avoid false positives.