Preventing DDoS attacks is one of the main concerns of every server administrator and online business owner. A distributed denial of service (DDoS) attack saturates your virtual server's resources by sending massive amounts of spoofed traffic from thousands of different sources so that real users cannot access the service. In this guide, we will practically check what types of DDoS attacks are and what combination of server settings, firewalls and protection services can be used to resist them. If you need an infrastructure that is designed from the ground up for sustainability, you can start by buying a virtual server.

What is a DDoS attack and why is it dangerous?

In a DDoS attack, the attacker uses a network of infected devices (botnets) that can include computers, servers, and even Internet of Things devices. These devices simultaneously send traffic to the destination. Because the sources of attack are distributed and numerous, simply blocking an IP will not work.

Consequences of a successful attack include service outages, lost revenue, damage to brand reputation and, in some cases, increased bandwidth costs. That's why preventing DDoS attacks should be part of any organization's security strategy, not a post-attack reactive measure.

The important thing to understand is that the nature of defending against DDoS is different from other security threats. In most attacks, the attacker seeks intrusion and unauthorized access, but in DDoS, the goal is simply to make the service unavailable. An attacker doesn't necessarily break into your server, but by saturating resources, making it useless to real users. For this reason, defense requires a different approach, often based on capacity and scale.

A factor of concern in recent years is the easy availability of attack-for-hire services (called booters or stressers). These services allow anyone to launch an attack against a target for a small fee. This issue has made even small and medium-sized sites to be at risk, and preparation against DDoS is no longer reserved for large companies.

The main types of DDoS attacks

  • Volumetric attacks: such as UDP Flood and ICMP Flood, which aim to completely saturate the bandwidth and are measured in gigabits per second.
  • Protocol Attacks: such as SYN Flood that target server processing resources and network equipment by exploiting the weakness of protocols.
  • Application Layer Attacks: such as HTTP Flood, which analyze web server and database resources with seemingly valid requests and are more difficult to detect.

The first layer of DDoS attack prevention: OS-level hardening

Before investing in expensive services, you can increase the basic resistance of the server with Linux kernel settings. These settings are especially effective against small and medium attacks. Edit the /etc/sysctl.conf file and add the following values:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1

Then apply the changes:

sudo sysctl -p

The tcp_syncookies option is one of the most important defenses against SYN Flood attacks; With it enabled, the server can handle half-open connections without consuming resources, and the connection queue is prevented from filling up.

Limiting the connection rate with iptables

You can limit the number of simultaneous connections from each IP so that one resource cannot saturate the server:

sudo iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
sudo iptables -A INPUT -p tcp --dport 80 --syn -m limit --limit 20/second -j ACCEPT

These rules block too many connections from a single IP and limit the rate of new SYN requests.

Warning: OS-level settings are only effective against small to moderate attacks. If the volume of the attack exceeds the bandwidth capacity of your server (for example, several gigabits per second), no internal adjustment can save you, because the network link itself will be saturated. In this case, you need protection at the network level.

Use of CDN and anti-DDoS services

The most effective way to prevent large DDoS attacks is to put a layer of protection between your users and your main server. Content distribution networks (CDNs) and anti-DDoS services such as Cloudflare or ArvanCloud with very high bandwidth capacity capture and filter malicious traffic at the edge of their network and deliver only clean traffic to your server.

Advantages of CDN based architecture

  • Hiding the main IP of the server: The attacker only sees the IP of the CDN network and cannot attack the server directly.
  • Huge absorption capacity: Large networks have terabits per second capacity and neutralize volume attacks.
  • Application layer filter: With WAF rules and browser challenges, bots are separated from real users.
  • Content Cache: Load static requests off the main server.
Important security tip: After placing the server behind the CDN, be sure to set the firewall to accept only traffic from the IP range of that CDN on ports 80 and 443. Otherwise, by finding the real IP, the attacker can bypass the CDN and attack directly.

Protection at the web server level

Against application layer attacks (such as HTTP Flood), web server settings are very important. In Nginx, you can limit the request rate with the limit_req module. In the http block of the configuration file, add:

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

Then apply it in the desired location block:

location / {
    limit_req zone=one burst=20 nodelay;
    limit_conn addr 10;
}

This setting allows each IP to have an average of 10 requests per second with the possibility of bursts of up to 20 requests and rejects excessive requests.

Use Fail2ban for malicious patterns

You can configure Fail2ban to block IPs with a high number of 4xx error requests or suspicious patterns in the Nginx log. This tool is a good complement to the application layer defense and automatically blocks Egyptian attackers.

Using Web Application Firewall (WAF)

