Shield Your Site on a Budget: Simple DDoS Defense

Running a website or web‑app on a budget doesn’t mean you have to ignore security. Distributed Denial‑of‑Service (DDoS) attacks can cripple a site by flooding it with traffic, exhausting bandwidth, CPU, or memory. Enterprise‑grade mitigation services are expensive, but there are practical, low‑cost measures you can apply on a typical VPS or dedicated server to reduce the risk and impact of a DDoS attack.

1. Know the Threats You Face

Defence starts with understanding the attack vectors. The main categories are:

• Volumetric attacks – massive traffic floods that overwhelm network bandwidth (e.g., UDP floods, DNS amplification).
• Protocol attacks – exploit weaknesses in network protocols to exhaust server resources (e.g., SYN floods, fragmented packet attacks).
• Application‑layer attacks – mimic legitimate user behaviour to overload web‑server processes (e.g., HTTP GET/POST floods, slow‑loris).

Recognising the type of attack helps you choose the right combination of network‑level and application‑level defenses.

2. Harden the Network Edge with Free or Low‑Cost Services

Even a small budget can benefit from a CDN or DNS provider that includes basic DDoS protection in its free tier.

Use a CDN with Built‑In Mitigation

Providers such as Cloudflare, Fastly (free tier), and StackPath automatically filter traffic, rate‑limit HTTP requests, and block IPs with bad reputations. To use the service:

1. Change your domain’s nameservers to those supplied by the CDN.
2. When you suspect an attack, enable the “I’m under attack” mode to increase scrutiny.

Leverage DNS‑Level Rate Limiting

Some DNS services (e.g., Cloudflare, Google Cloud DNS) let you set query‑rate limits. This stops DNS‑amplification attacks before they reach your origin server.

3. Apply Server‑Side Rate Limiting and Connection Controls

Direct traffic can still reach the origin. Kernel‑level and web‑server limits absorb or drop malicious traffic early.

Linux Kernel Settings (Debian/Ubuntu)

# Edit /etc/sysctl.conf and add:
net.ipv4.tcp_syncookies = 1          # Protect against SYN floods
net.ipv4.tcp_max_syn_backlog = 2048  # Increase backlog queue size
net.ipv4.tcp_fin_timeout = 15        # Reduce time sockets stay in FIN_WAIT
net.ipv4.tcp_tw_reuse = 1            # Allow reuse of TIME_WAIT sockets
net.ipv4.ip_local_port_range = 1024 65535
net.core.somaxconn = 1024            # Max pending connections for listen()
net.core.netdev_max_backlog = 5000   # Max packets queued on the NIC
net.ipv4.icmp_echo_ignore_all = 1    # Optional: ignore ping floods

Apply the changes with sudo sysctl -p. Each line fine‑tunes TCP handling to make the kernel more resilient to connection‑flood attacks.

Linux Kernel Settings (AlmaLinux/Rocky/RHEL)

# Edit /etc/sysctl.conf and add the same lines as above
# Apply
sudo sysctl -p

The settings are identical across distributions; only the package manager differs when installing required tools.

Web‑Server Rate Limiting

Both NGINX and Apache can limit request rates per IP.

NGINX (Debian/Ubuntu)

# Install if missing
sudo apt update && sudo apt install nginx -y

# Add /etc/nginx/conf.d/ratelimit.conf
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    listen 80;
    location / {
        limit_req zone=mylimit burst=20 nodelay;
        proxy_pass http://localhost:8080;
    }
}

The limit_req_zone directive tracks requests per client IP, allowing 10 requests per second with a burst of 20. Adjust rate and burst to match normal traffic.

NGINX (AlmaLinux/Rocky/RHEL)

# Install
sudo dnf install nginx -y
sudo systemctl enable --now nginx

# Same configuration file as above

Apache (Debian/Ubuntu)

# Install
sudo apt update && sudo apt install apache2 -y

# Enable mod_ratelimit
sudo a2enmod ratelimit

# Add /etc/apache2/conf-available/ratelimit.conf

    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400


# Enable and reload
sudo a2enconf ratelimit
sudo systemctl reload apache2