A Web Application Firewall is a layer that analyzes HTTP requests before they reach your application and filters malicious or suspicious requests. Tools like ModSecurity can be installed on Nginx or Apache and with ready-made rule sets (such as OWASP Core Rule Set), identify and block many application layer attack patterns. WAF is particularly effective against HTTP Flood attacks made with seemingly valid requests, as it can detect unusual behavior such as missing cookies, invalid headers, or abnormal request rates.

The role of the infrastructure provider in DDoS defense

One of the determining factors in your resistance to attacks is the virtual server provider. Professional providers usually have implemented filtering and attack absorption mechanisms at their network level, which are activated before malicious traffic reaches your server. When choosing a server, consider the following:

  • Upstream network capacity: The greater the bandwidth of the data center, the higher the ability to absorb volume attacks.
  • Existence of automatic attack detection and mitigation system: which detects and filters abnormal traffic.
  • Fast and Responsive Support: At the moment of attack, the speed of response of the support team is critical.
  • Possibility to change or hide IP: For when the server IP is the target of a direct attack.

In many cases, working with a provider in a moment of crisis can mean the difference between minutes and hours of downtime. That's why choosing a reliable provider is part of your defense strategy.

Monitoring and early detection of attacks

Quick detection of an attack is half the defense. The sooner you notice, the quicker you can react. The following tools are useful for real-time traffic monitoring:

sudo apt install iftop nload -y
sudo iftop -i eth0
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

The last command displays the number of connections by IP; If one or more IPs have an unusually high number of connections, this is a possible sign of an attack.

Table of warning signs of a DDoS attack

signPossible interpretation
Sudden and extreme slowness of the siteResource or bandwidth saturation
Sudden increase in bandwidth consumptionPossible volume attack
High number of connections from unknown IPsBotnet activity
Increase in 5xx web server errorsServer processing saturation
High CPU usage for no apparent reasonApplication layer attack

Program optimization for more resistance

An optimized and lightweight application is naturally more resistant to application layer attacks. The less resources each request consumes, the more requests your server can handle before it becomes saturated. Some key actions in this regard are:

  • Using cache: By caching frequent pages and queries (eg with Redis or Varnish), the database load is greatly reduced.
  • Optimization of database queries: Heavy and unindexed queries are weak points that an attacker can repeat and crash the server.
  • Limit high traffic: Protect processing-heavy pages like search or login with stricter rate limiting.
  • Serve static content from CDN: so that requests for images and files never reach the main server.

In addition to improving attack resistance, these measures also improve the speed and user experience of the site in normal conditions, so investing in them is worthwhile in every way.

Resource management and scalability

One way to deal with attacks is to be able to quickly scale resources. If your infrastructure allows for a temporary increase in resources (such as CPU, RAM, and bandwidth) during an attack, you can increase the traffic capacity to neutralize the attack. Of course, this approach should be used with caution, because in very large attacks it may cause heavy costs. For this reason, combining scalability with malicious traffic filtering is a smarter approach.

Incident response and debriefing plan

No solution is 100%, so you should have a plan ready for when an attack occurs. This plan should include: identifying the type of attack, enabling CDN protection mode, contacting server provider support to enable network filtering, and notifying users if necessary.

It is also recommended to designate a specific team and person responsible for the response before an attack occurs, and have the necessary contact numbers (provider support, CDN service and technical authorities) available. In a moment of crisis, every minute counts and having this information ready can greatly reduce recovery time. Periodic practice of attack scenarios will also help your team not get confused in real situations.

Preventing DDoS attacks is a multi-layered approach: combining operating system hardening, web server rate limiting, using a powerful CDN, and continuous monitoring will greatly increase your server's resilience. It is important to understand that defending against very large attacks is practically impossible without the help of specialized infrastructure and service providers. To learn more about security topics, read other Rapido Server articles.

Frequently asked questions

Can I prevent DDoS attacks without an external service?

For small to medium attacks, OS and web server level settings can be effective. But for high-volume attacks that saturate the server's bandwidth, you'll need a high-capacity anti-DDoS service or CDN, because the problem happens before it reaches your server.

What is the difference between DoS and DDoS?

A DoS attack comes from a single source and is relatively simple to counter by blocking the same IP. But DDoS comes from thousands of distributed sources (botnets), and this distribution makes countering much more difficult because not all sources can be easily blocked.

Is a firewall alone enough to prevent DDoS?

A firewall is part of the defense, but it is not enough by itself. A firewall can block some patterns, but it is powerless against volume attacks that fill the network link itself. Effective defense requires a combination of firewalls, rate limiting, and network-level protection.

How do I know if my server is under DDoS attack?

Common symptoms include sudden and extreme slowness of service, explosive increase in bandwidth consumption, very high number of connections from unknown IPs and increase in server errors. You can confirm this by using tools like iftop and checking the number of connections with netstat.