This limits the output bandwidth per request, slowing abusive connections without dropping them outright.

Apache (AlmaLinux/Rocky/RHEL)

# Install
sudo dnf install httpd -y
sudo systemctl enable --now httpd

# Enable mod_ratelimit
sudo dnf install mod_ratelimit -y   # package name may vary

# Create /etc/httpd/conf.d/ratelimit.conf with the same directives

4. Deploy a Lightweight Application‑Layer Firewall

Tools such as ufw‑dos or iptables‑logging add extra checks without heavy resource usage.

Using ufw with Rate‑Limit Rules (Debian/Ubuntu)

# Install if missing
sudo apt install ufw -y

# Basic firewall policy
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH with rate limiting (6 connections per 30 seconds)
sudo ufw limit 22/tcp

# Allow HTTP/HTTPS with basic rate limiting
sudo ufw limit 80/tcp
sudo ufw limit 443/tcp

# Enable the firewall
sudo ufw enable

The limit rule permits up to 6 connections per 30 seconds from a single IP, helping block rapid connection bursts typical of DDoS tools.

Using firewalld with Rich Rules (AlmaLinux/Rocky/RHEL)

# Install firewalld if missing
sudo dnf install firewalld -y
sudo systemctl enable --now firewalld

# SSH rate limit
sudo firewall-cmd --permanent --add-rich-rule='
rule family="ipv4"
  service name="ssh"
  limit value="6/m"
  accept'

# HTTP/HTTPS rate limits
sudo firewall-cmd --permanent --add-rich-rule='
rule family="ipv4"
  service name="http"
  limit value="10/m"
  accept'

sudo firewall-cmd --permanent --add-rich-rule='
rule family="ipv4"
  service name="https"
  limit value="10/m"
  accept'

# Apply changes
sudo firewall-cmd --reload

Rich rules let you specify a connection rate directly in firewalld, providing comparable protection to ufw on RHEL‑based systems.

5. Monitor Traffic and Respond Quickly

Early detection gives you the chance to tighten controls before the attack escalates.

Basic Connection Monitoring

# Debian/Ubuntu
sudo apt install net-tools -y   # optional, provides netstat
watch -n 5 "ss -tn state ESTAB | wc -l"

# AlmaLinux/Rocky/RHEL
sudo dnf install net-tools -y
watch -n 5 "ss -tn state ESTAB | wc -l"

The watch command shows the number of established TCP connections every five seconds. A sudden spike may indicate an ongoing attack.

Real‑Time Log Analysis

Free tools like GoAccess turn logs into live dashboards.

# Debian/Ubuntu
sudo apt install goaccess -y
sudo goaccess /var/log/nginx/access.log --log-format=COMBINED --real-time-html -o /var/www/html/goaccess.html

# AlmaLinux/Rocky/RHEL
sudo dnf install goaccess -y
sudo goaccess /var/log/httpd/access_log --log-format=COMBINED --real-time-html -o /var/www/html/goaccess.html

Open the generated HTML page in a browser to spot abnormal patterns, such as a surge from a single IP range or repeated requests for a single resource.

6. Keep an Incident Response Plan

Technical controls are only part of the solution. A clear, rehearsed plan reduces downtime.

• Identify critical services – know which ports and processes must stay online.
• Document escalation steps – who contacts the ISP, who updates DNS, who informs customers.
• Backup firewall rules – store a copy of your iptables/ufw/firewalld configuration in a secure location.
• Test rate‑limit changes – simulate a burst with ab -n 1000 -c 100 http://yourdomain/ to verify legitimate traffic still passes.

A simple checklist can shave minutes off response time, which matters when an attack peaks.

Conclusion

Protecting a website from DDoS attacks doesn’t require an expensive enterprise service. By combining a free CDN, kernel‑level hardening, web‑server rate limiting, lightweight firewalls, and basic monitoring, you can build a layered defense that fits a tight budget. Apply the steps for your distribution—Debian/Ubuntu or AlmaLinux/Rocky/RHEL—review logs regularly, and keep an incident response plan ready. These practical measures make your site more resilient against common DDoS tactics while staying cost‑effective.